¿Por qué más desarrolladores no “usan la plataforma”?
Muchos desarrolladores web siguen prefiriendo frameworks al estilo React y widgets personalizados por encima de las funciones nativas del navegador, argumentando que “la plataforma” ha sido históricamente inconsistente, insuficiente para las necesidades reales de UX y difícil de usar directamente. Se citan ejemplos como `<dialog>`, los selectores nativos de fecha/hora, `<datalist>` y Web Components como elementos con fallos, inflexibles o inaccesibles entre navegadores, mientras que las exigencias de diseño y los requisitos de producto suelen ir más allá de lo que los controles integrados pueden hacer. Otros responden que el HTML/CSS/JS modernos han mejorado y pueden sustituir gran parte del tooling intensivo en JavaScript, pero reconocen que el impulso del ecosistema, la documentación y las abstracciones existentes dificultan volver a las primitivas del navegador.
Limitaciones percibidas de las funciones nativas del navegador
- Muchos widgets nativos (inputs de fecha/hora,
<dialog>,<datalist>, multiselección, comboboxes) se consideran demasiado limitados o inflexibles para requisitos del mundo real (por ejemplo, deshabilitar fechas arbitrarias, listas buscables, programación solo en días laborables). - El drag-and-drop nativo y algunos controles de formularios se comportan mal o de forma inconsistente entre navegadores y dispositivos (iOS Safari, errores de Firefox, casos límite extraños como “99 minutos” en campos de hora).
- A menudo, los desarrolladores descubren que rápidamente “superan” los elementos nativos y terminan reimplementándolos en JS de todos modos.
Web Components vs Frameworks
- Los Web Components son ampliamente criticados por ser incómodos, de bajo nivel y difíciles de usar directamente (boilerplate, atributos frente a propiedades, gestión de estado, problemas con Shadow DOM, estilos/resets).
- Muchos sienten que, en la práctica, necesitas una biblioteca envoltorio como Lit o Stencil; en ese punto, se parece a usar React, solo con trade-offs distintos.
- Otros defienden los Web Components como bloques de construcción de alto rendimiento, pero reconocen una integración áspera con la plataforma más amplia y la falta de APIs ergonómicas.
Experiencia de desarrollador, historia y efectos del ecosistema
- Históricamente, la plataforma era débil; bibliotecas desde jQuery hasta React llenaron enormes vacíos y acostumbraron a los desarrolladores a recurrir a npm en lugar de a las especificaciones.
- El éxito de React se atribuye menos a una superioridad técnica pura y más a una documentación excelente, materiales de enseñanza, conferencias e impulso del ecosistema.
- Una vez que una tecnología gana atención, su comunidad (ejemplos, soporte, componentes) refuerza su dominio incluso si las alternativas tienen algunas propiedades mejores.
Accesibilidad, UX y requisitos de producto
- Los equipos a menudo abandonan los widgets nativos porque no pueden igualar los diseños de UX/branding ni las expectativas de accesibilidad (gestión del foco, comportamiento del teclado, lectores de pantalla).
- Los controles personalizados suelen estar más rotos en algunos dispositivos, pero los diseñadores y PMs siguen exigiendo una UI a medida; los ingenieros se sienten obligados a alejarse de los valores predeterminados de la plataforma.
Inconsistencias del navegador y confianza en la plataforma
- Implementaciones inconsistentes o con fallos (especialmente Safari y versiones antiguas) hacen que los desarrolladores desconfíen de depender de “la plataforma”.
- Los polyfills, workarounds y los largos plazos de los estándares incentivan resolver problemas en JS, donde los equipos tienen control total y pueden publicar correcciones de inmediato.
IA, abstracción y “usar la plataforma”
- Algunos usan IA para generar sitios mayormente nativos y con poco JS; otros señalan que aún necesitas un conocimiento profundo de la plataforma para depurar los errores de la IA.
- Varios argumentan que HTML/CSS/DOM son, en efecto, un ensamblador de bajo nivel; los frameworks y los patrones reactivos se ven como la forma práctica de gestionar estado y complejidad.