React is Dead, Long live Reactive Rails(medium.com)
medium.com
React is Dead, Long live Reactive Rails
https://medium.com/@obie/react-is-dead-long-live-reactive-rails-long-live-stimulusreflex-and-viewcomponent-cd061e2b0fe2
50 comments
My take: the fundamental problem is that HTML was never completed as a hypertext.
- Why should only anchors and forms be able to make HTTP requests?
- Why should only click and submit events trigger them?
- Why should only GETs and sometimes POSTs be available?
- Why should you have to replace the entire screen every time?
htmx tries to complete HTML as a hypertext, removing each of these limitations, so you can write advanced interfaces using plain ol' markup:
https://htmx.org
- Why should only anchors and forms be able to make HTTP requests?
- Why should only click and submit events trigger them?
- Why should only GETs and sometimes POSTs be available?
- Why should you have to replace the entire screen every time?
htmx tries to complete HTML as a hypertext, removing each of these limitations, so you can write advanced interfaces using plain ol' markup:
https://htmx.org
I don't see any reasonable way for htmx to do error handling without writing your own JS, it has an example of 'ic-post-errors-to', but that only seems to be for error tracking and requires writing a whole other dialect of js (hyperscript).
Examples like https://htmx.org/events/#htmx:validation:validate also seem weird. Basically it replaces JS with it's own scripting dialect that is written inline in a attribute and that dialect does not even have syntax highlighting on their own site.
Is it actually more simple than writing the equivalent html+js when you add on all the real-world requirements?
Examples like https://htmx.org/events/#htmx:validation:validate also seem weird. Basically it replaces JS with it's own scripting dialect that is written inline in a attribute and that dialect does not even have syntax highlighting on their own site.
Is it actually more simple than writing the equivalent html+js when you add on all the real-world requirements?
Validation, as with the normal html request/response cycle, is done on the server side. Here is an example:
https://htmx.org/examples/inline-validation/
It's the normal web 1.0 thing: validate your data server side and render an error message/flagged input which is returned as html.
The latest dev version plugs into the HTML5 validation API so that client side validations are respected, but that doesn't require any scripting.
Htmx does fire a lot of events that you can hook into if you wish, and hyperscript is an experimental mechanism for doing so, but neither are the focus or a requirement for using htmx.
From experience, yes, it is much simpler than the javascript-framework based approach, at least for many use cases.
https://htmx.org/examples/inline-validation/
It's the normal web 1.0 thing: validate your data server side and render an error message/flagged input which is returned as html.
The latest dev version plugs into the HTML5 validation API so that client side validations are respected, but that doesn't require any scripting.
Htmx does fire a lot of events that you can hook into if you wish, and hyperscript is an experimental mechanism for doing so, but neither are the focus or a requirement for using htmx.
From experience, yes, it is much simpler than the javascript-framework based approach, at least for many use cases.
So how do you propose to do error handling? I mean proper error handling where you can show the user a meaningful message and that can handle normal stuff like timeouts, 500's 400's and so on.
Ah, you mean system errors, not application-level errors. App errors are handled the normal way.
I usually try to avoid 500 and 400 errors in my applications, but for something like a network error, that obviously has to be handled client-side since, well, the server isn't available.
So you can write a three liner to handle it:
I usually try to avoid 500 and 400 errors in my applications, but for something like a network error, that obviously has to be handled client-side since, well, the server isn't available.
So you can write a three liner to handle it:
htmx.on("htmx:onLoadError", function(evt) {
htmx.find("#error-div").innerHTML = "A network error occured..."; // or whatever
}
This looks super interesting, thanks for posting.
Can't help but wonder how much cooler it would be if only the attributes were not hx- namespaced. Is that not done for some technical reason?
Can't help but wonder how much cooler it would be if only the attributes were not hx- namespaced. Is that not done for some technical reason?
I just followed other frameworks on it, feels a little presumptuous and dangerous to use unqualified top level attributes.
I could make it pluggable so you could do away with the hx- if you wanted to. Most people want to go the other way and use data- prefixes (which is supported out of the box)
I could make it pluggable so you could do away with the hx- if you wanted to. Most people want to go the other way and use data- prefixes (which is supported out of the box)
I always am irritated when people insist on disabling javascript. The fundamental problem is that HTML on its own is flawed and unusable. Even the most basic features that users expect will require a few lines of javascript.
Half of the webapps I make are just digitalizing existing paper forms. There is barely any javascript but the javascript that is there is absolutely essential. If the noscript warriors actually thought about ways of making plain HTML good enough that a JS free site was possible then I'd have sympathy for them. As it is right now they are asking the impossible. They would even complain about htmx even though it is exactly what they want.
Half of the webapps I make are just digitalizing existing paper forms. There is barely any javascript but the javascript that is there is absolutely essential. If the noscript warriors actually thought about ways of making plain HTML good enough that a JS free site was possible then I'd have sympathy for them. As it is right now they are asking the impossible. They would even complain about htmx even though it is exactly what they want.
I love it
I can’t read your article as Medium says I reached my quota. I manage an analytics team and I am pretty annoyed with most dashboard tool out there (Tableau, PowerBI, etc), so I have been extending our internal python grizly library with server side components built as python classes and rendered “reactively” using htmx. The idea being that my team could easily build scalable server rendered apps from Jupyter notebooks. Most analytics requires server anyway to for instance do Excel extracts or in memory data transformations. It’s been an amazing discovery of simple but powerful patterns and it’s working. My question is why is this not more popular? Maybe I am doing something wrong?
> My question is why is this not more popular?
Resume driven development is a real problem in our industry.
Resume driven development is a real problem in our industry.
I was thinking 2 things could be better done with react: reactivity and server load due to more client requests to manage. Not sure what else. Server load is pretty high on Tableau too so not sure that’s a real problem.
You can open any Medium article in an incognito window. It's not a very secure paywall.
That seems like a funky workaround for a problem that shouldn't exist. I have some stuff on Medium, but when I find time to port it over to Bridgetown or similar, I will.
Why shouldn't I take some of the money that Medium has raised from their VCs?
And blocking cookies on Medium works.
>My question is why is this not more popular?
I have no idea.
> Maybe I am doing something wrong?
You are doing nothing wrong.
I have no idea.
> Maybe I am doing something wrong?
You are doing nothing wrong.
I'm surprised that someone with your technical sophistication is hosting their blog on a platform like Medium. Yuck!
Wow, cool technology! But, I don't have any confidence that this gets adoption. And it has some major holes for when you want to add some rich user interface elements to your pages. And you lose out on a React ecosystem that's really hitting it's stride.
I got sucked into RJS, Turbolinks, Sprockets, and several other "cool" frontend technologies coming out of the Rails world that made my life miserable until I finally dropped them. Developer beware
I got sucked into RJS, Turbolinks, Sprockets, and several other "cool" frontend technologies coming out of the Rails world that made my life miserable until I finally dropped them. Developer beware
The technique has been validated elsewhere: LiveView in Phoenix, Blazor in dotnet, LiveWire in Laravel, etc.
It's also not mutually exclusive. You can totally leverage React components when Stimulus Reflex isn't enough.
It's also not mutually exclusive. You can totally leverage React components when Stimulus Reflex isn't enough.
> React is clearly not dead.
> there is absolutely no technical need for Rails developers to use React anymore
The article is about React on top of Rails, not React in general. Leaving that out of the title makes this just clickbait.
> there is absolutely no technical need for Rails developers to use React anymore
The article is about React on top of Rails, not React in general. Leaving that out of the title makes this just clickbait.
Funny because you could probably say Ruby On Rails is dead for React developers
There are definitely more server-side options than front-end options. The approach here isn't necessarily just about React - the point is using web sockets and rendering HTML directly (sped up via DOM diffing) will replace heavy Javascript logic (whether React, Vue, etc) for most use cases.
I really doubt it. Loading HTML fragments was the norm with AJAX. Part of the DHTML days. It makes more sense to have UI logic in the client.
If your logic is complex enough, sure. (I mispoke - it won't replace "heavy" logic, but most UI needs aren't heavy) But for many the logic really isn't that complex; they just want reactivity. There's a frustration with needing to roll out a complex build process, JWTs, state management, etc, just to speed things up a bit. This is an alternative to that, in a way that really doesn't differ much from React in terms of speed or reactivity.
For those truly complex UI logic cases, React components are still a tool you can use. The approaches aren't mutually exclusive.
For those truly complex UI logic cases, React components are still a tool you can use. The approaches aren't mutually exclusive.
I used to use MVC frameworks a lot. The problem I ran into was as soon as you have one thing on the page that can't survive the reload, you can never reload again. Cue 3k lines of JQuery and regret.
I think of it this way, would you stream pre-rendered markup to a native iOS, Android, or Windows app? The thought of it is crazy, who would ever do that.
I think most people agree that the web is getting closer to native all the time. I think we're reaching the pivot where you're better off using React and co for any kind of interactivity. Page reloads are already used in media to portray slow/old websites. I don't see that getting better
I think of it this way, would you stream pre-rendered markup to a native iOS, Android, or Windows app? The thought of it is crazy, who would ever do that.
I think most people agree that the web is getting closer to native all the time. I think we're reaching the pivot where you're better off using React and co for any kind of interactivity. Page reloads are already used in media to portray slow/old websites. I don't see that getting better
Agreed. The rise in mobile usage has made server-side rendering redundant. Single page web apps are really a by-product of this, not the main cause. If you're serving your content to iOS, Android and the browser rendering needs to be done on the client.
Having never used ruby outside of some rough puppet scripts but using both react and react-native daily for years - this was an interesting read. Always great to see someone excited about the future of technology - especially if they've been a part of it for so many years.
How does it handle connectivity problems in the SPA? Not that react does this out of the box - just wondering if there is some advantage to how the Reflexes do it.
Also the names of ruby libs are hilarious. CableReady, ActionCable, TurboLinks, and StimulusReflex.
How does it handle connectivity problems in the SPA? Not that react does this out of the box - just wondering if there is some advantage to how the Reflexes do it.
Also the names of ruby libs are hilarious. CableReady, ActionCable, TurboLinks, and StimulusReflex.
Actually those are some of the more sensible Ruby libraries names - you have a pretty good chance of running `gem install {some-random-noun}` and it being a valid command. An XML parser named after a Japanese saw? Why not. A testing library named after a giant rodent? Even better.
Not that "redux" or "thunk" much better.
Not that "redux" or "thunk" much better.
Last time I used redux it was basically just "reduce" for react. If that name doesn't make sense then no name will.
Redux means "brought back", not "reduce".
Good summary.
One of the issues I find with Rails is that the 'old-way' of views, partials and a sprinkling of React is INSANELY productive. I've been trying hard to justify getting into Stimulus properly.
DHH is on a four-month sabbatical at the moment and my hope is that he's working on open-sourcing the framework behind hey.com, which Basecamp are calling 'new magic'[0]
There's something coming around object-oriented view components and client-size JS. I'm just not quite sure the perfect recipe has been found yet.
https://twitter.com/dhh/status/1275901955995385856?lang=en
One of the issues I find with Rails is that the 'old-way' of views, partials and a sprinkling of React is INSANELY productive. I've been trying hard to justify getting into Stimulus properly.
DHH is on a four-month sabbatical at the moment and my hope is that he's working on open-sourcing the framework behind hey.com, which Basecamp are calling 'new magic'[0]
There's something coming around object-oriented view components and client-size JS. I'm just not quite sure the perfect recipe has been found yet.
https://twitter.com/dhh/status/1275901955995385856?lang=en
Keep in mind that Stimulus Reflex leverages Stimulus, but you don't necessary have to get into Stimulus to get most of the advantages.
I suspect that the framework DHH comes up with will be very similar to Stimulus Reflex, or they may even roll that project into Rails/Stimulus.
I suspect that the framework DHH comes up with will be very similar to Stimulus Reflex, or they may even roll that project into Rails/Stimulus.
Looks similar to .NET's Blazor running in server render mode, which is awesome and super productive.
off topic, but is doing cocaine something you can officially brag about now in the US ??
Having done cocaine in the past, sure, sure, why not?
Is this a joke? Are you just trolling? This article is just hype.
Certainly the headline is clickbait-y, but the techniques described in the article are quite real.
There are techniques? I gave up after the fourth or fifth paragraph of hype. I suppose there are enough Javascript haters here to take the bait, but I've learned that when someone has to tell you how great something is a dozen times before they tell you what it is, it probably isn't.
I don't think the target is Javascript haters, as much as the developers who feel like Webpack'ing all the things is a bit much for most apps. The technique is delivering HTML partials over web sockets in response to events, optimized via DOM-diffing.
Obie Fernandez is a bad ass. He is not hyping anything he is describing his journey. If you knew who he was you would know how much weight that should carry.
I've been a fan of Obie's for some time, but I do agree that an article should stand on its own, with no appeal to authority needed.
It’s not an appeal to authority to listen to an experts journey through new emergent technology and how that has shaped their own professional achievement. If anything that is the sole example of when expertise and authority is really valuable. And discounting most of the article because he says “mongodb was awesome” and “server less was awesome” and “stimulus is just as awesome” is losing the value he offers
Stimulus Reflex is picking up a lot of steam among Rails developers. It's not novel - it's the same approach being used in LiveView in Phoenix, Blazor in dotnet, and LiveWire in Laravel. (Details vary a bit, but basically DOM diffing over web sockets, with HTML being rendered on the server as opposed to heavy client side logic transforming JSON/GraphQL)
You managed to pique my interest more in 4 sentences than that entire article did. Thanks!
Since writing the blog post I found out that there's another competing framework that might realize the design goals I'm describing in succint, self-contained fashion:
https://github.com/unabridged/motion