Intro

Sugerimos la necesidad de un movimiento inspirado en contrarrestar la obesidad de la Web, ¿que nos haga más autónomos de los contados fabricantes de navegadores Web dominantes ( Google, Microsoft, Apple…) ? ¿también desde un punto de vista medioambiental?

Las requirimientos de consumo energético (potencia) de sitios Web obesos, (por ambas partes) tanto en servidores como en clientes son ridículos (y a la larga, desastrosos) A causa principalmente del exceso del lenguaje JavaScript con el que se carga al navegador (aparentemente, ninguno de los llamados “desarrolladores Web modernos” sabría como crear frontend sin JavaScript, el usuario regularmente experimenta un aumento en el consumo de potencia al abrir/navegar sobre una simple página Web. Y con motivo de los enfermizos frameworks del lado servidor como Ruby on Rails y Django (Python), los servidores también experimentan un innecesarios incremento en consumo enérgetico. Incluso el lenguaje PHP, sobre el que se ejecuta la mayoría de sitios Web se libra de esta tendencia. PHP en sí mismo no es tanto el problema, desde la versión 7.0 ha incorporado relevantes mejoras de rendimiento (muchas de ellas motivadas por cuestiones medioambientales), no, será que … ¿de algún modo los (en parte) responsables somos los desarrolladores que, al trabajar con PHP, no podemos vislumbrar como hacer nada sin alguno de los (energéticamente) ineficientes como Laravel, Symfony, CodeIgniter o Yii? .

El hecho es que todos los populares frameworks de programación adolecen del mismo mal. Han sido desarrollados principalmente por ‘la teoría’

Teoría basada en abstracciones, patrones de diseños, y toda la fanfarria que suele ser inútil en la mayoría de los casos de ‘la vida real’. Más allá, si usas un framework de entrada, requiriendo rendimiento(¿?), requieres trabajar con código fuente optimizado desde la base. Necesitas dejar atrás todo lo pesado y sobrante, no añadir más.¿Como es posible hacer software orientado al rendimiento cuando requieres 75 clases o módulos para escribir “Hola Mundo” en el monitor?. Lo que nos sería útil sería herramientas sencillas, pequeñas, librerías optimizadas y especializadas, ¿frameworks?.

“Solíamos sentarnos en círculo en la ‘Sala Unix’ diciéndonos, ‘¿De que podemos prescindir? Que hace ahí esa opción?” A menudo ocurre que es a causa cierta deficiencia en el diseño básico — por lo que realmente no se llega al punto óptimo de diseño. En vez de añadir una opción, pensemos en aquello que nos fuerza a añadir esa opción.

― Doug McIlroy.

Frameworks pesados

En relación a (Ruby on) Rails y (Python) Django (específicamente), esta cuestión queda patente. Ni Ruby ni Python fueron pensados para el desarrollo Web originalmente. Lo patológico del asunto es que son demasiado lentos. No son la herramienta adecuada para la tarea. ¿No por el mero hecho de que puedo usar Bash para crear y ejecutar un sitio Web no quiere decir que sea buena idea hacerlo así?.

Hay quien argumenta que “las horas de desarrollador” son más costosas que los recursos de computación, y que Rails y Django tratan de ‘hacer el trabajo, y listo’, rápidamente. Pero ese, precisamente, es el problema. Los problemas que enfrenta Internet a día de hoy es una consecuencia a largo plazo de precisamente ese enfoque cortoplacista. ‘Tener las cosas hechas, y listo!’. Rápido mejor que correctamente.

¿y si (al desarrollar) consideramos los siguientes factores

Si estudiaste desarrollo Web “modern” en algún centro de formación profesional o universidad

¿ estás dispuesto a descartar gran parte de lo que te enseñaron y empezar a pensar por tí mismo?. A no ser que hayas tenido un profesor consciente las probabilidades de que hayas estado oyendo a quienes no hablan más que desde la teoría. ¿ estudiar como las tecnologías subyacentes funcionan de tal manera que podamos tomar decisiones informadas?. El (para entendernos) desarrollo web “moderno” va en perjuicio de las tecnologías sobre las que se ejecuta.

Aprender a construir un sitio web con mero HTML y CSS en el frontend. Usar únicamente JavaScript en cuentagotas

para pequeñas mejoras si fueran necesarias. Asegurándonos de que está realmente justificado (se requiere del testing adecuado para discernirlo). Incluso si se justifica asegurate de que puede funcionar sin JavaScript.

Prueba tu aplicación / producto

en un PC portátil ya (casi) obsoleto

«No, tu website no es una webapp»

aunque así lo llames

No más «single page websites» !

El protocolo HTTP ha sido hecho ‘para usarse’

sirviendo pequeñas y discretas peticiones (requests), cada cual con su propio y único propósito .No tiene sentido cargar un sitio web en el navegador al completo y ‘de una vez’. La mayoría de la gente no lee o visualiza el 90% del contenido de un espacio web. No hay ningún buen motivo para (p.ej.) cargar la página “About Us” en el navegador si el usuario nunca la lee. Separemos el sitio web en diferentes y pequeñas porciones y dejémos que el usuario/a decida cuales quiere ver. Para ello se hicieron los enlaces HTML. Sirvamos un pequeña página de entrada,tan sólo. Dejemos entonces a las personas que visiten la Web requerir específicamente aquello que les interesa. ¿No era así como la Web debería funcionar?. Si, también en un teléfono móvil.

No envíemos más JSON del backend hacia el frontend, p.f.

No estamos construyendo una API. Cuando el cliente es un navegador Web ¿ y si se lo mandamos directamente?.

Hagamos toda la validación de usuario ejecutarse del lado del servidor.

Puedes construir una aplicación de tal manera que sólo requiera una petición (“single round trip”) al servidor para validar la entrada al usuario/a de una. No es necesario AJAX/JavaScript. Raramente JavaScript realmente mejora la experiencia de usuario/a (UX).

Más bien, a menudo, la validación JavaScript suele impactar en el flujo del website provocando que las teclas como TAB y otras cuestiones dejen de funcionar Si no estás haciendo la validación de datos de entrada en el servidor… algo se te te está escapando! Toda validación de datos de entrada de parte de cliente (en un esquema cliente-servidor) se hecho en JavaScript o realizado via HTML5 en el propio navegador web puede ser circumvalada, dado que está ejecutándose en el cliente, recuerdas ?

Dejemos de enviar fuentes (tipografías ) al navegador

Nadie les presta tanta atención, y pocos notarán la diferencia. Puedes hacer un test de usuario/a, te sorprendería. Dejemos que el navegador web elija.

Dejemos de hacer pasar al navegador por las CDNs.

Es peligroso e inseguro, compromete la privacidad y puede potencialmente dañar al usuario/a. ¿servir el contenido localmente?.

Abandonemos los anuncios (ads)

y prescindamos de popups, slideovers, subscripciones a mailing lists / newsletter , etc.

Ofrezcamos información clara y concise en el espacio web.

Evitamos así que el usuario/a tenga que rebuscar la respuestas a sus preguntas.

Stop al uso de Google Analytics, enlaces Facebook y demás «redes sociales»

.. basura en los espacios Web!

¿ Y si nos deshacemos de todo ello?. Además, ¿necesitamos realmente datos estadístics que ya están disponibles recolectados por el servidor? ¿no son suficientes?

Dejemos de usar lenguajes de programación no adecuados para el desarrollo web

Python y Ruby son dos lenguajes de programación que jamás deberían haber sido usados para ello, inadecuadamente. Aseguremonos de que el lenguaje de programación elegido ha sido optimizado a efectos de rendimiento.

Hagamonos cargo del software que desarrolles .

Al hacerlo, te responsabilizas de todo aquello que ocurre con el proyecto. Ello impacta directamente en la calidad del trabajo realizado y facilita un radical cambio de mentalidad. El impacto que tiene en el energéticamente en las computadoras y dispositivos de lxs usuarixs. Es tu responsabilidad. ¿El impacto en el medio ambiente? Es tu responsabilidad. ¿El impacto (en la llamada accesibilidad) en personas con cierta diversidad funcional(antes llamada ‘discapacidad’) ? Es tu responsabilidad.¿El impacto a futuro?. Es tu responsabilidad. Si no te apetece responsabilizarte ¿deberías entonces involucrarte en el desarrollo Web?.

Tomemos decisiones informadas. Recordemos que la mayoría de tendencias y «hype» son producidas por la ignorancia o por la gente que se lucra con aquellos que las siguen.

Quizás te parezca que este artículo pertenece al 2001, y no al año 2021, pero no es así, realmente. Más y máś desarrolladores web estamos despertando lentamente
y percibiendo que lo que hemos estado haciendo a lo largo de estos años con el llamado desarrollo web “moderno”. ¿ Voracidad de recursos computacionales tanto en lado del cliente como del servidor?. ¿Hagamos que eso sea historia?.

NOTA particular: en Librebits estamos aprendiendo a hacer desarrollo Web en Go (+ HTML5 + CSS3) , con el mínimo JavaScript en el frontend.