¿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.
Referencias
El coste de javascript (en inglés)
01-12-2018
