La cinta de correr del frontend
(polotek.net)- En los productos duraderos, el tiempo y la energía que se gastan discutiendo una reescritura terminan siendo un costo mayor que la elección del framework frontend
- Si el producto sigue vivo dentro de 5 años, será un éxito, pero en ese período el framework elegido probablemente se vuelva obsoleto o cambie de forma significativa con una nueva versión bajo el mismo nombre
- Los mejores equipos de producto, en vez de cambiarse a una herramienta nueva, entienden en profundidad el framework actual y elevan su dominio lo suficiente como para que la herramienta no bloquee el avance del trabajo
- Para reducir costos a largo plazo, elegir mantenerse cerca de la plataforma web y de las tecnologías web centrales, en lugar de abstracciones complejas, puede ser una concesión de negocio realista
- La complejidad del ecosistema frontend complica tanto a los desarrolladores junior como a los equipos de contratación, y los desarrolladores con bases web débiles quedan más vulnerables ante el próximo cambio de stack
Con una reescritura es difícil salir de la cinta de correr
- Muchos equipos frontend creen que una reescritura los llevará a un mejor estado, pero en productos de larga vida la elección del framework en sí no es la decisión técnica más importante
- Si un producto dura más de 5 años, puede considerarse un éxito; sin embargo, durante ese período, el framework elegido puede quedar obsoleto
- La comunidad frontend siempre se ha movido alrededor del cambio, y es poco probable que eso cambie pronto
- Incluso los frameworks populares que sobreviven pueden cambiar por completo por dentro y, bajo un nuevo número de versión, convertirse en una reescritura en la práctica
- En lo que el equipo debe enfocarse no es en perseguir herramientas nuevas y brillantes, sino en aprender lo suficiente el framework que ya usa
- Se necesita comprensión y dominio suficientes para que la herramienta no se vuelva un obstáculo para avanzar en el trabajo
- La expectativa de que cambiar a una herramienta alternativa resolverá los problemas se parece más a una trampa
Cuanto más cerca de la plataforma web, menores son los costos a largo plazo
- Si una empresa quiere reducir el costo de que las tecnologías frontend se vuelvan obsoletas con frecuencia, puede considerar una dirección más cercana a la plataforma web
- Hay que reducir abstracciones complejas y volver a aprender qué puede hacer realmente la web
- Esto no significa que sea la respuesta a todos los problemas ni que sea incondicionalmente mejor
- Puede ser una concesión de negocio que entregue más valor y reduzca costos a largo plazo
- Al mantenerse cerca de las tecnologías web centrales, se es menos vulnerable en el futuro al argumento de que, para que ingenieros competentes puedan trabajar, hay que reescribir millones de líneas de código
- Para los ingenieros en lo individual, entender en profundidad las tecnologías web centrales ayuda más al valor de mercado de largo plazo que seguir continuamente un framework específico
- Puede implicar renunciar a parte de la empleabilidad de corto plazo
- Es más favorable para la sostenibilidad de la carrera que intentar aprender todas las tecnologías populares
- Conocer una tecnología específica no protege frente a realidades como un deterioro del mercado
Preferencias de frameworks y costos para el equipo
- Los ingenieros con una fuerte preferencia por un framework deben reflejar ese criterio en sus condiciones de búsqueda laboral
- Si entran a un equipo que ya usa un framework específico y luego intentan migrarlo al framework que prefieren, desestabilizan al equipo y aumentan mucho los costos
- La complejidad del ecosistema frontend actual es una carga tanto para desarrolladores junior como para empresas
- A los desarrolladores junior les cuesta aprender habilidades suficientes para conseguir empleo y se sienten abrumados por herramientas complejas
- A las empresas incluso les resulta más difícil contratar desarrolladores generalistas, y también sube el umbral de entrada para puestos regulares de desarrollo
- Si quienes aprenden el ecosistema tecnológico actual no aprenden las bases web, pueden quedar en seria desventaja cuando el stack vuelva a cambiar
- La web es una plataforma capaz y única para entregar software; con el tiempo ha mejorado y ha mantenido un alto nivel de compatibilidad hacia atrás
- Las herramientas básicas actuales ya son suficientemente buenas, pero la capa de frameworks funciona en contra de la plataforma en lugar de adoptarla
1 comentarios
Opiniones de Hacker News
Hace poco trabajé en cambiar el sistema de build del código frontend de yarn a pnpm. Aunque normalmente soy ingeniero backend, también he tenido bastante experiencia con JS.
Lo más frustrante al meterse en frontend es que de verdad todo parece estar deprecated. Si en 2022 usabas Apollo CLI, enseguida queda deprecated y tienes que aprender una herramienta completamente distinta, como graphql-client, con configuraciones y opciones totalmente diferentes. Al final mantuve lo viejo y solo desactivé la verificación del motor de Node en pnpm para que dejara de quejarse. Si intentas hacer un patch upgrade de alguna dependencia, pueden romperse las firmas de tipos, así que también la dejé fija y puse un TODO en el codebase esperando que alguien lo arregle algún día.
Cuando por fin logras que corra, durante la instalación pasan cientos de advertencias de deprecated, y en cuanto termina el build te dan ganas de salir corriendo.
Me parece realmente extraño el grado en que todo el desarrollo frontend acepta así los cambios incompatibles y lo deprecated. He trabajado casi 4 años en un proyecto grande en Rust y en ese tiempo hubo algunos cambios incompatibles pequeños en librerías de terceros, pero solo un cambio importante que requirió modificar mucho la aplicación. En cambio, en JS parece que en menos de 6 meses ya tienes que reescribir algo.
El mundo frontend adoptó las redes sociales, YouTube e incluso Twitch mucho más activamente que otros campos. Estos influencers necesitan material nuevo constantemente para mantenerse relevantes, así que empujan sin parar cosas nuevas que puedan convertir en contenido.
A eso se suma una cultura de conferencias muy activa. Las conferencias de frontend y JS se sienten como una gran competencia por presentar el nuevo tema de moda.
También hay un gran mercado de venta de cursos de frontend. Los creadores de cursos tienen que lograr que tu jefe apruebe un curso en video de precio limitado de USD 700 para aprender la nueva tendencia, y para eso necesitan que la industria se aleje de lo viejo que todos ya conocen. Por eso empujan fuerte lo nuevo y vuelven deprecated lo viejo.
Una pequeña webapp de JS puro de 5 KLOC que escribí hace 15 años todavía la usan unas 10 personas todos los días sin haber cambiado una sola línea. De hecho, aguantó mejor que una aplicación Win32.
Creo que la mayor parte del churn en frontend es, simplemente, algo cercano a un fracaso político y organizacional.
Cuando empecé en la época de JS puro/jQuery, la gestión de dependencias era básicamente copiar archivos
.jsen el directoriovendor/. Después llegaron nodejs/npm; en frontend, antes de npm también se usaba bower, y de pronto el consejo estándar pasó a ser bajar módulos en vez de hacer las cosas uno mismo.Pero ya en ese entonces mucha gente se preguntaba si realmente tenía sentido no hacerse cargo de miles de líneas de código oculto y dejarlas en manos de voluntarios que hacen open source por diversión.
Incluso hoy, si quieres mantener un proyecto por mucho tiempo, puedes evitar que la parte invisible crezca demasiado. Puedes resolver problemas pequeños con un enfoque como: “solo necesito una función de esta librería, así que no dependamos de toda la librería; copiemos esa función al codebase y agreguémosle tests”.
Por eso creo que esto no es un problema de JavaScript en sí, sino un problema de personas y procesos. Hay muchos desarrolladores JS que no sufren estos problemas, pero una gran parte del ecosistema sí.
Cada día se gastan miles de horas-persona arreglando las consecuencias de cambios incompatibles “muy importantes”™, como: “¿Qué tal si cambiamos MultiselectDropdown a MultiSelectButtonDropdown? ¡Y de paso cambiemos la API por completo!”.
Casi no existe una cultura que entienda el enorme costo de romper APIs. Me resulta especialmente frustrante después de 10 años usando Go. Go tiene una promesa de compatibilidad hacia atrás, y eso parece influir también en la actitud de los desarrolladores de librerías de Go respecto de la compatibilidad y los cambios incompatibles. Que código escrito hace 10 años compile y funcione tal cual en la versión más reciente de Go es una experiencia realmente buena.
En algún momento me pasé a Flutter para escapar de este infierno de JS/web, y me encajó bastante bien; pude olvidarme de mucha complejidad accidental del stack web. Pero la cultura de “está bien romper paquetes” se está filtrando también en el ecosistema Dart, y eso es muy molesto.
Honestamente, creo que es mucho peor que frontend. En frontend, al menos TypeScript y las características del lenguaje mantienen el alcance del daño en un nivel relativamente sane. En Python puedes hacer, literalmente, cualquier cosa, y por eso los autores de librerías también hacen literalmente cualquier cosa. Si quieren cambiar la forma de importar módulos, la cambian; si quieren romper con metaclases todos los supuestos sobre el comportamiento de las clases, pueden hacerlo. Aunque creas que los tipos estáticos van a ayudar, ni siquiera algo trivial como
Partialfunciona, y tampoco se puede afirmar estáticamente que dos objetos sean del mismo tipo.Me da risa ver quejas porque una librería cambió. La transición de Python 2 a 3 fue tan horrible que en mi trabajo anterior había un monolito Python de 100 millones de líneas sin ningún plan de actualizar a Python 3. Pasar de SqlAlchemy 1 a 2 es una migración de 8 pasos y, en la práctica, una reescritura completa; si se rompe una sola cosa, el sitio se cae. Pero luego se quejan de que React agregó hooks de forma opcional.
Lo raro es que internet está lleno de artículos sobre la “cinta de correr del frontend”, pero casi no se ven textos quejándose del otro lado.
Sobre la frase “si eres ingeniero, cuanto más profundamente entiendas las tecnologías web fundamentales, mayor valor de mercado podrás mantener con el paso del tiempo”, creo que tengo derecho a opinar, ya que llevo casi 20 años en frontend y pasé por varios cambios grandes de paradigma.
Es cierto que conocer todas las tecnologías web fundamentales te convierte en un ingeniero más equilibrado. Pero soy escéptico sobre si eso te hace ver más atractivo en el mercado laboral. No porque ese conocimiento no importe, sino porque quienes toman decisiones de contratación por lo general hacen pattern matching.
Si quieres maximizar tu “valor de mercado”, todavía tienes que ser muy bueno en React. Es casi como el boleto de entrada básico; lo demás es excelente, pero si no tienes esa base, tus opciones se reducen. Quizá eso era lo que quería decir el autor y yo lo leí mal.
Dicho eso, en roles de consultoría o por contrato estoy de acuerdo con el comentario original. Si trabajas con personas de grandes consultoras que contratan o deciden a quién entrevistar, verás que descartan casi automáticamente a quien no conozca ya el stack que prefieren o el que usa su cliente actual. También lo hacen los arquitectos técnicos, así que no es solo un problema de reclutadores no técnicos. No quieren dedicar tiempo a que alguien se adapte a la tecnología en sí, sin importar su nivel de experiencia.
En estos roles es muy importante mantenerse al día. De lo contrario, el gerente de contratación tira el CV por no encontrar buzzwords antes de que un ingeniero siquiera evalúe la capacidad real.
Tal vez sea un caso raro, pero no saber React nunca fue un problema para mí. Decir “boleto de entrada básico” me parece demasiado fuerte.
El frontend tiene un techo bastante firme en compensación. Cuando pasas de cierto nivel, ya no necesitas volver a construir UI.
La mayoría de las empresas, incluso las grandes, no se preocupan demasiado por los fundamentos básicos, ni los verifican, ni contratan con base en ellos. Contratan con criterios como “es bueno en React” o “tiene mucha experiencia con Next.js”.
Los fundamentos son excelentes cuando construyes algo desde cero, pero las empresas reales casi nunca hacen eso. Por lo general toman soluciones ya hechas con ecosistemas grandes y buena documentación. Si eres bueno con esas cosas, te contratan mucho más fácilmente, y los fundamentos los puedes aprender en el camino.
La frase “cualquier framework que elijas quedará obsoleto en 5 años” suena como un argumento algo viejo.
No soy principalmente desarrollador frontend, pero cuando hago frontend no lo evito, y he usado React durante unos 10 años. Parte del ambiente se está moviendo hacia Svelte, pero para cuando Svelte supere a React, probablemente Svelte también ya habrá sido usado en producción durante mucho tiempo. Angular también podría perder fuerza algún día, pero si contamos la época de Angular1 junto con Angular2+, es más antiguo que React.
Es cierto que el desarrollo frontend avanza rápido, pero no es tan terrible. Si eliges opciones aburridas, obtienes resultados aburridos.
Angular1 y 2 eran tan distintos que casi no se podían comparar salvo por el nombre, y muchos desarrolladores se quemaron con eso. Angular en sí también está cambiando bastante. No es tan extremo como el salto de v1 a Angular2, pero aun así requiere una readaptación considerable. Todo se está moviendo hacia standalone components, nueva sintaxis de templates, signals, etc.
Con React pasa algo parecido. Con la llegada de los componentes funcionales y los hooks hubo un gran cambio de paradigma. Eran compatibles, pero muy distintos entre sí.
Lo mismo ocurre con los paradigmas más generales. Al principio todo era server-side rendering, luego se corrió con todo hacia las single-page apps, y después se volvió al server-side rendering, pero esta vez como server-side rendering parcial con hydration.
Es tan diferente que podría llamarse otro framework, así que, aunque hay matices, ese argumento no está completamente muerto.
Es realmente simple trabajar con él. Hice una app sencilla de asignación de acciones, y lo que más me sorprendió fue el tamaño del bundle. Era 9KB con gzip, más pequeño que cualquier framework que conozca. Incluso más pequeño que htmx, que hasta cierto punto es casi “anti-JS”.
Los frameworks antiguos pueden seguir ejecutándose durante muchísimo tiempo. Mientras exista gente que conozca ese stack y se la pueda contratar para trabajar cuando haga falta, ese stack no está obsoleto. Puede ser “viejo” o “legacy”. Pero hasta que llegue el día en que no quede nadie que pueda manejarlo, no está obsoleto.
Es interesante que a esto lo llamen un problema de frontend. No es un problema de frontend, sino el problema de que sigan entrando nuevos participantes a un ecosistema enorme.
Vi exactamente lo mismo hace 15 años, cuando Java estaba en la primera línea de la innovación. En pocos años aparecieron decenas de frameworks y varios sistemas de build. El cambio de React 17 a 18 es mucho menor que pasar de Perl 5 a 6, o de Python 2 a 3.
En backend, en vez de “usemos un framework nuevo”, aparece “usemos un lenguaje nuevo”. La moda actual es reescribir cosas en Rust, y antes estuvieron Go, Haskell, Scala y F#.
Si te parece molesto mover código frontend de React a algo como Svelte, prueba reescribir una app en VB 6. Ni hablar de cosas como RPC con los datos metidos dentro del código.
No quiero decir que la inestabilidad de las prácticas de ingeniería no sea un problema. Es un gran problema. Pero no es exclusivo del frontend.
webpack también tiene 13 años, pero incluso en los últimos años cambió drásticamente la forma de configurarlo.
Si la configuración de Apache cambiara con tanta frecuencia como la de estos sistemas, nadie usaría Apache.
En mi trabajo anterior hubo dos migraciones de base de datos en dos años, y se gastó en total un año de tiempo de ingeniería. No eran algunas tablas no esenciales: eran todas las tablas. Si algo se rompía o la gerencia preguntaba por qué todo iba tan lento, culpaban a los ingenieros que estaban aprendiendo frontend, diciendo que les faltaba experiencia.
Trabajé como desarrollador Java durante más de 25 años; durante los primeros poco más de 10 años hice desarrollo full stack, que era la forma habitual en las empresas de entonces. Ahora lo normal es tener un equipo separado de frontend, y muchas veces incluso tres equipos: web, iOS y Android. Para mí, ese cambio ocurrió más o menos en la época del paso de AngularJS a Angular.
Java también cambió rápido durante sus primeros 10 años, y especialmente rápido durante los primeros 3. Pero esa etapa terminó. Java 5 fue un cambio grande y Java 8 también tuvo funciones importantes, pero Java 8 es de 2014. Mi equipo recién se pasó hace poco a Java 11, y ahora ya salió Java 24. Nunca usé funciones de Java 11 y ni siquiera sé cuáles son. En 10 años no aprendí ni una sola función nueva del lenguaje.
Las herramientas de build son las mismas desde hace 15 años, y el IDE es el mismo desde hace 20. El framework principal que uso también es el mismo desde hace 10 años. Cuando me cambié a mi último trabajo, la estructura del codebase era exactamente igual a la del equipo anterior.
Crear servicios web con Java es un problema resuelto. Es completamente aburrido en el buen sentido, como COBOL.
El frontend cambiaba rápido a fines de los 90 y principios de los 2000, pero siguió cambiando rápido después. Un proyecto personal de UI que hice hace unos años quedó completamente obsoleto.
Si fuera un proyecto Java en el que trabajé después de la era EJB, hoy se podría encontrar un desarrollador Java, incorporarlo y sería productivo de inmediato. Incluso si esa persona nació después de que se creó el proyecto. Solo tendría que aprender algunas bibliotecas viejas.
La forma de bajarse de la caminadora es no usar ningún framework de frontend. No elegir otro framework cualquiera para luego reescribir todo otra vez.
Se necesita server-side rendering, JavaScript solo cuando haga falta, y una forma de trabajar en la empresa que no separe al personal de backend y frontend.
Si un ingeniero puede escribir SQL para traer exactamente las columnas necesarias para una vista web SSR y también hacerse responsable de esa vista web, no hace falta pensar ni un segundo en cosas como APIs u ORMs. Solo hay que saber SQL y HTML/CSS/JS moderno y puro. La mayor parte del trabajo termina siendo transformar vistas del negocio (SQL) en DOM (HTML), y el ecosistema de programación del lado servidor pasa a segundo plano.
Creo que la forma final es hacer SSR de contenido web dentro del RDBMS. Algo como Oracle APEX. Pero la mayoría de los ingenieros todavía no está lista para tener esa conversación. A mí también me pasó cuando lo vi por primera vez en un entorno real. Estamos demasiado apegados a nuestras formas de sufrir.
Empeoró el problema de la complejidad excesiva en el frontend. Como hay gente en el equipo de frontend, siguen generando trabajo y agregando complejidad. También es un problema que haya demasiada gente que solo sabe desarrollo web y nada más.
En un proyecto lateral, una de las restricciones iniciales que puse fue que todo el sitio debía degradarse elegantemente aunque JavaScript estuviera desactivado. Eso hizo que cada vez que quería agregar una función que normalmente se haría con JavaScript me preguntara: “¿se puede hacer esto sin JavaScript?”. Hasta ahora, sorprendentemente, la respuesta siempre fue sí.
Solo con selectores CSS sobre controles HTML básicos se puede hacer muchísimo hoy en día. En ese codebase todavía no hay ni una línea de JS.
Los equipos de producto/diseño pueden presionar para meter la mayor cantidad posible de adornos en JavaScript, sin considerar en absoluto la usabilidad, el rendimiento, la accesibilidad ni la buena ingeniería.
Yo no soy bueno en frontend y tampoco tengo diseñador. Soy mucho mejor en backend, pero otras personas del equipo tienen más talento que yo para el diseño frontend.
Al crear mi primer sitio web, leía cosas como “Svelte es mejor que React” o “solid-js será la próxima gran tendencia”, y pensaba que eso era una parte importante del desarrollo web.
A los principiantes les conviene leer MDN e ignorar lo demás.
La gente necesita tutoriales y walkthroughs, y construir una comprensión interna de cómo funciona todo esto.
Los frameworks ayudan a abstraer esas partes.
Pero quizá no sea el caso de la reciente obsesión con Next.js y SSR. Personalmente, creo que eso incluso podría ser un factor de declive para el lado de React.
Si pensamos en cómo han avanzado JS y CSS puros en los últimos años, y en que funciones interesantes como animar
display: noneya están casi en etapa de adopción, generar HTML con templates en el servidor y usar JS solo donde hace falta parece más razonable que nunca.Lo digo como alguien que vive principalmente de React.
Igual que el autor, llevo 20 años haciendo frontend de una u otra forma. El ecosistema, el churn y las acrobacias para sincronizar el estado entre frontend y backend son una locura.
Hace poco empecé un proyecto de prueba de concepto con Go templates y HTMX, tratando de aproximar la sensación de construir UI con “componentes” como en React. Todavía tiene muchas asperezas, pero hay potencial. Sinceramente, aún no estoy seguro de si HTMX es necesario. Empecé a gestionar event listeners directamente y creo que eso me gusta más.
Curiosamente, manejar estados de UI complejos basados en roles y permisos de usuario es mucho más fácil en el servidor. Solo envías el HTML que el usuario puede ver y listo.
Aun así, React, Vue y otros tienen un impulso enorme. No sé cómo podría empezar un cambio colectivo de mentalidad. Más aún considerando que muchos desarrolladores solo conocen frameworks frontend como forma de crear UI.
No sé qué tan cierta sea la frase “cualquier framework que elijas quedará obsoleto en 5 años”.
Llevo más de 10 años usando React profesionalmente.
package.json? ¿Qué versión de node/npm usa el equipo?Si usan una versión lo bastante reciente y librerías populares, seguramente han visto cómo se acumulan avisos de deprecated sobre dependencias transitivas durante
npm install.Para ser justos, creo que el código de React en sí ha mantenido bastante bien la compatibilidad hacia atrás. No es culpa de React. Pero todos los sistemas de build que se usaban hace 5 años cambiaron y rompieron compatibilidad. También me había olvidado de los métodos del ciclo de vida de los componentes.
Incluso un proyecto tan bien mantenido como React no puede escapar del desorden de su ecosistema.
No siempre se puede elegir, pero últimamente suelo optar por importar JS puro sin sistema de build, manejar todo lo posible en el backend con Python/Django y salirme por completo del ecosistema JavaScript. Nunca me arrepentí.
¿Sigues teniendo la app en React 15?
Todos los editores WYSIWYG que funcionan con React 16 ya no tienen soporte. Si se encuentra un problema de seguridad, quedamos “a la suerte”. O directamente no deberíamos usarlos.
React 16 todavía tiene soporte, pero definitivamente está obsoleto.
El contraargumento es que, si no adoptas un framework, terminas creando un framework propio que la gente fuera del equipo no entiende, que por lo general está mal documentado, y en el que tienes que seguir trabajando para agregar funciones que ya existen en frameworks establecidos.
En frontend hay funciones que se necesitan en común y problemas comunes que resolver. ¿No es mejor empezar al menos con algo ya puesto en lugar de empezar desde cero?
Como nadie ha visto el framework interno, es imposible encontrar a alguien que pueda ser productivo de inmediato. Incluso si la documentación está muy bien hecha, lleva tiempo aprenderlo e internalizarlo. Si es una contratación a largo plazo no es lo peor, pero si de pronto necesitas más desarrolladores temporalmente, no hay salida.
Lo escribí también en otro lado, pero aunque casi todos quieren una webapp o creen que tienen una webapp, en realidad la mayoría de las veces solo es un sitio web dinámico. No hace falta apilar frameworks para construir un sitio web dinámico.
Esto no es un problema de frontend, sino un problema del ecosistema JS. También pasa en backend.
El entorno JS es un caos total, con dependencias que tienen decenas o cientos de otras dependencias. Por ejemplo, el grafo de dependencias de Platformatic, un framework de Node basado en Fastify, es el siguiente:
https://npmgraph.js.org/?q=platformatic#zoom=h
Estas dependencias pueden ser abandonadas en cualquier momento. Incluso dependencias gigantes como Axios o Express alguna vez parecieron quedar desatendidas.
Además, cada dependencia queda bajo el criterio de lo que su mantenedor considera correcto. Hace unos días, una dependencia que usamos en producción —con alrededor de 25 millones de descargas semanales, mientras React ronda los 26 millones, y usada en 10 millones de repositorios de GitHub— decidió que estaba bien dejar de dar soporte a una versión de Safari de hace unos 3 años. Considerando que Safari tiene más del 50% de cuota del mercado móvil en EE. UU., es una verdadera locura.