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.
| 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/
No hay comentarios:
Publicar un comentario