En Digg referencian un artículo de Kurt Cagle titulado “Will AJAX Replace Java and .NET?“.

Para empezar, el título se las trae y mucho. ¿Sirven AJAX, Java y .NET para lo mismo? Ni por asomo. ¿Entonces por qué mezclar en un titular así estos tres conceptos? Mi opinión: porque es cool y porque pregonar que AJAX es la “next big thing” es garantía de tráfico en la blogosfera. Valga como muestra el que haya llegado a la portada de digg.

Leer el artículo es difícil, sobre todo porque no se entiende a donde quiere llegar el autor.

Regardless of whether that is in fact true, what AJAX has done in the space of the last few years has been to set into motion what looks to be a major, perhaps even tectonic, shift in the way that we build applications, providing the necessary critical link to turn Services Oriented Architectures (SOAs) from being a convenient marketing term into being something far more significant.

Aún admitiendo que AJAX hubiera revolucionado la forma en que desarrollamos aplicaciones (aceptamos pulpo) el pensar que SOA es sólo una palabra marketiniana y que va a materializarse con la llegada de AJAX, sólo demuestra que el autor desconoce SOA. Es un argumento tan absurdo que no vale la pena ni intentar rebatirlo. Además el autor debería explicar cómo AJAX es capaz de interactuar con aplicaciones empresariales a nivel de servidor.

Luego ya podríamos entrar en otros temas -ganas de complicarse la vida que tiene uno- tan banales como entornos de desarrollo para “programar” en AJAX, estandarización de las plataformas, soporte, formación, seguridad, escalabilidad, y demás trivialidades que el autor parece obviar.

One of the critical problems that I felt with the direction of Web Services initially (and through to its now politically more correct SOA incarnation) has been that they have not in fact been very friendly to the one area where they would seem most logical - the web.

WebServices no es lo mismo que SOA. SOA no es una forma políticamente correcta de llamar a los WebServices. ¿Qué mezcla de conceptos es ésta? A partir de ahí el autor se enfrasca en una incoherente queja sobre el uso que se le ha dado a SOA por parte de las empresas. Lo siento, he leído varias veces el texto y aún no entiendo qué es lo que quiere transmitir.

I’d rather not use a photoshop-esque program over the web, for instance, because while you could do a pretty fair job writing one in AJAX, the things that make Photoshop powerful - its wide array of filters, masks, actions and so forth would prove to be both hideously difficult to accomplish in a pure web interface and very inefficient if using something like Javascript.

Aquí el autor se contradice. Si AJAX va a reemplazar a Java o a .NET, ¿por qué no puedo utilizar un “Photoshop” escrito en AJAX? ¿Porque sería difícil emular funcionalidades y altamente ineficiente? ¿Entonces en qué quedamos? ¿O es que las aplicaciones empresariales no son igualmente exigentes?

Yet on the flipside, think about most enterprise level applications. Web page design and content is becoming increasingly easy to do within a web browser context, and it is a surprisingly small step from there to building a fully functional document editor (with an open XML standard underlying it of course). Spreadsheets are declarative, and could readily be handled by utilizing some of the capabilities of XForms (indeed, I think that the true killer XForms editor app is going to look a lot more like Excel than it will Visual Basic). Flash already produces far better “slideshows” than Powerpoint and I think that the CMS aspects of XML driven slideshows utilizing SVG will likely be the final nail in the slideshow coffin. Ditto for graphical symbol manipulation programs such as Visio being replaced by browser based SVG that is generally much more lightweight, doesn’t require a specialized runtime beyond that necessary to display the SVG, and that creates truly powerful, metadata rich graphics.

Por partes, primero, en las aplicaciones empresariales, y entendamos empresa en su concepto más amplio, y los procesos que en ella se realizan igualmente, lo más común no es el diseño de páginas web o la gestión de contenidos. Sustituir OpenOffice o Microsoft Office por editores de textos en web es altamente cuestionable (algún día quiero escribir sobre ese tema). Sustituir Excel por una aplicación XForms a día de hoy me parece más cuestionable aún. Puede ser que Flash sea más “mono” y produzca mejores presentaciones, pero dígale al directivo o al mando intermedio que abandone PowerPoint y que escriba sus presentaciones en Flash. Y lo mismo aplica para que SVG reemplace a Visio.

Seamos serios: hay que tocar suelo. La teoría es muy bonita pero hay que llevarla a la práctica. Y si lo que expone el autor es cierto, lo que falta son herramientas de verdad que me permitan escribir un documento de verdad vía web, hacer una hoja de cálculo de verdad vía web, hacer una presentación de verdad con Flash, etc. Si eso no existe, lo único que estamos haciendo es calentar la cabeza a la gente, vendiendo humo en cantidades industriales, y generando expectativas difíciles de cumplir.

Beyond the office suite camp, most enterprise-oriented applications are already moving to the web, but typically the story being sold is that while there are advantages to having the presentation layer be dynamically generated HTML or XHTML or even SVG, for middle-tier applications, Java or ASP.NET are far superior to poor old Javascript on the client. Curiously enough, though, even this conventional wisdom is beginning to be challenged. Part of the reason for this has to do with a significant shift in where business logic resides. In the Enterprise Java space (through much of J2EE) one of the central concepts has been that the business logic should be handled via binary components because of the inherent efficiency of compiled components.

Cierto, las aplicaciones empresariales se están “trasladando” a la web. Y la eficiencia es una característica que buscamos en las aplicaciones que se exponen en la web. Pero no sólo esa. Si AJAX no se usa en ese ámbito no es por la clásica discusión entre código compilado vs código interpretado. Es porque AJAX no cubre ni de lejos las áreas que se cubren con Java o .NET. Hablemos de acceso a datos, seguridad, encriptación, gestión de XML, protocolos de comunicaciones, etc. No se puede obviar todo tan a la ligera.

Java does not necessarily completely disappear, but its role is increasingly relegated to running the XSLT transformers, filter engines, and socket level communications. This isn’t because of the inherent flaws of Java as a computer language - its because XML essentially pushes the level of abstraction up at least a notch, and in such an abstract world you can far more effectively separate model, processing and presentation than you could a generation earlier.

Más de lo mismo: Java no tiene por qué desaparecer completamente. ¿En qué quedamos? ¿Reemplazamos Java o no? Las limitaciones de AJAX, más bien de Javascript, para gestionar protocolos de comunicaciones, XML, etc. están ahí. O se resuelven o no hay mucho que hacer.

En resumen: el autor hace una mezcla de conceptos realmente escalofriante.

La conclusión del autor: no he acabado de descubrirla. Si alguien la averigua que lo escriba en los comentarios.

Lo peor: que alguien crea que realmente AJAX sustituye a Java. Apañados vamos.