HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
73% Positive
Analyzed from 1323 words in the discussion.
Trending Topics
#htmx#react#html#angular#pages#page#load#web#apps#why
Discussion (37 Comments)Read Original on HackerNews
With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions.
The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.
But on serious note, htmx is basically a solution in the search of a problem. It is the new hype.
Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap.
The fundamental problem is that it is pretending to be a declarative language while entirely imperative.
I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half decade as that was the best option at the time, but sooner or later, you get sick of stuffing "little codelets" inside attributes all over the place, which is exactly what htmx does.
If you want to understand what htmx is going to look like at scale, look at angular 1.0 projects.
Say you have a huge Google Ads budget burning up on those landing pages. Make one version with React and one with HTMX. Open Lighthouse and see performance difference. First page renders are much slower with React. Page load is slower and this makes a huge difference in mainland USA where people are still on 3G speeds on their budget phones.
"High traffic" might be the simplified view here and it took me a few page memos to explain it to my lead but the gist is that React is slower, takes longer to load and most of what it is used for is easily done with plain HTML and sprinkles of JS as needed. Unless you're streaming sound or video like you do on Facebook pages it's really not the right tool for the job in a majority of cases.
The only thing the 2 have in common is the use of HTML attributes for functionality. Completely different on every other axis that matters.
If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version.
Most of the time (existing user using the same browser, no update) there will be precisely zero traffic to your servers to load the React app except for the initial HTML skeleton.
For an app using SSR it's more complicated and I'll admit I don't know how that works at very high load
People weren't cancelling the page load and surfing back anymore. You cannot argue that React is extremely heavy and also adds a lot of time between first render. Test a normal HTMX page in Lighthouse and then convert it to React and you'll see how drastic things are.
People use React today out of habit rather than because it's the best tool for the job.
Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is?
The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproject.org/ Please read this and reply when you still think it's hype.
Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatches and what not.
And the features specified in that project is nice to have, in the same way that it is nice that we have Date Pickers or other advanced input features, but it is never going to replace React-like frameworks.
Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.
I have no idea what this means. The World Wide Web itself is quite literally hypermedia.
The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true.
> Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management...
You may have stabilised on JSX, "we" have not. React is one way of building web applications. It's appropriate for a certain subset of highly interactive SPAs, and completely inappropriate for many other things.