Cuando hacemos una aplicación con AJAX para una WEB 2.0, todos sabemos que ya de por sí el utilizar AJAX optimiza el ancho de banda, ya que no se está reenviando una y otra vez cosas que no cambian, así que solo se transmiten trozos de informacón útiles para cambiar cierta parte de la aplicación.
Pero en muchas aplicaciones de este tipo no hay que descuidar dos aspectos muy importantes, uno de ellos es la optimización del ancho de banda (aspecto para el usuario) y el otro es la seguridad de nuestro código (aspecto para el desarrollador)
En cuanto a optimización se refiere, durante la ejecución de la aplicación se tiene una comunicación lo más optimizada posible gracias a AJAX, pero ¿que pasa al inicio?, es decir, cuando estamos entrando en la aplicación, es el momento en el que nos descargamos toda la tecnología necesaria para que la aplicación funcione correctamente.
En estas aplicaciones tan dinámicas, la carga de javascript es muy pesada en relación al XHTML. Así que cuando accedemos a la aplicación por primera vez tenemos que descargarnos mucho javascript, en ciertas aplicaciones hablamos de unos cuantos KB (funciones nuestras), en otras de unas decenas de KB (muchas funciones y objetos nuestros) y en algunas de cientos de KB (plataformas de desarrollo javascript, pro ejemplo dojo). Descargarse cientos de KB al empezar la aplicación puede provocar que el usuario se canse, deje la aplicación y no vuelva. Así que este primer aspecto se va a dedicar a optimizar esa carga inicial.
Para conseguirlo existen herramientas que estudian tu código y devuelven un código que hace lo mismo, pero en menos espacio. Pongamos un ejemplo:
Codigo inicial:
----------------------------------------
//este fichero javascript hace........
//funcion mifuncion hace .......
mifuncion = function(param1, param2){
//multiplicamos los números
return param1*param2;
}
-------------------------------------------
Código optimizado con la misma funcionalidad
------------------------------------------------
mifuncion=function(param1,param2){return param1*param2;}
------------------------------------------------
Como puede observarse el tamaño es muchísimo menor, simplemente quitando cosas que al desarrollador le sirven, pero que al navegador del cliente no le hacen falta, así que los ficheros originales estarán en el ámbito de desarrollo y para pasarlos a explotación, se pasan por este parser que los optimiza.
En cuanto al segundo punto, cierta seguridad de nuestro código nos puede servir tanto para que el desarrollador tenga un código propio y nadie se lo robe (ya que el javascript es interpretado y hay que enviar los fuentes al navegador), como para comprimir aun más el javascript que enviamos.
Esta ocultación del código se consigue gracias a la ofuscación del mismo, esto consiste en cambiar los nombres de las variables, funciones, objetos, etc. por nombres que no dicen nada semantico, es decir, las variables podrian ser en lugar de: arbol, persona, objeto; pondríamos: v1, v2, v3, etc. Hay que fijarse que con esto además de conseguir código ilegible, necesitamos menos caracteres por variable.
Utilizando la primera idea y esta segunda, conseguimos que nuestro código inicial que tenía aproximadamente 200 caracteres pase a ser de la siguiente forma:
------------------------------------------------
f1=function(v1,v2){return v1*v2;}
------------------------------------------------
Que ocupa 33 caracteres, conseguimos un código ilegible para una persona, pero funcional para un navegador y conseguimos además disminuir el tamaño en más de 6 veces
Jose Carlos Calvo Tudela
Pero en muchas aplicaciones de este tipo no hay que descuidar dos aspectos muy importantes, uno de ellos es la optimización del ancho de banda (aspecto para el usuario) y el otro es la seguridad de nuestro código (aspecto para el desarrollador)
En cuanto a optimización se refiere, durante la ejecución de la aplicación se tiene una comunicación lo más optimizada posible gracias a AJAX, pero ¿que pasa al inicio?, es decir, cuando estamos entrando en la aplicación, es el momento en el que nos descargamos toda la tecnología necesaria para que la aplicación funcione correctamente.
En estas aplicaciones tan dinámicas, la carga de javascript es muy pesada en relación al XHTML. Así que cuando accedemos a la aplicación por primera vez tenemos que descargarnos mucho javascript, en ciertas aplicaciones hablamos de unos cuantos KB (funciones nuestras), en otras de unas decenas de KB (muchas funciones y objetos nuestros) y en algunas de cientos de KB (plataformas de desarrollo javascript, pro ejemplo dojo). Descargarse cientos de KB al empezar la aplicación puede provocar que el usuario se canse, deje la aplicación y no vuelva. Así que este primer aspecto se va a dedicar a optimizar esa carga inicial.
Para conseguirlo existen herramientas que estudian tu código y devuelven un código que hace lo mismo, pero en menos espacio. Pongamos un ejemplo:
Codigo inicial:
----------------------------------------
//este fichero javascript hace........
//funcion mifuncion hace .......
mifuncion = function(param1, param2){
//multiplicamos los números
return param1*param2;
}
-------------------------------------------
Código optimizado con la misma funcionalidad
------------------------------------------------
mifuncion=function(param1,param2){return param1*param2;}
------------------------------------------------
Como puede observarse el tamaño es muchísimo menor, simplemente quitando cosas que al desarrollador le sirven, pero que al navegador del cliente no le hacen falta, así que los ficheros originales estarán en el ámbito de desarrollo y para pasarlos a explotación, se pasan por este parser que los optimiza.
En cuanto al segundo punto, cierta seguridad de nuestro código nos puede servir tanto para que el desarrollador tenga un código propio y nadie se lo robe (ya que el javascript es interpretado y hay que enviar los fuentes al navegador), como para comprimir aun más el javascript que enviamos.
Esta ocultación del código se consigue gracias a la ofuscación del mismo, esto consiste en cambiar los nombres de las variables, funciones, objetos, etc. por nombres que no dicen nada semantico, es decir, las variables podrian ser en lugar de: arbol, persona, objeto; pondríamos: v1, v2, v3, etc. Hay que fijarse que con esto además de conseguir código ilegible, necesitamos menos caracteres por variable.
Utilizando la primera idea y esta segunda, conseguimos que nuestro código inicial que tenía aproximadamente 200 caracteres pase a ser de la siguiente forma:
------------------------------------------------
f1=function(v1,v2){return v1*v2;}
------------------------------------------------
Que ocupa 33 caracteres, conseguimos un código ilegible para una persona, pero funcional para un navegador y conseguimos además disminuir el tamaño en más de 6 veces
Jose Carlos Calvo Tudela
Llegas tarde a la web 2.0 ... te recomiendo bajarte ahora mismo, y meterte en RIA, creéme investiga y prueba Flex, primero conoce la tecnolgía y luego da un veredicto. No te fíes de lo que te cuentan, averigualo tu mismo.
ResponderEliminarBuenas anónimo, lo de RIA y Flex lo conozco, pero aun así me quedo con la Web 2.0 y con AJAX.
ResponderEliminar¿En qué me baso? pues en accesibilidad.
Flex es (si no me estoy confundiendo) una aplicacion Flash con un motor de peticiones asincronas XML, de esta forma la idea subyascente de FLEX y AJAX es la misma, es decir, tengo una aplicacion en el cliente que hace pequeñas peticiones a un servidor.
Viendo que la idea que hay por debajo de ambas es la misma, tenemos que Flash es mucho más potente en cuanto a lenguaje y opciones te permite el action script.
Lo malo es que es una miniaplicación, y solo puede verse con visores de Flash, una persona invidente no es capaz de ver esas cosas, en cambio si que tiene navegadores que ven el XHTML y se lo representan de alguna forma al invidente. Cuando digo invidente tambien me refiero a personas con capacidad visual mermada.
Otro problema de Flash es el tema de que un sistema automático no puede entender que hay en esa página, por lo tanto no esperes que Google te indexe de forma correcta.
Bueno, donde quiero llegar es que a la parte fundamental a la que me refiero en esto de temas 2.0 es a la arquitectura de cliente-servidor que se monta. Y podría admitir dentro de esa arquitectura tanto a AJAX como a FLEX.
Y por último dejar caer que existen plataformas javascript (dojo por ejemplo) que dan mucha potencia al lenguaje y permiten muchos efectos
Saludos y espero que sigas dando tus puntos de vista por aquí, siempre es interesante ver otras formas de enfocar la tecnología, te agradecería que respondieses explicando un poco el tema de Flex
Yo también creo que es importante optimizar el ancho de banda y pongo por ejemplo el correo nuevo de yahoo (aunque no se que tecnología usa exactamente) que me deja el navegador un poco bloqueado mientras carga, muchas veces me pregunto si es necesario tanta sobrecarga.
ResponderEliminarOtra cosa que quería comentarte es que mencionas herramientas para Optimización y Ofuscación pero no recomiendas ninguna en particular, ¿existe alguna especialmente buena o que hayas probado?
Y para terminar un pensamiento, y es que una cosa que temo al desarrollar aplicaciones webs es liberar parte del código a los clientes (como bien dices sería legible para cualquiera) y por lo tanto podría ser la entrada para personas malintencionadas que quisieran explotar alguna debilidad del sistema. Si la ofuscación se puede automatizar será algo que les dificultará en gran medida este trabajo.
Gracias por tu trabajo y hasta pronto!
Pues no recomiendo ninguna en particular, tienes razón. El caso es que eso depende de la arquitectura que utilices, por ejemplo si usas dojo, éste lleva un script que se encarga de hacer la optimización y la ofuscación de forma inmediata.
ResponderEliminarEntonces cabe esperar que si usas una arquitectura javascript, ésta traiga algún tipo de script que haga algo de esto.
Si lo que usas es javascript propio, pues en la Web hay varias herramientas que lo permiten.
Y claramente es bastante interesante hacer código y por lo menos dificultar al máximo que te lo copien.
Particularmente te voy a recomendar ShrinkSafe que es el que usa dojo, lo puedes encontrar por la web, ésta herramienta te comprime código y ademas ofusca un poco, es decir cambia todas las variables temporales, es decir, que si tienes una funcion pos el nombre de la función no te la cambia para que puedas usarla desde otros sitios, pero por dentro de la función, te cambia todas las variables temporales, te pongo un ejemplo:
----------------------------------
factorial = function(numero){
var resultado = 1;
for(i = 2; i<= numero; i++){
resultado*=i;
}
return resultado;
}
----------------------------------
Este código es muy simple, y por tanto aunque se ofusque se puede entender algo, pero ya se ve que en códigos con más variables la cosa va a ser más chunga
Resultado del programita
---------------------------------
factorial=function(_1){var _2=1;for(i=2;i<=_1;i++){_2*=i;}return _2;};
---------------------------------
Compartir es vivir.
ResponderEliminarNo considero mi código tan avazando como para ocultarlo y aquellos que si tienen un gran nivel... LO COMPARTEN DE FORMA "ALTRUISTA" (los beneficios indirectos, los dejo aparte).
Los compresores se han de utilizar con el fin de reducir el peso de nuestros script y evitar ataques basados en errores de nuestro código.
Espero que alguien pueda apreder de mi trabajo igual que yo aprendo del trabajo de tantos otros.
Un saludo a todos.