El salsedito de Ruby on Rails.
Se ha liado parda porque resulta que alguien, no a Falk,
se ha quejado del rendimiento que tenía la aplicación de Hey.
Vamos a ver muy honesto.
Dice, si quieres saber por qué una aplicación necesita JavaScript en el cliente
y no se puede hacer todo en el servidor,
solo tienes que mirar Hey o cualquier aplicación escrita con Hotwire.
Ahora os explico qué es Hotwire porque a lo mejor no lo sabe todo el mundo.
Lo importante es que veáis esta experiencia de usuario.
Fijaos la experiencia de usuario.
Tú le das clic, te aparece ahí una rayita, pasa un rato y entonces aparece todo lo demás.
Parece como que es un rato.
Vale, ¿qué es Hey?
Hey es un servicio...
Hey, no vayas tú mintiendo por ahí.
No es la canción de Julio Iglesias.
Hey es un servicio de email y calendario del creador de Ruby on Rails justamente
y que la verdad que el email está bastante chulo pero no es gratuito, ¿vale?
Hay que pagar sí o sí para poder utilizarlo y por lo tanto pues es un poco complicado.
O sea, es complicado porque yo no voy a pagar y por lo tanto no lo puedo enseñar.
Pero es una alternativa a Gmail, Outlook, Apple Email y todo esto.
El creador de Hey es el creador de Ruby on Rails.
Es una persona bastante conocida seguramente en el mundo del salseo porque es DHH.
DHH está en todas las peleas contra JavaScript, TypeScript y tal.
David Heinemacher, no sé qué.
Creador de Ruby on Rails, es también el CTO de 37signals, era el co-owner.
Creó Basecamp también.
Total, es este hombre que cada dos por tres se está quejando y tal.
Pero esta vez no se ha quejado él, se ha quejado otra persona.
Se ha quejado no a Falk y se ha quejado de esta experiencia de usuario.
Y ahora os diré yo mi opinión final al respecto, al respecto de esto, de todo este salseo.
Porque a partir de este tuit se ha ido liando cada vez más.
¿Cómo?
Aquí Daniel Vasallo dice que él no puede reproducir esto, ¿vale?
Porque le da un clic y aparece de golpe.
Dice, creo que los productos de 37signals utilizan JavaScript y no lo hacen todo en el servidor.
Estoy utilizando Campfire ahora mucho y veo que esto es una cosa que pasa mucho en el navegador.
Luego, aquí hay gente que habla de que la ideología es mayor a la necesidad.
Que muchas veces hay gente que se queja, o sea, que dice, no voy a utilizar JavaScript en el cliente porque odio JavaScript, lo odio y tal, ¿no?
Estoy de acuerdo, hacer puro server-side para interacciones en el cliente es awful, o sea, es horrible.
Lo cual estoy bastante de acuerdo en esto, en este punto.
Y es que hay mucha gente que está como demasiado, como no quieren tocar JavaScript con un palo, pues están como forzándose de alguna forma en que exista un lenguaje en el que lo pueda hacer todo en el servidor
y que directamente te pueda ayudar a enviarte solo el HTML y tú le envías el clic al servidor y que sea el servidor el que te devuelva el HTML y tal.
Eso lo he visto mucho, lo he visto mucho y esa es un poco la idea de Hotwire.
Hotwire es algo que se puede utilizar con Ruby on Rails y que la idea es hacer como single page applications sin necesidad de tener JavaScript en el cliente.
Lo haces todo con Ruby on Rails 7, ¿ves?
Sin necesidad de escribir nada de JavaScript code.
Y aquí pues tienes este ejemplo maravilloso, donde tú tienes todo esto, tú lo escribes todo en el servidor, lo que haces es enviar los eventos mínimos, los envías al servidor, te los devuelve y ya está.
No me parece una mala idea, la verdad, y creo que hay un montón de aplicaciones, luego lo explicaré un poco porque no me parece mala idea,
pero hay un montón de frameworks o tecnologías que vienen a tener esta idea, ¿no?
La idea de intentar hacerlo todo en el servidor o con lenguaje de servidor, por ejemplo, Blasor lo hace con Csharp.net y lo compila WebAssembly.
Luego tenemos aquí en este caso Hotrails, yo pensaba que era Hotwire, pero bueno, pues Hotwire, pues tiene, ah, Hotwire, es que Hotwire es este, no es Hotrails, perdón, Hotwire.
Hotwire es de default, aquí es, no será que es un, o sea, esto es un curso, Hotrails es un curso, ¿no?
O sea, eso es el tutorial, vale, este es el tutorial, Hotwire es esta, esta es la página, Hotwire, HTML over the wire.
Claro, esto lo que hace es devolverte HTML directamente desde el servidor, ¿vale?
Y aquí tenemos, por ejemplo, una demo para que les voy a dar un poco y os hagáis un poco la idea, ¿vale?
Aquí tenemos un poco la idea, ¿vale?
Ta, ta, ta, ves, aquí tú tienes todo esto, pu, pu, pu, pu, pu, aquí tú escribes y para que veamos un poco, a ver si, bueno, ¿veis?
Aquí tú, pues cuando lo escribes en la Nickword le das un clic, ¿ves?
Envías ahí y cuando envías, update, pues esto te está devolviendo directamente el HTML que tiene que re-renderizar, ¿vale?
No es una mala idea, la verdad, o sea, es que, a ver, que es una cosa, una idea bastante antigua, ¿eh?
Las cosas como son.
Tiene sus cosas buenas y sus cosas malas.
El tema, un montón de gente, yo soy Howard Wood, React Bad Camp.
Hostia, hay gente que está en contra totalmente de React también.
Pero también me he dado cuenta de que el calendario, los diálogos del calendario están súper mal, no sé qué, ya sé cuánto.
Ojo, dice aquí alguien, dice David Becerra, dice, oye, ¿has simulado una conexión lenta para esto?
Porque parece que va muy lento.
Y dice, y aquí entonces dice, sí, exacto.
Para demostrar, por temas de demostración, lo he hecho que vaya lento.
Esto no significa de que no vaya mal, sino que simplemente era solo para demostrarlo.
Y aquí es donde se ha empezado a liar un poco la cosa, ¿vale?
Porque aquí ha respondido el bueno de DHH.
Dice, este tío ha olvidado compartir que ha creado este clip de forma artificial porque lo que ha hecho es simular una conexión lenta de una conexión entre eje.
Si haces lo mismo con Google Calendar, por ejemplo, o con una single page application completa, el resultado va a ser tan malo como este o incluso peor.
Si las web applications requieren una conexión en internet para funcionar, es como, anda, has descubierto América, ¿no?
Como, ah, y ahora te enteras de esto.
Mira, por ejemplo, ha puesto un vídeo de Google Calendar, ¿vale?
Aquí tenemos un Google Calendar donde pone la conexión de 3G, ¿vale?
Le das a Create, Evento, ¿vale?
Y veis, no aparece el diálogo, dónde está el diálogo, dónde está el diálogo y entonces aparece el diálogo, ¿no?
Porque está con una conexión de 3G.
Y, bueno, pues no aparece.
Y esto es, por ejemplo, cómo funciona con una conexión en condiciones sin tener un throttling artificial.
Aquí hay gente que dice que ya discrepa y hay gente que está de acuerdo, que no está de acuerdo.
Pero qué mal que haga esto, cualquiera que haga lo mismo tendría el mismo resultado.
Bueno, bueno, ahora os comentaré sobre esto, ¿no?
Hay también páginas web, por ejemplo, Linear, que dice por aquí, mira Linear.
Linear, esto es con una, con un simulando 3G.
Fijaos cómo funciona simulando 3G Linear.
Ojo, ¿eh?
Esto es simulando 3G.
Simulando 3G, ¿eh?
¿Vale?
¿Habéis notado algo mal?
¿Algo raro?
¿Algo tal?
¿Vale?
Pues no.
No, porque parece ser que todo está funcionando increíble porque es local first.
O sea, que funciona todo en local por defecto.
Me imagino que están trabajando con service workers y tal.
Yo imagino que esto no es la primera vez que carga.
Ya os lo digo yo.
¿Vale?
O sea, estará muy bien.
Yo me imagino que, obviamente, no es la primera vez que carga, que a lo mejor ya ha cacheado cosas.
Es algo negativo de cuando tú devuelves el HTML desde el servidor.
Es que no puedes cachear muchas cosas que ya irían en el cliente, ¿no?
Y aquí, pues sí que hay cosas que podrías hacer.
Y que una vez que las has descargado, como todo pasa al local, incluso podrías guardar, como en la base de datos local, las issues y tal.
Y luego sincronizarlas.
O sea, que está muy bien.
O sea, ahí ya se ve una buena experiencia.
Pero el tema es que, claro, la tenía que liar alguien.
Alguien, alguien la tenía que liar parda.
Y es que, pum, el bueno de CIO ha hecho un vídeo reaccionando a esto.
E incluso probándolo todo.
Ha estado probándolo todo.
Y lo podéis ver, el vídeo se llama Rails Deserve Beta.
Y lo que hace es como comparar, ir viendo cada una de las cosas.
A ver cómo funcionaba esto, dónde fallaba y tal.
Y el bueno de Daniel Basallo, bueno, te puedes dar cuenta que este tío es un estúpido cuando se pone a enviar un email real al soporte de Hey intentando romper la aplicación.
Estoy seguro de que llama al 911 para probar que la recepción del teléfono funciona.
Y ya ha pedido disculpas CIO como diciendo, oye, lo estaba probando pero no sabía que eso realmente iba a soporte y tal.
Pero CIO sí que decía de que, oye, para demostrar que realmente Ruby on Rails va muy lento, ¿vale?
Va muy, muy, muy lento.
La cosa es que va muy lento.
De hecho, él ha estado, ha estado, a ver si lo encuentro, tenía por aquí el email.
Ahora lo encuentro.
Pero CIO, para que veáis un trozo de lo que ha demostrado, lo que estaba enseñando en el vídeo CIO, que está bastante bien.
Lo que hacía era probar la aplicación en real y es esto lo que pasaba, ¿vale?
Esto es lo que basaba un poquito en la aplicación.
Dice como que le ha dado enter y que no se ve que te dé una, en la interfaz te diga, oye, que le has dado el enter.
Vale.
Ahora viene de bueno.
Está ahí detrás.
La verdad, la verdad, que ahora no tiene Thronlin, o no parece que tenga Thronlin, y también le pasa esto de la cosa de esta.
No es tan bestia, pero fijaos, le da.
Y sí que aparece como el salto ese.
Claro, fijaos, esto es una cosa que no me gusta nada, porque fijaos que cada vez que escribe, cada vez que escribe, fijaos que envía una petición, una petición, envía una petición.
O sea, esto sí que da miedo, Dios mío.
Fijaos que cada vez que escribe.
Polémico, ¿eh? Polémico.
Y ahora le ha dado enter dos veces.
Y claro, le ha creado dos veces.
Le ha creado dos veces él.
Claro, la risa de Theo, el tío, el cabrón, también.
Vale, y le ha creado dos veces el evento.
Le ha creado dos veces el evento.
El tío se parte.
Qué cabrón.
¿Cómo es esto serio?
A ver, la verdad, tiene razón lo que dice.
Pero vuelvo a responder un poco el bueno de HH.
Cuando te enfocas en los edge cases, como la velocidad de una modal o hacer test artificiales, te estás olvidando de la suma de todos los trade-offs.
Y aquí hay un vídeo en el que te está explicando todo lo bueno de Hey Calendar y lo bien que funciona realmente, ¿no?
Y aquí te explica cómo funciona en general bien la aplicación.
La muestra, no sé si controlling, si trolling, y la verdad es que está...
La verdad es que la aplicación tiene muy buena pinta.
A mí me gusta bastante.
Está hecha con ribbon rails y tal.
Con todo este drama, hay gente que ha querido demostrar cómo se haría esto con Next.js bien.
Por ejemplo, aquí tenemos este ejemplo del optimistic drag and drop.
El optimistic, porque muchas veces el tema es cómo se haría esto bien.
Pues se tendría que hacer con un approach optimista.
Un approach optimista quiere decir que tú lo que vas a hacer es decir, vale, yo voy a hacer que la UI se sienta que responde inmediatamente.
Fijaos, la diferencia del default cuando arrastra es que tú arrastras y hasta que en el servidor no termina, ¿vale?
No aparece.
Esto lo hemos visto en las novedades de React 19.
Estuvimos haciendo unas pruebas sobre esto y también lo hemos visto en diferentes cosas.
En el curso de React también lo vimos de cómo son las mejoras optimistas, ¿vale?
Esto sería por defecto lo que está pasando.
Y aquí en el optimista lo que estaría pasando es que tú lo arrastras, la UI se siente que es inmediata, aunque en el servidor esté tardando esto en responder, ¿vale?
Y tú puedes ir haciendo que no pasa nada, que se va a sincronizar correctamente con el servidor.
Y esto sería con Next.js.
Y luego por aquí hay gente que le dice, oye, pero ¿qué pasa si tienes un error, no?
Por ejemplo, si tienes un error en el servidor, pues aquí lo podéis ver.
¿Qué es lo que pasa si hay un error en el servidor?
Si hay un error en el servidor, vais a ver que lo arrastras y como es optimista, cuando hay el error, vuelve para atrás y ya está.
O sea, esto es lo que se diría una UI optimista.
Pero el punto yo creo que de todo esto es que yo creo que ha habido como una batalla.
Ruby on Rails, JavaScript, server side rendering, single page applications, ha habido como una mezcla.
Y yo la verdad, sinceramente, es que no hay nada de Ruby on Rails que no le permita hacer esto bien.
Esto es simplemente un error de UX.
No es un problema de la tecnología, es un problema muchas veces de prioridad, de que seguramente no le han dado ningún tipo de prioridad.
Yo no tengo nada ni en contra, ni a favor de Ruby on Rails, de JavaScript, ni nada.
Pero es que creo que tanto en Ruby on Rails como en JavaScript se puede hacer bien y se puede hacer mal.
Porque no se trata de una limitación de la tecnología, sino que se trata de algo que no han hecho, que podrían llegar a arreglar y que son capaces de hacerlo.
Lo que pasa es que no lo han hecho porque, uno, no han probado la aplicación con una conexión 3G, cosa que nos pasa a todos muchas veces y que os recomiendo que no falléis en eso.
Que sí que probéis vuestra aplicación en 3G para ver cómo se siente con malas conexiones.
Si hay que mostrar un loader, si hay que hacer actualizaciones optimistas para que el usuario no tenga que esperar.
Imaginaos que en Twitter, cuando a vosotros le dais like, tú le das like y hasta que en el servidor no se actualiza, entonces no aparece el like.
La gente se volvería loca, sería una experiencia de usuario muy rara.
Cuando dejas un comentario, todo esto.
Entonces, yo no creo que sea un problema de la tecnología.
Yo creo que más bien el problema, dice, se empieza criticando el mal uso de una tecnología y se termina por criticar la prueba de tecnología sin motivo.
Yo, sinceramente, que Hikus, creo que no tiene nada que ver con que sea algo de Ruby on Rails.
Creo que, sinceramente, lo podrían arreglar y ya está.
Es verdad que lo que puede ocurrir es, si tú haces un enfoque 100% que siempre el servidor te devuelva el HTML,
como siempre vas a depender de que el servidor te dé el HTML, pues al final vas a tener este problema de que la UI se sincronice con el servidor
y siempre se tiene que sincronizar igual, pero se podría arreglar igualmente con muy poco JavaScript.
Ahora, si es verdad que los extremos son malos.
Si tú estás en un extremo de decir, no quiero nada de JavaScript en el cliente,
pues seguramente vas a perder la posibilidad de enriquecer la experiencia del usuario en el cliente.
Para eso es JavaScript, justamente.
Pero el otro extremo de decir, no, es que esta tecnología es mala porque pasa esto,
también es que dices, es que lo podrías hacer sin ningún tipo de problema.
De hecho, también se puede hacer Optimistic UI con Turbo, y aquí lo tenéis, ¿no?
Por ejemplo, aquí hay un ejemplo de cómo hacer Optimistic UI, ¿vale?
Aquí tenemos cómo hacer Optimistic UI, y puedes ir viendo que, aunque aquí se va escribiendo
y aquí está pending todavía, aunque está pending, podéis ver que se está mostrando ahí.
Aquí todavía no está guardado, están en pending todas.
Bueno, no lo veis porque esto es completo, ¿vale?
Pero aquí, mientras está escribiendo, básicamente se está mostrando en la UI.
O sea, que también se podría hacer, que no es un tema de que no se puede hacer.
Se trata simplemente de un problema de UX que le podría haber pasado en JavaScript,
en Ruby, en PHP, en Python, en cualquier cosa.
Y eso es lo más importante que yo creo.
Que creo que lo importante es no poner el foco tanto en la tecnología
y además ir de hater independientemente del lado.
Si es que no me pongo ninguno de los lados.
Sino que creo que a veces perdemos un poco el foco como si no se pudiera hacer
y sí que se puede hacer sin ningún problema.
¿Es un problema de UX?
Sí, creo que es grave.
Tampoco me parece tan grave.
Las he visto peores.
Sinceramente, he visto peores cosas de UX.
Pero atacar a Rubion Race o a Hotwire o esto, justamente por esto,
yo sinceramente no me parece.
No me parece.
Si queréis más información sobre esto,
hay un artículo final que ha escrito la propia gente de Hey,
que no está mal, aunque no me gusta el artículo,
no me gusta mucho el approach,
porque se pone con el drama,
que hay trolls,
troles profesionales,
que sí, que hay un debate de HTML,
de enviar HTML,
que son un equipo muy pequeño
y han hecho un producto muy complejo.
El artículo al final explica cómo funciona paso a paso,
solo para que entendáis un poco esto,
y cómo se compara este modelo con el de las single page applications,
como toda la complejidad que hay detrás.
Pero yo creo que también está bien abrir el debate
y también reconocer que la experiencia de usuario,
en este caso en concreto,
no es el mejor,
que se puede mejorar
y simplemente no ver al otro como que es un troll por esto,
aunque sí que pueda ser un poco troll,
porque creo que realmente hay que mejorar la experiencia de usuario
y hay que abrazar el cambio en este sentido.
Y ya está, ¿no?
Me ha parecido un salseo,
porque hay mucha gente que se ha metido a bicho,
ha habido mucha gente ahí,
como cada uno en un extremo,
y me da la sensación que a veces olvidamos
que realmente y simplemente es que no se puede priorizar todo.
En un producto no todo puede ser perfecto.
Y encontrar que en un diálogo se abra un poco más tarde
y hacer un caso de que la tecnología está mal justamente por eso,
me parece un poco infantil, sinceramente.
Me sabe mal porque he visto a gente que aprecio mucho en este debate,
pero me parece un poco infantil.
Por ejemplo,
yo no podría juzgar a React
porque alguien haya hecho un porfolio
y ocupe 10 megas
y tarda mucho cuando le das clic a un botón en responder.
Ah, pues es que React,
el problema es React
y entonces hacer un vídeo y reírme del porfolio,
como ha hecho CIO del producto.
La verdad es que ahí me parece
que es llegar ya a un punto demasiado extremo.
Creo que está bien dar feedback
y decir, oye, esto...
Y hay un debate sano
sobre si estamos de acuerdo
de enviar HTML o no enviar HTML,
pero hacer que la tecnología sea mala
por un específico caso
no me parece bien, la verdad.
No se puede hacer abstracciones tan ambiguas.
Es infantil totalmente.
X está lleno de haters de JavaScript.
Si no,
que también pasa con haters de JavaScript.
O sea,
que...
Pero yo estoy,
en este caso,
en este caso,
estoy...
Estoy defendiendo
o realmente estoy defendiendo a Rubén Ress.
Tu opinión sobre enviar HTML.
Mi opinión,
la verdad,
es que creo que a veces tiene bastante sentido.
Enviar HTML puede ser algo bastante óptimo.
Por ejemplo,
los React Server Components
vienen a traer esa idea un poco.
No es HTML directamente,
pero se trata de hacer el renderizado
y el fetching de datos
directamente en el servidor.
O sea,
los React Server Components
vienen a tener un poco esta idea
porque tiene sus beneficios.
Pero yo creo que no puede ser todo.
O sea,
no creo que todo pueda ser
o 0 o 100.
Me puede gustar la idea
de enviar HTML
y creo que puede tener
algunos casos de uso interesantes,
pero creo que construirlo todo
100% así
no es viable.
Y al final
es demasiado costoso,
el tener que enviar
todos y cada uno
de los eventos
que haces en una página web,
en el servidor
y que el servidor responda y tal,
pues no es muy realista.
Por ejemplo,
ese ejemplo que hemos visto
en el calendario
que cada keystroke,
o sea,
cada vez que le das a la tecla
lo envías al evento
porque vete a saber
si tienes que hacer una validación,
si tienes que hacer cualquier cosa,
no es realista.
JavaScript se inventó para algo.
Yo entiendo que hay gente
que no le gusta JavaScript,
lo entiendo.
Pero hay que entender una cosa,
te guste o no te guste.
JavaScript en el cliente
sirve perfectamente
y para eso se creó,
para enriquecer
la experiencia del usuario.
Y hay que estar abierto
a esa posibilidad
porque es la vital.
No hay un lenguaje mejor
que exista para eso.
No hay un lenguaje mejor
en coste, rendimiento y tal.
Porque tú en una línea
o en tres líneas
de JavaScript
le puedes dar interactividad
a un botón,
puedes hacer una validación
de un email y tal.
Otra cosa
es que luego quieras validar
en el servidor
todo lo que haces en el frontal.
Eso por supuesto,
en el servidor siempre
se tiene que validar todo
y se tiene que hacer todo.
Pero en el cliente
le estás mejorando
la experiencia al usuario
para una actualización optimista,
cambiar el renderizado de algo
para validar una cosa
y mostrarle una información.
Por ejemplo,
en este diálogo,
si tú en el cliente
ya tuvieses
la creación del diálogo
mientras realmente,
o sea,
si tú le das
Open New Dialog
y tuvieses esa parte
al menos en el JavaScript,
pues eso mejoraría
un montón
la experiencia del usuario
y eso no te evita
que después
sí que devuelvas el HTML
en otras APIs,
¿no?
Eso es así,
no pasa nada,
o sea,
no todo tiene que ser
blanco o negro,
que es que nos encanta
y menos en la tecnología,
que hay tantas capas de grises,
tantas tapas
y así son las cosas.