I've never seen one of these "logic in html-attributes" systems take error checking seriously. In stimulus they start to mention it in "Designing For Resilience" (though only for feature-checking), but in "Working With External Resources" where it uses calls network/IO bound calls they never mention how to handle errors or if the framework just leaves it up to you. Stimulus is also where you need to write your own js code, so I guess you could handle it yourself but in turbo when I skimmed the handbook I find no mentions of what/how to handle errors (or even what happens when turbo gets one), and when loading stuff over the network that is pretty much crucial.<p>From the turbo handbook: "An application visit always issues a network request. When the response arrives, Turbo Drive renders its HTML and completes the visit." Using the phrase "When the response arrives" begs the question of what happens if it doesn't arrive, or if it takes a minute for it to arrive, or if it arrives but with a faulty status code.
As others have noted, seems reasonably similar to LiveView, Livewire and Blazor. I’m somewhat bullish on these approaches - server side rendered monoliths (Rails, Django, etc.) are SO productive, at least for the first few years of development, but lack of interactivity is a big issue, and this solves it well.<p>However, another big issue is the dominance of mobile. More and more, you’ve got 2-3 frontends (web and cross-platform mobile, or explicitly
web, iOS and Android), and you want to power them all with the same backend. RESTful APIs serving up JSON works for all 3, as does GraphQL (not a fan, but many are). This however is totally web-specific - you’ll end up building REST APIs and mobile apps anyways, so the productivity gains end up way smaller, possibly even net negative. Mobile is a big part of why SPAs have dominated - you use the same backend and overall approach/architecture for web and mobile.<p>I’d strongly consider this for a web-only product, but that’s becoming more and more rare.
What's old is new again. I recall ASP.NET had some interesting tech around this in the 2000s where it could dynamically update parts of the page.<p>If I recall correctly, this made use of that new technology of the time called "XMLHttpRequest" (/s) which pretty much jump-started web 2.0.
Okay this is a bit meta, but the whole cluster of "everything old is new again", "the pendulum of fashion has swung", "nothing new under the sun" takes is ignoring what tends to drive this sort of change: relative costs.<p>The allure of xmlhttprequest was that over connections much slower than today, and with much less powerful desktop computers, a user didn't have to wait for the whole page to redownload and re-render (one can argue that focusing on better HTTP caching on the server and client might have been smarter) after every single user interaction. This was also much of the draw of using frames (which were also attractive for some front-end design use-cases later re-solved with CSS).<p>As apps got more complex, clients got more compute, bandwidth grew, and as web audiences grew, offloadingl much of the page rendering to the client helped to both contain server-side costs and increase or maintain responsiveness to user interactions.<p>Now, as desktop client performance improvement slows down (this isn't just the slowing of computer speeds, computers are also replaced less frequently), average bandwidth continues to grow, app complexity and sophistication continues to grow, but as server compute cost falls faster than audience size grows, shifting rendering to HTML back to the server and sending more verbose pre-rendered HTML fragments over the wire can make sense as a way of giving users a better experience.
This is so exciting to see, especially for older folk like me.<p>Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery.<p>However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we are moving back to server side because things are too complicated.<p>Obviously tech is different, better, more efficient but the overall idea seems to be the same.
It sounds a lot like Laravel Livewire[1]<p>Also a lot like React Server Components that we saw on HN yesterday[2]<p>It seems like this is the next wave of web apps. Hopefully once the hype settles, we'll be able to decide which approach is best for which project.<p>[1] <a href="https://laravel-livewire.com/" rel="nofollow">https://laravel-livewire.com/</a><p>[2] <a href="https://news.ycombinator.com/item?id=25497065" rel="nofollow">https://news.ycombinator.com/item?id=25497065</a>
I wonder how long it will take before we reinvent SPAs?<p>I like Hacker News in part because the tech is so boring. Server-side rendered, static HTML with a minimal amount of JS[0].<p>[0]: <a href="https://news.ycombinator.com/hn.js" rel="nofollow">https://news.ycombinator.com/hn.js</a>
Most of the comments here are along the lines of: this is old tech!<p>But this isn’t really about the tech, it as much a productivity hack that allows people to be much closer to that old fashioned concept of a full stack developer<p>This is what has allowed Basecamp to create Hey with a team just a fraction of the size of their competitors
Pure JS developers trying to jump off the JS train have a few decent choices now:<p>- Elixir / Phoenix<p>- .NET / Blazor<p>- Laravel / Livewire<p>- Rails / Hotwire<p>Or hold on for the JS ecosystem to figure out good patterns that balance performance/maintainability (React Server Components look ok, and will probably trickle into Next.js for those who want a framework).<p>Does one of the above stand out as a good thing to learn from a career perspective, say, for a JS developer growing tired of frontend?<p>Is the thirst for React developers ever likely to dry up and leave devs who know these frameworks with an advantage?
I love that these new techniques come out to make web dev simple again. I however think Phoenix Liveview is still the best from all the alternatives I have seen so far and that is mainly because Elixir as a language seems to be very stable and suited for having a lot of websocket connections open at the same time.<p>It seems easier to accomplish this with Liveview and perhaps Alpine.js for displaying stuff like modals etc. It's a really good way to build applications I think for places that need a server roundtrip anyway which is most of the stuff in a modern app.<p>I write a SPA app for work in javascript and about 90% of the issues that occurs are mainly state issues where the state differs or is in a bad state for some reason. State management is very hard to do right and I think solutions like these simplyfies it a lot!<p>I urge people to check out Elixir and Phoenix Liveview which I think is the "original gangsta" when it comes to sending small updates over websockets and if you try it I will guarantee you will be blown away of the speed of which you can develop web apps as a solo dev.
I read a little about Turbo, not sure I get it, is this like htmx? <a href="https://htmx.org/" rel="nofollow">https://htmx.org/</a>
Isn't this replacing the complexities of JS libraries like react/redux-saga with the complexities of these new server-side libraries..? Reduced bundle size looks like a big advantage & this will hopefully encourage the adoption of lighter front-end tech like preact/inferno/svelte. But the downside seems to be more resource consumption on the back-end, especially if using websockets, and so higher cost & more vulnerability to a DDOS? Also, what about offline support?
I get the feeling it will draw a bit of criticism from this crowd. IMO it’s fine to experiment with tech like this, but I have to wonder where sending HTML fragments over Websockets instead of HTTP falls apart.<p>Curious to hear about the success/horror stories in a few months/years from any adopters :)
A few years ago, I had this bright idea of updating a site I maintained to be a single page application (SPA). I was very inspired by this site (<a href="https://pocketjavascript.com/blog/2015/11/23/introducing-pokedex-org" rel="nofollow">https://pocketjavascript.com/blog/2015/11/23/introducing-pok...</a>) and thought it would make the user experience a lot better by making the site easier to navigate.<p>I preloaded data such that a user could navigate via search or clicking through some drill-down menus without having to wait for a full page refresh. The data would hydrate the views so that the transition time between views was almost always fast, even on slow mobile traffic.<p>One aspect that was very difficult to figure out was incorporating views that would require more data from the server. Once a user drilled down to such a view, the challenge became how to load the view via AJAX without having to make another AJAX call to load more data.<p>The solution was to return server side rendered HTML instead of JSON...<p>Looking at the demo, this seems very similar to some of the things I had to do minus 95% of the hacky Angular/PHP code I had to set up.<p>This is a killer feature to have in Rails and I am looking forward to learn more of the conventions that will surround the implementation.
The crucial missing piece in this and LiveView, Livewire, etc is optimistic handling of client-side updates. It is not okay standard behaviour to have to wait a roundtrip to visually add a todo list item on the client.<p>Afaik Meteor is the only major full-stack framework handling this. Any other takers?
'HTML over the wire' is an unfortunate tagline, but it does actually seem interesting, I'd suggest looking at the 'Turbo' docs before reacting.<p>I have thought in the past I wish I could have a frameworky component-style frontend, but where the component is HTML rendered by my rust (or whatever) backend. This would seem to get me a lot closer to that.
In case anyone from Basecamp sees this thread:<p>The introductory video is far too long, far too technical (I know a lot about web dev but don't know a lick of Ruby or Rails) and far too fast to follow. I was really interested in Hotwire because of the comments here and now… not so much anymore.<p>(Which of course doesn't say anything about the quality of the tech. I just thought I'd post my first impression of the website.)
These folks literally invented Ruby on Rails and were building web applications for over 20 years now. This tech seems "old" but it's solid.
Products like Slack, Figma and VSCode will not benefit from this kind of technology. Get off of your old school horse. Not all websites are just websites. Performance is not determined solely by load time.
This is exciting! I am less convinced by the Stimulus part though. I currently prefer the Htmx (ex Intercooler) + AlpineJS combo, or VueJS components sprinkled into views for heavier stuff (setup is a bit tricky but then it’s very easy to enhance views with augmented html). Am I missing something?
Am I the only one who was very, very surprised when the screencast immediately jumped into Rails? There's no mention of Rails anywhere on the landing page.
Can someone familiar with this please diff it with Phoenix LiveView?<p><a href="https://github.com/phoenixframework/phoenix_live_view" rel="nofollow">https://github.com/phoenixframework/phoenix_live_view</a>
amazing. This used to be called /cgi-bin/ with templates and XMLHttpRequest (a Microsoft invention initially supported only in IE then adopted by everyone) and now it's suddenly a new technology/approach but with a new name so you're not ridiculed for using it?<p>I gotta give them credit for revisiting server-side page assembling though; moving application logic and templating mostly to the front end was a HUGE mistake. JS is very fast now, but it's still absolutely glacial in its speed compared to server-side code written in compiled languages.
This is the Ruby on Rails version of what Elixir Phoenix Live View and .NET Blazor do.<p>For those not familiar, rather than using a standard web framework where a lot of processing is done client side, these frameworks allow html buttons etc to call native Ruby, C#, or Elixir functions on the server rather than using some sort of post/get request to do that. Every UI interaction goes over the wire, which is where performance can be hurt.<p>Having used Blazor in production for nearly a year, it speeds up development, but your server is doing a lot more processing and will not be able to handle an equivalent amount of users that a normal web app would because it’s keeping a copy of the clients DOM in memory. It’s updates the dom on the server then streams that update through websockets to the clients dom, creating your magic Single Page App experience.<p>I think it’s cool tech, but not necessarily scalable due to the increased server load. I’d be interested to hear from people using it to serve large orders of magnitude of clients at once.
A while ago, way before SPA were cool and even AngularJS was around, I had done something sort of like this, based on Ajax calls though, so the underlying tech was definitely different.<p>While this is truly clever and being based on sockets does seem to simplify communications between client and server, I'm not fully convinced.<p>Currently I see client side rendering as a way to delegate some computing to the clients. Which is a nice way to lower operating costs.<p>I can see the benefit of this and the reasoning behind it. Because SPA still need a server (serverless still implies server side coding) as long as you are executing code on the client you need two codebases. One for the client, one server side.<p>With this solution it would seem that it's possible to serve a web app with only one codebase, so that's definitely a plus. But then performance and costs do preoccupy me a little.<p>Perhaps the ideal scenario for this tech would be for (enterprise) apps to be deployed on proprietary servers, where scale is a minor concern.
Is this the "new magic" that DHH teased on Twitter, or are we still waiting to see what that is? Also, should we expect this to be included in a future version of Rails?<p>My first impression is that the API seems a little convoluted, but that might just be me. In an ideal world, I'd love to just build components (similar to React components) on the server side, and let the framework intelligently handle synchronizing state over the network (Phoenix LiveView seems closer to that), but this feels like it involves a lot more framework-specific logic (and markup) with special cases - stuff that's likely to change as the framework evolves, so I'm not sure how I feel about it.<p>I guess it makes sense in terms of making this easier to add to an existing rails app incrementally (since it's more-or-less "opt-in" for each model, view, and controller), but if I'm building a new project with this and want it on everything, it feels like it will necessitate a lot of code duplication. Either that, or I use it judiciously only when absolutely needed (and use traditional rails behavior for everything else), but that feels like a mess of two very different approaches bundled together in one codebase.
Without reading the details, LiveView in Phoenix (Elixir) sends HTML/DOM updates only. Hotwire sounds pretty similar (and it's a good thing IMO)
This is a continuation of existing Rails ideas: "This is a conceptual continuation of what in the Rails world was first called RJS and then called SJR, but realized without any need for JavaScript. The benefits remain the same" [1]. So if this doesn't wow you, that's why; Rails already largely can do this, but you have to write some javascript yourself. This does seem simpler for the toy example. I'm curious as to how it works with nested templates, there are no examples for it that I noticed.<p>1. <a href="https://turbo.hotwire.dev/handbook/introduction" rel="nofollow">https://turbo.hotwire.dev/handbook/introduction</a>
So far, this looks very much tied to some Rails gems : documentation for installing outside of Rails is pretty much non-existent, I guess to be expected for a beta. My issue with Turbolinks/Stimulus is really that it's developed pretty much behind closed doors at Basecamp and we maybe get a shiny new release every few years, instead of being developed as a more open source project with incremental improvements and input from a wider group of contributors with diverse needs and insights than one small team at one company.
I think the complexity/level is too high. You could easily do the chat from the example video in vanilla JavaScript with a Node.js server and Websocket, that would also be faster and smaller.<p>The video was however a great tutorial, although a bit too fast. (I had to pause and replay a few times). But it did not sell me on the concept.<p>A more simple approach would be to send a (head) request to the server every 5 second asking if the source/HTML/state has changed. Then do a sophisticated diff/replace of the DOM (like in React, but without React) making the smallest change to the DOM as possible (only change what was updated). eg. no full page refresh, nor iframes. (and also send a diff over the wire, not the full page).<p>If you would make the app fully functional/pure you would then be able to cache many states (input->output) and predict them on the client and prefetch, for example a link click, would instantly do the DOM/diff and update the page with the new content. For example in a tic-tac-toe game you could pre-render all states and have the client pre-fetch them.
It took a decade for the industry to realize that JS frameworks were overhyped and the degraded productivity because of them was not worthy. I think they will be replaced by Hotwire-like technologies in the next decade.<p>The same thing will happen to micro services (especially, distributed monolith) and Kubernetes. They are just overhyped.<p>Productivity matters most!
As a non web developer, writing less JS appeals to me, and I've found HTMX[1] to be simple to use. I'll add that the HTMX website/docs are much more approachable than this site.<p>[1]: <a href="https://github.com/bigskysoftware/htmx" rel="nofollow">https://github.com/bigskysoftware/htmx</a>
Laravel's crew had a very similar idea with Livewire (even the name sound similar, probably not intentionally) and it also created a lot of buzz back when it was released - but I don't think it really got past "let's play with it a bit" step for most of teams. We'll see how well this one does...
from a security engineer's perspective, these things seem great, but ultimately become really tricky where DOM nodes need to be produced safely. string concatenation doesn't cut it for obvious reasons, then you have mXSS from mismatches between the backend server and the browser's interpretation of the HTML
Chiming in like all the other old farts...<p>This is how I used to build web apps 20 years ago! :)<p>Render all HTML on the server side using a lightweight templating engine, make page loads fast and make all interactions reload the current page avoiding all client side JavaScript for validation and logic. (except for hotkeys for quick nav)
After playing for some hours with the new Turbo on a side project (with Django as backend), it mostly works fine.<p>One thing that is kind of broken out of the box is form submissions: so a common pattern with server side rendering is to re-render the form with validation errors, but otherwise redirect to wherever.<p>The workaround here I think is to use turbo-streams and just re-render the invalid form HTML snippet rather than the whole page. While this is probably ok for most cases, I have some forms (3rd party library stuff) where this is going to be more work than I'd like, and due to a bug in the beta release you can't override the default form submission behavior - Turbo throws an error if a form POST returns anything other than a redirect. So it's probably not quite ready for production yet.
This all seems super cool, but mega complicated. I'm not in the Rails ecosystem at all, so would love someone's assessment.<p>Is this a new, giant complexity or a nice add-on? A huge mental/development shift or a nicely paved new path to something better?
This is sort of ironic because many years ago what caused me to move functionality to client side was the fact that Ruby on Rails was slower on server side and required horizontal scale and things like memcached to meet my demands.
Generally people argue that static HTML is more <i>energy efficient</i> than server side rendering.
I wonder If that is true in the case of static HTML "that loads an SPA", versus a server-side rendering with a proper cache in place. The SPA loading will still consume good energy on each client computer. Would love to see some numbers.
Lots of hype, lots of projects and approaches, and lots of opinons about what is more convenient, but few numbers measurements of resources (space, time, what more?). May be It silly me, and the difference in energy terms is irrelevant.
I'm currently more interested in processing content as JSON serializable abstract syntax trees, whether it comes from Markdown, HTML, or something else. The popular Markdown renderer Remark (<a href="https://remark.js.org/" rel="nofollow">https://remark.js.org/</a>) supports this. It's based on Unified.js which has markdown abstract syntax trees (mdast) and HTML abstract syntax trees (hast). <a href="https://unifiedjs.com/" rel="nofollow">https://unifiedjs.com/</a>
Two points on client-side JS have been a constant for me for many years:<p>- Noticed excessive JavaScript contributes to poor web performance
- Things cause JS to break, which breaks other interactivity, often I end up using incognito<p>During lockdown, I struggled ordering groceries because 20 seconds of JavaScript execution on the main thread made my "delivery slot" expire!<p>Similar to heydonworks.com stating "Please disable JavaScript to view this site", I'm glad Hotwire is encouraging folks to think about things a little differently.
SPA moves all the routing/templating to the browser side.<p>server side rendering does it all on the server and spits out html(legacy cgi style)<p>between these two: static html template downloaded from the server, then use ajax to update json in the html pages, which is the old boring way but it might still be the best middle ground?<p>Unless I need make a desktop complex GUI program where SPA could be a reasonable choice, I will just do the html/ajax old way, not fully geared towards to server or client side rendering, life is much easier.
I didnt see html, just ruby bindings. Anyone can make easy bindinds on server but it costs flexibility on components, imagine for deep nested levels customized components and syncing.
I'm a big fan of pure HTML pages because of performance and simplicity, but the techniques presented here are neither of those.<p>For performance, server-side rendering is just bad. It won't scale to high volume traffic, cost too much money and is complicated to maintain. Hosting a static HTML files is more performant than that.<p>For simplicity, the current protocol relies on so much "magics" to give the impression of simplicity. I think that's just an illusion of simplicity.
I prefer to send updates to my web application as bitmaps. I do all the rendering of the HTML on the server to an image and just loop over the pixels and send a pixel if something changes from the last update. I call these updates “frames” and the client can even gracefully degrade — it can request a certain frame rate, or I can only send the luminosity value of a pixel, or randomly sample pixels to reduce detail for poor connections.
As a web developer 20+ years, I'm just happy to see how much job security I have since none of you are smart enough to manage a React app and Webpack config.
Is the basic idea that you only transmit the new content when they click a link? Rather than a JavaScript application rendering it?<p>So it's effectively similar to just a normal HTML page, but without things like headers and sidebars etc. being retransmitted?<p>I guess I am old but I don't understand why this requires a multi-million dollar marketing effort and all of the other stuff they invented on top of it.
For those interested in the source code, here they are the repost of the mentioned tech:<p>- Turbo (HotWire) <a href="https://github.com/hotwired/turbo" rel="nofollow">https://github.com/hotwired/turbo</a>
- Stimulus <a href="https://github.com/hotwired/stimulus" rel="nofollow">https://github.com/hotwired/stimulus</a>
Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong.<p>It's just another attempt to put the square peg in a round hole.<p>The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try.<p>You want to build applications? Use tools that where build from the ground up to support application development.<p>On mobile people realized mostly by now that "native" is the way to go. Because native apps are superior along any dimension compared to "web-apps". The same is <i>of course</i> true on the desktop.<p>Mature and full featured technology to build "native" cross desktop applications exists since forever. Just have a look at great tools like IntelliJ IDEA or Bitwig Studio for example.<p>Hotwire on the other hand is just another try to misuse "the web" as an application development platform. It's closer to what the web actually is (namely HTML pages) but it's still wrong on the fundamental level (as it tries to build an app framework on top of something that was meant to be <i>only a hyper-text system</i>).<p>Let's see how long it'll take until people realize this truth - and we're really full circle.
I looked at several html-over-the-wire frameworks during the last weeks and wrote down my opinionated perspective.<p>I think I will go with htmx.<p>If you want to know more: <a href="https://github.com/guettli/html-over-the-wire" rel="nofollow">https://github.com/guettli/html-over-the-wire</a>
The downside is that this makes it really easy for developers to avoid making an actual API. The turbo frames _are_ the API. Great to bootstrap, but miserable if you ever want to implement a native mobile app (or any other client) on top of the same codebase.
I won't say this is a step backwards in terms of progress but it is a step back to the way things used to be done in the early days of Ajax - albeit with a slightly more modern approach.<p>It is appropriate for some applications and not for others. That's just my view.
Not to be confused with Turbo by Yandex: <a href="https://yandex.com/dev/turbo/index/" rel="nofollow">https://yandex.com/dev/turbo/index/</a>, which is a competitive take on Google AMP.
What are the pros and cons of this technique? Seems like this pushes a lot of the rendering compute power from the client to the server. I guess that is good for low power devices but now you need more powerful servers?
We stopped doing this ten years ago because it tightly coupled the front- and back-ends and made it almost impossible to insert an API for mobile apps after the fact.
I guess this is similar to htmx.org (was intercooler.js) which I like a lot! Will learn more about it later and I'm glad similar idea is getting more popular!
Am I wrong to think this is like unpoly except it uses web sockets ?<p><a href="https://unpoly.com/" rel="nofollow">https://unpoly.com/</a>
> The heart of Hotwire is Turbo. A set of complimentary techniques for speeding up page changes and form submissions<p>s/complimentary/complementary
Gotta give @dhh credit - he is one of the world's great marketers/promoters. He's been building hype for this as the "next Rails" for months and the man knows how to pique an audience's interest.
I hate javascript as much as the next person, but when I had to step into .erb templates and regress back into javascript-as-<script> blocks in HTML, holy crap did I realize how far the FE landscape has come. Watching the Turbo demo, I cannot fathom going back to erbs.<p>It seems like DHH is just trying to make relevant tooling without writing Javascript, which I guess is fair, but given all of the advancements in all of the other tech, this really just does not seem like a good idea to me.
How do they intent to not have "Send massive files without using other apps" being abused? Isn't this one of the key reasons to use a separated system.<p>I can see this becoming a big problem on their ecosystem if it starts to scale it'll start to be very costly.
wasn't this called Hijax back in the day?<p><a href="https://domscripting.com/blog/display/41" rel="nofollow">https://domscripting.com/blog/display/41</a>
The downside of this is very high coupling between the frontend and the backend. However, many companies have been successful with strong coupling to Rails so maybe it's not a problem.
15 years ago RoR went against the bloated Java enterprisey frameworks, and after being dormant for some years now it's the time against SPAs.<p>Time will tell --I'm not so bullish on Hotwire-- but one has to admire figures the likes of DHH that can almost single handedly change the status quo of the industry.
Honestly couldn't tell if DHH's initial tweet was satire like vanillajs<p><a href="https://twitter.com/dhh/status/1341420143239450624" rel="nofollow">https://twitter.com/dhh/status/1341420143239450624</a>
Spoiler, it's just Ajax but it pushes the data through your templates before sending it to the client. We were doing this literally over a decade ago in the early days of XHR.
This kind-of tangential reply is in bad taste, but DHH is currently being an asshole about <i>this very topic</i> on Twitter, so:<p>This seems cool, but the progress that HEY has made since launch isn't very impressive if that's the flagship example.<p>HEY's search UX, which uses these capabilities, has been <i>abysmal</i> since the day it launched. It's a much better experience if you disable JavaScript/Hotwire and fall back to the server-side-rendering instead of the hybrid mess they push down. I'm very disappointed that this hasn't been improved. (I sent feedback about this while they were still in their invite-only phase.)<p>We were also promised custom domain support by the end of the year, and we don't have a timeline or even pricing yet. (That's obviously backend and unrelated to this announcement.) I don't want to go back to Google, but the lack of improvement isn't giving me a lot of confidence as a HEY customer, so I'm considering alternatives.
My first thought was that some dude is ripping off LiveWire and Turbolinks because of the strange centered text (no professional web designer would do that), until I saw that those were renamed evolutions of those technologies from Basecamp, cool!.