2007-02-16

Los lenguajes de la web

Para programar páginas web hay que aprender unas cuantas cosas. En particular es llamativa la cantidad de lenguajes que hay que aprender:

  1. HTML
  2. JavaScript
  3. CSS
  4. XML
  5. XPath
  6. CSS selectors
  7. Javascript
  8. Lenguaje y bibliotecas server side de tu preferencia (Ruby on Rails, PHP, Perl, Java, JSP, EJBs, ASP.NET, etc)
  9. SQL?
Sin embargo, la mayoría de estas cosas son carga cognitiva al dope. Es mi opinión que el desarrollo web se simplificaría bastante ordenando este quilombo.

En primer lugar, en vez de usar HTML, se podría usar una biblioteca en JavaScript para generarlo (algo como markaby pero hecho en JavaScript). Esto haría que sea más fácil generar dinamismo en el cliente.

Los CSSs deberían ser una biblioteca que encaja con la biblioteca anterior. Si quieren separar los datos para que los maneje un diseñador, podría perfectamente usarse JSON.

El XML es 100% reemplazable por JSON (que, es más lindo para escribir datos y todo). JSON (y javascript) es lo que usan varias bibliotecas de AJAX (ATLAS, prototype) para comunicar cambios en la página.

XPath puede llegar a ser algo práctico, pero solamente para navegar por árboles de objectos (no XML). Quizás una biblioteca para buscar cosas en JSON con sintáxis parecida estaría buena.

Los CSS selectors son una creación abominable. No aportan nada al XPATH, pero como están en los archivos de estilo, no queda otra que usarlos.

Con respecto al server, estoy esperando que alguien haga JavaScript on Rails (la capacidad de metaprogramación está ahí) y lo enchufe con algún intérprete de Javascript. "¿Harías Rails en el cliente?", se preguntarán. Nop. La idea es usar el mismo lenguaje en el cliente y en el server. Netscape lo intentó hace un tiempo pero se le acabo la plata. El mundo sería mejor si Sun hubiera apoyado esto en vez de impulsar Java a diestra y siniestra. Tener el mismo lenguaje en cliente y server permitiría hacer algunas cosas que ahora no se puede, como compartir el código de validación formato de los datos entre cliente y server sin repetir nada.

Y, por último, SQL es lo que intentamos sacarnos desde hace años de encima. Cada ORM (Hibernate, ActiveRecord) que hay es un intento fallido para escaparle.

¿Y por qué no lo ven así? Lo que hay que darse cuenta es que programar una página web dinámica es un ejercicio de metaprogramación. Un escribe un programa (que está en el server) que cuando se ejecuta genera un programa que se transmite al cliente (HTML + Javascript + CSS, etc) que cuando se ejecuta se renderea y muestra la página. Cuando se hace AJAX, en realidad hacés un hot fix en un sistema productivo. El resultado de una llamada AJAX son instrucciones de como cambiar el programa que está corriendo.

Pensado de esta manera, es razonable ver que conviene unir lenguajes en uno solo. JavaScript, a pesar de no ser mi lenguaje favorito (que es Ruby), para mi tiene todas las de ganar.

Tiene:
  • Soporte en el cliente.
  • Es conocido por los desarrolladores de páginas web.
  • Es razonablemente metaprogramable.
Para mi, el mayor problema es que para pasar cachos de código hay que escribir demasiado. Un bloque de código, pasado a una función, se ve así:
foo( c, function(a, b) { return a+b })


En cambio, el mismo código en Ruby es:
foo(c) { |a,b| a+b }


De todas maneras, JavaScript ya está por todos lados y es razonablemente bueno. Lo más importante es que tiene soporte en el cliente, que es la parte más dificil de cambiar en una página web. Si no me creen, traten de hacer páginas que anden solamente en FireFox y diganles a sus usuarios que se lo instalen.

Por último, quería agradecerle a frinfrunfranfrun haberse bancado chatear conmigo de este tema, lo que hizo que me caiga la ficha sobre que escribir.

Éxitos,
Aureliano.

2 comentarios:

frinfrunfranfrun dijo...

Falta el plan de marketing para poder llevarlo acabo.

aurelianito dijo...

Bueno, en realidad se puede implementar sobre los browsers actuales algo bastante cercano. Hacer una rutina que escriba una página web a partir de JSON parece no tan difícil. Teniendo esta rutina funcando, se puede hacer que genere diferente HTML en función del browser. Con eso andando, poner los estilos en el JSON es fácil. También hay que wrappear el DOM para que sea consistente con la creación de la página en JSON (todo esto, puro javascript).

En el server hay que buscar un intérprete de javascript (por ejemplo usar rhino en una JVM o el kjscmd, intérprete basado en la librería de javascript de KDE) e implementarle algo parecido a Rails arriba.