05 julio 2005

En camisas de once varas

Siempre he sido desarrollador en Windows. Nunca me ha gustado demasiado, nunca me he sentido demasiado cómodo programando para la Web. Y sin embargo poco puedo hacer al respecto: el paradigma Web es algo que nos lleva invadiendo mucho tiempo y del que no se ve una salida cercana, a pesar de la innegable presencia y las numerosas ventajas de los smart clients.

El caso es que ahora mismo estoy metido, cómo no, en un proyecto ASP .NET, en C#. Y, claro, está implementado mediante el sagrado patrón MVC, o Modelo-vista-controlador; más presente en el panorama tecnológico actual que un crucifijo en una iglesia. Y es que en el fondo los programadores somos criaturitas de costumbres, y cuando nos dicen que algo funciona, lo usamos. A piñón, haga o no haga falta, existan o no soluciones mejores.

¿O quizás serán los gerentes, esas personas generalmente sin background técnico pero con capacidad de decisión, los que realmente imponen estas cosas? ¿Será posible que nos dejemos enmarronar en cacaos cada vez más esotéricos sencillamente porque los que mandan han leído algo al respecto y les ha gustado el nombre, como tanto gustan de workflows, know-hows, sinergias y demás giliflauteces? Naaaaahhh...

El caso es que ojo, no estoy despotricando contra el MVC, que es un patrón que me gusta. Pero tendréis que admitir que para según qué proyectos es uno de los mejores ejemplos de la vieja y refinada táctica militar de matar moscas a cañonazos. Y las cosas empeoran cuando los clientes están migrando una antigua aplicación de escritorio y quieren, claro, que su nueva y flamante aplicación Web tenga como mínimo las mismas capacidades y funcione de forma muy similar para que la transición sea menor. Y así pasa lo que pasa, que nos encontramos proyectos J2EE con páginas web diseñadas calcando las botoneras, y las cajas de texto y las reglas de interfaz de una vieja aplicación Visual Basic. Y el aborto resultante, repletito de líneas y más líneas de JavaScript de lado de cliente para emular esa funcionalidad, termina por ser una hidra inmanejable.

Es lo que pasa con las medias tintas: tenemos que hacer una aplicación web para que cualquiera pueda acceder sin instalarse nada, sea fácilmente manejable y se pueda actualizar el código sin que los usuarios tengan que reinstalarse n versiones del aplicativo. Pero es que además queremos que sea tan manejable como nuestra vieja aplicación para escritorio, y que muestre muchos mensajitos, y que cargue documentos del lado del cliente, y si me apuráis hasta que cambie el registro de Windows del lado del cliente. Y no se puede: como dice mi madre, o se está en la misa o se está en la procesión.

Hay que elegir. ¿Queremos una aplicación web con las obvias ventajas que representa? Apechugemos con los inconvenientes que también (e innegablemente) tiene, a pesar de la moda del momento. Y diseñemos una aplicación web como se debe, atendiendo a la usabilidad de un interfaz mucho más limitado hoy por hoy que el de una aplicación de escritorio.

Y si no queremos renunciar a esa usabilidad, deberemos seguir creando aplicaciones de escritorio, pero aprovechando las posibilidades actuales que se nos brindan, como las actualizaciones automáticas del software de escritorio. Que, siempre bajo mi muy subjetivo, prejuiciado y seguramente equivocado punto de vista, era en lo único que las aplicaciones web superaban a las de escritorio: la capacidad de que las actualizaciones de software fueran distribuidas automáticamente y de forma transparente al usuario.

En fin, volviendo al argumento inicial, he estado investigando un poco y he encontrado un par de enlaces interesantes. Ya había trabajado con el MVC en J2EE, con lo cual no me pilla completamente de nuevas, pero nunca había trabajado con MVC en .NET. Y aquí he encontrado un artículo de Microsoft con un ejemplo sencillito al respecto. Curioseando un poco más, encuentro un framework para MVC en .NET: es un port de uno ya existente para Java (otro port más) llamado Maverick .NET. Una de las gracias que tiene, bajo mi punto de vista, es que puedes independizarte completamente de las páginas ASPX y sus controles de servidor y generar las vistas mediante transformaciones XSLT de datos XML generados por el controlador, lo que permite que el navegador cargue sencillamente HTML. Lo mismo que hacía en J2EE.

4 Comments:

  • Mira tú que guasa. Llevo ya 6 años (seis) programando aplicaciones con ASP y sustituyendo todas las aplicaciones previas (algunas en VB 4) por sus equivalentes en navegador y te puedo decir que los usuarios están mucho más contentos y el sistema es más rápido y escalable. El truco es diseñar cada aplicación desde cero y no hacer un calco de lo anterior. Yo siempre me he negado a hacer calcos. Hago borrón y cuenta nueva. Se habla con los usuarios, se les pregunta qué necesitan y cuando se enteran que la aplicación va a ser nueva se vuelven locos de alegría y empiezan a aportar modificaciones e ideas A SACO. Se hace una aplicación nueva en función de sus necesidades definiendo pantalla a pantalla y menú a menú y todo el mundo contento. Ellos y yo.

    Mis quejas son para el ASP NET. Eso sí que me parece matar moscas a cañonazos. Con el ASP 3 las aplicaciones van como un tiro. Sus equivalentes NET son paquidermos con modorra.

    By Blogger Jomaweb, at 11:50 a. m.  

  • Evidentemente, si las cosas se hacen bien quedan mejor. Eso es parte de lo que defiendo en este post: que si tienes que adaptar y presumiblemente expandir la funcionalidad de un software antiguo adaptes eso, la funcionalidad pero teniendo muy en cuenta que la usabilidad de una aplicación web es radicalmente distinta a la de una de escritorio. En eso no vamos a discutir. Pero es que he visto cosas durante mi etapa J2EE que no creerías...

    Y sí, mis quejas son también para ASP .NET, al menos el 1.1. Está cogido con pinzas, y hace mogollón de extraños: ficheros web.config que se desconfiguran solos, cambios en la página ASPX que no se refrescan adecuadamente en el code-behind, reinicios (o directamente reinstalaciones) de IIS 5, etc... espero francamente que con ASP .NET 2, Cassini y todo lo demás las cosas cambien, y mucho.

    A no ser, claro, que esta sea una (otra) maquiavélica práctica de MS para que nos desesperemos y dejemos la web por imposible, abrazando los smart clients... :P

    By Blogger CodeCruncher, at 9:15 p. m.  

  • Sobre las ventajas de una aplicación web sobre una de escritorio, yo añadiría que son accesibles desde cualquier equipo con conexión a la red en la que trabaja la aplicación (sea internet o una local), sin necesidad de instalar nada.

    Ojo, que a mí también me gustan más las aplicaciones de escritorio, pero reconozco las ventajas de las aplicaciones web.

    By Blogger Jaime Irurzun, at 5:07 p. m.  

  • Pero es lo que digo, Jaime, que con una buena aplicación que se auto-actualice desde un servidor central (y que compruebe si necesita autoactualizarse cada vez que se arranca, como tantas y tantas que hay ya en el mercado) y una buena configuración del sistema, la ventaja (innegable) de las auto-actualizaciones en las aplicaciones web desaparece por completo. Evidentemente, siempre habrá que hacer una primera instalación,... pero sólo ésa.

    By Blogger CodeCruncher, at 11:51 a. m.  

Publicar un comentario

<< Home