Very cool. It's interesting to see REST become REST again. Also cool to see this come from 37signals. I use Basecamp for a makerspace that I am a part of, and it works quite well for our needs.
It's insane to me we simultaneously have LiveView, LiveWire, and HotWire, all referring to somewhat similar but different frontends... I guess that's really LiveWire's fault for most recently combining those names, otherwise the other two would be distinct.
Phoenix live view is awesome. If you use Phoenix that's the way to go. If you don't want to go to the erlangvm, htmx or hotwire/turbo are the only options I would consider.
This is by far the easiest way to do PWA without getting into the rabbit hole of react/Vue/svelte. I used them, and are awesome, don't misunderstand me.
While comparing with htmx it feels more developer focus than tech focus, but I believe the race between the two will depend on which one is integrated with your backend framework.
The difference is developer behavior that each framework encourages.
While htmx/turbo focus in just couple of helpers and then leave you with the full HTML/JS, in a react ecosystem you end having with 3 party components, and a state management system and build system that will change in 10 months. I don't say it isn't justify and that it have its pros, but it's a rabbit hole in my experience, where you easily end fighting with the framework than focusing on business.
Huh, there hasn't been a significant change to our build system for our React application in the last ~5 years. Same is true for state management (redux). Our users include half of fortune 100 companies.
Really don't understand the argument that React apps must be rewritten all the time. Most of our code is still old class components that still work in the latest version of React.
I can’t speak to React. But with Vue it’s been like this. Vue 3 we’re not deprecating the Options API. And we’re not recommending the Composition API. But if you read into that you can mix and match the two, any pain you experience in the corner cases where they don’t play nice, well, that’s on you. All of your Vue 2 components might work but not really. Also the Vue 3 versions might happen. We’re switching from WebPack to Vite as the build system. (Does Vite actually use WebPack as a component, a question that lingers in the back of my mind) Oh and now the “CJS build” of Vite is deprecated so you’ll need to go from TypeScript 4 to 5. Your IDE may or may not work with the new Vue-specific tslint infra and when you’re done sussing that out now you find code that worked just fine in your previous build is rejected when you do a npm run build (no longer prod btw).
Can you imagine needing to fix a bug requiring a dependency (upon dependency and so on and so on and so on) update on code you haven’t touched for a year and suddenly having a herd of Yak like that need shaving?
Vite uses esbuild for fast dev builds and Rollup for production bundling, not webpack. Once the Rust port of Rollup is ready (called Rolldown) it is likely Vite will migrate both dev and prod bundling to that.
Re: Typescript 4 => 5 that should be a trivial migration. All we needed was to bump our node version IIRC.
And yes I can imagine the sort of bug you describe, because I'm the guy who fixes these sorts of things on my team. Usually just a few hours of head banging once or twice a year. Though the apps I've built on Vite have never required this. Really cannot recommend Vite highly enough for web frontend tooling.
Yes getting the JavaScript community to just STFU when it comes to revising for the sake of revising is an entirely different issue. Some day they will have to maintain something they haven’t touched in 5 years and then they will learn. Well, some of them.
yeah, just a couple of them, like 11 core html attributes and 25 additional html attributes, oh, also some events and also a JavaScript API. So easy to remember compared to 7 scary react hooks.
Maybe if one’s mobile apps are just a WebView. Otherwise you’re maintaining a REST API for the mobile apps and the Hotwire/Livewire request handlers that deliver html fragments.
IMO PWA is a client issue and should be handled client side without introducing server dependencies.
Hotwire is the umbrella term for turbo, stimulus and strada. Turbo has client and server side components that enable easy ways to do partial page refreshes and send html templates (turbo streams) to initiate page updates from the server. That’s all without writing any js (using mostly data attributes and custom html tags, like turbo-frame).
Stimulus comes in as a small framework for the cases where you want to write some JavaScript, in a way that you still control the behavior from html, by attaching controllers to elements explicitly.
These two aspects are similar to htmx:
- send html from the server even for partial page updates
- encode desired js behavior into the html
The main difference is that turbo is designed with a convention over configuration attitude, as many of it’s behaviors are automatic (like intercepting all form submissions and handling them using fetch, preventing a full page reload). When custom js is needed Hotwire defers to letting you write actual js code, htmx has this tailwind style shorthand that allows you to basically write js from the html.
I’d add - stimulusjs lets you write your own htmx-like functionality by providing a convention for triggering and passing data to js via html data attributes.
The stimulus JavaScript controllers (not to be mistaken with the Rails mvc controllers) are reusable and nest-able which makes them very powerful and quite fun to write.
I thought “HTML over the wire” was literally what the web has always been about from the very start.
Even if you redefine “the wire” to “XHR requests” or “Ajax requests” it’s still weird to treat this as a revolutionary thing since the “X” in XHR and Ajax is “XML” which is just a sibling markup language to HTML.
Also, IIRC the original Rails approach to Ajax like 15 years ago or so was sending page partials like this.
It feels like we’re going in circles.
(I’ve also never been impressed with their “turbo links” which just seem like “we think we can do caching better than the browser makers” and thus dubious. Core Rails seems great but I’m always wary of this stuff at the edges with the extra dollop of hype.)
Most dynamic websites do not pass html for updates, the communicate with a backend using json (normally) and the frontend figures out what to do with that data. Hotwire is about removing that JavaScript layer, to have a dynamic app without a heavy UI framework.
We’ve come almost full circle. I remember using this approach back in 2005 or 2006 by intercepting clicks and appending a parameter that just returned rendered html partials that just .innerHTML replace the main contents.
I'm doing something similar with [1] where pagination (scroll down, click on "Show more") is implemented by requesting the next page as an HTML fragment from the server, loading it into an invisible iframe and once it finished loading, appending it to the current page.
We used to let people browse and page through photo galleries by preloading the next columns or rows of photos, then on click URL swapping under the static HTML page grid. The order you replace the URLs gives a visual of a paging motion.
And for infinite pages, a long forgotten technique: for scrolling or continuing content, you could use "multipart" since the 90s, effectively streaming the additional page content to the user as you got more bytes to send them.
Sometime in the early 2000s, before AJAX was a thing, Adam Rifkin showed me a demo from his startup KnowNow that was achieving the then-mind-blowing thing of a web page updating itself without refreshing. Their trick was to keep the HTTP request open and the server to send occasional updates. More HTML. I don't think they could even manipulate the DOM back then, it may literally have been a page that just never closed the <html> tag.
People were definitely experimenting with it before that. Developers were mostly using it to load direct server-side snippets of HTML, dynamically. It took the evolution of SOAP and (especially) JSON/RESTful APIs for it to start seeing mass adoption as the combined technology of "AJAX".
Prototype.js and jQuery had a big hand in the latter.
what made Gmail memorable was cross browser ajax. Prior to, you had things like OWA but it only worked right in IE.
The big inbetween OWA and Gmail, was Oddpost, which was also IE only, and was purchased by Yahoo three months after gmails April Fool announcement, to become Yahoo Mail. In a roundabout way, you can argue gmail was a copy of what was eventually Yahoo Mail.
It was fairly easy to communicate between frames with JavaScript, so before this was widely adopted, I remember the way we used to “fetch” new data was with an iframe that always had a meta refresh tag in it, and the server response would include JavaScript that would call into functions from the main window passing along any data that was needed.
I might be wrong, but I think even early versions of Gmail did something similar.
I did something similar (same time frame) that definitely manipulated the DOM, but I didn’t keep the HTTP connection open, I used hidden Iframes. Clicks got redirected to the iframe, which returned <script> elements that would replace DOM elements (in the parent frame) using their .innerHTML.
AJAX streamlined the process, but there were a lot of hacky ways to get similar dynamic HTML effects. I like the idea of keeping the HTTP connection open, but that seems quite resource intensive… particularly for the early 2000s.
This technique is called COMET. The very first web chat that I used way back in 1996 was COMET based, tho the term hadn’t been coined yet. It was the chat room on Sierra Online’s website. The app had two frames, one for the input field and another for the room feed, which was a long running connection. No JavaScript, just a never ending HTML page. I suspect the backend was written in Perl, as it was a cgi script.
Basically the server sends a multipart content type header, never sends a content size, and simply doesn’t terminate the connection, so the browser just waits patiently for more parts and renders them as they come. My team experimented with it a bit back in 2000 for doing what would eventually be termed JSONP Streaming. It was really cool tech, but we didn’t have a practical application for it.
Rather than come full circle, I think it's more accurate to say that the different web UI paradigms are expanding their scope. Server rendered frameworks are making it easier to do client interactivity, and React is making it easier to do server rendering (via RSCs).
For highly interactive web apps you would still benefit from a SPA since that's what they're designed for.
Yeah I was really into Wicket in late 2000s and while I personally liked it and hated JS, managing UI state and templates on the server was always kind of a foot gun for performance and scale in a team environment. Really hard for me to be excited about this approach again, especially after all the improvements to web, JS, and TypeScript in meantime.
I feel like everytime Hotwire and similar libraries get posted we hear this, but the reality is simple CRUD w/ AJAX never went away… Sure theres loads of SPA projects out there but that doesnt account for every single website ever.
I haven’t worked with web apps that need highly interactive frontends, but for our e-commerce stores and internal rails apps turbo and stimulus have really lowered the bar on how much new developers must learn to build a nice to use website.
If you keep your stack simple, it's never been THAT hard. For example, with one Django project, I spun up whole office-facing tools using the tried and true KnockoutJS - which is kind of in the spirit of HTMX (and so is the still nascent Arrow.JS).
Most of the complexity, especially the UI part, has been self-inflicted. The old ways are very much not outdated, and are actually coming back.
There is a whole young generation of devs who came into the job at the stupidest possible time, when the industry convinced them that every web application has to be an overcomplicated, insufferable mess.
It does once you dig a little into the documentation, you need to click past the first two pages of self-flattering and you’ll see that it’s mostly just going back to writing old world JavaScript.
Yeah your comment ironically points out the issue (at least I have) with this - you are maintaining state on a server, and so messing with a UI isn't just dealing with local UI state.
I'm no JavaScript fanboy, but I'm also not bent on avoiding it at all costs shrug.
I passed the video to GPT4o through Kagi and then asked "What is Hotwire and how does it work?" and got a satisfactory write-up. I can email it to you if you'd like (I think posting LLM generated text here is frowned upon).
It's sort of in between. I wrote a browser extension (in Arc btw!) that has Emacs-style keyboard shortcuts that let me do things quickly. I look via HN search for related past submissions, open the relevant threads en masse in browser tabs, and build a list of IDs of the ones that are interesting. Then the browser extension sends the list of IDs to the server and gets back formatted text like you see in those lists ("title - link - mm yyyy (n comments)).
It created a bunch of heated conversation (DHH saying the original video was throttled, other people saying Hotwire is too reliant on the network if a modal needs time to load, people defending Rails/Hotwire, people disagreeing with its approach, etc...).
Basically, it's been a big topic on Twitter the past week.
I'm checking out Hey and am finding it super zippy on my 600MBit connection, and still pretty usable on "slow 3G". What I'm not impressed by is DHH's snippy response, but having read DHH's outbursts before, neither am I surprised.
I last looked at Hey about a year ago and it seemed pretty snappy even from the the wrong side of the Pacific. The page architecture impressed me specifically ... things like, applying progressive enhancement to a details/summary/anchor element trifecta for a contextual menu overlay, and if you disabled Javascript or assets didn't load or whatever, it gracefully fell back to loading the menu content in a simple layout. There are a bunch of other well-considered uses of the Web APIs in there. I recall that practically all their client code was unobfuscated and source mapped, too, if you wanna take a look. I'm no fan of DHH and have no interest in boning up on his drama of the week, but it seemed to me that 37signals got it right this time.
It was. Author said as much: "This is slow on purpose asa demonstration. This isn't meant to show the experience someone in SF on a fancy MacBook with Gigabit internet has. No matter which tech, they're good. It's about the person on a cheap laptop on slow mobile internet." https://x.com/noahflk/status/1795855075526471915
People also pointed out that the Google Calendar SPA is much slower.
And not like "SF Gigabit internet" and "highly throttled 3G" are the only two options...
The original post was highly misleading. Basically just a lie.
I think that has more to do with the fact that he is paid for by Vercel than anything. He's mostly been saying negative things about Rails despite not understanding how it works.
Hi, I work at Vercel. We have sponsored some of the videos on his YouTube channel, but this is not one. And FWIW, I don't agree with the approach here.
I agree that that calendar doesn't seem great, and the problems do exist. However, adding tons of latency while saying you're not doing so in order to make fun of someone's work is either malicious or extreme lack of competence.
In the video he sets the chrome throttle option to slow 3G, and that adds large restrictions on bandwidth, and a ton of latency. He states that he is not doing so, and that adding latency can't be done in the browser. That is literally what the option does.
If you add seconds of latency then requests will take seconds, who would imagine...
A. The complaint about how every keypress goes to the server says literally nothing about HTML over the wire. It’s obviously how Hey chose to do things (or it was a bug), but Theo should be experienced enough to know that most approaches don’t need to be like this. Attributing a sloppy implementation by Hey onto a video about Rails as a whole is inflammatory.
B. And if he isn’t, and doesn’t realize that HTML over the wire doesn’t mean you can’t have any JavaScript, he should stop talking about what he does not understand.
C. This is personal taste, but a man with his hair style shows he can’t recognize good taste if it hit him in the face.
I don’t think you’re intimately familiar with the concept of maintaining state server side vs client side. The field is reactive, therefore under Hotwire/Livewire/etx state changes (aka ‘typing on keyboard’) require a round trip to the server to get the state updated server side and to get the re-rendered component to update the client. Could he perhaps have chosen a different reactivity model, perhaps, or maybe not. In any event this is a clear illustration of client-side vs. server-side reactivity.
This is why we abandoned DHTML 2 decades ago, invested in jQuery to encapsulate variations in JavaScript across browsers and worked hard on standardizing JS so you could write code once and have it work across vendors.
Or, as many approaches i.e. Livewire use, you can just use some JavaScript for basic interactivity, and send a non-trivial amount of state to the server in a batch rather than a request for each item.
This is how I’ve implemented my website. I am quite aware of how this is done, I suggest you look further into it.
It’s entertaining and he points to some bugs like race conditions that shouldn’t be there, but I’m not sure if it’s specific to Hoywire. Also his statement that DHH/Rails claim Hotwire is the only way, or that you cannot also use React or plain JS is just silly and disingenuous.
Nah, creating duplicate calendar entries because you did not receive visual feedback before getting frustrated and making another one sucks. Maybe watch the video instead reading the bullshit the narrative drivers are feeding you.
Why does everything Theo touch go up in a flaming shitshow? DHH can be an inflammatory prick himself, but he just about balances it with competence.
I hate how there are JS influencers now. And I hate how they repeatedly cause drama for clicks. There will be a fresh idiotic topic bubbling up every few weeks. It will be semicolons soon, I am sure of it. I hate it.
wait, is that a directory of dynamically loadable web content thats interactive i can surf? please i do not know the old ways, i only know they were forgotten :(
I used to be really negative on Hotwire/Livewire but I now realize it’s a horses-for-courses kind of thing. Sending partials over the wire is a hypermedia thing, and I just don’t write hypermedia apps nowadays. It was htmx and re-reading RTF’s REST paper that got me to this place: I still don’t think hypermedia is inherently the superior architecture, but it is a legit peer among several, and it’s nice to see it keep evolving, even if slowly.
I’ve been using Hotwire for a greenfield project for the last year. The hotwire framework they’ve created is pretty nice but I miss React and will probably choose it for my next project.
Not just because it’s decoupled from the backend api. The React/Vue ecosystems have a lot more useful open source components, and you can build faster, more cache friendly front ends, among other benefits.
I agree React is more complex, but as with many things if you are gonna need it then it’s great to have started with it.
I appreciate there are projects which will hit no limits with the Hotwire/stimulus/turbo mix. I’ve worked on them before and would choose Hotwire when appropriate (eg for government services Hotwire is perfect).
The SSR vs CSR debate is quite tired and played out at this point, and doesn’t lend itself to thoughtful threads… While hotwire does make it easier to do SSR with progressive enhancement, for some projects it’s easier for me to just build a single “enhanced” experience with React (for performance, ecosystem, and IME UX).
For those looking for something similar in PHP/Laravel, I strongly recommend checking out Livewire:
https://laravel-livewire.com/
I still use React for more complex projects but it’s always a breath of fresh air to be able to write everything in Blade/PHP while keeping the reactive UI elements.
Edit: Although I have not used, I remember seeing this package which lets you render React/Vue components within Livewire when you need it: https://minglejs.unitedbycode.com/ an interesting escape hatch for when you want to pull in existing packages
Turbo’s morphing is insane. With 2 lines of code: 1 in the model and 1 in the view, you can make any previously static page an instant updating multiplayer experience.
I've used Hotwire for a few sites. I much prefer it to HTMX since it's significantly easier to implement.
My No-React tech stack is Alpine.js, Hotwire, EJS, and Express. Works very nicely for simpler sites.
Though for the majority of the sites I make, React wins almost every time since it's way easier to use as a templating and interactivity engine. And Tailwind works a lot better with React.
A way less marketed version of this is htmx [1]. It is a single javascript file that enables this functionality. I mostly see people using it with Go backends but I think it is flexible. I have been meaning to try it out for a year or so.
At least as far as Hacker News is concerned, I'd call htmx way more marketed. It has hundreds of HN submissions in the past year alone [0] including one that broke 1000 points. Compare that to Hotwire which is sitting at less than 30 submissions in the past year [1], the most popular of which is this one.
I guess it is that HTMX just feels like one guy's side project. Granted he is great at posting. TFA feels like 37 Signals took the same idea and is trying really hard to sell it.
But not before Intercooler.js (the predecessor to HTMX) or Turbolinks (the predecessor to Hotwire). This is an idea that has been developing for as long as the web itself, I don't think it's important to assign inventorship of the concept as a whole to any one project. They've all been learning from each other and innovating in their own ways.
It's not just that the idea has been developed over and over, but it is constantly hyped as a return to the golden past, and yet never gets the love that new client side spa messes end up attracting.
htmx was a mashup of $.load(), pjax and angular 1 style attributes (very different conceptual model but I saw how angular used custom attributes and thought that looked better than the JavaScript api I had cooked up)
later on I figured out that what I was doing was generalizing hypermedia controls, but that took me years to figure out.
His mastery of millennial style memes is so rich. You can tell he just believes he is right and everyone else is dumb but he’s just “in it for the lols”.
I don't know _htmx personally, but I think he's more than willing to poke fun at those heavily invested in technology that is overkill for their needs. He most definitely is poking fun and laughing at the current mindset of javascript culture.
A good thread for understanding the different ways people think of it. I always go with @speg's interpretation, because the pejorative meaning just isn't used that frequently on HN:
> I tend to rethink of it as "the featured article".
Turbo is more or less a continuation of Turbolinks, which has been around for ages. The Turbo repo goes back to 2015 (htmx starts in 2020), but Turbolinks is many years older. Of course there have been other "htmx-like" frameworks before; who even knows who or what was first at this point?
I don't think "feels like 37 Signals took the same idea and is trying really hard to sell it" is very fair (I've never seen them try to "sell it" at all, much less "very hard"). Regardless, you're allowed to "steal" ideas.
I'm curious as to what people think is the appropriate amount of time to wait before reposting the same story.
I know people complain about any and all reposts in the first place (https://xkcd.com/1053), but obviously there should be a priority on teaching people things they didn't already know instead of punishing people that never read old news.
You may have noted this from my links, but just in case—when I say the htmx has a lot of submissions I'm not referring to duplicate submissions, I'm referring to dozens of different submissions of different projects using or adjacent to htmx.
Re: the meta question, dang's policy that he repeats a lot is that reposts are fine every year or so [0]. Individuals may obviously disagree, but that's the rule that's actually enforced.
Personally I also find value in those posts even if knew about those technologies before. I often find interesting and up-to-date information or opinions in the comments.
In fairness to the commenter, I don’t know either of the projects but htmx’s _page_ is way less marketing focused that hotwire’s page. The hotwire page’s marketing is crazy: ‘turbo’, ‘stimulus’, ‘strada’…
Crazy but yet commendable.
Yes, they are. And the product names are an artefact of the marketing effort.
By ‘crazy’ I mean ‘crazy good / near over the top’ effort marketing.
Agree they both look good products. But put the websites side by side and ask what page has had more marketing effort put into it and I’ll think you’ll see the commenter point.
I researched it yesterday and there are differences, htmx is a lot lower level, hotwire cover only some narrow usecases but from a high level, and finally unpoly is highlevel with a lot of usecases coverage
Can I come live in whatever bizarro world you're in? I've never heard of Hotwire before but I'm up to my ears with htmx this and htmx that. It's impossible to spend a minute on Youtube without seeing programmer influencers with their moronic thumbnails featuring their face twerks next to htmx.
It’s pretty marketed though. That’s why it has become more popular than Unpoly, which has been around for longer, was not rewritten 10 times, and has a lot more useful features.
178 comments
[ 3.0 ms ] story [ 307 ms ] threadhttps://phoenixframework.org/blog/phoenix-liveview-1.0-relea...
While comparing with htmx it feels more developer focus than tech focus, but I believe the race between the two will depend on which one is integrated with your backend framework.
The difference is developer behavior that each framework encourages.
While htmx/turbo focus in just couple of helpers and then leave you with the full HTML/JS, in a react ecosystem you end having with 3 party components, and a state management system and build system that will change in 10 months. I don't say it isn't justify and that it have its pros, but it's a rabbit hole in my experience, where you easily end fighting with the framework than focusing on business.
Really don't understand the argument that React apps must be rewritten all the time. Most of our code is still old class components that still work in the latest version of React.
Can you imagine needing to fix a bug requiring a dependency (upon dependency and so on and so on and so on) update on code you haven’t touched for a year and suddenly having a herd of Yak like that need shaving?
Re: Typescript 4 => 5 that should be a trivial migration. All we needed was to bump our node version IIRC.
And yes I can imagine the sort of bug you describe, because I'm the guy who fixes these sorts of things on my team. Usually just a few hours of head banging once or twice a year. Though the apps I've built on Vite have never required this. Really cannot recommend Vite highly enough for web frontend tooling.
IMO PWA is a client issue and should be handled client side without introducing server dependencies.
However, I will argue that 80% of PWA exist to have proper push notifications, or faster development than native.
I had the same question, then watched the video to get the answer.
You can Google Hotwire with Django, or Laravel, or many others (https://hotwire.io/frameworks).
The linked page shows only integrating Hotwire with Ruby on Rails, giving me my original impression.
Framework agnostic but Ruby-only it seems.
If your backend can send templates down the websocket, you can use Hotwire.
Rails has a lot of affordances for Hotwire and is the back end framework for which Hotwire was originally written.
The stimulus JavaScript controllers (not to be mistaken with the Rails mvc controllers) are reusable and nest-able which makes them very powerful and quite fun to write.
Even if you redefine “the wire” to “XHR requests” or “Ajax requests” it’s still weird to treat this as a revolutionary thing since the “X” in XHR and Ajax is “XML” which is just a sibling markup language to HTML.
Also, IIRC the original Rails approach to Ajax like 15 years ago or so was sending page partials like this.
It feels like we’re going in circles.
(I’ve also never been impressed with their “turbo links” which just seem like “we think we can do caching better than the browser makers” and thus dubious. Core Rails seems great but I’m always wary of this stuff at the edges with the extra dollop of hype.)
[1] https://animasci.com/
And for infinite pages, a long forgotten technique: for scrolling or continuing content, you could use "multipart" since the 90s, effectively streaming the additional page content to the user as you got more bytes to send them.
Prototype.js and jQuery had a big hand in the latter.
The big inbetween OWA and Gmail, was Oddpost, which was also IE only, and was purchased by Yahoo three months after gmails April Fool announcement, to become Yahoo Mail. In a roundabout way, you can argue gmail was a copy of what was eventually Yahoo Mail.
I might be wrong, but I think even early versions of Gmail did something similar.
Started in 2000 in Exchange/Outlook web and took a year or two to become prevalent in the browsers and other places.
https://medium.com/@mohamedtayee3/make-an-http-request-in-ja...
AJAX streamlined the process, but there were a lot of hacky ways to get similar dynamic HTML effects. I like the idea of keeping the HTTP connection open, but that seems quite resource intensive… particularly for the early 2000s.
I bet ASP had something similar too around the same time
Basically the server sends a multipart content type header, never sends a content size, and simply doesn’t terminate the connection, so the browser just waits patiently for more parts and renders them as they come. My team experimented with it a bit back in 2000 for doing what would eventually be termed JSONP Streaming. It was really cool tech, but we didn’t have a practical application for it.
For highly interactive web apps you would still benefit from a SPA since that's what they're designed for.
Most of the complexity, especially the UI part, has been self-inflicted. The old ways are very much not outdated, and are actually coming back.
There is a whole young generation of devs who came into the job at the stupidest possible time, when the industry convinced them that every web application has to be an overcomplicated, insufferable mess.
Surprised something like this wouldn't have any example code or demos to look at.
It’s really very disappointing.
I'm no JavaScript fanboy, but I'm also not bent on avoiding it at all costs shrug.
- [1] https://news.ycombinator.com/item?id=25507942
Hotwire: HTML over the Wire - https://news.ycombinator.com/item?id=25507942 - Dec 2020 (545 comments)
Also related:
Why Hotwire Could be the Future of Front-end Dev - https://news.ycombinator.com/item?id=26195969 - Feb 2021 (6 comments)
Hotwire: A new old way to build web apps - https://news.ycombinator.com/item?id=25942864 - Jan 2021 (56 comments)
(This comes up a lot! https://news.ycombinator.com/item?id=35668525)
Last week, someone posted online how Hey (created by DHH, who also created Hotwire and Rails) is slow when opening a modal: https://x.com/noahflk/status/1795758603577545035
It created a bunch of heated conversation (DHH saying the original video was throttled, other people saying Hotwire is too reliant on the network if a modal needs time to load, people defending Rails/Hotwire, people disagreeing with its approach, etc...).
Basically, it's been a big topic on Twitter the past week.
It was. Author said as much: "This is slow on purpose asa demonstration. This isn't meant to show the experience someone in SF on a fancy MacBook with Gigabit internet has. No matter which tech, they're good. It's about the person on a cheap laptop on slow mobile internet." https://x.com/noahflk/status/1795855075526471915
People also pointed out that the Google Calendar SPA is much slower.
And not like "SF Gigabit internet" and "highly throttled 3G" are the only two options...
The original post was highly misleading. Basically just a lie.
https://m.youtube.com/watch?v=5jIwILYjXrU
Idk why he does videos like this because it ends up reflecting poorly on Vercel or other companies he's associated with.
In the video he sets the chrome throttle option to slow 3G, and that adds large restrictions on bandwidth, and a ton of latency. He states that he is not doing so, and that adding latency can't be done in the browser. That is literally what the option does.
If you add seconds of latency then requests will take seconds, who would imagine...
A. The complaint about how every keypress goes to the server says literally nothing about HTML over the wire. It’s obviously how Hey chose to do things (or it was a bug), but Theo should be experienced enough to know that most approaches don’t need to be like this. Attributing a sloppy implementation by Hey onto a video about Rails as a whole is inflammatory.
B. And if he isn’t, and doesn’t realize that HTML over the wire doesn’t mean you can’t have any JavaScript, he should stop talking about what he does not understand.
C. This is personal taste, but a man with his hair style shows he can’t recognize good taste if it hit him in the face.
This is why we abandoned DHTML 2 decades ago, invested in jQuery to encapsulate variations in JavaScript across browsers and worked hard on standardizing JS so you could write code once and have it work across vendors.
This is how I’ve implemented my website. I am quite aware of how this is done, I suggest you look further into it.
I hate how there are JS influencers now. And I hate how they repeatedly cause drama for clicks. There will be a fresh idiotic topic bubbling up every few weeks. It will be semicolons soon, I am sure of it. I hate it.
Not just because it’s decoupled from the backend api. The React/Vue ecosystems have a lot more useful open source components, and you can build faster, more cache friendly front ends, among other benefits.
I agree React is more complex, but as with many things if you are gonna need it then it’s great to have started with it.
I also use Hotwire/Stimulus and haven't run into any issues yet. Happy to share links with you on anything I know about.
Not sure what this is in response to, sorry.
I appreciate there are projects which will hit no limits with the Hotwire/stimulus/turbo mix. I’ve worked on them before and would choose Hotwire when appropriate (eg for government services Hotwire is perfect).
The SSR vs CSR debate is quite tired and played out at this point, and doesn’t lend itself to thoughtful threads… While hotwire does make it easier to do SSR with progressive enhancement, for some projects it’s easier for me to just build a single “enhanced” experience with React (for performance, ecosystem, and IME UX).
I still use React for more complex projects but it’s always a breath of fresh air to be able to write everything in Blade/PHP while keeping the reactive UI elements.
Edit: Although I have not used, I remember seeing this package which lets you render React/Vue components within Livewire when you need it: https://minglejs.unitedbycode.com/ an interesting escape hatch for when you want to pull in existing packages
My No-React tech stack is Alpine.js, Hotwire, EJS, and Express. Works very nicely for simpler sites.
Though for the majority of the sites I make, React wins almost every time since it's way easier to use as a templating and interactivity engine. And Tailwind works a lot better with React.
1. https://htmx.org/
[0] https://hn.algolia.com/?dateRange=pastYear&prefix=true&query...
[1] https://hn.algolia.com/?dateRange=pastYear&prefix=true&query...
Principles of Rich Web Applications (rauchg.com) Nov 4, 2014 https://news.ycombinator.com/item?id=8559519
https://www.infoworld.com/article/2612250/application-develo...
https://shiggyenterprises.wordpress.com/2013/03/11/picking-a...
https://blog.emberjs.com/inside-fastboot-the-road-to-server-...
It's not just that the idea has been developed over and over, but it is constantly hyped as a return to the golden past, and yet never gets the love that new client side spa messes end up attracting.
later on I figured out that what I was doing was generalizing hypermedia controls, but that took me years to figure out.
I do enjoy the lols I will admit that, hopefully as much at my own expense as anyone
Not pejorative btw - just a phrase to refer to the current article.
A good thread for understanding the different ways people think of it. I always go with @speg's interpretation, because the pejorative meaning just isn't used that frequently on HN:
> I tend to rethink of it as "the featured article".
I don't think "feels like 37 Signals took the same idea and is trying really hard to sell it" is very fair (I've never seen them try to "sell it" at all, much less "very hard"). Regardless, you're allowed to "steal" ideas.
I know people complain about any and all reposts in the first place (https://xkcd.com/1053), but obviously there should be a priority on teaching people things they didn't already know instead of punishing people that never read old news.
Re: the meta question, dang's policy that he repeats a lot is that reposts are fine every year or so [0]. Individuals may obviously disagree, but that's the rule that's actually enforced.
[0] https://news.ycombinator.com/item?id=40523838
Hotwire and htmx both look like good products to me.
Agree they both look good products. But put the websites side by side and ask what page has had more marketing effort put into it and I’ll think you’ll see the commenter point.
Can I come live in whatever bizarro world you're in? I've never heard of Hotwire before but I'm up to my ears with htmx this and htmx that. It's impossible to spend a minute on Youtube without seeing programmer influencers with their moronic thumbnails featuring their face twerks next to htmx.
Context for why this might be coming up now:
https://news.ycombinator.com/item?id=40555541