Prólogo
¡Feliz año nuevo! 2025 ha sido uno de aquellos que categorizo como el “ha pasado todo y al mismo tiempo no ha pasado nada”. En el panorama general todo se fue al carajo mientras en lo personal tampoco es que me haya ido de maravilla: tras dos meses de búsqueda conseguí empleo en bendito home office por una paga miserable pero que compensa las dos horas mínimo que desperdiciaría en transporte, aunque esto ha provocado un aumento de estilo de vida sedentario y unas cada vez menores energías en salir a tocar pasto y tener contacto humano, porque aunque no lo parezca… vivimos en la era de la automatización; una época donde tenemos todo y nada a la vez.
En parte es mi trabajo el motivo de por qué me desaparecí un año completo de hacer entradas y ya dos años de hacer videos.
Peeeeero estando ya un año y pocos meses trabajando en la industria tecnológica he de decir que ha sido bastante duro y -para adentrarnos en el punto central del escrito- aborrecible al punto donde condeno ferozmente cualquier momento en donde todos hayan decidido que la tecnología podía ser la solución final a todos nuestros problemas. ¿A qué me refiero? Bien, todos sabemos que en estos momentos (puede que ya no tanto en primer mundo pero sí al menos en el resto) se ha acelerado esta tendencia de digitalizar todos los procesos burocráticos y actividades de modo que se optimiza en su máximo posible el sistema -refiriéndome a este último como un proceso de fases para solventar una problemática o brindar una solución, siendo un ejemplo el sistema de servicio de una cadena de comida rápida-.
Y justamente tengo demasiadas quejas sobre cómo la industria tecnológica está haciendo más mal que bien a la sociedad (siendo trabajador y al mismo tiempo consumidor de esta); literalmente podríamos hacer un compendio de áreas donde ha afectado antes que beneficiado su existencia, pero el día de hoy quiero enfocarme en criticar lo que he vivido de primera mano… para ello debo todavía hablar un poco de mí y al mismo tiempo dar mi argumento.
Primera parte: La web está literalmente en todo lados
Fue bastante curioso ver cómo Windows 11 se ha estado autodestruyendo lentamente al punto donde me creía imposible ver cómo Linux aún teniendo su sistema igualmente bloateado tenga más optimización. Primero lo viví de primera mano cuando instalando el SO de Microsoft a un equipo al que iba a configurar para un punto de venta y verlo arrancar me pidió forzosamente una cuenta Microsoft para continuar bajo una interfaz que sospechosamente me pareció haber visto en otros dispositivos que no fueran desktop, y posteriormente notar al primer arranque un consumo inicial de casi 5GB de RAM de los 16 que tenía de base el equipo. Esto me impactó porque eso es lo que de normal consumo usando Linux en mi laptop teniendo 10 pestañas de navegador, mi editor de código y mi suite de ofimática.
¿Pero esto qué tiene que ver con la parte del desarrollo web? Bueno, pues no es novedad saber que hoy en día varias partes de Windows 11 (como la barra de aplicaciones) están creados con componentes react [native], que es una librería de JavaScript usada para hacer componentes interactivos con estados en la web. Esto puede que parezca raro de primera mano ¿Cómo un componente web puede instanciarse como una aplicación de escritorio? Eso quisiera describirlo en la siguiente parte, pero básicamente existen formas de hacer que lo que construyes en web se desplieguen como aplicaciones de escritorio, y eso es un problema.
¿No recordamos a caso por qué existían las apps de escitorio en los viejos tiempos? Bueno, al tener equipos con un límite de recursos y un entorno descentralizado donde aún la web teniendo la posibilidad de hacer aplicaciones completas no se percibía como una ventaja, había equipos de trabajadores que desarrollaban dichas aplicaciones en web, mientras otros compartían parte de los recursos para diseñar las versiones de escritorio en lenguajes nativos (como Visual Basic y similares pero más modernos), y al mismo tiempo otro equipo desarrollando la versión para smartphones. Esto hacía que el foco del desarrollo se centrara en la optimización de recursos, pero evidentemente tenía un severo problema: se estaba trabajando el triple por una sola versión, y eso cuesta más dinero del necesario, por lo que lentamente fueron haciendo cambios en la infraestructura para que todo fuera desarrollado en web.
Este es un esquema que se repite en varias ocasiones: muchas de las aplicaciones que se ven en dispositivos móviles, PCs de escritorio, en sitios web y a veces hasta en televisores son básicamente el mismo proyecto de desarrollo web pero empaquetados para que sean su propia instancia. Esto ocasiona cosas positivas, como que ahora el trabajo se reduce y si algún componente falla se pueda solucionar más rápidamente para todas las versiones o que se optimice el flujo de trabajo, pero ocasiona igualmente demasiados problemas los cuales acaba pagando el usuario final, siendo ese el motivo de mi odio a las aplicaciones que se empaquetan como web. ¿Por qué? Resumiendo:
Limitaciones arbitrarias según dispositivo
¿Por qué no puedo alejarme de tener un maldito celular? Ya hablaré de ello en otra ocasión, pero el principal motivo de por qué pese a que detesto con toda mi vida Android (y los smartphones en general) es porque hay aplicaciones importantísimas en mi día a día y sólo se pueden usar ahí… a pesar de que básicamente están construidas a partir de lo mismo.
Ejemplos tengo dos, una app que no uso en mobile y otra que es forzosa:
- ¿Cómo no nos hemos dado cuenta de que abrir la ‘aplicación’ de Twitter/X y verla en navegador es básicamente lo mismo? Yo me había fijado de ello en el pasado pero realmente no le había dado importancia. Pero no fue sino hasta ahora que mi teléfono se alenta por tener más de dos aplicaciones abiertas que lo noto de forma grotesca: abrir la app de twitter es básicamente como abrir un navegador por aparte y que se redirija al sitio. Antes que ser óptimo se vuelve tedioso porque además de estar cargando de más los recursos del celular tienes que andar gestionando visualmente dos procesos que se podrían distribuir fácilmente en pestañas del navegador; evidentemente ponen barreras que te obligan a usar su mugre aplicación -como lo hace Reddit- y eso hace casi obligatorio para algunos el tener instaladas estas apps.
- La que más me parece un insulto: yo suelo utilizar MercadoPago, y usar la aplicación es horrible porque en ocasiones va lenta pero igual es usable, sin embargo ¿Qué pasa si quiero no nada más ver mi dinero sino gestionar mi tarjeta de crédito desde el sitio web? PUES QUE TE JODES, la web no te muestra esas opciones aún a pesar de que se nota a leguas que están construídas en prácticamente el mismo proyecto; no hay necesidad de limitar al usuario de esa forma, y más para aquellos que no gustamos de tener literal nuestra vida registrada en un rectángulo.
ESTÁS USANDO UN MINI-NAVEGADOR PARA SERVIR LA APLICACIÓN
Básicamente eso es lo que se hace. ¿Que no te gusta abrir Whatsapp en web porque qué flojera pero prefieres usar la aplicación de escritorio? Pues eres retrasado porque son lo mismo. Pero no es que coexistan en los mismos procesos y de ahí se optimice el uso de memoria, sino que son su propio navegador. Es decir, al abrir una aplicación ‘de escritorio’ sólamente mandas a llamar frameworks que abren un mini-navegador empaquetado con la versión web de lo que estás ejecutando.
Hay dos en concreto que se usan (aunque realmente hay más): Electron y WebView2. El primero es un framework de Javascript que utiliza chromium (el proyecto bajo el que está creado Chrome) y sobre este construye y pinta toda la interfaz de la plataforma web, mientras el segundo es básicamente lo mismo pero para el entorno de Microsoft. Según la documentación de ambos realmente no tendrían por qué estar mal optimizados pues por sí solos rara vez llegan a pasar del consumo de memoria/CPU/GPU en megabytes y tienen apartados hablando sobre formas de mejorar el uso de recursos, por lo que normalmente se le echa la culpa a las propias aplicaciones que lo usan. Sin embargo me permito cuestionar esto pues consideremos que usar cosas como chromium (un proyecto que usa un motor web extremadamente pesado porque toda la web ya es pesada de por sí) y que esté usando sus propios recursos aislados (es decir que si tuviésemos la “aplicación” y aparte un navegador abierto ambos trabajarían bajo procesos que no se comparten), me hacen pensar que tan óptimo para el usuario no es.
Ambas tecnologías se venden como “lo mejor para el desarrollador” pues prácticamente se está ahorrando la mitad del trabajo, pero consideremos que las aplicaciones que lo usan ya de por sí son pesadas. La noticia de que whatsapp y discord llegaban a alcanzar hasta los 4GB de RAM cada uno es preocupante, pues acaba demandando al consumidor que no sea un tacaño y compre más memoria cuando en la práctica debería ser lo opuesto. Motivos de por qué existen estos consumos excesivos hay demasiados, pero lo más probable es que tengan fugas de memoria y/o tengan en caché demasiada información o estén ejecutando demasiados procesos a la vez (transmisión + recuperación de mensajes + multimedia + estados + configuraciones + llamadas constantes al servidor + Javascript + telemetría).
Y sí, en ocasiones no es culpa de que la aplicación está mal optimizada sino que la infraestructura está construida sobre un alfiler o toma las peores decisiones que acaba pagando el consumidor. Un ejemplo es el caso de Linux: antes todos los paquetes/aplicaciones que necesitabas ejecutar se podían conseguir mediante lo que se llamaba un gestor de paquetes, el cuál contenía lo justo y necesario además que si contenía dependencias de procesos los mandaba a llamar y los utilizaba en conjunto; pero con el paso del tiempo se fue popularizando ‘flatpak’ que es básicamente un framework para construir aplicaciones de escritorio Linux que fuera agnóstico al gestor de paquetes o distribución que se manejara, trayendo ventajas como la portabilidad/‘universalidad’ de las aplicaciones, pero su mayor inconveniente es que ejecuta sus propias instancias como entornos aislados, provocando que tenga sus propios procesos duplicados ejecutándose de manera aislada, supuestamente para mejorar la seguridad pero también provoca un incremento desmedido en la utilización de recursos.
- Ejemplo de esto último: Mi laptop tiene 12GB de RAM y cuando solía usar la versión de flatpak de ungoogled chromium acababa consumiendo casi 8GB de memoria en poco menos de 15 pestañas, mientras que su versión portable con la misma cantidad consume a lo sumo poco más de la mitad. Porque efectivamente, este problema de la optimización no es únicamente de Windows sino uno de infraestructura.
Segunda parte: la infraestructura no prioriza la optimización
En el mundo del desarrollo web se tiene principalmente una prioridad: que las cosas se deben lanzar rápido y bien. Es una infraestructura donde los productos de milagro funcionan ya que los tiempos de desarrollo suelen ser demasiado cortos por la filosofía establecida en SCRUM de “falla pero hazlo rápido” y “haz despliegues e integración contínuos”. Esto es algo que posiblemente ahonde en otra parte, pero lo que provoca es que los desarrollos tengan que optimizarse pero no por la parte de coditectura, sino mayormente en las formas de trabajo, implementaciones y estándares.
Los tres puntos anteriores se complementan, pues se optimizan en las formas de trabajo porque se rigen bajo calendarios donde un fallo grave puede provocar un atraso en la cadena de producción; se optimizan las implementaciones pues la infraestructura puede o ser preferente a un stack tecnológico o los procesos automatizados lo están pero bajo un estándar en concreto; y precisamente se optimizan los estándares porque utilizar varios lenguajes o librerías para un solo desarrollo toma tiempo en hacerse y a largo plazo es complejo de mantener, además hay equipos grandes trabajando en lo mismo y para evitar complicaciones se normaliza un lenguaje/framework o un stack tecnológico en concreto sin posibilidad de cambios.
Esto es algo que la gente y sobre todo el consumidor final pasan de largo y optan por culpar al desarrollador, cuando realmente es otra víctima más de cómo funciona la industria. El desarrollador en la teoría es aquel que sabe lo que tiene que hacer, define la infraestructura y toma decisiones aún si los dueños o clientes no están de acuerdo con tal de entregar un producto de calidad; pero la realidad es que en casi todos los casos su puesto se resume en solucionar tickets y mostrar entregables. Es un obrero de una fábrica, sólo que la única diferencia es que no hace productos tangibles, sino proyectos digitales.
Y no es que lo diga de forma resentida, pues que en casos como proyectos pequeños o con equipos de trabajo reducidos podemos hacer cambios radicales y eso es genial, pero en proyectos de gran escala donde varios equipos están trabajando en los mismos módulos esto no es posible porque el más mínimo cambio que se salga de lo establecido puede romper el avance y atrasar las entregas. Mi crítica es entonces que esa industria creativa que trataban de vender estos gurús vendecursos resulta ser más bien una dedicada a hacer más en el menor todo (tiempo, dinero, personal) posible. No les sorprenda entonces que muchos desarrolladores utilicen IA para generar código y sacar las cosas a tiempo.
Y sobre todo esto de que se acabe normalizando un solo stack tecnológico concreto o una sola tecnología para desarrollar todo el proyecto me parece peligroso y uno de los motivos de por qué toda aplicación se siente pesada, lenta, tosca incluso teniendo esas animaciónes que disimulan tener un comportamiento instantáneo y veloz. Para desarrollar mi punto sobre esto necesito hacer dos pequeños interludios, uno hablando sobre mi forma de trabajo en este blog y otro sobre cómo aprendí a no menospreciar los frameworks y tecnologías web modernas. juro que ambos se complementan.
Interludio: ¿Por qué tardo tanto en subir contenido? y una recomendación de Astro
¿Por qué tardo (y en este año que pasó tardé) en subir entradas? Bien, no es tanto tema de falta de tiempo pues mis más de 5000 videos vistos en youtube durante todo 2025 demuestran lo contrario, sino que me daba flojera actualizar o subir entradas porque hacer todo el proceso de modificar el blog es tardado ya de por sí. No nada más es escribir y ya, sino que mi proceso se resumía en:
Escribir el markdown -> Migrarlo a HTML -> Crear una nueva página con el esqueleto del blog (header, banner, licencia, etc.) -> Volcar el html a la página y corregir errores semánticos -> modificar la página del listado de entradas por fecha -> modificar la página de listado de entradas por categoría -> actualizar el index -> subir
Era un proceso tedioso que me tomaba horas en realizar y pocas ganas me quedaban, pero consideraba que era la única forma de hacer de este proyecto uno genuino porque solía arremeter contra la idea de usar tecnologías que dependieran de cosas como ‘npm’ -que es un gestor de paquetes- y frameworks y librerías de desarrollo; yo pensaba que mientras se hicieran las cosas en html+css+js puro era más que suficiente. Luego en mi trabajo aprendí de la existencia de astro. Este es un framework de desarrollo de páginas estáticas que funciona básicamente igual a cosas como HUGO o Wordpress , pero su principal diferencia radica en que está diseñado para ser flexible y óptimo.
- Flexible en sentido que se puede integrar componentes de librerías modernas como React o Vue pero sin necesidad de que todo el proyecto lo use, sino sólamente los componentes que se requieran (lo que llama como ‘arquitectura de islas’), además de estar listo para implementarse a cosas como Vercel.
- Óptimo porque está creado bajo la idea de usar la menor cantidad de Javascript para su construcción y para consumir la menor cantidad de memoria posible. Como muestra de ello, la versión anterior de mi blog (2.0) pesaba 16MB mientras la presente (3.0) sólo pesa la mitad (7.8MB). OJO, que esto no significa que el proyecto en sí pese lo suyo, pues por dependencias y todo sí llega a pesar fácilmente hasta 200MB, pero lo que yo me refiero es que el producto final -ya construído- está optimizado para ser ligero. siendo este el que pesa menos de 10MB.
Y mejor aún, está planteado bajo el concepto de ser componetizable y poder gestionar tus contenidos de forma automática, haciendo que todo mi proceso de actualización de este blog ahora se resuma a
Escribir el markdown -> buildear el proyecto (npm run build) -> subirlo
¡Pasar de 8 pasos manuales a únicamente 3! Es una maravilla y desde que descubrí esto aprendí a amar no solamente Astro sino los frameworks modernos.
¿Por qué no deberíamos despotricar tanto contra los frameworks y librerías modernas?
Mucha atención a este sub-capítulo, pues servirá como precedente para la siguiente parte.
Nuevamente, trabajar en la industria me ha demostrado que así como tenía muchos prejuicios hacia el desarrollo web que eran certeros, también tenía sesgos que no me dejaban avanzar de ninguna forma, y una de ellas fue haber criticado con toda mi alma todas las librerías, paquetes y frameworks ( en su mayoría frontend). No es que sean todos buenos ni todos malos, sino que se tienen que aprender a usar con matices.
Durante mi trabajo en un desarrollo que estaba haciendo me llegaron a regañar por hacer que todos mis componentes fueran react porque según yo ayudaría con la interacción del usuario y trabajaría menos para mantenerlo a futuro (lo que normalmente te enseñan a decir en estos cursos de udemy y la documentación oficial). Mi jefe me dijo algo que me dejó con la boca abierta y me hizo entender que el problema no era (totalmente) ni de los desarrolladores ni de las aplicaciones y posiblemente tampoco del motor web bajo los que trabajan Firefox y Chromium:
No sirve de nada hacer todo con react porque este sólo sirve para cuando necesitamos guardar estados y que el usuario interactúe con éste. Recuerda cuando hicimos [módulo], que sólo los botones y los inputs los hicimos con react porque no tiene sentido que todo lo demás no se hiciera con Astro porque no dependían (de estos). Además por eso definimos en la arquitectura que [componente] se haría en estático mientras los botones con react, pues mandarle al cliente que renderice todo acaba sobrecargando la página más de lo que debería
Desde ese entonces entendí todo: no se basa en que todos deberíamos dejar de usar estas tecnologías, pues si no hubiera sido por descubrir Astro posiblemente no hubiera vuelto a escribir una entrada nueva en todavía más meses y si no fuera por haber usado react en sólo lo necesario en mi trabajo no tendríamos un proyecto en el que la carga de recursos se reparte entre lo que ya se le entrega al cliente y lo que este tiene que renderizar por aparte.
¿Por qué entonces es mala idea usar al 100% estas librerías o frameworks si no son entonces las culpables del bloat existente en la web moderna? Bueno, esto último es medio trampa, pues consideremos que componentes como los de React son pesados por dos motivos en particular: renderizan del lado del cliente y su base es JavaScript. Para explicar esto mejor darme a entender con estos:
- Cuando se visita un sitio web lo que suceden son fundamentalmente dos actividades: renderizado del lado del servidor y del lado del cliente. El primero significa que cuando el usuario hace la petición el servidor ya debe mandar la página precargada a este y sólo desplegarla tal y como es; el segundo implica que se manda una ‘página carcasa’ sin casi nada de contenido más código en Javascript que construye el contenido inyectándolo a la página.
- Una web con HTML + CSS de base suele ser ligera (salvo que contenga demasiados elementos pesados como imágenes o videos); pero lo que puede llegar a sobrecargarlo más es la inyección de demasiado JavaScript. Como nuevamente mencioné, librerías como React fundamentalmente es Javascript inyectable y si se usa en demasía provoca que se acabe sobrecargando la página con scripts.
Entonces con esto podemos percibir que la culpa no es tanto por los desarrolladores ni por las tecnologías. Mi experiencia me ha demostrado que las cosas existen porque solucionan algún problema que era común antes, y entonces podríamos estar llegando al posible culpable de que la industria tecnológica del lado de la web esté tan mal como está.
Tercera parte: los modelos de negocio obligan a la sobrecarga
¿Podemos recordar cuando cité todos esos multiprocesos que hacen las aplicaciones que provocan un incremento de uso de memoria?
(transmisión + recuperación de mensajes + multimedia + estados + configuraciones + llamadas constantes al servidor + Javascript + telemetría).
Pues bien, yo como persona con una perspectiva de vida minimalista debo decir que me parece una de las peores “cualidades” que obtuvo Internet. Si la gente se queja de ver en todos lados un uso innecesario de IA y chatbots, yo quiero ir un paso más allá y decir que además la gran mayoría de estas ni siquiera deberían tener todas las mencionadas anteriormente. Si uno se pone a pensar es un despercidio impresionante de recursos hechos únicamente porque es lo que dicta el nuevo esquema de desarrollo.
En alguna ocasión aquellos entusiastas de la web antigua han llegado a declarar su odio a la web masivamente pesada y cargada. Se les puede criticar del hecho de que en muchas ocasiones exageran al pedir páginas que literalmente son hojas en blanco con dos imágenes y toneladas de texto, pues muchos servicios directamente no podrían funcionar así. Pero pongámonos a cuestionar ¿Por qué muchas páginas no podrían hacerlo? porque directamente no ganan nada de la caridad de tener un sitio en línea. Precisamente la burbuja de las dotcom demostró en su tiempo que tener una página para todo no significa que tienes ganancias ilimitadas, sino que debe estar conectado a un servicio donde verdaderamente haga creer al consumidor que obtiene algo a cambio, sea verdad o simple efecto placebo. De hecho el mercado en ese entonces explotó porque no había forma de percibir si verdaderamente se recaudaban las ganancias que prometían, y aunque ese tiempo ya pasó me gusta la idea que dice que realmente no hemos salido de la burbuja sino que símplemente encontró formas de inflarse todavía más.
¿Que cómo? Entrar a cualquier sitio web más allá de las clásicas y notar que a día de hoy es casi imposible navegarlas como hace 20 años puede demostrarlo. Si hoy en día entras a un sitio cualquiera sin tener instalado un bloqueador de anuncios ya de por sí hace torpe la experiencia de navegación, peor se pone si empiezas a tirar del hilo y notas que casi toda web moderna tiene un sistema de tipo usuarios, donde para poder tener información completa, contenido exclusivo y demás basura entonces necesitas registrarte y -si la casualidad da- de paso anotar tus datos bancarios para tener todavía más acceso a todavía más contenido.
Páginas con trackers a montones, sitios que tienen el esquema SPA (Single Page Aplication) que consiste en tener una sola página renderizando todo el proyecto dependiendo de lo que el usuario esté solicitando, servicios que se llaman en tiempo real para poder desplegar contenidos que ni siquiera se sienten necesarios, junto con montañas de anuncios y APIs de redes sociales, monitoreo y pasarelas de pago provocan que exista básicamente todo excepto una web verdaderamente óptima y de calidad; pues todo está diseñado para generar ganancias antes que ser esa pista de la información que vendían hace décadas.
¿Y si da la sorpresa de que la web es totalmente gratuita? Pues tampoco se salva uno; ponerse a ver el inspector de elementos, clickear en la pestaña network y hacer filtrado por scripts o Fetch/XHR demuestran la pesadez que un sitio puede cargar de base. Hasta eso ni siquiera es necesario, al usuario promedio se le da de primera mano muros completos que impiden que uses el sitio que estás viendo de forma cómoda sin antes plagarte de una advertencia que te incentiva con patrones oscuros a aceptar todas las cookies y scripts de telemetría que no nada más registran tu ip, sino encima tu actividad para poder personalizar sistemas de recomendación y anuncios de terceros.
De hecho esa información es tan valiosa para las empresas y la web en general que hacen literalmente todo lo que tengan en mano para que aceptes a toda costa este sistema de recomendación y anuncios. Es por esto que cuando ves una página de noticias, un feed de una red social o una simple receta te acabas topando con literales murallas que no paran de crecer por más que scrollees hasta el tope; no nada más alimentando la maquinaria de “mientras más se registre mejor”, sino que de plano se incentiva a través de ingeniería social con cosas como la castración de nuestro sistema de recompensa al implementar diseños visualmente atractivos, chillones y con estilos establecidos para promover la aleatoriedad.
No es que en cualquier proyecto requieran un sistema de cookies para recordar datos de formulario y completarlos de forma rápida por comodidad del usuario, pues eso se puede hacer fácilmente con mil herramientas que te da el propio navegador, sino que con el tiempo esos “servicios” crecerán para poder implementar anuncios y cookies externas y así monetizar a través de visualizaciones, sistemas de retención, promociones y patrocinios, modelos de suscripción e insaciables motivantes para que revises la “aplicación” porque ahí pueden controlar de mejor forma dichos sistemas gracias a la permisividad de Android y iOS.
Pongámonos a pensar ¿Por qué Discord, Whatsapp, Reddit y demás son aplicaciones gratuitas? Evidentemente no porque la caridad llegó a las puertas de las empresas matrices. ¿Cómo ganan entonces dinero si rara vez veo anuncios en ellos? Es una pregunta común, pero raramente es clara la respuesta pues de base -como todo- estos modelos de negocio están ofuscados para que parezcan inofensivos al cliente, mientras por detrás tienen esa gran obtención de ganancias. En casi todas las ocasiones es porque la data que obtienen es más poderosa de lo que parece, aún si no poseen información sensible.
Así que no es mentira cuando se dice que el usuario ES el producto, porque no sólamente es eso, sino que lo es y aparte se les lobotomiza para hacerles creer que no es problemático y no debería de ser una cuestión para tomar cautela y ser cuidadosos. Directamente no eres un producto, eres el engrane de la maquinaria.
La cruz que toca cargar
Esta es una sección que pongo un poco de último momento y a regañadientes, pues cuanto menos lo esperé me puse a ver la cantidad de RAM que suelen utilizar mis entradas para poder cerciorarme de que fuera un blog accesible, pero resulta ser que nada de eso es verdad para las entradas en donde pongo videos de youtube incrustados.
Esto me molesta pues de normal no habría necesidad de implementar este tipo de inyecciones que de por sí son pesadas porque es básicamente abrir una pestaña dentro de la misma pestaña del navegador. Supongo la única ventaja es que consume menos memoria que si abrieras Youtube directamente; ejemplo de ello es lo que he notado mi entrada más pesada: la de mi reseña al álbum de Lámina Once; abrir dicha entrada consume por lo menos unos 590MB de RAM, lo que suena a demasiado y más porque tiene 8 incrustaciones a Youtube. Peeero si lo comparamos a abrir dichos videos en su respectiva página, que por cada video serían al menos 400MB entonces tendríamos una clara ventaja al hacer inyección de video antes que sólo poner un enlace.
¿Que por qué es una cruz que toca cargar? En ocasiones este tipo de implementaciones pesadas las veo necesarias por el bien del contexto, pues de nada sirve -por ejemplo- tener un blog donde hablas sobre contenido audiovisual sin siquiera tener referencias; con el cine y la literatura no me preocupa pues suelo hablar de contenido relativamente sencillo de encontrar y que hasta sinopsis te pueden dar un referente; mientras que en la música es una barrera puesto que indicar qué hace que algo suene bien o mal, que la letra te haga sentir algo o fallos técnicos o creativos reducidos a texto no hace justicia a dar como mínimo una fuente donde la persona pueda entender por qué se dice lo que se dice.
Esto puede llegar a suceder con otro tipo de sitios, y es por eso que llegaría a entender que plataformas como Bandcamp tengan el consumo de recursos que tienen. Buenamente podrían aligerarla pues sus algoritmos de recomendación básicamente no sirven para una plataforma que ya de por sí se usa para descubrir música nueva, pero ¿Que consuma menos que una web que contiene puro texto? Casi imposible. Con esto no estoy defendiendo a servicios que son pesados por el mero gusto, sino razonando que en ocasiones por más que se intente aligerar la carga de la web la forma en la que se usa hoy en día hace esto básicamente una lucha contra la marea del mar abierto. Es más sencillo aprender a vivir sin ella que intentar optimizarla y esto último es lo que suelo recomendar: el dejar de abrir tantas pestañas para usar servicios que son puro humo, pura basura que soluciona estupideces o de plano no soluciona nada.
Algo bueno que ha traído el desarrollo web
Aunque no lo parezca, realmente este campo no es del todo malo y no nada más se debería de resumir en “urr malo maloso”, pues hay una ventaja severa que provoca que todos quieran diseñar en web antes que en cualquier otra cosa. Como bien sabemos la base de la web es la famosa trinidad de lenguajes de desarrollo: HTML + CSS + JavaScript:
- El primero [HTML] es un lenguaje de marcado, útil para dar semántica a la web y que todo se despliegue en documento. Lo más similar en eficiencia que se tiene a HTML es Markdown o TeX.
- El segundo [CSS] es un lenguaje de estilos que proporciona diseño y en tiempos modernos algo de interacción y comportamiento a lo diseñado en el primero. Ambos se complementan demasiado bien para dar por resultado desde pequeños detalles estéticos a las páginas, hasta cosas demenciales como animaciones complejas. Pero lo que hace que todo esto tenga sentido es
- El tercero [JS], el cuál es un lenguaje de programación que describe el comportamiento de los dos anteriores. Es tan poderoso que puede generar interacciones cuasi infinitas; aquel que sepa dominar javascript será requerido en el desarrollo web sí o sí.
Pues bien ¿Qué diferencia esto con lenguajes o frameworks que trabajaban o se usan y siguen usando para desarrollo de aplicaciones de escritorio o móbiles nativas? no existe algo similar para estas, evidentemente hay herramientas y kits de desarrollo (GTK, SwiftUI, JavaFX, .NET MAUI) incluso algunas que trabajan de forma declarativa al igual que con este stack mítico (QT+QML, XAML), pero ninguno se le acerca a la forma tan fácil y accesible de desarrollar que tienen los primeros. Al no existir un estándar y que básicamente la mayoría de apps nativas necesitan de IDE (o entornos de desarrollo con interfaz) para poder construirse se vuelve incómodo y a la larga inviable. Es este el motivo de por qué desarrollar en web es tan cómodo y sencillo y por eso mismo se opta por reempaquetar a aplicación de escritorio y mobile antes que rehacer todo desde cero.
Y de hecho tampoco es como que las aplicaciones web sean malas per se, pues básicamente en nuestro día a día usamos estas -que son instancias de la versión web- pero de tan bien desarrolladas que están no se percibe; normalmente nos damos cuenta que éstas son versiones empaquetadas cuando se notan lo mal hechas. Un ejemplo (positivo) diría que es Visual Studio Code (la versión VSCodium) que pese a que sí consume algo así como 300MB de RAM, es tan ligero como para ser su propia instancia que incluso en una laptop con 4GB de RAM y un procesador i3 de tercera generación trabaja bien.
¿A quién culpar?
Yo personalmente culparía a cómo es que la propia industria trabaja. Muchos nos vemos apresurados a sacar entregables en tiempos récord sin tomar en consideración lo que se está generando; en alguna ocasión leí a un antiguo ingeniero de software quejarse de esto, hablando sobre cómo al presentarle al cliente formas de optimización éste prefería centrarse en fulanitos que sacaban código con deuda técnica en velocidad récord. Esto significa que el campo te obliga a ser una máquina -aunque siendo sincero, en todos lados se te obliga a eso bajo la excusa de la productividad-.
Si entonces todas estas herramientas que facilitan los desarrollos y existen modelos de negocio que se supone mejoran nuestras vidas tanto en la programación como del lado consumidor ¿Por qué seguimos haciendo las cosas mal? ¿Por qué las cadenas se ajustan cada vez más en un mundo donde debería de hacerse lo opuesto? Actualmente somos más productivos que hace varias décadas y eso no se traduce en mejores condiciones ni puestos, por lo que ¿Cuál es la necesidad de yo preocuparme por una industria que me exige ir a mil por hora aprendiendo las nuevas tecnologías y consumiendo mi tiempo para que se cumplan calendarios estrictos y brindar soluciones que arreglan problemas que nosotros mismos creamos?
Igualmente deberíamos de apuntar directamente con ambos dedos a los modelos de negocio extremadamente abusivos que buscan implementar “soluciones” de tráfico, recomendaciones y murallas de pago para poder monetizar hasta el último centavo de cada persona, poniendo a la venta información que nos hace únicos y nos convierte en una masa sin identidad y controlable. Y todo esto para… ¿Productos que en retrospectiva no ofrecen nada sustancial?.
Porque esa es otra: tenemos un montón de propuestas de aplicaciones y demás que ofrecen soluciones a cosas que directamente ya no tienen sentido solucionar de dichas formas, y más si tienen implementado un modelo de suscripción. Dígase por ejemplo un reproductor de música, una alarma digital o una utilidad que ya existen en las aplicaciones por defecto del celular o escritorio y que encima cobren por ello. Yo particularmente creo que, si ya existe una opción FOSS nativa o en web que solucione un problema genuino o que no pueda solucionar manualmente con lápiz y papel, entonces no veo motivo que exista otra aplicación web empaquetada que finja ser la solución definitiva a nuestros problemas (igual puede que ahonde más a detalle en otra ocasión de esto).
Recomendaciones
- USAR LAS MALDITAS VERSIONES WEB: No ganamos nada usando las aplicaciones de escritorio porque la cuota de recursos se paga dos veces haciendo esto, mientras que las versiones web al estar compartiendo recursos entre pestañas y que -dependiendo cómo tengas configurado el navegador- se pueden inhabilitar o liberar memoria, resultan ser más óptimas y viables de usar sobre todo en equipos de menos recursos.
- Pensar dos veces antes de usar una plataforma: esto es básicamente un consejo de estilo de vida, pues si de por sí a veces son innecesarias más de la mitad de las compras que hacemos, todavía es peor usando aplicaciones o proyectos web. ¿Que si usar una nueva red social que se puso de moda? No es una forma más de comunicarte ni informarte, porque las alternativas que de verdad funcionan no están ahí; ¿Que si buscamos una app que gestione nuestras otras apps? Además de considerar ultra inútil andar teniendo demasiadas suscripciones, la mejor opción sería gestionarlas manualmente o domiciliar pagos desde las aplicaciones que ya tienes para gestionar la fuente y no el recurso -pues si haces esto último tan necesaria no es-. Es decir, descartar plataformas que consumen una barbaridad de recursos y usan un montón de scripts y sistemas de espionaje a sólamente las que sean necesarias.
- Para los devs: establecer mejores infraestructuras: Sé que es prioritario tener un proyecto funcional antes que uno optimizado (y más para mí que no soy ni de chiste un buen programador), y ese es precisamente el problema. Si se usan frameworks y scripts en cosas que no se necesitan se termina por optimizar el proceso de desarrollo y la mantenibilidad pero se pierde en hacer las cosas bien. Yo por mi parte si llegara a desarrollar algo (ya sea solo o con un equipo) será siempre con la mentalidad de hacer las cosas lo más minimalista posible y sólamente usar scripts y demás para lo justo y necesario; y eso es a lo que instaría a todos a hacer.
Fuentes
Modern bloated websites causing low end devices struggle
RAM prices soar but popular Windows 11 apps are using more ram due to electron web components
Discord admits windows 11 app hogs ram and tries solving it with auto restarts
Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial 4.0 Internacional.