El futuro del software web es HTML-over-WebSocket
(alistapart.com)-
SPA + API + JSON ralentiza el desarrollo y el ciclo de lanzamientos
-
Se plantea que, usando WebSocket bidireccional, son posibles el renderizado del lado del servidor, el prototipado rápido, un SEO intuitivo y el desarrollo ágil de funciones
→ Enviar por socket el HTML que cambia o texto simple
→ En lugar de validaciones complejas de valores y objetos de error en el cliente, que el servidor se encargue de validar
→ Verificar si el usuario está conectado según si la conexión del socket está activa
→ También es fácil dar soporte a chat multiusuario o colaboración en documentos
-
El regreso de Rails: Turbolinks, Stimulus, StimulusReflex, CableReady y GitHub’s ViewComponent
-
El Hotwire de Basecamp también usa la misma tecnología
7 comentarios
Parece que el
serverside blazorde dotnet funciona de forma parecida. Pero cuando de verdad intentas usar esto en producción, terminas pasando por bastantes situaciones bastante cansadas...Fuera de distribuirlo empaquetando tanto el servidor como el cliente dentro de Electron, la verdad es que no le vi ninguna ventaja en particular.
¿Podrías compartir un poco más sobre tu experiencia de uso concreta?
Pero si creas un endpoint de API, se puede usar en móvil, web y escritorio, así que tiene buena versatilidad; no sé si se pueda decir que WebSocket sea el futuro.
Elixir Phoenix LiveView, o incluso RoR Stimulus Reflex, son conceptos parecidos.
También se comenta que Chris McCord estaba construyéndolo con Rails, pero por problemas estructurales se pasó a Elixir.
Suena a dar vueltas en círculos...
Supongo que está bien verlo como una de esas posturas interesantes.
Estoy de acuerdo en que, a medida que Javascript se usa en todas partes, han aparecido muchos términos como SPA y SSR, y todo se ha vuelto excesivamente complejo.
Parece probable que WebSocket se aproveche más porque permite procesamiento bidireccional, pero creo que habrá que esperar a que aparezca algo más cómodo que Hotwire.
(Tal vez sea porque no sé mucho del tema), pero últimamente hubo una parte que me pareció algo graciosa: en una web app con React + Laravel, cuando solo cambia el lado del servidor, lo que se despliega es la marca de versión y unas cuantas líneas de código modificadas; pero cuando cambia el frontend, hay que hacer el build de la app frontend y el tamaño del despliegue crece relativamente mucho, así que me da hasta risa. También es difícil aplicar personalizaciones urgentes de forma temporal. Supongo que también es porque inevitablemente lo comparo con experiencias de desarrollo anteriores.