Si quieres crear un botón desde cero, primero debes crear el universo
Recrear desde cero algo tan simple como un botón en la web moderna expone cuánta conducta, accesibilidad y matiz entre dispositivos ya proporcionan los controles HTML nativos, y lo fácil que es equivocarse en esos detalles. Los comentaristas debaten por qué los widgets nativos más ricos (como un combobox real) llevan décadas estancados, apuntando a la política de los navegadores, a estándares incómodos como Web Components y a la tensión entre el HTML de “documento” y las interfaces tipo aplicación. La accesibilidad surge a la vez como una preocupación técnica y ética genuina y como un campo minado legal, con algunos argumentando que la IA y herramientas más inteligentes pronto manejarán gran parte de esta complejidad, mientras otros advierten que delegarla en agentes opacos podría empeorar la usabilidad, la privacidad y la fiabilidad.
Sátira, botones y complejidad de accesibilidad
- Muchos consideran que el artículo es acertado, pese a estar enmarcado como sátira: reimplementar un botón adecuado es sorprendentemente difícil.
- Algunos lectores lo encontraron educativo, ya que dependían de frameworks y no conocían muchas preocupaciones de accesibilidad.
- Otros señalan que el código de ejemplo todavía tiene fallos (por ejemplo, lógica incorrecta de pointer/mouse-up), lo que refuerza el punto de que hacerlo “bien” es complicado.
HTML nativo vs componentes personalizados y widgets faltantes
- Varios argumentan que los widgets complejos (por ejemplo, comboboxes con filtrado del lado del servidor) son difíciles o imposibles de hacer solo con HTML nativo, lo que empuja a los desarrolladores hacia implementaciones personalizadas.
<input>+<datalist>se cita como una solución parcial de combobox, pero la actualización dinámica/eficiente y un comportamiento más rico siguen siendo lagunas.- Frustra que HTML todavía carezca de muchos widgets de nivel superior que los toolkits nativos tenían hace décadas.
Proveedores de navegadores, estándares y estancamiento
- Algunos culpan a todos los navegadores principales del lento progreso hacia componentes nativos de HTML sin JavaScript.
- Otros rechazan las afirmaciones de que Apple bloquee de forma única el progreso, señalando estándares como Open UI y filosofías distintas sobre velocidad frente a seguridad.
- Se discute la negativa de Safari a admitir la extensión de built-ins (por ejemplo,
class MyButton extends HTMLButtonElement); los críticos dicen que eso obliga a una reimplementación completa en lugar de una personalización ligera.
La web frente a la “web semántica” y las necesidades de las aplicaciones
- Los comentaristas distinguen entre la “web semántica” centrada en documentos y las aplicaciones web altamente interactivas.
- Los requisitos de negocio y de UX a menudo divergen de lo que ofrecen los controles de formulario nativos; cumplir esas expectativas con elementos nativos puros se considera impráctico o demasiado costoso.
Impacto de la IA en la UI y la accesibilidad
- Un bando sostiene que la IA ahora hace trivial generar componentes complejos y accesibles, junto con pruebas, desde cero, debilitando el argumento de “no reinventes el botón”.
- Otros responden que la IA repite errores comunes (por ejemplo, usar botones incorrectamente para la navegación), no cubre automáticamente todos los casos límite y puede fomentar la sobrecarga de código.
- Algunos informan buenas experiencias pidiendo a LLMs que adapten la accesibilidad en aplicaciones existentes; otros temen que los modelos entrenados con “código basura” propaguen malos patrones.
Cumplimiento de accesibilidad, demandas y preocupaciones sobre el “racket”
- Se comparte una historia sobre una demanda por accesibilidad que llevó a cambios costosos, en gran medida superficiales, y a suscripciones continuas de “cumplimiento”.
- Hay debate sobre si futuros lectores de pantalla/agentes de IA harán menos relevante el cumplimiento técnico estricto, frente a leyes e incentivos que mantendrán el sistema actual en su lugar.