Los Web Components no son el futuro, madre mía.
Se ha liado bastante parda porque resulta que Rian Carniato, que es el creador de Solid 10,
ha lanzado este artículo sobre los Web Components, que dice que no son el futuro.
Como obviamente es un artículo muy largo y no quiero aburrir a nadie,
todo lo contrario, ¿qué he hecho? Me lo he leído yo y os he hecho un resumen.
Digamos que he resumido en 7 puntos lo que dice el bueno de Rian Carniato sobre los Web Components.
Uno, dice que son una promesa engañosa porque los Web Components prometen que son portables
y que son interoperables, o sea, los puedes utilizar en cualquier sitio, de cualquier manera y tal,
pero no es verdad. Dice que eso puede ser peligroso porque no siempre se cumple con las expectativas
en todos los contextos. Entonces, son promesas incumplidas.
Lo segundo, dice que restringe la innovación porque dice que la estandarización de los Web Components
limita la posibilidad de explorar alternativas y enfoques innovadores,
creando una presión para dotar un único enfoque y que podría no ser óptimo para todos los casos.
Ahora os diré si estoy de acuerdo o no estoy de acuerdo con todo esto.
De hecho, vamos a ver otros puntos de vista y tal.
Tercera, dice que es una abstracción incorrecta. Vamos, que están mal.
Que los Web Components se están basando en los custom elements, que utilizan el DOM,
y esto introduce complejidades innecesarias.
Y una abstracción inadecuada hace que en muchos desarrollos modernos no sea la mejor solución.
Problemas técnicos y incompatibilidad, que dice que hay muchos problemas técnicos con el manejo del showdown DOM,
atributos, propiedades, que afecta a la funcionalidad.
Cinco, sobrecarga de rendimiento, porque dice que, por ejemplo, implementar cositas como server-side rendering
en los Web Components implica una sobrecarga adicional por su naturaleza basada en el DOM,
y entonces aumenta la complejidad y hay un alto coste de rendimiento.
Escenarios limitados de utilidad, es el punto 6.
Dice que tampoco ve que haya tantas oportunidades de los Web Components.
Dice que, bueno, puede estar bien en casos específicos, como un widget, como un microfrontend, cosas así,
pero que dice que no, que su coste puede superar sus beneficios.
Y finalmente, el compromiso con un alto coste, porque dice que tiene ventajas ergonómicas,
pero que el coste general para todo el ecosistema es elevado.
Dice que solo su existencia podría frenar el avance y la innovación del desarrollo web,
presentándose como algo que no son realmente.
Esto es lo que comenta, esto es mi resumen, en 7 puntos, de Rian Carniato,
sobre el tema de los Web Components.
Dice que lleva mucho tiempo trabajando con Web Components,
que él no dice que tampoco sean inútiles ni nada de esto,
que los ha intentado estar utilizando durante mucho tiempo,
y que él cree que no son el futuro.
Pues esta es un poco la opinión de Rian Carniato.
El tema es que, obviamente, no se podía saber,
esto ha iniciado una guerra que alucinas.
Lee Berow dice,
mucho odio contra los Web Components por parte de los autores de frameworks en los últimos dos días.
Los que hemos estado en el negocio sonreímos con complicidad,
ya que hemos visto esto suceder unas cuantas veces.
Un claro ejemplo de ello es la enorme resistencia que supuso el uso de CSS
cuando se introdujo por primera vez en los años 90.
Las tablas para diseño tenían una ergonomía mucho mejor.
El rechazo duró hasta mediados de los años 2000,
cuando se pasó de esto nunca funcionará a
esta fue claramente la solución desde el principio,
casi de la noche a la mañana.
Y el resto, como dicen, es historia.
Esto dice Lee Berow,
que obviamente es una persona muy influyente en el mundo de la programación web,
que además está en el Working Group de CSS.
Dice,
yo lo que no sé es por qué no se estandariza React
para que se pueda usar sin librería en los navegadores,
si es que ya es un estándar.
Pues no, me parece muy mala idea, GetraBanco.
React no puede ser un estándar, no puede ser.
De hecho, lo último que estamos viendo de React lo demuestra,
que no puede ser un estándar de ninguna forma.
Y eso no significa que a mí no me guste React,
sino que no puede serlo por el mero hecho
de que ya la semántica en React va cambiando
y ahí vemos cómo su evolución no podría tener cabida en los navegadores.
Todo lo que está pasando con el tema de Suspense,
los React Server Components, cómo pueden cambiar los componentes y todo esto,
es que no puede ser algo que pueda estar en el navegador.
Porque no es algo que sea estable realmente.
No puede ser un estándar porque ya estaríamos rompiendo la compatibilidad hacia atrás.
Ni JSX podría ser.
Es difícil que JSX se pueda convertir en un estándar.
De hecho, es una cosa que estuvo a punto de llegar.
No JSX como tal,
pero sí que estuvieron a punto de llegar algo similar a JSX,
que no sé si lo sabéis,
pero algo muy similar a JSX estuvo a punto de llegar,
que se llama SX, hace muchos, muchos años,
que era nativo se supone y tal,
pero bueno, por suerte se desechó en su día.
Era algo así.
Ah, E4X, perdón,
que era como meter algo parecido a XML en JavaScript.
¿Ves?
ECMAScript for XML.
Esto es lo que hace muchos, muchos años querían meter.
Era algo similar.
No era exactamente JSX,
pero era algo similar como podéis ver por aquí.
Incluso tenía la posibilidad de iterar y todo esto.
Al final nunca llegó y ahí se quedó.
El tema es, yo creo que Ryan entiendo por lo que dice
de los web components.
Creo que la gente ha sobre reaccionado un poco
porque creo que los web components
es una tecnología que está para quedarse
y es muy útil a muchos niveles.
Yo creo que los web components
es algo de la plataforma
que siempre va a estar ya
y que realmente se le está dando un uso
bastante interesante.
Por ejemplo, la gente de GitHub
tiene algunos web components muy interesantes
que son los que utilizan.
Por ejemplo, esto que veis aquí a la derecha,
last month, last year,
todo esto es un web component
que está bastante bien,
que es el relative time, este de aquí.
Y tiene todo el sentido del mundo
porque al final es algo que se ejecuta en el cliente,
que quiere que se pueda reutilizar en todos los sitios.
Y aquí podéis ver el elemento,
lo podéis instalar,
es totalmente de código abierto,
se puede utilizar donde queráis
y además en diferentes idiomas.
Es genial.
Este web component me parece que es tremendo.
Pero es verdad que yo creo que muchas veces
la gente se cree que los web components
vienen a matar a React o a Vue o a Astro,
yo que sé, cosas así, ¿no?
Y una cosa no tiene nada que ver con la otra.
Son como dos cosas totalmente distintas, ¿sabes?
No encajan, no encajan.
No, no se pelean.
Son para convivir realmente.
Las cosas que te ofrece un web component
no tienen tanto que ver
como lo que te ofrecen estos frameworks.
Yo creo que por eso hay muchas,
muchas peleas muchas veces
porque unos se creen que es para acabar con los otros,
los otros se creen que deberían utilizar
los web components para todo
y no creo que sea así.
Y de hecho, esto, ¿no?
Esto de que dice que mucho odio
contra los web components,
yo en el artículo de Ryan
no veo odio como tal, ¿vale?
Es verdad que puedes estar
o no estar de acuerdo
por las razones que dice Ryan,
pero hay algunos puntos
que yo creo que sí que son de valorar.
Por ejemplo,
el tema de que los web components
en tema comunidad como tal
no han terminado de dispararse.
Y seguramente, y él lo comenta,
es porque ha habido bastantes cambios
en el estándar de que al final muchas cosas
no funcionan igual en muchos navegadores,
de que puede ser que vayan un poco lentos
comparar con otras soluciones,
este tipo de cosas.
Solo el hecho de que necesitas ya JavaScript
para que se ejecute ese web component,
claro, eso le crea cierta fricción.
Pero eso no significa que esté mal.
Es algo de la plataforma
que se pueden utilizar,
que puede estar genial
y no significa que tengan que desaparecer
los frameworks de repente.
De hecho, los frameworks
son los que nos ayudan
a que haya una innovación
que empuje a los estándars,
a la plataforma
y a los lenguajes
a ir hacia adelante.
Y esa es una de las cosas más bonitas
que siempre ha tenido
la tecnología web.
El hecho de que aparece algo
que se hace con JavaScript
y luego se va a integrar en CSS
porque se ha visto una necesidad
de que eso tenga que estar.
Entonces, eso no significa
que mate a las bibliotecas.
Es que eran necesarias
para que siguiese evolucionando.
Ese es el tema de la evolución.
Es una cosa en la que constantemente
vamos hacia adelante
gracias a frameworks y bibliotecas
que suplen necesidades
que no están ahora en moneda estándar.
Yo creo que van un poco
por ahí los tiros.
He visto, por ejemplo,
que hay mucha gente que se enfada
pero yo creo que es por el tema este
de que la gente lo mete como una guerra.
Aquí lo tenemos, ¿no?
Evan Yu,
que se ha metido también en la pelea,
obviamente,
dice,
suponer que los autores de los frameworks
están en contra de los web components
porque tenemos miedo
a los cambios radicales
es exactamente la razón
por la que los web components
nunca ganarán.
Es que hablan de ganar,
como si tuviera que ganar algo.
Pero es que no tiene que ganar nada.
Dejen de ganar y perder.
Que no tiene que ser así las cosas.
Y de suponer abiertamente
que hay motivos ulteriores
en personas que no están de acuerdo contigo,
claro,
porque mucha gente dice
es que hay algo
hay algo oculto
que la gente de RIAC
y de VIEW
y de SOL
y te están haciendo
porque no quieren
que los web components ganen, ¿no?
Ese es el tema, ¿no?
Suponer abiertamente
que hay motivos ocultos
en personas que no están de acuerdo contigo,
especialmente teniendo en cuenta
el artículo Ryan
escrito de forma muy diplomática
simplemente
de mala educación.
Ya lo he dicho antes,
si los web components
realmente simplifican los frameworks
y al mismo tiempo
conservan el mismo nivel de características,
yo sería el primero
en reescribir VIEW
sobre la base a ello.
Estoy seguro
de que Ryan y Rich
también comparten esta postura.
La conclusión colectiva
es que no,
es un impuesto
y deberíamos superarlo.
Y esto,
ahí yo voy a estar
un poco de acuerdo.
Quiero decir,
los web components
como cualquier cosa
que existan
en la plataforma,
creo que no se le puede obligar
a nadie
que se utilice.
Yo creo que las cosas
tienen que pasar
de una forma natural.
Que sí,
que se puede abogar a ello,
pero no se le puede,
no te puedes ir a quejar
a alguien de,
es que React
deberías reescribirlo
basado en web components
porque no sé qué,
no sé cuánto y tal.
Y es como,
bueno,
déjame tranquilo,
suéltame el brazo.
Si quieres,
haz tu propio framework
basado justamente
en web components
y todos felices.
De hecho,
pues tienes lead,
por ejemplo,
que lead aquí lo podéis ver,
es un framework
que está utilizando
perfectamente
y está basado
en web components,
pues la gente
lo puede utilizar
si quiere.
O sea,
no hay algo
que te obligas ahí
que diga,
no,
es que no lo puedes hacer.
Dice,
pero se equivoca
don't troll you
porque Rich Harris
siempre ha estado
en favor de los estándares,
tan es así
que Svel soporta
y exporta web components.
Pero es que Vue
también lo hace,
Mario Abreumux.
Puedes hacer exactamente
eso que dices,
que los soporta
y los exporta,
lo puedes hacer.
O sea,
es que eso no es una cosa
que no puedas hacer.
Es verdad que,
por ejemplo,
en React
no los puedes exportar.
Es que es una cosa
que ya ocurre.
El tema es que lo que quieren
es más bien
que se haga algo
como más bien
como lead,
que lo que está haciendo
es como expander
el dominio
de los web components,
que lo tenéis por aquí,
que estás exportando
una clase,
que extiende
delete element,
no sé qué,
no sé cuándo.
Y yo he utilizado lead
y a mí,
sinceramente,
no me gusta.
No me gusta la sintaxis,
no me gustan muchas cosas,
no me gustan.
¿Sabes?
Entonces,
pero eso no significa
que estén mal,
sino que a mí simplemente
no me gusta
y lo bueno,
JavaScript en este caso,
las tecnologías web,
nos dan la posibilidad
de utilizar otras cosas
que sí que nos puedan gustar,
como por ejemplo Svelte,
pues me gusta mucho más
la sintaxis de Svelte
que la de un web component,
¿vale?
Que Svelte,
y además es lo que dices,
que tiene interoperabilidad Svelte
con los web components
y yo creo que ya está.
Yo creo que no es tan necesario
el hecho de que tengan
que pelearse,
de que lo que tiene que ganar,
de hecho,
Rich Harris está aquí debajo,
que está totalmente de acuerdo.
Creo que todos los autores
de Frameworks,
excepto quizá el equipo de React,
pasaron por esta fase.
Yo ciertamente lo hice.
Algunos de los peores
defectos de diseño de Svelte
son un resultado directo
de que planificamos un mundo
en el que los web components
será el objetivo de compilación dominante.
Creo que Evan lo hizo,
Ryan en particular
los analizó en profundidad,
pero porque por supuesto
lo haríamos.
Todos somos súper competitivos
entre nosotros,
así que sí que podemos delegar trabajo
a una plataforma primitiva
que dé como resultado
un mejor rendimiento
y paquetes más pequeños.
Entonces,
estaremos en ello.
En un mundo sano,
el hecho de que seamos nosotros
de entre todas las personas
los menos entusiastas
con respecto a ellos,
provocaría una profunda introspección
por parte de quienes diseñan
estas especificaciones.
Y en lugar de eso,
se nos amonesta
por no contribuir
a hacerlos mejor.
Os envía un mensaje en Twitter
sobre conflictos de intereses
u otras estupideces absurdas.
Vera es un conflicto de interés
en mantener un framework
aunque los web components
no componen con los frameworks.
Pero no hay ningún conflicto de interés
en los que nos paguen
por trabajar en frameworks
o especificaciones o bibliotecas.
Mientras tanto,
siempre estamos a 20 especificaciones
de la paridad
con el espacio del usuario
y la complejidad
de la propia plataforma
sigue aumentando.
Es una jodida locura absoluta.
¡Buah!
¡Tlaca!
O sea,
Rich Harris también lo comenta,
también lo habla.
Rich Harris está de acuerdo
un poco con Evan Yu.
Yo creo que todos los que hacen frameworks
obviamente están de acuerdo
con este punto.
Pero mi punto de todo esto,
mi opinión,
sé que muchas veces la gente
cuando digo estas cosas
se pone un poco como
¡Ah!
Es que eres un pecho frío, ¿no?
O un blando y tal.
Este artículo
creo que está bastante interesante.
Web components están bien.
Este artículo
creo que está muy bien.
porque las cosas como son.
Yo creo que los web components
están bien
pero no son perfectos.
Y es lo que dice por aquí.
Y si te lees el artículo de Ryan
tampoco los insulta
ni nada de esto.
Sino que aquí lo que está hablando
es
oye,
los web components
están bien.
Es verdad
que tienen casos de uso
que son interesantes
pero no van a matar
de repente
a los frameworks actuales.
Y a lo mejor
en los del futuro
pues llegará un momento
en el que evolucionen
de forma que
eleven un poquito más
los web components
pero el estándar
es el que es
y tiene sus limitaciones
también
y tenemos que entenderlo.
Hay cosas que han funcionado
en los web components
y que se han utilizado
súper bien, ¿no?
De hecho
todos los frameworks
utilizan sin ningún tipo
de problema
la etiqueta template
justamente
para mejorar
el rendimiento
de los frameworks
y template
es una etiqueta
que se creó
bajo el paraguas
de los web components
porque hay que recordar
que los web components
no deja de ser
un set de tecnologías.
No es una cosa.
Son muchas tecnologías
los custom elements
el shadow DOM
el template
hay un montón de cosas
que digamos
es todo el paraguas
de los web components
y hay cosas
que sí que han triunfado
y otras pues que no han triunfado tanto
o que a lo mejor triunfan
más adelante
y ya pasará
y en el momento
en que se haga un framework
en que realmente llegue
y dé lo mejor
de los web components
y todo el mundo
esté de acuerdo
pues será tremendo
pero yo creo que
quizás los web components
no es el futuro
para todo el mundo
y creo que eso está bien
pero quizás
sí que lo será
en parte
para otra gente
o sea
los web components
van a tener un uso
ya es parte de la plataforma
GitHub lo está utilizando
en muchos sitios
y en otros no
en otros está utilizando React
porque resulta
o sorpresa
que los web components
no vienen a competir
uno a uno
contra React
sino que hay ciertos casos
donde el web component
puede llegar a tener sentido
y hay otros
donde no llegan
los web components
que a lo mejor
necesitas un framework
o una biblioteca
que te va a hacer el trabajo
por ejemplo
los web components
no tienen un estado
como tal
reactivo
como puedes tener
en otros frameworks
o no tendrías
de base
un server side rendering
que tendrías que utilizar
en un framework
o alguna biblioteca
o los atributos
al final los atributos
tienen que ser strings
como tal
tendrías que transformarlos
tienes que hacer
algún tipo de cosas
al final
vamos a tener que utilizar
unos u otros
y este tipo de discusiones
muchas veces
lo único que hace
yo creo
es más bien
hacer daño
y no solo digo
de los web components
hacia los frameworks
también este tipo de comentario
que me parece un poco horrible
si los web components
fueran buenos
todos los estaríamos usando
ningún framework de trabajo
que hace más trabajo
del que debe
las personas que trabajan
con web components
necesitan acercarse
a los frameworks
y comprender las necesidades
en esto estoy de acuerdo
pero este primer punto
básicamente ha sido
un poco como
si los web components
fueran tan buenos
todo el mundo
los estaría utilizando
no tiene sentido
es un poco
una falacia típica
porque en realidad
que algo
se utilice mucho
no significa
siempre que sea
lo mejor
esto es una mentira
como un piano
esto está demostradísimo
en el mundo de la tecnología
y en el mundo
en general
que algo se utilice mucho
no hace que sea
lo mejor
de repente
simplemente
significa que se utiliza mucho
punto
ya está
como si dijésemos
que a día de hoy
jQuery es lo mejor
de lo mejor
porque se sigue utilizando
más que el resto
por lo tanto
es tecnológicamente mejor
no, no tiene nada
que ver con esto
ahora
lo que sí que creo
y esto sí que puede ser interesante
es que sí que puede haber
espacios de colaboración
entre la gente
de los frameworks
y la gente
de los web components
que yo creo que a verlos
ya los hay
por ejemplo
el tema de las signals
que es una cosa
una propuesta
que va a llegar a javascript
en la que se está trabajando
que sería la reactividad
nativa
a javascript
oye
pues es interesante
porque esto no deja de ser
una colaboración
que ha habido
a muchos niveles
donde tenemos gente
como Rob Heisenberg
y Daniel Erenberg
que han estado trabajando
en web components
durante mucho tiempo
y que al final
esto en realidad
es un draft
que ha tenido input
de frameworks como Angular
Ember
Fast
Pria
Quick
Solid
Svelte
Vue
y esto es una colaboración
que si llega
al lenguaje
si llega finalmente
a la plataforma
pues simplificará
un montón del trabajo
que tendremos en los frameworks
y tendrá todo el sentido del mundo
y quien lo quiera utilizar
que lo utilice
y ya está
así que no sé
yo creo que es mejor
enfocarse
en la colaboración
que puede haber
muchos
y muy interesantes
en lugar de ponerse
con los comentarios
el hate
y el enfocarse
en o esto
o lo otro
como que hay que pelearse
entre una cosa y la otra
aquí está el comentario final
que me parece que
como haciendo un poco las paces
porque ha habido pelea
bastante bestia
tengo un inmenso respeto
por Ryan Carniato
Yu Yuichi
y Riharris
ha habido muchas discusiones
improductivas este fin de semana
pero en medio del caos
también hubo otras reveladoras
que ayudaron a aprender
sobre las perspectivas
me gustaría reconocer
que SolidView y Svel
son algunos frameworks
más innovadores
en términos de elementos
personalizados
de Custom Elements
gracias
también me gustaría disculparme
por crear divisiones
en la comunidad
de desarrollo web
divisiones que creo
que no son necesarias
mi intención era defender
algo en lo que creo
pero las cosas se salieron
de control bastante rápido
si algo bueno ha salido de esto
espero que sea el reconocimiento
por parte de los defensores
de los estándares
y los autores de los frameworks
que debemos dejar de hablar
sin entendernos unos a otros
y que hay una historia
desafortunada
en el lado de los estándares
que debemos reconocer
y resolver
hay mucho en lo que pensar
pero de algo estoy seguro
el progreso requiere
que todos
trabajemos
juntos
y en eso
sí que estoy de acuerdo
que hay que trabajar juntos
que hay que trabajar juntos