When I first read the haiku at the bottom of the HTMX homepage, I had a flash of insight.
javascript fatigue:
longing for a hypertext
already in hand
What are we doing? State management libraries? Hypermedia is the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You will find that semantically structured HTML is almost as economical as JSON.
The Zen of jQuery moment for me was realizing that many of our bugs came from trying to separate the source of authority from the system of record.
It was a tremendous amount of busy work keeping metadata about DOM elements stored separately from the DOM elements, and hanging the values off the element was so much simpler in initial implementation, maintenance, and exploring other people's code.
Everyone was so excited about the virtual DOM in React 'n friends, whereas I saw both the functionality and the excitement as warning signs that I should stay away. I hoped this would turn out to be a fad, but it's a little long in the tooth for that scenario to play out now. For a while I watched news articles for the chinks in its armor, these days I'm more focused on other tools that satisfy niches, and wondering what will end up being the 'CSS3/ES6' moment for React where the browser does 20% of the work to have 80% feature parity with React.
Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend
The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting.
Note that with an SPA you need to send templates (in the js bundle) + data (json api) to the client, which by definition will be at least as large as static HTML for the same content: HTML is nothing more than the template and content already baked in. In practice the JS templates are much larger due to containing the entire application logic + compiler overhead.
Finally, the benefit of having the templates already loaded is only realized over longer timespans, when probably half of your users are coming in with an empty cache anyway.
Transfer compression will usually take that down to the point where it's negligible. By the time you're talking enough data for this to matter, things like pagination will likely be far more important.
I have not seen a good case of this. Can you point out one? Managing state on the server is trivial; sessions and database and that is it. How does handling on the client work? Well it works if you double up on the server; it is a crime when there is some SPA that manages state client side; something goes wrong and it is stuck, press reload, state gone; login page. It is annoying to me as dev, it is creating serious anger for people who do not understand this. They press f5 and are logged out. Wtf. Or their shopping cart is now empty. So if you want to fix that you have to handle state on the client and then sync with the server; how is that better than just having it on the server? I am a backend dev but I see more and more of my frontend colleagues move stuff to the server: it is just easier to reason about imho.
Sending over generated pieces of html that update divs I find a quite nice compromise: not the complexity while having updates without refresh. Intercooler sounds like that.
I’m with you, but I do like applications that can continue to operate seamlessly without a connection or with an intermittent connection. Although for these I would also expect them to persist state across refreshes with IndexDB or similar. Basically, I want my applications to work similarly to a git workflow, with merges and conflict resolution with the server only required when you hit “Save” (but maybe preemptively noticed, depending on workflow).
It is absolutely fixable, but the extra complexity invites people not to fix it while on the server it works as default.
I have integrated some very popular backends the past months and their portals are all SPAs and they all have this issue; hit refresh and you lost where you are, thrown back to login.
The simplest of them include "consequences" of architectural decision. For PWA these include the development of that kind of features.
Now to be absolutely honest. I prefer having a dedicated back-end that does one thing well and a front end that does one thing well. Even if I have to put in extra effort with few features just to have my source-code more dedicated and therefore cleaner to work with.
The thing is that PWA not only included the front-end dev, they also reduced the complexity of back-end. And that's a huge win I'd pay with these kind of features happily.
Honestly I like HN but the constant talk about PWA vs pure HTML apps has became tiresome and unproductive. I haven't seen a single argument that's properly stated about why we shouldn't do them.
Having argument alike "Oh I have to dev that feature therefor X sucks" is not a good enough opinion that i would like to read here neither.
People implement different ways of doing things all the time; they have to get ideas somewhere and they also have to see their work is worthwhile for others. You might or not like the current state; you just suck it up, I get that, we all do. We also can complain and try to do something about the things we do not like. Every new software is created for some reason; money opportunity, interest, scratching an itch or trying to get rid of pet peeves. Nothing wrong with that and personally I like to read about people’s issues with software; it keeps me confident that ‘this’ is not ‘it’, because if it was, I would become a full-time pizza chef. In the meanwhile, obviously I suck it up and build things; I can still hope for better. For me personally, Phoenix and Blazor(server and maybe client) show that I am not the only one annoyed by the stuff ‘everyone uses’.
Noone (well...) sits behind HN crying while doing nothing; but it is a platform where people go who actually make the changes or at least talk about them without dismissing them with ‘just use node/react and stfu’ or, almost the opposite, ‘just use wordpress and stfu’ like much of reddit and other programming forums (as far as there are).
Theoretically, you have a point. Practically, you are reading this comment on a website that not only does exactly this, but refreshes the entire page (rather than a small block of HTML, intercooler-style). The performance benefits are evident.
Every time you collapse a thread, that's saved on the server. Then, if you return to the page, it will render those threads collapsed. So that's a decent amount of state.
I disagree. It’s Boolean and flat (there is neither sequential nor nested logic around the state). It does recurse for each sub thread, but only in the case where there is no state. There’s also no business logic built around it, only display logic. It also is updated from exactly one location in the application.
That said, it’s a very simple and effective design. It’s an excellent program. But it’s not a fair comparison against other applications which, for one reason or another, need significantly more advanced state.
I mean, this website only loads a very small amount of text and has barely any user state besides a list of comments and posts. I would hope that it loads quickly.
Treating 10KB of JavaScript as equal to 10KB of HTML is a big mistake. They transition over a network in the same amount of time, but HTML is far faster to process. Websites with large HTML sizes often display far faster than the same information that use JavaScript client-side frameworks. Often the framework is still trying to figure out which way is up, while the HTML version is already being displayed. It's a trade-off that isn't discussed enough.
I wrote a game engine with a DSL that renders as detail/summary html blocks. It wasn't hard to end up with a page that was hundreds (or thousands) of megabytes. Any given browser really had no issue until it was over several hundred megabytes.
javascript fatigue:
longing for a hypertext
already in hand
What are we doing? State management libraries? Hypermedia is the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You will find that semantically structured HTML is almost as economical as JSON.