Creo que a todos los que han escrito más de 100 lineas de código para web estarán de acuerdo en que casi nunca es deseable escribir todo el código necesario para el funcionamiento, sino hacer un uso inteligente de bibliotecas para cada cosa que sea posible.
Centrándonos en la parte del cliente (lo que era normalmente la “V” del MVC) ahora resulta que gran parte del proceso de construcción de la interface ([G]UI) para usuario tiene que ver con un montón de programación que no solo tiene que ver con vista, sino con reglas de negocio, mandado y recepción de datos del servidor, entre otras cosas que terminan mezclando las 3 capas típicas que se crean en una aplicación Web.
Esta necesidad de riqueza de funcionalidad (RIA: rich internet applications) en lo que el navegador ofrece hacia el usuario ha resultado en un gran cambio de lo que conocemos como “páginas de internet”, para convertirse en una plataforma de aplicaciones que corre no solo sobre algo que no estaba preparado realmente para eso (el navegador), sino que también corre sobre lenguajes que nunca se pensó serían tan explotados cuando fueron creados (HTLM, CSS, JavaScript), y bueno, ahora pasamos de tener simples funciones que creaban dinamicidad en las páginas, a tener grandes sistemas de paquetes, que contienen desde cosas muy sencillas como modificar partes de una página (DOM) hasta las llamadas “widgets” que son pequeñas aplicaciones apilables en una o más paginas.
Obviamente, esto ha generado el nacimiento de un sin número de herramientas/bibliotecas para facilitar el proceso de creación de aplicaciones “web 2.0”, tenemos desde cosas básicas hasta paquetes con una inmensidad de funciones (scriptaculous, dojo, meteora, GWK, YUI, etc).
Entre las herramientas disponibles tenemos 2 arquitecturas diferentes, una es mantener todo el JavaScript (JS) empaquetado de tal manera que separemos el lenguaje de la aplicación del lado del server por completo del lenguaje del cliente (JS); la otra opción es mantener “escondido” todo el JS y que a través del lenguaje servidor se cree de manera automática todo lo necesario para el cliente, de tal manera que el programador solo utiliza un lenguaje para la totalidad de la apliación, no tiene que tocar para nada JS.
GWT es el ejemplo perfecto de el segundo caso, todo se hace con Java, y de manera interna, sin que el programador llegue a escribir una sola linea de JS, se crea todo el código necesario para el cliente. La propuesta es muy interesante, pero el contra principal es que no hay manera de usar la biblioteca si no sabes Java, o si no lo quieres usar.
El otro lado de la moneda es más flexible, pero requiere no solo aprender con suficiente destreza tanto el lenguaje del lado del servidor (Java, PHP, Python, Perl, Ruby, etc), como aprender Javascript, DOM, y las tripas de la biblioteca que hayas decidido usar para AJAX/Efectos/Widgets. Y no solo esa desventaja tiene, frecuentemente hay serios problemas para mantener la separación de capas, en especial entre la V y la C, porque frecuentemente es más sencillo escribir código (HTML y JS), que será agregado al cliente, directamente en la capa de control, porque la opción de andar creando plantillas para cosas como un “<p>Los datos de $usuario han sido guardados</p>” pues nomas meten más confusión, y la separación de capas en vez de ayudar nos estorba, por otro lado, generar una función en JS que acepte un argumento ($usuarui) y cree el texto que será mostrado no solo es más lento, además es tonto.
De tal manera que tenemos 2 grandes opciones, con grandes limitantes cada una de ellas. Y además, respetando la separación de capas estilo MVC, el hecho de que el cliente necesita saber mucho tanto de vista como de control, genera necesariamente una mezcla de V y C que dificilmente puede ser corregida manteniendo la funcionalidad a menos que te vayas por la opción 1 que te obliga a sujetarte a la funcionalidad disponible en la librería.
La pregunta es cuál es la mejor opción ??, pues yo prefiero lidiar con JavaScript por separado, el lenguaje está hecho para modificar el DOM, y tiene su atractivo, no me agrada mucho la idea de usar cosas demasiado complicadas para “facilitarme” la vida, y por otro lado, el separar el código del servidor con el código que se ejecuta en el cliente, obtenemos mucha más flexibilidad, es más fácil agregar funciones en javascript que modificar el código de un “framework” para agregale nueva funcionalidad. Por otro lado, no haya nada equivalente a GWT para python, php o similares.
Y tu qué opinas ?
No Comments, Comment or Ping
Reply to “Bibliotecas de JavaScript/AJAX: en JavaScript o en el lenguaje nativo de la aplicación?”