Hay dos puntos de vista con el tema de RIAG y me gustaría saber tu opinión a ver con cuál de las dos te quedas, ¿vale?
Y es que el bueno de Jaime Gómez Obregón, que es un crack, es un activista, yo diría, programador en España,
así que si sois de Latam quizá no lo conozcáis, pero aquí en España, Jaime lo que hace muchas veces es destapar un poco las cloacas de los documentos
o la falta de transparencia en el mundo de gobiernos, entidades públicas, del Estado, ayuntamientos y demás.
Es programador y muchas veces trabaja en ello.
Ha puesto este tuit que me ha parecido muy interesante, yo no estoy de acuerdo del todo y ahora os explicaré por qué,
pero bueno, me parece una opinión muy válida y muy interesante.
Dice, RIAG acabará como jQuery, muerto.
Cuando yo digo que no estoy de acuerdo, no es tanto porque creo que tiene mucha razón en lo que dice,
pero creo que empieza mal.
No por RIAG, porque RIAG en realidad como que acabará muerto, pues seguramente acabará muerto.
Creo que a día de hoy no podemos decir que jQuery esté muerto, ¿sabes?
Es que no está muerto.
Pero yo creo que muchas veces el tema es cómo lo utilizamos nosotros mismos.
Creemos que como utilizamos nosotros las cosas es como lo utiliza todo el mundo, ¿no?
Y lo cierto es que no.
Creo que jQuery a día de hoy no está muerto para nada.
Yo es verdad que no lo utilizo, ni en broma.
Pero, y seguramente Jaime tampoco lo utiliza o lo ha dejado de utilizar y tal.
Pero lo cierto es que yo más que decir muerto seguramente diría que no es la forma recomendada
o no es la primera opción.
Diría algo más así que decir que está muerto, porque algo muerto es algo que no se utilizaría
o que no tiene vida, ¿no?
Y entonces si no podemos decir eso cuando podemos ver que jQuery no solo está vivo,
porque se están sacando nuevas versiones, sino que a día de hoy, teniendo en cuenta
lo que dicen algunas encuestas, se está utilizando en que el 90% de las páginas web utiliza jQuery.
Lo cual, hombre, algo utilizado por el 90% de las páginas, yo no diría que está muerto.
Sinceramente, yo, en mi opinión.
Pero entiendo que en su contexto, cuando dice muerto, quiere decir que no lo utilizaría él como primera opción
o para sus proyectos, ¿vale?
Eso lo puedo llegar a entender.
¿En cómo ha inducido?
Bueno, lo podemos entender así.
En zombie.
A ver, zombie, yo tampoco diría zombie porque realmente está bien que sigue teniendo actualizaciones.
Se sigue actualizando jQuery, por lo tanto, tampoco está en modo zombie.
Así que yo diría que jQuery está más vivo de lo que nos podría gustar.
Entonces dice, cuando empecé a programar para la web, la plataforma era Q3.
CSS era un rudimentario juguete, JavaScript era el lenguaje arcano.
Cada navegador implementaba el DOM a su manera.
Esto tiene toda la razón del mundo.
Aunque más que JavaScript era un lenguaje arcano, no es que fuese arcano.
Bueno, entiendo que por arcano quizás quiere decir...
Yo lo entiendo de otra forma, por arcano.
Igual por arcano, él...
A ver, que arcano dice una cosa secreta, recóndita, reservada, oculta, misteriosa.
Lo entiendo como que es algo así, secreto.
Yo diría que era...
Misteriosa.
Difícil de conocer.
No es que fuese difícil.
Yo, más que arcana, no sé.
Yo diría que arcaico.
Es que arcaico tampoco.
Yo diría que era muy limitado JavaScript.
Era un lenguaje muy limitado.
Los desarrolladores comenzamos a crear nuestras propias librerías y herramientas.
Este, de toda razón, capas de abstracción para homogeneizar unas tecnologías incoherentes
y brindar superpoderes a los estándares web que no traían.
Nació DHTML, CoffeeScript, SAS, jQuery...
Erraquimientas que van quedando atrás porque los estándares web han evolucionado
incorporando de forma nativa muchas de las características que brindan.
Lo que dice tiene razón, pero ahora os diré un poco una opinión que tengo yo sobre esto.
La siguiente generación de librerías, Fronten, es más ambiciosa.
Ayuda a componentización, composición, enrutado, gestión del estado, testeo, ergonomía, desarrollador...
Así nacieron Angular, Vue o React.
Pero todo está cambiando de nuevo.
Los estándares web evolucionan más rápido que nunca.
Los navegadores implementan ágilmente las nuevas especificaciones.
Desde hace un par de años, mis proyectos web no se apoyan en ningún framework.
Es perfectamente posible construir un proyecto digital con los potentes estándares web actuales.
El nuevo DOM hace jQuery innecesario.
El nuevo CSS hace que SAS no tenga ya sentido.
Enmascript 13 y los web components dejan en el limbo a React.
Aquí no estoy muy de acuerdo.
Pero no por React, sino por cualquier cosa que le queráis poner ahí.
React como Angular o Vue están dejando rápidamente de ser necesarios.
También en gendros, otrora imprescindibles, como JSX, Babel o el hecho mismo de transpilar.
Ahora podemos escribir aplicaciones web complejas solo con estándares nativos.
Especificaciones potentes que ya son soportadas por todos los navegadores.
El futuro de la web es prometedor y minimalista.
Tras lustros de stacks tecnológicos artificialmente complejos,
abracemos el minimalismo.
Programar frontend sin frameworks, librerías ni dependencias.
Código estándar que funciona en cualquier dispositivo.
Llevo 25 años programando en la web y esta es mi visión.
¿Cómo lo veis vosotros?
Podemos debatirlo en los comentarios.
Bueno, me ha parecido muy interesante.
Yo lo voy a debatir, Jaime.
Pero bueno, respeto mucho a Jaime.
Y la verdad es que me parece que tiene mucha, mucha razón en muchas cosas.
Yo voy a dar mi opinión.
Polémica, pero con todo mi respeto.
Creo que tienen mucho sentido las cosas que dice.
Pero hay dos cosas.
Uno, creo que nunca, jamás, jamás van a desaparecer las bibliotecas o los frameworks.
Y no porque a mí me encanten.
Sino porque justamente las bibliotecas y los frameworks lo que nos proporcionan
es una herramienta de adelantarnos a las necesidades que la plataforma no nos da.
Y es un pescado que muerde la cola y que se retroalimenta.
Porque si no existiesen las bibliotecas y los frameworks no evolucionaría tampoco la plataforma web.
Las necesidades que se originan muchas veces, desde por ejemplo la componentización, el hecho de no necesitar SaaS y que muchas especificaciones lleguen a CSS es porque existió SaaS.
Lo mismo pasó con CoffeeScript.
El hecho de que CoffeeScript existiese empujó a JavaScript hacia adelante a evolucionar.
Entonces esto va a ocurrir siempre.
Siempre lo que va a ocurrir es que vamos a construir encima de la plataforma bibliotecas y frameworks que van a empujar la plataforma en el futuro más adelante para que sea nativo.
Y esto va a ocurrir siempre.
O sea, no es una cosa que vaya a desaparecer, en mi opinión, puedo estar equivocado, pero es que me parece hasta positivo.
Porque si creyéramos que las bibliotecas y los frameworks no van a existir, seguramente la plataforma habría llegado a su límite.
Y no lo veo así.
Quizás SaaS dejará de sentido, pero entonces empezará una nueva hornada de frameworks o de bibliotecas para venir a suplir cosas que la plataforma hoy en día no nos puede dar.
Como por ejemplo, post-CSS, ¿vale?
Pues post-CSS te va a permitir un poquito más que CSS todavía no tiene y entonces CSS se pondrá al nivel y volverá a salir otra cosa.
Como por ejemplo, Tailwind.
Y entonces algo de Tailwind llamará mucho la atención que llegará hasta la plataforma y otra vez y otra vez.
Y será constantemente así porque será como siempre una carrera hacia adelante donde las bibliotecas y los frameworks, al no estar atados,
van a poder correr un poquito más para adelante para que luego la plataforma llegue otra vez a ese nivel.
Entonces, yo no creo que sea ni siquiera algo malo.
O sea, me parece algo natural y creo que esto va a pasar.
Por eso, hablar de que sin un frontend, sin frameworks, librerías ni dependencias,
creo que siempre se ha podido hacer y de hecho muchas veces lo hemos hecho.
Pero no creo que todo el mundo pueda llegar a aspirar a eso y no es malo.
O sea, creo que los proyectos de Jaime, pues como él dice, abraza el minimalismo y lo puede hacer.
Pero la realidad es que la plataforma no es suficiente a día de hoy para crear todas las experiencias que necesita la web.
Todas y cada una de ellas.
Entonces, de forma personal nos puede pasar, pero no es así.
Por ejemplo, los web components no es suficiente.
Un claro ejemplo sería los signals.
Por ejemplo.
Por ejemplo, los signals es un muy buen ejemplo.
Los signals a día de hoy no es parte de la plataforma, pero sí que lo podemos hacer con bibliotecas.
Al crearse una necesidad gracias a las bibliotecas y los frameworks y ver que los signals es algo lo suficientemente interesante,
ahora se está creando una propuesta que pueda llegar a la plataforma, quien sabe, en los siguientes años.
Y eso va a ser así constante.
Quizás después de los signals se llegará otra cosa y otra cosa.
Entonces, yo creo que me gusta mucho su mensaje y de hecho lo abrazo y estoy súper de acuerdo de que el futuro de la web es prometedor.
Estoy súper, súper de acuerdo.
Pero a la vez creo que, por ejemplo, dice el hecho mismo de transpilar, que dice engendros como JSX, Babel o el hecho mismo de transpilar.
Yo no llamaría que estos son engendros porque en realidad transpilar como tal va a ser necesario ya de aquí a siempre.
Seguramente va a ser necesario de aquí a siempre y no como algo negativo o como un engendro, sino porque lo que vamos a querer es siempre intentar utilizar lo más nuevo,
pero sin sacrificar el soporte a los usuarios.
Y por lo tanto, la transpilación no es algo negativo, sino lo que nos va a permitir muchas veces es por lo que dice él.
Por ejemplo, él habla de Enmascript 13 y los Web Components.
Claro, Enmascript 13 a día de hoy no está soportado por todos los navegadores al 100%.
Quizás sí por el 90%, pero una empresa que quiera dar la máxima compatibilidad a sus usuarios va a tener que necesitar utilizar la transpilación,
la compilación, como le queráis decir, para asegurarse de que muchas cosas que utilizan todavía usuarios antiguos lo puedan utilizar.
Quizás Jaime, que este hombre es un crack, para sus proyectos, pues no le importe y no pasa nada.
A mí me pasa, o sea, yo creo que tiene mucho sentido porque yo lo hago también.
Lo que hace Jaime lo hago yo también y muchos proyectos intento hacerlo con el mínimo número de framework, dependencias y todo esto.
Pero entiendo muchas veces que hay empresas que no se pueden permitir esto.
Y entonces creo que decir que Enmascript 13 y los Web Components dejan en el limbo a React tampoco es verdad.
Los Web Components en realidad es una tecnología que es bastante antigua como tal.
Los Custom Elements, que es parte de los Web Components, fijaos que es que ni siquiera todavía lo tenemos al 100%, ¿vale?
Pero es que, ya no digo al 100%, me refiero que estén totalmente bien implementados,
solo el 80% de los usuarios, de los navegadores que utilizan los usuarios, están soportados al 100%.
Safari, sin ir más lejos, tiene todavía algunos peros donde hay algunas propiedades que todavía no funcionan.
Por lo tanto, necesitamos pues cargarlo con Polyfill o lo que sea, ¿no?
Así que ahí está alguna limitación que obviamente vamos a tener con la plataforma.
Pero es que ni siquiera es verdad que los Web Components dejan en el limbo React.
Porque, fijaos, Lit es una biblioteca, un framework que es de Google que está construido con Web Components
y que al final lo que hace es intentar darte cosas que todavía le falta a la plataforma.
Por ejemplo, algo tan sencillo como puede ser estado.
Crear tu propio estado con Vanilla JavaScript es posible,
pero no es algo que te gustaría hacer en todos tus proyectos.
Y por lo tanto se crean abstracciones para facilitarte el trabajo.
Siempre vamos a querer evolucionar, siempre vamos a querer ir hacia adelante,
eso es totalmente normal, pero siempre vamos a querer también evitar repetir trabajo.
Y para eso muchas veces creamos bibliotecas, frameworks, para no tener que estar creando esto.
Los Web Components no tienen una reactividad tan robusta como puede ser un estado de React.
No tiene ciertas cosas o ergonomías que tiene React o Vue.
No digo, no solo una cosa de React, sino también Vue.
Vue al final es compatible con Web Components o Svelte,
pero la ergonomía que te dan el desarrollo es mucho mejor que los Web Components.
Y no pasa nada, es que es normal, por eso estás pagando el coste.
Lo bueno que tenemos es que los Web Components nos están dando como una base
sobre la que podemos construir mejores frameworks y bibliotecas.
Ese es el punto.
Y eso es lo que yo creo que es súper importante,
que realmente la plataforma siempre te va a permitir construir mejores experiencias,
aunque tengas que utilizar y seguir utilizando bibliotecas sin frameworks,
porque eso va a pasar.
Siempre depende del público objetivo.
A veces la gente se preocupa por ser un sistema de administración que tiene las rutas protegidas.
No tiene sentido, pero pasa cuando quieres usar lo que le diste recién.
Claro, eso sí.
Por eso yo creo que sí que es interesante lo que dice de esto,
pero hay veces que hay que tener en cuenta lustros de stacks tecnológicos artificialmente complejos.
Me da la sensación, y creo que muchas veces nos pasa esto,
que estamos como blanco o negro.
Todo es siempre blanco o negro, blanco o negro.
Estamos totalmente en contra de los frameworks.
Estamos totalmente a favor.
Y creo que hay tantos matices de grises.
No todos los frameworks son malos.
Los frameworks han ayudado a la plataforma a seguir hacia adelante, a evolucionar.
Y está bien su...
Me encanta.
O sea, me encanta el trabajo de Jaime, que lo aprecio un montón y que es un verdadero crack.
Y me gusta mucho su opinión.
O sea, la verdad es que me gusta que piense así.
Pero aún así, también creo que deberíamos tener un poco cuidado
de que cuando leamos esto, pensemos que sí, que ya está.
Todo nativo y ya está, ¿no?
Si es JavaScript nativo y la web API llega a un estado tan sólido como frameworks actuales,
solo para cosas muy avanzadas te haría falta meter 20 librerías.
No, eso totalmente.
Pero quiero decir, 20 librerías.
Es que esto...
Pero va a pasar constante.
Siempre vamos a ir hacia adelante.
O sea, siempre más adelante pasará otra cosa
y siempre vas a necesitar algunas bibliotecas o frameworks
para no repetir exactamente lo mismo.
Porque no todo puede ni debe llegar a la plataforma.
Creo que Jaime se le olvida que los frameworks no nacieron una vez
que CSS y JavaScript ya tenían todas las características que tienen ahora,
cuando más bien los frameworks cubrieron esas necesidades que ahora son nativas.
Sí, pero a ver, que hay cosas que los frameworks,
o sea, que de forma nativa no se cubren, por más que queramos.
Por ejemplo, NextGS te da muchas cosas que la plataforma de forma nativa no te da.
Por ejemplo, Service Art Rendering, tienes que crear algo.
Tienes que construir esa plataforma para hacerlo.
Y no hay forma fácil de hacerlo a no ser que lo hagas a mano.
Claro, no, es que yo tengo un archivo estático.
Claro, en tu caso puede tener sentido y está bien que lo ahora haces.
Pero no es tan fácil decir que esto lo puede hacer cualquier persona en el mundo.
Ah, no, no voy a utilizar.
O un enrutador.
Algo tan sencillo como hacer un enrutador,
que sí que se puede hacer en Vanilla,
de hecho lo hemos hecho alguna vez en Vanilla,
no te lo da la plataforma.
Lo tienes que construir tú sobre la plataforma,
que puede ser más o menos código.
Pero hablar de todos los corner cases,
de trabajar además tanto en servidor o en cliente,
no es tan fácil como parece.
No es tan fácil.
Y por poco trabajo que sea,
si vosotros miráis un enrutador,
vais a ver un montón de corner cases
que al final los tienes que tener en cuenta tú o una biblioteca.
Y la idea es que tú no la vayas a querer hacer.
Tú no vas a querer estar reconstruyendo todas las bibliotecas del mundo.
A no ser que tengas algún tipo de problema de confianza
y no confíes en ninguna biblioteca del mundo.
Así que no sé, hay que tener en cuenta eso.
A ver, que os leo alguna cosa.
Los que dicen que nunca usan frameworks
seguramente nunca han estado en una empresa
con tres proyectos activos en el desarrollo.
Bueno, claro, es que yo entiendo que a lo mejor
los proyectos de Jaime,
él no utiliza absolutamente nada de esto
y que no lo necesite.
Y me parece súper bien que todo sea Vanilla,
pero es verdad que en muchos sitios
es bastante complicado pensar que eso pueda ser realista.
Algunos casos puede ser, pero...
Los frameworks son geniales,
pero lo mejor es que avance la plataforma.
Si va en nativo más rápido,
terminas ejecutando menos Polyfields y código extra.
Totalmente, ¿eh?
Yo soy un amante de la plataforma,
que nadie se confunda y que piense...
No, es que no sé qué.
A mí me encanta la plataforma
y yo estoy encantado.
Y ya sabéis que yo siempre que puedo
abogo por utilizar la plataforma.
Eso tiene todo sentido.
Pero también creo que tampoco tiene mucho sentido
pensar que los frameworks van a desaparecer,
porque ya os digo, se retroalimentan.
Aquí entra lo de no reinventar la rueda.
Claro, es que si tenéis que reimplementar
todo lo que os da los frameworks o bibliotecas,
es que os volveríais locos,
a no ser que tengáis ciertos productos en general.
Hay gente que piensa esto, ¿no?
Que va a morir React como ha muerto jQuery.
Y por otro lado,
hay gente que piensa como todo lo contrario.
¿Es React el verdadero sucesor de jQuery?
¿El sucesor?
¿O está hecho para una audiencia diferente,
con diferentes necesidades?
¿Es React una herramienta de propósito general
para crear cualquier tipo de sitio web?
¿O es útil principalmente en equipos grandes
con presupuestos enormes
que puedan permitirse emplear equipos
de backend y frontend separados?
Esto es lo que dice Michael Jackson.
Y ojo, porque le contesta a alguien
que me ha parecido muy interesante,
que es Evan Yu.
Y dice, definitivamente no.
Supongo que hay muy pocos usan React en producción
a través de un enlace CDN.
O sea, utilizarlo como una URL.
Dice, sin un paso de compilación,
pocos disfrutarían usándolo sin JSX.
Ni querrían utilizar Babel
solo para compilar JSX sobre la marcha.
Y dice, Vue y Alpine
están mucho más cerca de jQuery
en tales casos de uso.
Me ha parecido interesante.
Y creo que tiene razón.
Creo que tiene bastante razón
en el punto que dice Evan Yu.
Porque una cosa que sí que tiene muy buena view
es que igual que pasaba con jQuery,
tú jQuery para utilizarlo,
lo único que tenías que hacer en tu página web
era añadir una URL y ya está.
O sea, tú lo que decías era el download,
te ponías aquí este de aquí,
te lo copiabas,
a CDN, hacías script source, tal.
Y ya tenías aquí jQuery,
ya lo podías utilizar en tu página
y te olvidabas de todo, ¿no?
Esto es una cosa que no puedes hacer con React.
Y de hecho, mucha gente me decía,
React se ha copiado de Vue
porque ahora se compila.
Y yo pensando, pero a ver,
React se ha tenido que compilar
desde el día uno.
Desde que empezó con JSX,
React siempre se ha tenido que compilar
porque JSX no es una cosa nativa,
es una sintaxis inventada por React
y siempre las tengo que compilar con Babel
o con otra alternativa.
Pero las tengo que compilar siempre.
Entonces, que se tenga que compilar realmente React
no es una cosa nueva ni novedosa.
Y lo que era muy interesante de jQuery
era justamente esto,
que ponías la URL y ya está.
Pero es que con Vue también lo puedes hacer,
que es una cosa que no puedes hacer.
Lo podrías hacer con React,
pero no es lo mismo.
Nadie lo utiliza así.
No conozco absolutamente a nadie
que lo utiliza así.
En cambio, con Vue tampoco es
que sea la mejor idea del mundo,
pero lo puedes hacer.
Tú puedes poner un archivo, ¿vale?
Que sería aquí.
Y ya puedes utilizar Vue sin ningún problema.
O sea, esto funciona.
Con React, funcionar.
Podría funcionar,
pero tendrías que hacer alguna cosa, ¿no?
React.createlement
o empezar a generar cosas un poco raras
que no sería la forma recomendada
de utilizar React, ¿no?
Entonces, me parece que tiene un punto
Evan Yu,
que creo que tiene razón en esto que dice.
Creo que ninguno, en mi sensación,
creo que ninguno, ninguno,
es como el sucesor de jQuery.
Creo que ninguno ha llegado a llegar
a ese nivel de jQuery.
Seguramente por eso,
porque se ha segmentado más,
porque no ha habido tanta popularidad
de uno solo.
En popularidad puede ser que pensemos
que React es el que más se ha acercado,
pero aún así,
yo creo que no hay sucesor de jQuery.
Punto.
Ya está.
O sea, es como hemos cambiado el paradigma
y hay otro tipo de cosas,
y punto.
Y ya está, ¿no?