Durante años, los defensores de los estándares web, el rendimiento y la accesibilidad han instado a los desarrolladores web a 'usar la plataforma' — es decir, a confiar en las capacidades integradas del navegador en lugar de crear soluciones personalizadas o recurrir a bibliotecas. El argumento es sencillo: ¿por qué construir algo por cuenta propia en JavaScript cuando el navegador puede ofrecer funcionalidad equivalente de fábrica con mejor rendimiento y usabilidad? Sin embargo, muchos desarrolladores parecen resistirse a este consejo. Comprender por qué requiere mirar más allá de las explicaciones superficiales. Los factores históricos juegan un papel importante. Durante gran parte de la historia de la web, los navegadores se quedaron atrás respecto a las necesidades de los desarrolladores, obligando a los creadores a cubrir los vacíos con bibliotecas como jQuery. Los desarrolladores tuvieron que esperar a que navegadores obsoletos como IE6 desaparecieran antes de poder adoptar de forma segura las APIs estandarizadas. Esto creó un entorno donde crear soluciones propias era a menudo la única opción práctica, estableciendo hábitos que persistieron incluso cuando los navegadores se volvieron evergreen. La familiaridad con los ecosistemas existentes también moldea el comportamiento. Los desarrolladores acostumbrados a buscar componentes de React en npm naturalmente recurren primero a esas herramientas, incluso cuando existen soluciones de la plataforma. No existe un paquete de npm que simplemente diga 'solo usa CSS position: sticky, tú tonto' — en cambio, el ecosistema entrena a los desarrolladores a buscar soluciones empaquetadas en lugar de considerar lo que ya ofrece el navegador. La calidad de la documentación refuerza aún más este patrón. Mientras que los paquetes de npm suelen presentar READMEs amorosamente detallados, con sitios web que incluyen ejemplos, tutoriales y capturas de pantalla, la documentación de la plataforma web históricamente estuvo dispersa entre blogs, StackOverflow y sitios como CSS Tricks. Hasta que MDN se convirtió en la referencia autoritativa (con web.dev como un complemento más orientado al futuro), aprender las características de la plataforma requería reunir información de fuentes dispares, lo que hacía que las bibliotecas con documentación centralizada resultaran más atractivas. Más allá de las consideraciones prácticas, crear soluciones personalizadas suele proporcionar una satisfacción intrínseca. Por ejemplo, crear un cuadro de diálogo modal desde cero implica comprender el posicionamiento, el índice z, el manejo del desbordamiento, la dismissión con la tecla de escape, la captura de foco y la devolución del foco al elemento de origen — un proceso que, aunque complejo, puede ser profundamente atractivo. Muchos desarrolladores consideran este tipo de resolución de problemas divertida y educativa, lo que lleva a lo que los psicólogos llaman el 'efecto IKEA': valorar más lo que construimos nosotros mismos que las alternativas prefabricadas. Este disfrute tiene un significado histórico en el desarrollo web. Muchos de los principales defensores actuales de 'usar la plataforma' alguna vez escribieron polyfills, shims y bibliotecas por cuenta propia. El autor señala que los años dedicados a trabajar con IndexedDB, WebSQL y otras APIs de almacenamiento del navegador a través de proyectos como PouchDB le brindaron la experiencia necesaria para participar en las discusiones de los estándares del W3C. Sin vacíos en la plataforma que requerieran ser llenados, esa motivación para comprender profundamente los sistemas subyacentes podría no haber surgido. Sin embargo, evitar la plataforma no siempre es beneficioso. A veces proviene de la pura ignorancia sobre cómo funcionan realmente tecnologías como CSS. Históricamente, CSS ha sido percibido como poco intuitivo — requiriendo técnicas como los clear fixes, el manejo de flotantes y los trucos de min-width: 0 que no son obvios — lo que lleva a los desarrolladores a implementar soluciones en JavaScript simplemente porque comprendían mejor la lógica imperativa que la estilística declarativa. Durante años, CSS careció de formas directas para expresar patrones comunes como el ajuste de líneas, el cambio de tamaño de áreas de texto o la ocultación de barras de desplazamiento, lo que impulsaba a los desarrolladores a recrear estas características usando herramientas familiares. El fenómeno no es exclusivo del desarrollo web. El autor describe una experiencia similar con ClickHouse, donde el intento de un colega de comprimir datos JSON antes del almacenamiento y el enfoque alternativo del autor utilizando un almacén de pares clave-valor separado resultaron innecesarios. ClickHouse comprime los datos automáticamente y, al ser un almacén columnar, ofrece una mejor compresión entre filas cuando se deja que se encargue del almacenamiento de forma nativa — una realización que solo llegó después de leer la documentación y crear pruebas comparativas. Mirando hacia el futuro, el autor considera cómo podrían influir los asistentes de codificación basados en IA en esta dinámica. Optimistamente, los grandes modelos de lenguaje poseen un conocimiento enciclopédico de las plataformas y podrían seleccionar exactamente la API adecuada para cumplir con los comandos en lenguaje natural, prefiriendo potencialmente soluciones de la plataforma después de realizar pruebas y comparativas. Pesimistamente, los LLMs tienden a duplicar código existente en lugar de reutilizar funciones auxiliares, lo que podría aumentar el código no idiomático de la plataforma si los desarrolladores aceptan los primeros borradores sin explorar suficientemente las alternativas o siguen iterando en soluciones sobreingenieradas. En última instancia, la tensión entre usar plataformas y crear soluciones personalizadas refleja una verdad más profunda sobre el crecimiento del desarrollador: cuanto más uno comprende cómo funcionan de extremo a extremo los sistemas completos, mejor preparado está para hacer contribuciones mínimas y valiosas. Sin embargo, la alegría de crear algo desde cero — hermoso para su creador, incluso si no es objetivamente elegante — garantiza que la pregunta de 'por qué no más desarrolladores usan la plataforma?' seguirá siendo relevante mientras existan las plataformas.
Author portrait illustrating the perspective of a developer who has experienced both building custom solutions and advocating for platform use.