Sentando las bases para la extensibilidad

Más sobre Web Extensible ↬

Después de una década de trabajo en bibliotecas de JavaScript, la revolución de la mejora progresiva, la llegada de los polyfills y el esfuerzo por crear las especificaciones "Componentes web" y "Shadow DOM" nos han enseñado lecciones sorprendentes: en cada período, poder utilizar funciones siempre ha sido deseable. HTML es genial, hasta que deja de serlo. Y el uso exclusivo de JavaScript tiene inconvenientes predecibles. Pensar que existe una “forma correcta” de crear nuevas funciones web es seductor. Resulta que no es tan simple.

La Web ha logrado la interoperabilidad y la escalabilidad como ninguna otra tecnología lo ha logrado antes o después. Aun así, la Web sigue estando lejos de ser un “estado de arte” y está cada vez más amenazada por jardines amurallados. La plataforma web a menudo va por detrás de sus competidores en la entrega de nuevas capacidades de sistemas y dispositivos a los desarrolladores. Peor aún, a menudo obstaculiza las nuevas capacidades detrás de las API de alto o bajo nivel, lo que obliga a los desarrolladores a tomar decisiones dolorosas (y soluciones alternativas).

A pesar de que las versiones del navegador se lanzan mucho más rápido, las nuevas capacidades aún tardan mucho en materializarse y, a menudo, lo hacen en formas que, en el mejor de los casos, son frustrantes y, en el peor, casi inútiles para grandes sectores de la comunidad de desarrolladores para resolver las necesidades del mundo real.

Las mejores mejoras recientes de la plataforma han sido el resultado de discusiones colaborativas entre desarrolladores y proveedores de navegadores. A veces, esto conduce a grandes funciones nuevas. La mayoría de las veces, conducen a pequeños cambios que hacen que los sistemas existentes sean adecuados para una gama más amplia de usos. En ausencia de un marco intelectual para realizar estos cambios, obtenemos un enfoque mezcolanza del diseño , donde las buenas ideas no se llevan a cabo y los patrones desacreditados perduran mucho más tiempo del que deberían.

Aprovechando los éxitos de la estrecha colaboración entre desarrolladores web y creadores de navegadores, las personas que han repetido propuestas y se han situado a ambos lados de la línea (incluidos los autores de este artículo, Yehuda Katz , Dimitri Glazkov , Erik Arvidsson , Dave Herman y otros) han tomado una mirada más detallada a lo que otorga longevidad y utilidad a las funciones web.

El resultado de discusiones colaborativas entre desarrolladores y proveedores de navegadores conducen a pequeños cambios que hacen que los sistemas existentes sean adecuados para una gama más amplia de usos. ( Fuente de imagen )

Más de una década de trabajo en bibliotecas de JavaScript, la revolución de la mejora progresiva, la llegada de los polyfills y el esfuerzo por crear las especificaciones "Componentes web" y "Shadow DOM" nos han enseñado lecciones sorprendentes: en cada período, poder utilizar funciones siempre ha sido deseable.

HTML es genial, hasta que deja de serlo. Y el uso exclusivo de JavaScript tiene inconvenientes predecibles (y afortunadamente, ahora reconocidos).

Pensar que existe una “forma correcta” de crear nuevas funciones web es seductor. Simplemente define The Way To Do It™ y haz que todos los abanderados cumplan, ¿verdad? Resulta que no es tan simple. Las nuevas propuestas son orgánicas y surgen de necesidades, no de pura especulación. Las necesidades de bajo nivel exigen soluciones de bajo nivel. Los elementos HTML y las reglas CSS no son ideales para todo el trabajo. Y la existencia de JavaScript crea la necesidad de nuevas API cercanas al nivel del lenguaje.

El proceso de introducción de nuevas funciones suele ser una propuesta de uno u otro (es decir, funciones declarativas o API de bajo nivel) a corto plazo. Pero a largo plazo, casi todas las características necesitan expresión en ambos dominios. Además, debemos darnos cuenta de que las propuestas de nuevas normas son un trabajo duro. Las personas que hacen ese arduo trabajo generalmente intentan hacer lo correcto y no pueden esperar una eternidad para ofrecer funciones. Se necesita un enfoque pragmático y realista para aumentar el poder y la calidad de las API web, uno que no presuponga tiempo, esfuerzo o comprensión infinitos por parte de los participantes, sino solo buena voluntad y voluntad de tender puentes.

Para apoyar este objetivo, el proceso de estándares necesita una intervención .

El Manifiesto Web Extensible es un documento que hemos redactado para generar consenso entre los participantes en los estándares en torno a algunas ideas centrales:

• Las API y el marcado de alto nivel deben proporcionar puntos de extensión directos a través de JavaScript.
• Cuando la plataforma ya proporciona sistemas de alto nivel, se deben utilizar adiciones de bajo nivel relacionadas para explicar cómo se habrían escrito los bits de alto nivel en términos de estas nuevas API de nivel inferior.
• Al agregar nueva potencia bruta a la plataforma, prefiera las API de nivel inferior a las de nivel superior porque permiten la experimentación y la iteración antes de una adopción amplia.

La idea central es que la Web ha llegado hasta aquí gracias a características en gran medida declarativas y de alto nivel: elementos HTML para formularios, CSS para diseño y estilo, y apara definir relaciones entre documentos. Si bien cada uno de estos agrega API, hasta ahora se ha hecho poco esfuerzo para explicar cómo hacen su trabajo y cómo se relacionan entre sí. Blog sopper tappers

Si bien casi puedes sentir los muchos estratos de API debajo de las funciones web, quedan sin nombre , sin explicación , desconectadas y no disponibles para ti cuando el sistema no hace exactamente lo que necesitas.

Es vital saber cómo funcionan las API y cómo están conectadas entre sí. ( Fuente de imagen )

Por ejemplo:

• El canvaselemento HTML5 define una API de mapa de bits 2-D programática, mientras que el elemento antiguo imges, no por coincidencia, una forma de representar contenido de mapa de bits 2-D. Es fácil imaginar que podríamos explicar cómo JavaScript carga, descomprime y finalmente procesa el contenido de la imagen utilizando la canvasAPI. Muy extraño que sean elementos separados y que el imgelemento no tenga la canvasAPI, ¿no?
• Solicitar acceso a la cámara input type="file" accept="image/*;capture=camera"tanto con como con getUserMedia()es posible, pero la versión del elemento del formulario no se explica en la especificación HTML en términos de getUserMedia()(que, ciertamente, se agregó más tarde, pero nadie se ha molestado en conectarlos todavía).
• Eso es mejor que la API de geolocalización . Actualmente no hay forma de hacer eso con un inputelemento. Es una característica valiosa completamente desconectada del marcado.
• Ni HTML ni Web Audio API explican cómo audiofunciona la etiqueta, a pesar de que Web Audio API es claramente capaz de proporcionar la audioimplementación del elemento.

Esto no es para molestar o señalar a ninguno de los desarrolladores y autores que han dedicado sus vidas a crear consenso y software para introducir estas capacidades. De hecho, estamos agradecidos por sus logros .

Lo más importante es que el trabajo no se realiza cuando aparecen las versiones declarativa y basada en script de una característica. Construir una plataforma que sea resiliente y adaptable a largo plazo depende de darles a los desarrolladores la confianza para tomar lo que aprenden sobre un área y aplicarlo de manera uniforme en todo el sistema. Y eso significa explicar cómo funciona el sistema y establecer conexiones entre las piezas.

En el caso de muchas API de bajo nivel sin equivalentes de alto nivel (como Geolocalización), su deber de “explicarse” termina en el punto en el que han expuesto una buena API a JavaScript. "Bueno" aquí podría significar ser idiomático y no introducir más magia de plataforma de la necesaria. Pero cuando también hay versiones declarativas, o cuando sólo existen versiones de alto nivel, entonces la pregunta cobra gran importancia: ¿Cómo funciona eso? ¿Cuáles son las capas debajo de él? ¿Qué API se requieren para que funcione? ¿Cómo explicarías esa API en términos principalmente de JavaScript, apelando lo menos posible a las mágicas API de nuevas plataformas?

En una época anterior, intentar un cambio cultural tan radical podría haber sido una tontería. Comenzar a nivel declarativo fue sin duda una buena idea. Sin embargo, explicar incluso un poco de la magia subyacente ayuda mucho: exponer un árbol DOM JavaScript abrió nuevos mundos para los desarrolladores y reforzó la competitividad de la plataforma. También permitió a la comunidad adaptarse mediante la experimentación y permitió a las bibliotecas competir. Esto permite estandarizar potencialmente ideas de API valiosas y populares. La comunidad puede hacerlo más rápido y con menos riesgo que los proveedores de navegadores y las organizaciones de estándares.

Las respuestas no siempre son obvias, pero el proceso de preguntar "¿Cómo funciona eso?" suele ser más fructífero de lo que parece a primera vista. Los detalles se aclaran y las explicaciones faltantes se descubren, capa por capa. En cada capa, es tentador levantar las manos colectivamente y decir "Es demasiado difícil" explicar todo lo que hay ahí abajo. Tíralo todo. Comenzar de nuevo. Al menos no cometeremos los mismos errores, ¿verdad?

Tal vez. Pero también estaríamos empezando desde cero. Cero usuarios, cero desarrolladores y cero contenido útil. La Web es la plataforma universal, abierta, extensible y de múltiples proveedores de nuestra época. Los cambios pequeños y significativos en la Web pueden tener un impacto enorme en relación con el esfuerzo involucrado. Es una forma sencilla de hacer mucho bien. Fomentar el uso de capas, poco a poco, no significa darse por vencido o "reducir el ritmo". Todo lo contrario: es nuestra única esperanza creíble de crear una Web que sea digna de suceder a la Web que tenemos hoy.

Recuerde siempre “mejorar las cosas” tanto como pueda. ( Fuente de imagen )

Otras lecturas

• Haciendo una mejor Internet
• API HTML: qué son y cómo diseñar una buena
• Cómo diseñar mejores API de JavaScript
• Una guía para principiantes sobre aplicaciones web progresivas

(al, ea, il, mrn)Explora más en

• Codificación
• javascript
• Columna de opinión
• HTML5
• HTML
• API

Tal vez te puede interesar:

1. ¿Deberían abrirse los enlaces en ventanas nuevas?
2. 24 excelentes tutoriales de AJAX
3. 70 técnicas nuevas y útiles de AJAX y JavaScript
4. Más de 45 excelentes recursos y repositorios de fragmentos de código

Sentando las bases para la extensibilidad

Después de una década de trabajo en bibliotecas de JavaScript, la revolución de la mejora progresiva, la llegada de los polyfills y el esfuerzo por crear la

programar

es

https://aprendeprogramando.es/static/images/programar-sentando-las-bases-para-la-extensibilidad-832-0.jpg

2024-09-19

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente