IronWoods.es

Desarrollo web

¿Por qué NO usar JavaScript en Aplicaciones Web?

Yo soy una persona que se queja de todo y no está en contra de casi nada, sí de cómo se hacen las cosas. Aunque no lo parezca, esto le ocurre a mucha gente, las personas tienden a creer que tienen razón.

JavaScript es absolutamente necesario para la web hoy, pero no siempre.

Que algo sea necesario, no implica que no tenga aspectos negativos, y cuando se usa sin necesidad, si podemos hablar de una mala "solución". En la entrada ¿Cuándo usar JavaScript en Aplicaciones Web? pongo ejemplos, muy simples, de donde usar y no usar javascript.

Ser programador es muy difícil. Desde fuera parece que vas a ganar toneladas de dinero, pero no es lo normal. Si programar no te apasiona, te acabarás dedicando a otras cosas.

El programador, pasa mucho tiempo "escribiendo" y al escribir, uno normalmente vuelca sus filias y sus fobias... Si hablamos de quien tiene la posibilidad de elegir y ama un lenguaje determinado, tenderá a usarlo para todo, incluso cuando no sea necesario.

Usar JavaScript tiene un coste

Desde hace unos años las páginas web tienen un grave problema de "obesidad", que va en aumento. Posiblemente las empresas y programadores se están relajando, dado el incremente de los anchos de banda y la demanda de contenidos de los usuarios, sin tener en cuenta aspectos como el WPO (Website Performance Optimization), incluso aquellos que lo promocionaron.

En gran medida el aumento del peso de las páginas web se debe al uso extensivo de JavaScript.

Esto me recuerda un poco a las versiones de cierto Sistema Operativo y sus "requerimientos de memoria".

Uno de mis primeros ordenadores allá por el 2000, funcionó un tiempo con un módulo de memoria *prestado de 56Mb. Una memoria pequeña, con tiempos de acceso de la época, y la mitad de lo que mi equipo necesitaba... Lo importante, es que, la siguiente versión del SO requería 256Mb para funcionar de forma similar, la siguiente 512Mb, la siguiente 1028Mb...

Hoy, tenemos unos equipos bestiales en comparación con los de hace 20 años, pero no funcionan comparativamente mucho más rápido... Los programas son, en general, mucho más complejos, pero también se optimizan muchísimo menos.


Entonces JS tiene varios puntos en contra:

Primero, JavaScript es un recurso que debe de ser descargado para que la página funcione, esto afectará. muy probablemente. al **tiempo de carga de la página y al consumo de datos, si procede.

En segundo lugar, JavaScript es procesado por el dispositivo, lo que requiere un tiempo de procesamiento, que puede dilatarse mucho en dispositivos de gama media-baja, además del consumo de batería en dispositivos que la utilicen. Esto ocurre de manera similar con las animaciones CSS y debe tenerse en cuenta, especialmente por la proliferación de dispositivos móviles (ciertas páginas son lentas, calienten el dispositivo y agotan la batería).

Otro factor a tener en cuenta es que JavaScript puede no funcionar en el navegador, porque fue desactivado o dejó de funcionar (error del propio código, falta de soporte, etc.). Si esto ocurre la aplicación pierde su funcionalidad. Personalmente me molestan mucho los sitios web con un gran diseño donde no funcionan botones, formularios, etc.

* En el año 2000 me monté un "clónico". Tardé 3 días en comprar todas las piezas, por algún motivo, deje la memoria RAM para el final y dios me castigo. Un día antes de ir a la tienda a por ella, hubo un terremoto en Taiwán o Malasia, ¿quién sabe?, donde estaban todas las fábricas de RAM de la época. Parece que las fábricas y los elefantes estaban sanos y salvos, pero las carreteras no... Y así es como la RAM multiplicó su precio por 5 durante la noche y yo acabe con un ordenador nuevo que solo servía de pisapapeles. Tarde como un año en poder comprarme la RAM, para que te fíes de los elefantes asiáticos.

** Muchas aplicaciones permiten visualizar el contenido antes de descargar el JavaScript, pero la funcionalidad que dependa de este se demora hasta que este se encuentre disponible.

Ni negro, ni blanco

Las aplicaciones con un uso extensivo de JavaScript, como las basadas en frameworks front-end, trasladan la capacidad de procesamiento, en mayor o menor medida, al dispositivo que las utiliza, y como he dicho antes, usar JS tiene un coste.

Cuando una aplicación corre en el servidor, este soporta su carga. Si aumenta el número de usuarios, quien la mantiene funcionando, debe asignar más recursos, en ciertos casos esto acaba por "matar una aplicación". Aquí, se vuelven interesantes las aplicaciones que funcionan del lado del cliente, ya que la carga de la aplicación recaerá en gran parte en el dispositivo que la está usando, así un servidor puede soportar mayor número de usuarios y el escalado es más asequible. En contra, como no sabemos los recursos con los que cuentan los dispositivos que consumen la aplicación, debemos tratar de optimizar esta desde el principio.

Para aclararnos y en términos muy generales, si no tenemos dinero y podemos invertir 2 duros en poner en marcha una aplicación (sin contar con lo que cuesta la programación), podemos dar servicio a más usuarios con una aplicación cuya carga principal este en el lado del cliente y no del servidor. Esto es así porque el servidor lo pagamos nosotros y los dispositivos que consumen la aplicación no. El problema al final es la optimización. Con una programación de una "calidad intermedia" una aplicación del lado del servidor podría dar servicio a 100 usuarios (con esos 2 duros). Podemos soportar a más usuarios mejorando el programa (hasta cierto punto) o pagando un servidor con más recursos. Si la aplicación es del lado del cliente, suponiendo que JS está soportado, activo, sin errores, etc., si de esos 100 posibles usuarios, 25 tienen smartphones de menos de 100€, podemos estar casi seguros de que aproximadamente 25 usuarios, van a tener una experiencia mala, muy mala o inexistente... Y aquí pasan dos cosas: una perdemos usuarios (y reputación) desde el mismo comienzo, y dos: puede que ni siquiera nos demos cuenta. Eso sí, en este último caso nuestro servidor podrá soportar a cientos o miles de usuarios antes de que tengamos que mejorar nada.

Briconsejos

Valorar los pros y contras de invertir en WPO o Web Performance Optimization durante el desarrollo o en aplicaciones que ya funcionan (el WPO afecta a la experiencia de usuario y al SEO).

Desarrollos "Cheap First". Lo acabo de inventar, creo. No estoy hablando de "desarrollos de dos duros" (estos siempre acaban dando problemas), ni de desarrollos nativos, sino de aquellos con presupuestos normales, "basados en tecnologías web".

Con desarrollo "Cheap First" me refiero a que debemos desarrollar y testear sobre móviles de gama baja. Esto nos asegura que la aplicación funcionará en el mayor número de dispositivos posible.

Por ejemplo, hay smartphones de 1000€ que ejecutan una aplicación (basada en JavaScript) en 1 segundo, pero tarda 30 segundos en cargar en un dispositivo de 70€. Si desarrollamos con el primero y nuestro público objetivo NO es el que dispone de esta gama de teléfonos, tendremos un problema.