Javascript domina la web... pero hay que tener un poco de cuidado

Lo siguiente son trozos de varios artículos que he leído con los que estoy de acuerdo y creí que vale pena compartir en manera de un unico post.

 Quiero comenzar diciendo que soy un gran fan de javascript, escribo gran cantidad de código con el y lo encuentro increíblemente útil, de ambas maneras como un lenguaje de programación y como una manera de mejorar la usabilidad y accesibilidad del contenido web. En los primeros días de la web muchos programadores se distanciaban mucho de javascript, muchos lo miraban como un lenguaje de juguete y lo sentían similar a html y css. No era tan poderoso como Java,C o Perl por lo que no valia la pena aprenderlo. Pero con el pasar de los años javascript cambio mucho.

 La mayoría de los programadores comenzaron a tomarse enserio javascript cuando AJAX se volvió popular y con el nacimiento de los frameworks MVC javascript (angular,ember,ect) muchos programadores empezaron a volcarse a javascript. El único problema que veo con esto es la desconexión fundamental de estos programadores parecen tener en la manera en que ellos crean código para la web. En el desarrollo tradicional de software tenemos cierto control sobre nuestro entorno, pero en la web no.

 Por ejemplo si estamos escribiendo un programa del lado del servidor en Python, Rails o php una de estas cosas es cierta:

 1 - Nosotros controlamos el entorno del servidor: SO , versión de lenguaje paquetes , ect
 2 - Nosotros no controlamos el entorno del servidor: Pero tenemos conocimiento de el y podemos crear código deacuerdo a sus especificaciones y todo estara bien.

 En el mundo tradicional de instalación de programas nosotros podemos controlar nuestro entorno poniendo ciertas restricciones en los SO para que nuestro código pueda correr ,ram , espacio en disco duro etc. Nosotros establecemos todo esos requerimientos para que los que usuarios puedan usar nuestros programas.

 En la web sin embargo todo esto es incierto. No tenemos control del entorno  en donde nuestro código javascript,html,css se ejecutaran. Nuestros usuarios controlan el aparato que usan, nuestros usuarios deciden que sistema operativo usar, cuanta ram  y espacio en disco quieren , la velocidad del procesador y el tipo de navegador que quieren usar. Y los proveedores de Internet se sientan en medio de nosotros y nuestros usuarios controlando la velocidad de la red , latencia y por ultimo que contenido permiten que el usuario descargue.

Lo unico que podemos hacer es tratar de hacer la experiencia adaptable a cualquier tipo de situación y cruzar los dedos para que todo salga bien. El problema fundamental de confiar en javascript  es que crea la ilusión de que estamos en control, seguramente si construimos una aplicación de uso personal o para algún familiar nosotros podemos decidir los requisitos para nuestra app SO/navegador/ram/etc  pero eso no es una realidad para el mundo web.

No podemos confiar ciegamente en la disponibilidad de una versión de SO ó versión de navegador cuando se trata de llevar nuestra app a internet, en lugar debemos construir experiencias que sean adaptables y tomar decisiones inteligentes  sobre las tecnologías especificas a usar en orden de tomar ventajas de sus beneficios mientras somos conscientes que no podemos garantizar la completa compatibilidad en este caso entra en juego algo llamado "progressive enhancement"

El concepto de "progressive enhancement" se ha convertido en unos de los temas de mas debate en la web de la actualidad, para ponerlo simple "progressive enhancement" es la técnica para construir sitios web con fuertes cimientos para que se a accesible a un amplio rango de situaciones (SO , navegadores, ram, ect)

Si tienes tiempo puedes leerte este post de como twitter uso esa técnica en el 2012 link.

He tomado una tabla de unas pruebas hechas por Jake Archibald en su blog donde ha hecho pruebas de parseo y ejecución de jquery 2.1.1 en diferentes dispositivos.

Parse and execution times of minimized jQuery 2.1.1

Device	Browser	Median Parse	Median Execution	Median Total
Blackberry 9650	Default, BB6	171ms	554ms	725ms
UMX U670C	Android 2.3.6 Browser	168ms	484ms	652ms
Galaxy S3	Chrome 32	39ms	297ms	336ms
Galaxy S3	UC 8.6	45ms	215ms	260ms
Galaxy S3	Dolphin 10	2ms	222ms	224ms
Kindle Touch	Kindle 3.0+	63ms	132ms	195ms
Geeksphone Peak	Firefox 25	51ms	109ms	160ms
Kindle Fire	Silk 3.17	16ms	139ms	155ms
Lumia 520	IE10	97ms	56ms	153ms
Nexus 4	Chrome 36	13ms	122ms	135ms
Galaxy S3	Android 4.1.1 Browser	3ms	125ms	128ms
Kindle Paperwhite	Kindle 3.0+	43ms	71ms	114ms
Lumia 920	IE10	70ms	37ms	107ms
Droid X	Android 2.3.4 Browser	6ms	96ms	102ms
Nexus 5	Chrome 37	11ms	81ms	92ms
iPod Touch	iOS 6	26ms	37ms	63ms
Nexus 5	Firefox 32	20ms	41ms	61ms
Asus X202E	IE10	31ms	14ms	45ms
iPad Mini	iOS6	16ms	30ms	46ms
Macbook Air (2014)	Chrome 37	5ms	29ms	34ms
Macbook Air (2014)	Opera 9.8	14ms	5ms	19ms
iPhone 5s	iOS 7	2ms	16ms	18ms
Macbook Air (2014)	Firefox 31	4ms	10ms	14ms
iPad (4th Gen)	iOS 7	1ms	13ms	14ms
iPhone 5s	Chrome 37	2ms	8ms	10ms
Macbook Air (2014)	Safari 7	1ms	4ms	5ms

Lo que  Jake Archibald dice :  "La horrible verdad sobre javascript cuando se trata de dispositivos que no son muy poderosos en hardware. Puedes pensar que esos modelos donde los tiempos son mas grandes son modelos viejos que nadie usa, lo cual es un error por que según las estadísticas las personas usan mas dispositivos antiguos que nuevos. También no importa que navegador usen lo mas importante es el poder de hardware del dispositivo.

Lo interesante de los tiempos de parseo y ejecución es que son para la ultima versión de jquery la cual pesa 88kb minificada, sin plugins adicionales sin frameworks. De acuerdo con los últimos reportes de HTTP archive, la media de transferencia de archivos JS son de 230kb". Las pruebas que el hizo son solo una fracción de ese tamaño. Jake Archibald dice que no pidio que jquery hiciera nada.

Por eso en algunas ocasiones debemos considerar reducir la dependencia de javascript en nuestros proyectos, no solo es saludable en tiempo de carga sino sera accesible para las personas que tienen javascript desabilitado en sus navegadores.

Como programador de javascript yo uso el framework angularJS y me parece impensable que algún usuario tengo desabilitado javascript en su navegador, pero aunque no queramos admitirlo existen y las app que usan frameworks javascript se vuelven cada vez mas pesadas. Las recomendaciones que siempre leo en internet son:

• Reducir lo maximo posible javascript
• Usar mas los render del lado del servidor
• modular tus archivos javascript y usar lazy loading
• Algunos recomiendan que la pagina principal que tiene datos para presentar sean cargador por el lado del servidor primero y después usar ajax para lo demas, algo asi como incluir un json con todos los datos necesarios iniciales en el html.

Como Nate Koechley’s dijo una vez:

"En un empleo anterior a yahoo, siempre me hacian la pregunta al inicio del cualquier projecto: ¿ Cuales navegadores debemos soportar en este projecto ? vamos a soportar netscape 4 ? IE 5? y siempre me fue preguntada en un sentido binario donde la respuesta siempre tenia que ser si o no. y con el tiempo nos dimos cuenta que el principal objetivo de nosotros era la maxima disponibilidad posible. Y esa fue la primera cosa que tuvimos que entender, el soporte no es binario. La segunda cosa que tuvimos que aprender es que soportado no significa realmente identico. En lugar de soportar un navegador, nosotros queremos dar al navegador lo que puede manejar de la manera mas eficiente posible."


Hace algún tiempo salio una web con el titulo “You Might Not Need jQuery”  el sitio en si ofrece ejemplos de código donde puedes hacer lo mismo que jquery pero con javascript nativo por nosotros mismo.

Lo interesante de esta web son el sinnúmero de comentarios que recibio con opiniones divididas sobre el tema. Lo cual hace preguntarse si una simple sugerencia sobre no usar una tecnologia determinada puede generar tanta discusion sobre el tema entonces debemos preguntarnos si estamos demasiado  dependientes de ella.

No estoy diciendo que no debamos usar frameworks y librerías, De hecho me gusta mucho jquery y los frameworks javascript pero lo que preocupa es que estas librerias se han convertido en librerías por defecto en cualquier proyecto y damos por hecho que esa dependencia es sana y la mayoría dela gente esta amarrada a esa tecnologia. Esto obviamente lleva a que tengamos librerías con un peso considerable en nuestros proyectos por considerarlas obligatorias.


http://aaron-gustafson.com/notebook/2014/a-fundamental-disconnect/
http://timkadlec.com/2014/09/js-parse-and-execution-time/
http://jakearchibald.com/2013/progressive-enhancement-is-faster/
http://timkadlec.com/2013/08/being-practical/
http://sixrevisions.com/web-development/progressive-enhancement/