La amansadora .Net

Allá lejos y hace tiempo, creo que por el año 2001 (tiro de memoria) Microsoft lanzaba la séptima versión mayor del Visual Studio (el primer “puntonet”) y con ella prometía llevar a los desarrolladores “de aplicaciones de escritorio” al mundo de las “aplicaciones web”.

Yo (supongo que junto a muchos otros), que venía desarrollando “aplicaciones web” de gestión en ASP 3.0, me sorprendí gratamente con el chiche nuevo que me permitía (entre otras cosas) separar fácilmente el código de la presentación (aunque nada me lo impedía antes) y crear clientes en HTML “como si fueran formularios de Windows”, con controles, eventos y todo eso.

Lleno de entusiasmo, empecé a tirar controles sobre el diseñador y a escribir código para los eventos. Casi lloro al apretar F5 y ver a la aplicación levantarse mágicamente en un servidor local lista para depurar paso a paso, “como si fuera un formulario” (también se podía antes, pero había toda una burocracia previa). Todo parecía fácil y natural.

Pero el sueño dorado se convirtió en una terrible pesadilla cuando, apenas superadas las primeras pruebas triviales, conocí a dos horrendas criaturas, dos verdaderos abortos de la naturaleza: Postback y su deforme hermano siamés, Viewstate.

Postback envía toda la información contenida en la página al servidor, obligándola a recrearse constantemente una y otra vez para acometer desde la más compleja a la más trivial de las tareas: cambiar el color de una etiqueta, mostrar un mensaje de error de validación, lo que sea. Para eso necesita a su inseparable hermano Viewstate, que almacena… muchas cosas, un montón de cosas, todas las cosas. Creo que en el Viewstate de una página ASP.Net “creada como un formulario de Windows” se encuentra el sentido de la vida, el universo y todo lo demás, pero que es inhallable.

Metiéndome un poco más en la cosa, empecé a darme cuenta de lo que Microsoft había hecho para “facilitar las cosas” en el desarrollo web. No había magia detrás de todo ello sino un conjunto de complicadísimos y muy poco elegantes hacks que hacían de aquello tan fácil y divertido llamado HTML+Javascript un verdadero infierno.

XMLHttpRequest y esa gran bolsa de gatos llamada Ajax ya era utilizada por los sitios más modernosos dando origen a las RIA's y se perfilaba como el estándar que un usuario final más o menos exigente esperaría de allí en más. Yo lo había utilizado bastante, de una manera muy rudimentaria pero con muy buenos resultados (visuales, que por adentro, ¡madre mía!). Al querer combinarlo con el modelo propuesto por ASP.NET me metí en verdadero laberinto. Si antes las cosas me parecían desprolijas ahora se me hacían imposibles.

Un (largo) tiempo después apareció Atlas… baste decir que me cuesta (y desisto de) encontrar una referencia a esas primeras versiones de… lo que sea que haya querido ser (¿herramienta? ¿plantilla? ¿paradigma? ¿framework? ¿manotón de ahogado?). Lo que es seguro es que resultó otro conjunto de engendros mutantes a los que Microsoft les dio temprana y prolija sepultura (cambiándole el nombre, como suele hacer). Pero puedo resumirlo fácilmente: no era otra cosa que Postback y Viewstate (y otro ejército de hacks berretas) actuando en las sombras para no asustar al desarrollador con su horrible refrescado en cámara lenta.

Creo que me gané el derecho a adjetivar a esa visión del desarrollo de una aplicación web (tirar controles a un diseñador y codificar eventos) como “un verdadero desastre”, una obra maestra en hacer difícil lo fácil e imposible lo (no muy) complejo. Derecho que me gané (y ahora ejerzo) por haberlo intentado seriamente. Realmente intenté (Rick Hunter es testigo) desarrollar una aplicación web razonable siguiendo ese modelo. Y fracasé, una y otra vez. Tal vez soy yo, tal vez no le encontré la vuelta, pero así fue.

Fue hora de separar los tantos: el Framework .Net, desde su primera versión, fue y es una herramienta fabulosa que mejora en cada versión, eso que quede claro. Pero esa no era la forma de utilizarla, por más que su creador la fomentara.

Una vez alejado del camino oficial marcado por una visión que pretende que desarrollar una aplicación web es lo mismo que desarrollar una de escritorio^* (y guiado por Rick Hunter, que ya se había apartado de ella hacía tiempo), todo fue “casi” sencillo (eso fue irónico, pero de todas maneras valió la pena).

Primero hubo que encerrar a Viewstate (suprimiéndolo) en una página base de la que derivan todas las demás y en las que utilizamos controles controles propios que producen HTML sencillo y como Dios manda. Luego combinar con un framework de Javascript (puede ser propio o alguno de los tantos que circulan por allí) para enviar sólo lo necesario de vuelta al servidor e incrustar los datos (o el HTML, o las dos cosas, ¿por qué no?) elegantemente en la página, sin generarla nuevamente.

Es decir que terminé haciendo lo de antes, lo mismo que hacía (desprolijamente) en ASP 3.0: producir el HTML una sola vez y luego ingresar, validar, actualizar y modificar la página con Javascript (validar en Javascript es opcional –aunque muy recomendable-, que las validaciones tienen que estar del lado del servidor sí o sí, por supuesto).

Lo de antes, sí, pero ahora con herramientas (el Framework .Net) que permiten hacer más fácilmente una implementación rápida y prolija y con mucha reutilización. Después de haber superado, claro, la amansadora .NET.

---

^* Acerca de eso de “desarrollar una aplicación web no es lo mismo que desarrollar una de escritorio”… puede ser que con XAML y Silverlight Microsoft haya encontrado un camino para unificar las herramientas de desarrollo, aunque todavía le falte mucho. Por otro lado, está más que demostrado que con Javascript también se pueden crear interfaces complejas sin perder agilidad (en cualquier navegador que no sea el Internet Explorer, claro) y sin la molestia adicional de instalar algo en el cliente, con lo que… ¿podríamos decir que en algún punto compite con Silverlight…?