No puedo evitar identificarme bastante con el problema del desperdicio de espacio en disco...
Opero AKS, y cada vez que veo una app de Python con una imagen de contenedor que supera 1 GB, me duele la cabeza.
Por ahora simplemente tomo prestado el Dockerfile, vuelvo a reducir yo mismo el tamaño y lo subo; si no logro bajarlo de 500 MB, simplemente me rindo jaja
¡Guau...! Fue un proyecto que usé al principio porque era Python...
¡Ha pasado muchísimo tiempo!
Ojalá pudiera volver a trabajar en un entorno donde lo pueda usar :) jajaja
¿Será que hago algo side?
A mí también me siguieron apareciendo notificaciones push de Android diciendo que no se podía acceder al servidor DNS.
Por un momento me refugié en Google DNS. https://developers.google.com/speed/public-dns/…
Con una sola máquina increíble a un precio increíble debería bastar, ¿no? Un bufete increíble seguramente la compraría. Pero sería como hacer funcionar maquinaria de fábrica las 24 horas, jajaja.
La intención original del artículo no es simplemente criticar los frameworks de JS que se han vuelto más complejos.
Para mayor comodidad, citaré desde el enlace de la traducción al coreano que aparece arriba.
> Ahora, incluso para cambiar un simple título, se necesitan 4 ingenieros, 3 frameworks y un pipeline de CI/CD. Publicar una página web se ha vuelto absurdamente complejo.
> Así, gradualmente, la web se convirtió en algo que hay que compilar antes de publicar. No porque los usuarios lo necesitaran, sino porque los desarrolladores querían sentirse modernos.
> Todo se ha optimizado para los desarrolladores, y es hostil para todos los demás.
> Ya no solo toleramos la complejidad: la damos por sentada. Asumimos que todos los sitios necesitan una etapa de build, un bundler, una estrategia de hidratación, una capa de routing, una capa de API, un sistema de diseño y una lógica sofisticada de invalidación de caché. Construimos con microservicios, hospedamos en redes edge y desplegamos pipelines para entregar contenido simple.
> Estamos reconstruyendo las funciones de plataformas como WordPress, pero con un resultado 10 veces más pesado y mucho menos usable. Peor aún, cada nueva capa introduce nuevos bugs, nuevos problemas de compatibilidad y una nueva carga cognitiva. Ahora mantenemos lógica de hidratación, estrategias de caché y pipelines de build solo para poner una página de inicio en línea.
> Las campañas de marketing se retrasan porque la librería de componentes no es lo suficientemente flexible. Las pruebas A/B se cancelan porque la capa de analítica no es compatible con la estrategia de hidratación. Las actualizaciones de contenido tienen que esperar días por un build. Los ajustes básicos de SEO terminan enterrados en el backlog.
> Los marketers no pueden actualizar textos ni ejecutar experimentos sin abrir un ticket. No pueden previsualizar contenido, probar layouts ni publicar páginas. Todos los cambios tienen que pasar por desarrolladores, pipelines, aprobaciones y reconstrucciones.
> Marketers, editores de contenido, especialistas en SEO y diseñadores: todos quedan excluidos del proceso. Porque ahora incluso las tareas simples requieren fluidez técnica. Si quieres cambiar una title tag, te dirán que hables con un ingeniero; si quieres lanzar una campaña, que abras un ticket y esperes dos sprints.
> Todo fluye a través del equipo de desarrollo. Es decir, el equipo de desarrollo decide qué es importante, qué se despliega y qué queda indefinidamente relegado en la lista de prioridades. Y mientras más complejidad agregan, más indispensables se vuelven.
Coincido con el problema de la “complejidad excesiva de la web” que señala el artículo original. Pero me cuesta estar de acuerdo con el diagnóstico que atribuye esa causa únicamente a la cultura de desarrollo o al abuso de frameworks. La complejidad de la web actual es, en gran medida, la sombra de funciones y seguridad inevitables que exige el “modelo de negocio”. Si se omite ese punto, el diagnóstico inevitablemente queda a medias.
La web ya no es una “sala de exhibición gratuita”. Hoy, salvo los sitios públicos, la mayoría de los servicios web tienen como objetivo generar ingresos. Por eso, la pregunta clave al elegir tecnología no debería ser “¿este código es puro?”, sino “¿esta tecnología ayuda a que nuestro negocio tenga éxito?”.
Visto desde esa perspectiva, la “web ligera de contenido” que el artículo idealiza termina chocando con la pared de las exigencias reales del negocio. Por ejemplo, un negocio que vende contenido no puede operar solo con páginas estáticas simples. Para gestionar suscripciones pagadas y pagos, se necesita lógica basada en estado, como autenticación de usuarios, verificación del estado de la suscripción y gestión de permisos; y para proteger el contenido, también es indispensable una capa de seguridad con validación de tokens en tiempo real para impedir la piratería o el acceso no autorizado. Además, si se busca mejorar la experiencia de usuario y la conversión mediante personalización y pruebas A/B, también se requiere procesamiento dinámico de datos.
Todo eso pertenece al terreno de las “aplicaciones sofisticadas”, y los frameworks son herramientas realistas para implementarlas.
Por supuesto, no toda complejidad puede justificarse. Debemos distinguir entre dos tipos de complejidad.
Complejidad inevitable: es la complejidad con un ROI claro que surge al implementar funciones de negocio (autenticación, pagos, personalización, etc.). Es un costo que hay que asumir.
Complejidad accidental: es la complejidad innecesaria que aparece por conveniencia del desarrollo o por una abstracción tecnológica excesiva. Es deuda técnica y desperdicio que deben medirse y eliminarse de forma continua.
Los servicios exitosos distinguen entre ambas y construyen arquitecturas realistas. Es decir, hacen lo más liviano posible el frente de cara al público, donde el marketing y el SEO son importantes, y aseguran estabilidad con una base de frameworks en las áreas internas donde se necesitan transacciones críticas o funciones de personalización, adoptando una estrategia híbrida que les permite atrapar a la vez dos objetivos: velocidad y funcionalidad.
El artículo original se concentra solo en la cultura de frameworks como causa del deterioro de la experiencia de usuario, dejando fuera las “exigencias inevitables que trae el modelo de ingresos”. Hablar del desarrollo web sin considerar ese punto no es muy distinto de hablar solo de servir “comida rápida y sabrosa” en la mesa del cliente, mientras se hace como si no existieran la cocina compleja donde se prepara ni la caja donde se cobra.
Que la web se haya vuelto pesada no significa que podamos desechar los frameworks sin más. Creo que la discusión debería centrarse en cómo implementar, de la forma más eficiente y con el menor costo posible, las funciones que exige el negocio para entregar valor al usuario.
En servicios como los chatbots que necesitan ofrecer funcionalidad de streaming, cuando hay procesamiento simultáneo, el trabajo de prefill termina afectando incluso al decode, así que aunque haya VRAM de sobra, desde la perspectiva del usuario parece que el rendimiento baja muchísimo.
Probé opciones relacionadas con chunked prefill y también la función experimental de Disaggregated Prefilling que ofrece vLLM, pero aun así, cuando entra una nueva solicitud, sigue pasando que las respuestas que ya se estaban generando se cortan a cada rato. Como desarrollador principiante, me pregunto si existe un método más eficiente, aparte de aumentar la cantidad de GPU o de nodos.
En Android, si usas Vanced, puedes ocultar la interfaz de comentarios; se los recomiendo.
En el navegador web, les recomiendo ocultarla con algo como Improve YouTube o AdGuard.
No puedo evitar identificarme bastante con el problema del
desperdicio de espacio en disco...Opero AKS, y cada vez que veo una app de Python con una imagen de contenedor que supera 1 GB, me duele la cabeza.
Por ahora simplemente tomo prestado el Dockerfile, vuelvo a reducir yo mismo el tamaño y lo subo; si no logro bajarlo de 500 MB, simplemente me rindo jaja
¡Guau...! Fue un proyecto que usé al principio porque era Python...
¡Ha pasado muchísimo tiempo!
Ojalá pudiera volver a trabajar en un entorno donde lo pueda usar :) jajaja
¿Será que hago algo side?
¿Compararlo con Claude 3 justo cuando salió Claude 4 no es casi un engaño...?
Desde alrededor de las 7:00 a. m., hora de Corea, estuvo caído unos 50 minutos, pero ahora ya funciona bien.
CMD> nslookup news.hada.io 1.1.1.1
A mí también me siguieron apareciendo notificaciones push de Android diciendo que no se podía acceder al servidor DNS.
Por un momento me refugié en Google DNS.
https://developers.google.com/speed/public-dns/…
guau...
Sí, parece que cuanto más profundizas en cuál es el objetivo y por qué hay que hacerlo, más clara se vuelve la solución.
¡Gracias por leer el artículo con tanta buena disposición!
¡Muchas gracias por sus palabras!
Con una sola máquina increíble a un precio increíble debería bastar, ¿no? Un bufete increíble seguramente la compraría. Pero sería como hacer funcionar maquinaria de fábrica las 24 horas, jajaja.
Una persona que solo piensa en el precio de un Porsche y no considera para nada los costos de mantenimiento, gasolina, seguro, etc.
La intención original del artículo no es simplemente criticar los frameworks de JS que se han vuelto más complejos.
Para mayor comodidad, citaré desde el enlace de la traducción al coreano que aparece arriba.
> Ahora, incluso para cambiar un simple título, se necesitan 4 ingenieros, 3 frameworks y un pipeline de CI/CD. Publicar una página web se ha vuelto absurdamente complejo.
> Así, gradualmente, la web se convirtió en algo que hay que compilar antes de publicar. No porque los usuarios lo necesitaran, sino porque los desarrolladores querían sentirse modernos.
> Todo se ha optimizado para los desarrolladores, y es hostil para todos los demás.
> Ya no solo toleramos la complejidad: la damos por sentada. Asumimos que todos los sitios necesitan una etapa de build, un bundler, una estrategia de hidratación, una capa de routing, una capa de API, un sistema de diseño y una lógica sofisticada de invalidación de caché. Construimos con microservicios, hospedamos en redes edge y desplegamos pipelines para entregar contenido simple.
> Estamos reconstruyendo las funciones de plataformas como WordPress, pero con un resultado 10 veces más pesado y mucho menos usable. Peor aún, cada nueva capa introduce nuevos bugs, nuevos problemas de compatibilidad y una nueva carga cognitiva. Ahora mantenemos lógica de hidratación, estrategias de caché y pipelines de build solo para poner una página de inicio en línea.
> Las campañas de marketing se retrasan porque la librería de componentes no es lo suficientemente flexible. Las pruebas A/B se cancelan porque la capa de analítica no es compatible con la estrategia de hidratación. Las actualizaciones de contenido tienen que esperar días por un build. Los ajustes básicos de SEO terminan enterrados en el backlog.
> Los marketers no pueden actualizar textos ni ejecutar experimentos sin abrir un ticket. No pueden previsualizar contenido, probar layouts ni publicar páginas. Todos los cambios tienen que pasar por desarrolladores, pipelines, aprobaciones y reconstrucciones.
> Marketers, editores de contenido, especialistas en SEO y diseñadores: todos quedan excluidos del proceso. Porque ahora incluso las tareas simples requieren fluidez técnica. Si quieres cambiar una title tag, te dirán que hables con un ingeniero; si quieres lanzar una campaña, que abras un ticket y esperes dos sprints.
> Todo fluye a través del equipo de desarrollo. Es decir, el equipo de desarrollo decide qué es importante, qué se despliega y qué queda indefinidamente relegado en la lista de prioridades. Y mientras más complejidad agregan, más indispensables se vuelven.
No creo que aplique a las empresas coreanas.
Coincido con el problema de la “complejidad excesiva de la web” que señala el artículo original. Pero me cuesta estar de acuerdo con el diagnóstico que atribuye esa causa únicamente a la cultura de desarrollo o al abuso de frameworks. La complejidad de la web actual es, en gran medida, la sombra de funciones y seguridad inevitables que exige el “modelo de negocio”. Si se omite ese punto, el diagnóstico inevitablemente queda a medias.
La web ya no es una “sala de exhibición gratuita”. Hoy, salvo los sitios públicos, la mayoría de los servicios web tienen como objetivo generar ingresos. Por eso, la pregunta clave al elegir tecnología no debería ser “¿este código es puro?”, sino “¿esta tecnología ayuda a que nuestro negocio tenga éxito?”.
Visto desde esa perspectiva, la “web ligera de contenido” que el artículo idealiza termina chocando con la pared de las exigencias reales del negocio. Por ejemplo, un negocio que vende contenido no puede operar solo con páginas estáticas simples. Para gestionar suscripciones pagadas y pagos, se necesita lógica basada en estado, como autenticación de usuarios, verificación del estado de la suscripción y gestión de permisos; y para proteger el contenido, también es indispensable una capa de seguridad con validación de tokens en tiempo real para impedir la piratería o el acceso no autorizado. Además, si se busca mejorar la experiencia de usuario y la conversión mediante personalización y pruebas A/B, también se requiere procesamiento dinámico de datos.
Todo eso pertenece al terreno de las “aplicaciones sofisticadas”, y los frameworks son herramientas realistas para implementarlas.
Por supuesto, no toda complejidad puede justificarse. Debemos distinguir entre dos tipos de complejidad.
Complejidad inevitable: es la complejidad con un ROI claro que surge al implementar funciones de negocio (autenticación, pagos, personalización, etc.). Es un costo que hay que asumir.
Complejidad accidental: es la complejidad innecesaria que aparece por conveniencia del desarrollo o por una abstracción tecnológica excesiva. Es deuda técnica y desperdicio que deben medirse y eliminarse de forma continua.
Los servicios exitosos distinguen entre ambas y construyen arquitecturas realistas. Es decir, hacen lo más liviano posible el frente de cara al público, donde el marketing y el SEO son importantes, y aseguran estabilidad con una base de frameworks en las áreas internas donde se necesitan transacciones críticas o funciones de personalización, adoptando una estrategia híbrida que les permite atrapar a la vez dos objetivos: velocidad y funcionalidad.
El artículo original se concentra solo en la cultura de frameworks como causa del deterioro de la experiencia de usuario, dejando fuera las “exigencias inevitables que trae el modelo de ingresos”. Hablar del desarrollo web sin considerar ese punto no es muy distinto de hablar solo de servir “comida rápida y sabrosa” en la mesa del cliente, mientras se hace como si no existieran la cocina compleja donde se prepara ni la caja donde se cobra.
Que la web se haya vuelto pesada no significa que podamos desechar los frameworks sin más. Creo que la discusión debería centrarse en cómo implementar, de la forma más eficiente y con el menor costo posible, las funciones que exige el negocio para entregar valor al usuario.
En servicios como los chatbots que necesitan ofrecer funcionalidad de streaming, cuando hay procesamiento simultáneo, el trabajo de prefill termina afectando incluso al decode, así que aunque haya VRAM de sobra, desde la perspectiva del usuario parece que el rendimiento baja muchísimo.
Probé opciones relacionadas con chunked prefill y también la función experimental de Disaggregated Prefilling que ofrece vLLM, pero aun así, cuando entra una nueva solicitud, sigue pasando que las respuestas que ya se estaban generando se cortan a cada rato. Como desarrollador principiante, me pregunto si existe un método más eficiente, aparte de aumentar la cantidad de GPU o de nodos.
¿No es más bien una postura de asumir responsabilidad? Personalmente, creo que sí comparto la dirección general de Google.
Yo también estoy de acuerdo. No sé si es una doble moral. Pero dejan los que están bien hechos.
No entiendo por qué lo llaman una actitud de doble rasero...
En Android, si usas Vanced, puedes ocultar la interfaz de comentarios; se los recomiendo.
En el navegador web, les recomiendo ocultarla con algo como Improve YouTube o AdGuard.
Todo depende del caso.