9 ms·

Hotwire: A new old way to build web apps

141 points by grzm 6y ago

leephillips 6y ago
Also see https://htmx.org/ https://htmx.org/ for a library that progressively enhances web pages by getting HTML fragments from the server.
- donatzsky 6y ago
  I was about to say that it sounds a lot like the same idea. Seems like Hotwire leans a bit more towards "SPA" territory.
- AtlasBarfed 6y ago
  by "progressive enhancement" do you mean loading content in place? I though progressive enhancement was the ability of a website to accomodate no-js and max-js?
  - leephillips 6y ago
    Yes, I mean that with htmx it’s easy to make a page that works without JS but that works better with it.
jack_riminton 6y ago
Nice to see it being used in frameworks other than Rails Would be great to see someone to do a rewrite of an SPA using Hotwire, haven't come across anyone making the switch yet
- propelol 6y ago
  The Laravel (PHP) community is using Livewire, which is like Hotwire. Phoenix (Elixir) also have something called LiveView.
  - francislavoie 6y ago
    There are some pretty big key differences though. Livewire is pure ajax (at least for now, may change in the future, a rewrite is in the works), Hotwire is mostly websockets. Livewire does DOM diffing in the frontend, Hotwire does it server side (sorta? didn't dig a ton but that's my understanding). Performance characteristics are pretty wildly different depending on the usecase.
    - sagolikasoppor 6y ago
      With the advent of http3 won't normal ajax requests outperform websockets?
  - jack_riminton 6y ago
    The key test for me is whether a Rails/React site makes the leap. Perhaps the tech is just too new and therefore too risky
agd 6y ago
I’ve been using Hotwire (turbo and stimulus) with my latest elixir/Phoenix project and it’s been great. Adding dynamic behaviour to pages is quick and easy using the existing templating system. The stateless nature of it helps avoid bugs. If you really need a very complex / dynamic UX then this isn’t the way to go, but for everything else, I think it’s much simpler than react etc.
- yumraj 6y ago
  Why not just use Liveview since you're using Phoenix? Could you share your thoughts on the difference between Liveview and Hotwire.
  - agd 6y ago
    Liveview is stateful and uses websockets (or long polling) whereas turbo is stateless and uses regular http requests. NB. I haven’t used liveview, however turbo seems much simpler on a conceptual level because of the lack of state. This comes with extra performance cost, but on my current project I’m optimising for dev productivity and simplicity.
    - yumraj 6y ago
      I'd be interested in the "how" if you'd consider creating a blog on using Hotwire with Phoenix. Or, if the source is in a public repo.
      - nickjj 6y ago
        > I'd be interested in the "how" if you'd consider creating a blog on using Hotwire with Phoenix. Technically it doesn't involve adding or changing even 1 line of code on the back-end to make Turbo Drive and Frames work with any tech stack. It works out of the box by following Turbo's docs and using the HTML tags they mention along with bringing in the Turbo JS library. But for Frames you can optionally do what Rails does and add some server side code that says "hey, if this request is coming from a Turbo Frame only send the partial template as a response instead of the whole layout". That logic for Rails is here: https://github.com/hotwired/turbo-rails/blob/main/app/controllers/turbo/frames/frame_request.rb https://github.com/hotwired/turbo-rails/blob/main/app/contro.... It's a nice to have optimization that will reduce your frame's HTML payload size but it still works without doing this. It can be ported to Phoenix or any back-end language by using a plug / middleware to not render the layout if a specific header exists in the request. The ETag stuff could be ported over too if your web framework's web server sets an ETag header. Streams are a bit more tricky to get working in other tech stacks since it may involve Websockets. Hopefully we start to see more examples in the future. But I believe it should be possible to pull off in a production ready way with any back-end language that has a good library or built in support for Websockets at the framework level. That means Flask, Django, Laravel and Phoenix are all good to go in this regard (probably others too but I'm not familiar enough with their ecosystems to say for sure).
jaywalk 6y ago
This is how the old ASP.NET Web Forms UpdatePanel worked.
- sputr 6y ago
  And Drupal 7. What is old is new again. Laravel has also joined in on this train. But from what I remember ... I hated this technology with a burning passion back when I was still working on D7.
  - PaulDavisThe1st 6y ago
    was it actually different between D6 and D7 ?
- vyrotek 6y ago
  Ha, oh boy. They were both magical and a nightmare when I worked with them years ago. One company I was at was adding more and more dynamic interactions to parts of their asp.net web app. It was a messy time trying to mix jQuery, ajax, update panels, and dealing with viewstate.
rackforms 6y ago
Id like to propose an alternative to the alternative posed in the article: Years ago I was tasked with building dozens of basic web forms. Immediately recognizing the inherit silliness of this task (boring, error prone etc), I built a form creation tool, which all these years later lives on as RackForms. Over the years the feature set grew organically to accommodate an ever growing set of demands. Yes we still build forms, but we also call into web services, display data, and so on. Point being, RackForms and any number of other form builders are the blindingly obvious choice for this task -- it would be down right silly to code forms by hand in this era. And yet that's what we do with the web as a whole. Once again Microsoft seems to have had the right idea in the good old Web Forms days. Instead of coding app's you'd simply drag and drop components and add wiring code to do what you needed. Sure it was never that easy, but it's really hard to see how it couldn't have been better given more time. Fast forward to today and as much as I adore say, VS Code, it's really nothing more than a hyper-powerful text editor. It has none of that tolling to allow for drag and drop development, Id propose that;s the real solution to this issue - Better Tooling.
- danpalmer 6y ago
  That's great if you're building an internal tool, and in fact we use the Django Admin site for this, there exist low-code/no-code tools like Retool for things like this, it's a great type of solution. Where this breaks down is anything customer facing, like Hey (the product Hotwire was built for), Basecamp, or things like Thread the product I work on. These products aren't forms, or CMSs, and trying to fit them into those sorts of solutions results in a bad or counter-intuitive user experience, even if somewhere deep down these are essentially "CRUD" applications.
  - mistersys 6y ago
    I understand your point here, but I think we're a couple of innovations away from dramatically reducing the cost of UI development. The state of the art for web and mobile app development is a delicate stack of tools that require a lot of expertise to wield. However, if you pay attention, most the complexity of modern UI development is accidental, not fundamental. Figma already has "auto-layout", which is essentially flexbox. Imagine a world where your designer just builds your whole app with in Figma with flexbox-like constraints, then they hand off to your developer who just writes a couple of snippets code to wire it up to a database and makes sure the elements are configured to be SEO friendly. IMO developers dramatically underestimate the power of GUI tools to usurp their role because we think in terms of such low level tools.
jonstaab 6y ago
Maybe this would work for simple websites. But for web apps, it's a hard pass for me. For context, I write a web-based POS application, and waiting for a network request on every micro interaction is a no-go. There are lots of other problems with this approach that could be solved, but aren't immediately obvious, such as (similar to React) over-rendering. If someone has their focus in an input within the frame that gets swapped out, they're going to lose their focus. This has implications for accessibility as well as just regular usability.
- mattkevan 6y ago
  Hey, the webapp Hotwire was extracted from isn’t a webapp?
  - cercatrova 6y ago
    People say that Hey is definitely not as responsive as other client-side web apps like those made with React.
  - dbbk 6y ago
    It is a web app but not a good one.
- Scarbutt 6y ago
  For micro interactions Stimulus covers that part, which is a small client-side JS framework.
- throwaway08320 6y ago
  > web-based POS application That's a hard pass for me!
- midrus 6y ago
  The focus thing is as easy to fix as just not swapping that component. Certainly you need a different mindset to use this technique. If you try to do it the same way you do SPAs you will find a lot of problems of course
parentheses 6y ago
Old way indeed. I always asked why this went out of fashion. JavaScript thrived under the reign of JSON.
kuon 6y ago
I use phoenix live views with immense success. This seems similar.
da39a3ee 6y ago
> after receiving HTML from the server, the browser asynchronously requested fragments of HTML to dynamically alter the parts of the page to change based on user interactions or events occuring on the server. It sounds like the quality of the resulting UX would be strongly inversely correlated with the server connection latency. On a bad connection, surely the SPA way is preferable? (i.e. many UI updates would require no AJAX) (I only read the first few paras and didn't really take in what Turbo is)
- AtlasBarfed 6y ago
  Either you are blocked in a bad connection getting the data in json format, or getting the data in HTML format. Seems about the same from a network stability side. It moves "rendering" complexity from device to server.
dang 6y ago
Recent, related, and really big: https://news.ycombinator.com/item?id=25507942 https://news.ycombinator.com/item?id=25507942
stanislavb 6y ago
I've started using Turbo (Hotwire) on the new version of LibHunt (https://www.libhunt.com https://www.libhunt.com), and it is amazing. By adding preloading to all links, most pages load instantaneously. Then, if you need to keep the scroll context, you simply wrap the area in a <turbo-frame> and everything "just works". You can experience that on the homepage by switching the "Weekly"/"Monthly"/"Stars" views of the main table. On the whole - it's a huge productivity booster.
- deleted 6y ago
  [deleted]
- gleb 6y ago
  Your site does not seem to preserve scroll state correctly after clicking back on iPhone. Go to the homepage, scroll down to repos, tap on a repo, tap back, find yourself at the top of the homepage. Which illustrates a general problem with these kind of libraries - you need to put in a lot of effort to make them work as well as normal old old web applications. Is the performance improvement actually there, and is it worth the extra bugs and effort? Not to pick on you either. E.g. GitHub had broken back button behavior with their turbolinks for the longest time.
  - stanislavb 6y ago
    Thanks!
  - Scarbutt 6y ago
    Your site does not seem to preserve scroll state correctly after clicking back on iPhone. Go to the homepage, scroll down to repos, tap on a repo, tap back, find yourself at the top of the homepage. Wouldn't an old old web application exhibit this behavior too?
  - temeritatis 6y ago
    same for me with firefox 85 on desktop
  - bestinterest 6y ago
distalx 6y ago
If nature of the project is simple then you can easily get away by just using StimulusJS. I really liked the simplicity of AngularJS v1.2 & StimulusJS has some of it's simplicity. I dont know why using plain old html has become a frowned upon!! Or at least that what I've felt in my tech bubble.
airstrike 6y ago
Given https://www.hotwire.com/ https://www.hotwire.com/ https://hotwirecommunications.com/ https://hotwirecommunications.com/ https://www.hotwireglobal.com/ https://www.hotwireglobal.com/ I'm going to go ahead and say I don't love the name
nerdywordy 6y ago
I'm totally sold on server rendered, HTML over the wire web apps. What I'm not sold on is websockets for the transport layer. Unless you truly need real-time, I'd argue that something like HTMX (https://htmx.org https://htmx.org) is a much simpler and more reliable route. Simple HTTP calls keep the request stateless and give architectural freedoms that shouldn't be taken for granted.
- marckohlbrugge 6y ago
  Most of Hotwire uses regular HTTP requests. Web sockets are only used for broadcasting real-time updates. (Basically anything you’d traditionally use polling for.)
AtlasBarfed 6y ago
Is there a good, uh, gallery of examples of how much you can do with modern HTML + CSS without javascript with modern standards? This and htmx have me interested in making a web UI for the first time in a while, the max-JS frameworks are a big nope for me.

141 points by grzm 6y ago

Also see https://htmx.org/ https://htmx.org/ for a library that progressively enhances web pages by getting HTML fragments from the server.

donatzsky 6y ago
I was about to say that it sounds a lot like the same idea. Seems like Hotwire leans a bit more towards "SPA" territory.
AtlasBarfed 6y ago
by "progressive enhancement" do you mean loading content in place? I though progressive enhancement was the ability of a website to accomodate no-js and max-js?
- leephillips 6y ago
  Yes, I mean that with htmx it’s easy to make a page that works without JS but that works better with it.

jack_riminton 6y ago

Nice to see it being used in frameworks other than Rails Would be great to see someone to do a rewrite of an SPA using Hotwire, haven't come across anyone making the switch yet

propelol 6y ago
The Laravel (PHP) community is using Livewire, which is like Hotwire. Phoenix (Elixir) also have something called LiveView.
- francislavoie 6y ago
  There are some pretty big key differences though. Livewire is pure ajax (at least for now, may change in the future, a rewrite is in the works), Hotwire is mostly websockets. Livewire does DOM diffing in the frontend, Hotwire does it server side (sorta? didn't dig a ton but that's my understanding). Performance characteristics are pretty wildly different depending on the usecase.
  - sagolikasoppor 6y ago
    With the advent of http3 won't normal ajax requests outperform websockets?
- jack_riminton 6y ago
  The key test for me is whether a Rails/React site makes the leap. Perhaps the tech is just too new and therefore too risky

agd 6y ago

I’ve been using Hotwire (turbo and stimulus) with my latest elixir/Phoenix project and it’s been great. Adding dynamic behaviour to pages is quick and easy using the existing templating system. The stateless nature of it helps avoid bugs. If you really need a very complex / dynamic UX then this isn’t the way to go, but for everything else, I think it’s much simpler than react etc.

yumraj 6y ago
Why not just use Liveview since you're using Phoenix? Could you share your thoughts on the difference between Liveview and Hotwire.
- agd 6y ago
  Liveview is stateful and uses websockets (or long polling) whereas turbo is stateless and uses regular http requests. NB. I haven’t used liveview, however turbo seems much simpler on a conceptual level because of the lack of state. This comes with extra performance cost, but on my current project I’m optimising for dev productivity and simplicity.
  - yumraj 6y ago
    I'd be interested in the "how" if you'd consider creating a blog on using Hotwire with Phoenix. Or, if the source is in a public repo.
    - nickjj 6y ago
      > I'd be interested in the "how" if you'd consider creating a blog on using Hotwire with Phoenix. Technically it doesn't involve adding or changing even 1 line of code on the back-end to make Turbo Drive and Frames work with any tech stack. It works out of the box by following Turbo's docs and using the HTML tags they mention along with bringing in the Turbo JS library. But for Frames you can optionally do what Rails does and add some server side code that says "hey, if this request is coming from a Turbo Frame only send the partial template as a response instead of the whole layout". That logic for Rails is here: https://github.com/hotwired/turbo-rails/blob/main/app/controllers/turbo/frames/frame_request.rb https://github.com/hotwired/turbo-rails/blob/main/app/contro.... It's a nice to have optimization that will reduce your frame's HTML payload size but it still works without doing this. It can be ported to Phoenix or any back-end language by using a plug / middleware to not render the layout if a specific header exists in the request. The ETag stuff could be ported over too if your web framework's web server sets an ETag header. Streams are a bit more tricky to get working in other tech stacks since it may involve Websockets. Hopefully we start to see more examples in the future. But I believe it should be possible to pull off in a production ready way with any back-end language that has a good library or built in support for Websockets at the framework level. That means Flask, Django, Laravel and Phoenix are all good to go in this regard (probably others too but I'm not familiar enough with their ecosystems to say for sure).

jaywalk 6y ago

This is how the old ASP.NET Web Forms UpdatePanel worked.

sputr 6y ago
And Drupal 7. What is old is new again. Laravel has also joined in on this train. But from what I remember ... I hated this technology with a burning passion back when I was still working on D7.
- PaulDavisThe1st 6y ago
  was it actually different between D6 and D7 ?
vyrotek 6y ago
Ha, oh boy. They were both magical and a nightmare when I worked with them years ago. One company I was at was adding more and more dynamic interactions to parts of their asp.net web app. It was a messy time trying to mix jQuery, ajax, update panels, and dealing with viewstate.

rackforms 6y ago

Id like to propose an alternative to the alternative posed in the article: Years ago I was tasked with building dozens of basic web forms. Immediately recognizing the inherit silliness of this task (boring, error prone etc), I built a form creation tool, which all these years later lives on as RackForms. Over the years the feature set grew organically to accommodate an ever growing set of demands. Yes we still build forms, but we also call into web services, display data, and so on. Point being, RackForms and any number of other form builders are the blindingly obvious choice for this task -- it would be down right silly to code forms by hand in this era. And yet that's what we do with the web as a whole. Once again Microsoft seems to have had the right idea in the good old Web Forms days. Instead of coding app's you'd simply drag and drop components and add wiring code to do what you needed. Sure it was never that easy, but it's really hard to see how it couldn't have been better given more time. Fast forward to today and as much as I adore say, VS Code, it's really nothing more than a hyper-powerful text editor. It has none of that tolling to allow for drag and drop development, Id propose that;s the real solution to this issue - Better Tooling.

danpalmer 6y ago
That's great if you're building an internal tool, and in fact we use the Django Admin site for this, there exist low-code/no-code tools like Retool for things like this, it's a great type of solution. Where this breaks down is anything customer facing, like Hey (the product Hotwire was built for), Basecamp, or things like Thread the product I work on. These products aren't forms, or CMSs, and trying to fit them into those sorts of solutions results in a bad or counter-intuitive user experience, even if somewhere deep down these are essentially "CRUD" applications.
- mistersys 6y ago
  I understand your point here, but I think we're a couple of innovations away from dramatically reducing the cost of UI development. The state of the art for web and mobile app development is a delicate stack of tools that require a lot of expertise to wield. However, if you pay attention, most the complexity of modern UI development is accidental, not fundamental. Figma already has "auto-layout", which is essentially flexbox. Imagine a world where your designer just builds your whole app with in Figma with flexbox-like constraints, then they hand off to your developer who just writes a couple of snippets code to wire it up to a database and makes sure the elements are configured to be SEO friendly. IMO developers dramatically underestimate the power of GUI tools to usurp their role because we think in terms of such low level tools.

jonstaab 6y ago

Maybe this would work for simple websites. But for web apps, it's a hard pass for me. For context, I write a web-based POS application, and waiting for a network request on every micro interaction is a no-go. There are lots of other problems with this approach that could be solved, but aren't immediately obvious, such as (similar to React) over-rendering. If someone has their focus in an input within the frame that gets swapped out, they're going to lose their focus. This has implications for accessibility as well as just regular usability.

mattkevan 6y ago
Hey, the webapp Hotwire was extracted from isn’t a webapp?
- cercatrova 6y ago
  People say that Hey is definitely not as responsive as other client-side web apps like those made with React.
- dbbk 6y ago
  It is a web app but not a good one.
Scarbutt 6y ago
For micro interactions Stimulus covers that part, which is a small client-side JS framework.
throwaway08320 6y ago
> web-based POS application That's a hard pass for me!
midrus 6y ago
The focus thing is as easy to fix as just not swapping that component. Certainly you need a different mindset to use this technique. If you try to do it the same way you do SPAs you will find a lot of problems of course

parentheses 6y ago

Old way indeed. I always asked why this went out of fashion. JavaScript thrived under the reign of JSON.

kuon 6y ago

I use phoenix live views with immense success. This seems similar.

da39a3ee 6y ago

> after receiving HTML from the server, the browser asynchronously requested fragments of HTML to dynamically alter the parts of the page to change based on user interactions or events occuring on the server. It sounds like the quality of the resulting UX would be strongly inversely correlated with the server connection latency. On a bad connection, surely the SPA way is preferable? (i.e. many UI updates would require no AJAX) (I only read the first few paras and didn't really take in what Turbo is)

AtlasBarfed 6y ago
Either you are blocked in a bad connection getting the data in json format, or getting the data in HTML format. Seems about the same from a network stability side. It moves "rendering" complexity from device to server.

dang 6y ago

Recent, related, and really big: https://news.ycombinator.com/item?id=25507942 https://news.ycombinator.com/item?id=25507942

stanislavb 6y ago

I've started using Turbo (Hotwire) on the new version of LibHunt (https://www.libhunt.com https://www.libhunt.com), and it is amazing. By adding preloading to all links, most pages load instantaneously. Then, if you need to keep the scroll context, you simply wrap the area in a <turbo-frame> and everything "just works". You can experience that on the homepage by switching the "Weekly"/"Monthly"/"Stars" views of the main table. On the whole - it's a huge productivity booster.

deleted 6y ago
[deleted]
gleb 6y ago
Your site does not seem to preserve scroll state correctly after clicking back on iPhone. Go to the homepage, scroll down to repos, tap on a repo, tap back, find yourself at the top of the homepage. Which illustrates a general problem with these kind of libraries - you need to put in a lot of effort to make them work as well as normal old old web applications. Is the performance improvement actually there, and is it worth the extra bugs and effort? Not to pick on you either. E.g. GitHub had broken back button behavior with their turbolinks for the longest time.
- stanislavb 6y ago
  Thanks!
- Scarbutt 6y ago
  Your site does not seem to preserve scroll state correctly after clicking back on iPhone. Go to the homepage, scroll down to repos, tap on a repo, tap back, find yourself at the top of the homepage. Wouldn't an old old web application exhibit this behavior too?
- temeritatis 6y ago
  same for me with firefox 85 on desktop
- bestinterest 6y ago

distalx 6y ago

If nature of the project is simple then you can easily get away by just using StimulusJS. I really liked the simplicity of AngularJS v1.2 & StimulusJS has some of it's simplicity. I dont know why using plain old html has become a frowned upon!! Or at least that what I've felt in my tech bubble.

airstrike 6y ago

Given https://www.hotwire.com/ https://www.hotwire.com/ https://hotwirecommunications.com/ https://hotwirecommunications.com/ https://www.hotwireglobal.com/ https://www.hotwireglobal.com/ I'm going to go ahead and say I don't love the name

nerdywordy 6y ago

I'm totally sold on server rendered, HTML over the wire web apps. What I'm not sold on is websockets for the transport layer. Unless you truly need real-time, I'd argue that something like HTMX (https://htmx.org https://htmx.org) is a much simpler and more reliable route. Simple HTTP calls keep the request stateless and give architectural freedoms that shouldn't be taken for granted.

marckohlbrugge 6y ago
Most of Hotwire uses regular HTTP requests. Web sockets are only used for broadcasting real-time updates. (Basically anything you’d traditionally use polling for.)

AtlasBarfed 6y ago

Is there a good, uh, gallery of examples of how much you can do with modern HTML + CSS without javascript with modern standards? This and htmx have me interested in making a web UI for the first time in a while, the max-JS frameworks are a big nope for me.