David Heinemeier Hansson (DHH) y los suyos no descansan. Tras crear Ruby on Rails, Basecamp y lanzar este verano HEY, conocido servicio de correo eléctrónico por su pugna con Apple por poder estar en la App Store, ahora han presentado Hotwire. Como reza su propia página web, se trata de un enfoque alternativo y open source para construir aplicaciones web modernas sin utilizar JavaScript. ¿Cómo lograrlo? Con el envío de HTML 'over the wire' en vez del formato JSON.
Comentarios
https://xkcd.com/927/
Más que "adiós a JS" tiene pinta de ser una tecnología que incrementará el tráfico web de forma innecesaria.
Si ya existe JS y más o menos funciona, no se qué necesidad hay de convertir el ordenador de la gente en terminales ligeros.
#3 Algo parecido se decia de Cobol
#8: De hecho Cobol sigue usándose, en proyectos nuevos no, pero en los preexistentes...
Aquí hay dos obstáculos: muchas páginas cuyos autores NO van a modificar, y por lo tanto, los navegadores deberían poder seguir leyéndolas, y por otro, muchos navegadores web que a lo mejor no se pueden actualizar fácilmente o sus dueños no lo harán. Y luego hay un tercer obstáculo: la mayoría de programadores web están familiarizados con JS, no se hasta qué punto podría hacerles ilusión aprender un nuevo lenguaje que tal vez no se use mucho.
#3 y de "adiós" nada, dice "without using much JavaScript". Que no es lo mismo.
#11: De hecho como mucho parece que están reinventando las páginas web dinámicas.
Por lo que he entendido del artículo, sería básicamente AJAX por WebSockets.
En lugar de tener un front en JS que recibe un JSON con datos y los usa para "pintar" lo que corresponde, hace una petición por websocket y recibe el HTML ya formado para colocar en el sitio que corresponda.
Si es así, habrá que ver qué utilidad tiene, porque por lo pronto las APIs REST o GraphQL en principio no serían compatibles.
También se trasladaría el trabajo de generar el HTML del front al back. Aunque usando sistemas tipo memcached no se sobrecargaría tanto eso sólo podrías usarlo para plantillas que no tuvieran datos concretos del usuario, en caso contrario el backend tendría que renderizarla en la petición o actualizar esos datos con JS en el cliente, con lo que seguirías teniendo la necesidad de pedirlos a una API.
¿O es que lo que se propone es usar ambos? Es decir, pedir el HTML por Hotwire y los datos por JS, y luego manejarlo todo junto en el cliente, de manera que el renderizado no se haga en el front y este se dedique a manejar los datos sobre las plantillas que recibe.
No sé, seguro que se me están escapando bastantes cosas y el artículo no es claro, habrá que estar pendiente.
#1 Vamos, retroceder 10 años.
#1 puedes hacer un api rest que devuelva HTML, nada obliga a que devuelva JSON. Hace 10 años estaba yo haciendo algo parecido, solo que usando js para hacer peticiones ajax a un api que devolvía HTML...
Si algo tiene de bueno el envío de JSON es que son ficheros con poco peso lo cual facilita la comunicación, y la construcción del html lo derivan al cliente quitando trabajo de procesamiento al servidor agilizando la comunicación cliente servidor.. al igual que en el proverbio "divide y vencerás"... Por otro lado.. el uso de websockets es muy habitual para el envío de JSON
Creo que algo muy similar a Laravel Livewire
No identifico el problema de usar JS.
¿Falta de cómputo? Será por memoria y por núcleos.
Sin embargo los servidores cada vez requieren más cómputo y gastan más energía.
Intuiivamente, en mi opinión, de donde habría que aligerar es en el servidor. Pero esta tecnología pretende sobrecargarlo más y necesitar mejor conexión a la.red. Otra cosa que en gran parte del mundo es un problema.
Ahora mismo no lo veo claro. Pero veremos en un futuro.
Por cierto, para el que no lo sepa... La comunicación web habitual es HTTP.. los websockets usan un tipo de comunicación un poco diferente con menos pasos para que sea más rápido pero no garantiza la recepción del mensaje
#5 ¿Que quieres decir con "garantizar la recepción del mensaje"?
HTTP corre sobre TCP y ofrece los mismos mecanismos de entrega. No hay garantia de entrega pero si una alta resiliencia a fallos.
Json es de lo más fácil y ligero que hay, y siempre hay iluminados que quieren joder la simplicidad.
Nueva frase a recordar: "Este es el año del killer javascript"
Lista por ahora: dart, typescript, webassembly, blazor, coffeescript, elm, etc... y mientras node.js expandiéndose poco a poco en los servidores https://w3techs.com/technologies/details/ws-nodejs
#10 Esa gráfica no indica que cada vez se desarrolle más en node o que esté cobrando más importancia. Sólo dice que crece el número de servidores que son identificables como node.js.
Y eso,... puede no ser tan bueno.. Significa que cada vez hay más gente exponiendo directamente servicios en node sin colocar delante un nginx u otro servidor web. Ni un balanceador de carga, ni nada. Sirviendo certificados directamente, sin ocultar la firma del servidor y sin usar las herramientas potentes de administración que te da un servidor web en modo proxy.
Yo programo en go. Pero corriendo en un kubernetes y con un balanceador de carga delante. Lo que ve un cliente es un nginx.
#15 Ok, puede ser lo de la exposición, pero por ejemplo empresas como Amazon, Netflix, eBay, Reddit, LinkedIn, Tumblr y PayPal se han pasado a node.js
https://hostingtribunal.com/blog/node-js-stats/#gref