For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input.
Also, there was a push to move the shitty code from the server to the client to free up server resources and prevent your servers from ruining the experience for everyone.
We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.
But that isn't because of the technology, it's because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again. Nothing about this technology will stop that.
Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real problem was “not write the validation code twice” surely the answer would have been some kind of DSL that code-generated or interpreted the validation rules for the back end and front end, not the fantastically complex Rube Goldberg machine of the modern Javascript wait wait wait wait and wait some more to build machine and then users wait wait wait wait wait for React and 60,000 files worth of library code to load and then wait wait wait wait even more for completely inscrutable reasons later on. (e.g. amazing how long you have to wait for Windows to delete the files in your node_modules directory)
Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either
The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check.
or
They're changing things because they're already so far from default browser behavior, why not? ... Scrolling broken or janky because the developer decided it would be cool to replace it? Check.
There is a time and place for SPA (mail is a great example). But using them in places where the page reload would load in completely new content for most of the page anyways? That's paying a large cost for no practical benefit; and your users are paying some of that cost.
It's amusing that for a long time the response was "oh man that sounds terrible".
Now it is "oh hey that's server side rendered ... is it a new framework?".
The cycle continues. I end up writing all sorts of things and there are times when I'm working on one and think "this would be better as Y" and then on Y "oh man this should be Z". There are days where I just opt for using old ColdFusion... it is faster for somethings.
Really though there's so many advantages to different approaches, the important thing is to do the thing thoughtfully.
Node does not absolve from this. Any important verification still needs to be done on the server side, since any JS on the client side cannot be trusted to not be manipulated. JS on the client side was of course possible before NodeJS. NodeJS did not add anything there regarding where one must verify inputs. Relying on things being checked in the frontend/client-side is just writing insecure websites/apps.
> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.
I would claim they became even more so than the thing they replaced. Basically most of any progress in bandwidth or ressources is eaten by more bloat.
Server side validation is for security, correctness, etc.
They are different features that require different code. Blending the two is asking for bugs and vulnerabilities and unnecessary toil.
The real reason that SPAs arose is user analytics.
"The best SPA is better than the best MPA. The average SPA is worse than the average MPA."
https://nolanlawson.com/2022/06/27/spas-theory-versus-practi...
What? No.
The whole point of Node was a) being able to leverage javascript's concurrency model to write async code in a trivial way, and b) the promise that developers would not be forced to onboard to entirely different tech stacks on frontend, backend, and even tooling.
There was no promise to write code once, anywhere. The promise was to write JavaScript anywhere.
I mean, I'm using Laravel Livewire quite heavily for forms, modals and search. So effectively I've eliminated the need for writing much front-end code. Everything that matters is handled on the server. This means the little Javascript I'm writing is relegated to frilly carousels and other trivial guff.
Also, all these things the author complains about are realities of native apps, which still exist in massive numbers especially on mobile! I appreciate that some folks only need to care about the web, but declaring an architectural pattern as superior - in what appears to be a total vacuum - is how we all collectively arrive at shitty architecture choices time and time again.
Unfortunately, you have to understand all the patterns and choose when each one is optimal. It's all trade-offs - HTMX is compelling, but basing your entire architectural mindset around a library/pattern tailored to one very specific type of client is frankly stupid.
Technically, the technology support doing any of them right. On practice, doing good MPAs require offloading as much as you can into the mature and well developed platforms that handle them; while doing good SPAs require overriding the behavior of your immature and not thoroughly designed platforms on nearly every point and handling it right.
Technically, it's just a difference on platform maturity. Technically those things tend to correct themselves given some time.
On practice, almost no SPA has worked minimally well in more than a decade.
While I am a fan of MPAs and htmx, and personally find the dev experience simpler, I cannot argue with this.
The high-order bit is always the dev's skill at managing complexity. We want so badly for this to be a technology problem, but it's fundamentally not. Which isn't to say that specific tech can't matter at all -- only that its effect is secondary to the human using the tech.
It brings a tear of joy to my eye honestly. The circle of life continues, and people always forget people are bad at programming (myself included).
People forget how bad MPAs were, and how expensive/complicated they were to run.
Front end frameworks like svelte let you write nearly pure HTML and JS, and then the backend just supplies data.
Having the backend write HTML seems bonkers to me, instead of writing HTML on the client and debugging it, you get to write code that writes code that you then get to debug. Lovely!
Even more complex frameworks, like React, you have tools like JSX that map pretty directly to HTML, and in my experience a lot of the hard to debug problems come up with the framework tries to get smart and doesn't just stupidly pop out HTML.
FWIW I turned off JavaScript on my iPad a couple years ago ... what a relief!
I have nothing against JS, but the sites just became unusably slow
In the last years, for every layer of web development, what I saw was that a big smelly pile of problems with bad websites and webapps, be it MPA or SPA, was not a matter of bad developers on the product, but more a problem of bad, sometimes plain evil, developers on systems sold to developers to build their product upon. Boilerplate for apps, themes, ready-made app templates are largely garbage, bloat, and prone to supply chain attacks of any sort.
(I'm not actually arguing with you, just thinking out loud)
This is often repeated but I don't think it even close to a primary reason.
The primary reason you build JS web clients is for the same reason you build any client: the client owns the whole client app state and experience.
It's only a fluke of the web that "MPA" even means anything. While it obviously has its benefits, we take for granted how weird it is for a server to send UI over the wire. I don't see why it would be the default to build things that way except for habit. It makes more sense to look at MPA as a certain flavor of optimization and trade-offs imo which is why defaulting to MPA vs SPA never made sense now that SPA client tooling has come such a long way.
For example, SPA gives you the ability to write your JS web client the same way you build any other client instead of this weird thing where a server sends an initial UI state over the wire and then you add JS to "hydrate" it, and then ensuring the server and client UIs are synchronized.
Htmx has similar downsides of MPAs since you need to be sure that every server endpoint sends an html fragment that syncs up to the rest of the client UI assumptions. Something as simple as changing a div's class name might incur html changes across many html-sending api endpoints.
Anyways, client development is hard. Turns out nothing was a panacea and it's all just trade-offs.
This pretty much sums it up. There is no right technology for the wrong developer.
It's not about what can get the job done, it's about the ergonomics. Which approach encourages good habits? Which approach causes the least amount of pain? Which approach makes sense for your application? It requires a brain, and all the stuff that makes up a good developer. You'll never get good output from a brainless developer.
You did write it once before too. With NodeJS you have Javascript on both sides, that's the selling point. You still have server and client code and you can write a MPA with NodeJS
These are two different things and I don't see how they're related. You don't need code sharing to do client side navigation. And you should always be validating on the backend anyway. Nothing is stopping an MPA from validating on the client, whether you can do code sharing or not.
This never panned out because people are too afraid to store meaningful state on the client. And you really can't because (reasonable) user expectations. Unlike a Word document people expect to be able to open word.com and have all their stuff and have n simultaneous clients open that don't step on one another.
So to actually do anything you need a network request but now it's disposable-stateful where the client kinda holds state but you can't really trust it and have to constantly refresh.
Yes... but some people like me just don't like JS so for us that was actually a rebutal.
I think the root cause of this is lack of will/desire to spend time on the finer details, either on the part of management who wants it out the door the second it's technically functional or on the part of devs who completely lose interest the second that there's no "fun" work left.
Not sure about that. SPA’s load 4MB of code once, then only data.
Now look at a major news front page, which loads 10MB for every article.
A black & white view of development and technology is easy but not quite correct. Technology decisions aren't "one size fits all".
This is only sort of true. The problem can be mitigated to a large extent by frameworks; as the framework introduces more and more 'magic' the work that the developer has to do decreases, which in turn reduces the surface area of things that they can get wrong. A perfect framework would give the developer all the resources they need to build an app but wouldn't expose anything that they can screw up. I don't think that can exist, but it is definitely possible to reduce places where devs can go astray to a minimum.
And, obviously, that can be done on both the server and the client.
I strongly suspect that as serverside frameworks (including things that sit in the middle like Next) improve we will see people return to focusing on the wire transfer time as an area to optimize for, which will lead apps back to being more frontend than backend again. Web dev will probably oscillate back and forth forever. It's quite interesting how things change like that.
But we don’t have JS devs.
We have a team of Python/PHP/Elixir/Ruby/whatever devs and are incredibly productive with our productivity stacks of Django/Laravel/Phoenix/Rails/whatever.
HTML5 solved that to a first approximation client-side. Often later you'll need to reconcile with the database and security, so that will necessarily happen there. I don't see that being a big trade-off today.
drain the swamp man
This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side.
But Turbolinks is more than ten years old. React was born and rose to popularity during the age of Turbolinks. Turbolinks has already lost the war against React.
The biggest problem with Turbolinks/Htmx is that there's no good story for what happens when one component in a tree needs to update another component in the tree. (Especially if it's a "second cousin" component, where your parent component's parent component has subcomponents you want to update.)
EDIT: I know about multi-swap. https://htmx.org/extensions/multi-swap/ It's not good, because the onus is on the developer to compute which components to swap, on the server side, but the state you need is usually on the client. If you need multi-swap, you'll find it orders of magnitude easier to switch to a framework where the UI is a pure function of client-side state, like React or Svelte.
Furthermore, in Turbolinks/Htmx, it's impossible to implement "optimistic UI," where the user creates a TODO item on the client side and posts the data back to the server in the background. This means that the user always has to wait for a server round trip to create a TODO item, hurting the user experience. It's unacceptable on mobile web in particular.
When predicting the future, I always look to the State of JS survey https://2022.stateofjs.com/en-US/libraries/front-end-framewo... which asks participants which frameworks they've heard of, which ones they want to learn, which ones they're using, and, of the framework(s) they're using, whether they would use it again. This breaks down into Awareness, Usage, Interest, and Retention.
React is looking great on Usage, and still pretty good on Retention. Solid and Svelte are the upstarts, with low usage but very high interest and retention. Htmx doesn't even hit the charts.
The near future is React. The further future might be Svelte or Solid. The future is not Htmx.
> no good story for what happens when one component in a tree needs to update another component in the tree
HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page, even if what the user clicked on is a button heavily nested.
> it's impossible to implement "optimistic UI," ... hurting the user experience
Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection.
In the case of "useless without internet connection" do we really need optimistic UI. The actual experience of htmx is incredibly fast. There is no overhead of all the SPA stuff. No virtual dom, hardly any js. It's basically the speed of the network. In my limited practice I've actually felt the need to add delays because the update happens _too fast_.
I'm still evaluating htmx but not for any of the reasons you've stated. My biggest concern is ... do I want my api to talk in html?
Of course, I've not used Turbolinks, so I don't know what issues applied there.
Edit: I'm not saying htmx is the future either. I'd love to see how they handle offline-first (if at all) or intermittent network connectivity. Currently most SPAs are bad at that too...
Huh, no one told me this before, so I've been very easily doing it with htmx's 'out of band swap' feature. If only I'd known before that it was impossible! ;-)
If it's teams of 10X devs working around the world to make the next great Google-scale app, then yeah, maybe React or something like it is the future.
If it's a bunch of individual devs making small things that can be tied together over the old-school Internet, then something like HTMX moves that vision forward, out of a 90-00s page-link, page-link, form-submit flow.
Of course, the future will be a bit of both. For many of my various project ideas, something like React is serious overkill. Not even taking into account the steep learning curve and seemingly never-ending treadmill of keeping current.
Pretty common patterns for this- just use a sprinkle of client side JS (one of: hx-on, alpine, jquery, hyperscript, vanilla js, etc), then trigger an event for htmx to do its thing after awhile, or use the debounce feature if it's only a few seconds. Lots of options, actually.
React would have to eventually contact the server as well if we're talking about an equivalent app.
You can split a large app into pages and then each page only has to care about its own parts (sub components). If you want some component to be used on multiple pages you just create it with the server technology you use and include it. The other components on the page can easily target it. You may have some problem if you change a shared component in such a way that targeting stops working. You may be able to share the targeting code to make this easier.
From the February 31, 1998 Hacker News archives: "According to state of the web survey, Yahoo and Altavista are looking great on usage, Hotbot and AskJeeves are the upstarts. Google doesn't even hit the charts."
Also, it seems so cyclic, isn't HTMX/Hotwire similar to Java JSP's which was how things were before SPA's got popular?
hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more relevant for modern development
we have a free book on practical hypermedia (a review of concepts, old web 1.0 style apps, modernized htmx-based apps, and mobile hypermedia based on hyperview[2]) available here:
[1] - https://htmx.org/essays/when-to-use-hypermedia/
[2] - https://hyperview.org/
> introduction
> htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext
> htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react
This tells me what htmx does and what some of its properties are, but it doesn’t tell me what htmx is! You might want to borrow some text from your Documentation page and put something like the following at the top of your homepage:
“htmx is a dependency-free, browser-oriented javascript library that allows you to access modern browser features directly from HTML.”
Can be achieved in MPAs and SPAs alike. I'd also argue that having state floating around in HTTP requests is harder to reason about than having it contained in a single piece in the browser or in a server session. Granted this is not a problem of HTMX, but of hypermedia. There is a reason why HATEOAS is almost never observed in REST setups.
> two-codebase problem
This is a non-problem. In every part of a system, you want to use the right tool for the job. Web technologies are better for building UIs, if only by the sheer ammount of libraries and templates that already exist. The same splitting happens in the server side: you would have a DB server, and a web service, maybe a load balancer. You naturally have many parts in a system, each one being specialized in one thing, and you would pick the technologies that make the most sense for every one of them. I'd also argue that backend developers would have a hard time dealing with the never ending CSS re-styling and constant UI change requests of today. This is not 2004 where the backend guys could craft a quick html template in a few hours and went back to work in the DB unmolested. The design and UX bar is way higher now, and specialists are naturally required.
In the OPs article, it looks like the only thing going over the line is UUIDs. How does the server know "this uuid refers to this element"? Does this require a sticky session between the browser and the backend? Are you pushing the state into a database or something? What does the multi-server backend end up looking like?
These redesigns would be a lot more difficult if we had to edit HTML on the client and the HTML that a server returns.
Also, HTMX is best styled with semantic classes. Which is a problem for companies using Tailwind and utility classes in their HTML. With class-heavy HTML it's nearly impossible to redesign in two different places. And performance suffers and returning larger chunks of HTML.
Despite all that, I want HTMX to be the standard way companies develop for the web. But these 2 problems need to be addressed first, I feel, before companies (like mine) take the leap.
I looked at a bunch of frameworks before settling on dart/flutter for my own cross platform projects. I did look at htmx but since I wasn't really wanted to create a web app I moved on. But I like the idea of a true rest style of app.
Hypermedia advances would be microformats and RDF and the like. http://microformats.org/wiki/faqs-for-rdf
I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted.
After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with JavaScript sprinkled in.
This year, I've looked at Node again now that frameworks like Next offer a middle ground with server-side rendering, but I'm still put off by the dependency graphs and tooling, which seems to be in a constant state of flux. It seems to offer great benefits for front-end teams that have the time to deal with it, but that's not me.
All this to say pick the right tool for the job. For me, and for teams going fuller stack as shops tighten their belts, that's tech like HTMX, sprinkled JavaScript, and sometimes lightweight frameworks like Alpine.
I'd add a couple features if I were working there (making css changes and multiple requests to multiple targets standard), but as it stands, it's a pleasure to work in.
Next.js for example, comes packed with anything and everything one might need to build an app. Sitting on the promise of hyperproductivity with "simplicity". Plus, is made of single responsability principles set of modules, kind of necessary to build a solve-all needs framework.
And it does that.
A bit like Angular, set to solve everything front-side. With modules not entirely tightly coupled but sort of to get the full solution.
And it did that.
Then we have outliers like React, which stayed away from trying to solve too many things. But the developers have spoken, and soon enough it became packed in with other frameworks. Gatsby etc. And community "plug-ins" to do that thing that dev think should be part of the framework.
And they did that, solved most problems from authentication to animation, free and open source sir, so that developers can write 12 lines of code and ship 3 features per day in some non innovative way, but it works, deployed in the next 36 seconds, making the manager happy as he was wondering how to justify over 100k in compensation going to a young adult who dressed cool and seemed to type fast.
Oh no! dependency hell. I have to keep things maintained, I have to actually upgrade now, LTS expired, security audits on my back, got to even change my code that worked perfectly well and deal with "errors", I can't ship 3 features by the end of today.
We need a new framework!
I previously used HTMX for another project of mine, and it worked fine too. I did, however, feel limited compared to React because of what's available.
All that being said, I'm glad HTMX worked out for you!
At this rate, when I'm 80 years old we will still be fucking around with these stupid lines of code, hunched over, ruining our eyesight, becoming ever more atrophied, all to make a fucking text box in a monitor pop some text into a screen on another monitor somewhere else in the world. It's absolutely absurd that we spend this much of our lives to do such a dumb thing, and we've been iterating on it for five decades, and it's still just popping some text in a screen, but we applaud ourselves that we're so advanced now because something you can't even see is doing something different in the background.
Do an Internet search for “Quartex Pascal”, and/or its creator, Jon Aasenden. He has a blog on WordPress, and a Facebook group. His crazy Quartex project is apparently nearing completion. It's an Object Pascal compiler and IDE — kind of a Delphi / Lazarus clone, if you will — that compiles to JavaScript, for the end product to be run in the browser. I think that's as close to “Visual Basic for the web” as one can get.
It’s a pleasure to work with so little boilerplate.
The thing that keeps holding me back from htmx is that it breaks Content Security Policy (CSP), which means you lose an effective protection against XSS.[0] When I last asked the maintainer about this, the response was that this was unlikely to ever change.[1]
Alpine.js, a similar project to htmx, claims to have a CSP-compatible version,[2] but it's not actually available in any official builds.
[0] https://htmx.org/docs/#security
[1] https://news.ycombinator.com/item?id=32158352
I see a lot of resemblance to http://catalyst.rocks with WebComponents that target other components. I think there's something unspoken here that's really powerful & interesting, which is the declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped in code-land, away from the DOM. The exciting possibility is that we can nicely encode more of the behavior into the DOM, which creates a consistent learnable/visible/malleable pattern for wiring (and rewiring) stuff up. It pushes what hypermedia can capture into a much deeper zone of behaviors than just anchor-tag links (and listeners, which are jump points away from the medium into codespace).
Yes! There's always going to be some range of client behavior that's difficult to reduce to declarations, but so much of what we do is common that if it isn't declarative we're repeating a lot of effort.
And in general I think you're describing a big part of what made the web successful in the first place; the UI-as-document paradigm was declarative, accessible, readable, repeatable.
Web “app” development finally catching up to where Visual Basic and Delphi were ~30 years ago, hurrah!
Imagine 10s of thousands of clients requesting millions of HTML fragments be put together by a single server maintaining all the states while all the powerful high end computing power at the end user's fingertips goes completely to waste.
Not convinced.
HTTP is stateless. This is the whole point of the hypermedia paradigm.
If you have a page with many partial UI page changes over htmx, then yes, this paradigm puts increased load on the server, but your DB will almost certainly be your bottleneck before this will be, just as in the SPA case.
We've moved back to an MPA structure with decorated markup to add interactivity like scroll views, fetching data, tabs and other common UX use cases. If you view the source on yahoo.com and look for "wafer," you can see some examples of how this works. It helps to avoid bundle size bloat from having to download and compile tons of JS for functionality to work.
For a more complex, data-driven site, I still think the SPA architecture or "islands" approach is ideal instead of MPA. For our largely static site, going full MPA with a simple client-side library based on HTML decorations has worked really well for us.
At all of Yahoo? I imagined such a big company would have a variety of front-end frameworks and patterns.
What library are you using?
This is a necessity as long as latencies between the client and server are large enough to be perceptible to a human (i.e. almost always in a non-LAN environment).
[edit]
I also just noticed:
> ...these applications will be unusable & slow for those on older hardware or in locations with slow and unreliable internet connections.
The part about "slow and unreliable internet connections" is not specific to SPAs If anything a thick client provides opportunities to improve the experience for locations with slow and unreliable internet connections.
[edit2]
> If you wish to use something other than JavaScript or TypeScript, you must traverse the treacherous road of transpilation.
This is silly; I almost exclusively use compiled languages, so compilation is happening no matter what; targeting JS (or WASM) isn't that different from targeting a byte-code interpreter or hardware...
--
I like the idea of HTMX, but the first half of the article is a silly argument against SPAs. Was the author "cheating" in the second half by transpiling clojure to the JVM? Have they tested their TODO example on old hardware with an unreliable internet connection?
I agree with everything else you said, but having followed the development of Kotlin/JS and WASM closely I have to disagree with this statement.
JavaScript is a very bad compilation target for any language that wasn't designed with JavaScript's semantics in mind. It can be made to work, but the result is enormous bundle sizes (even by JS standards), difficult sourcemaps, and terrible performance.
WASM has the potential to be great, but to get useful results it's not just a matter of changing the compilation target, there's a lot of work that has to be done to make the experience worthwhile. Rust's wasm_bindgen is a good example: a ton of work has gone into smooth JS interop and DOM manipulation, and all of that has to be done for each language you want to port.
Also, GC'd languages still have a pretty hard time with WASM.
The word "slow" here is unclear. Thick clients work poorly on low bandwidth connections, as the first load takes too long to download the JS bundle. JS bundles can be crazy big and may get updated regularly. A user may give up waiting. Thin clients may load faster on low bandwidth connections as they can use less javascript (including zero javascript for sites that support progressive enhancement, my favorite as a NoScript user). Both thin and thick clients can use fairly minimal data transfer for follow-up actions. An HTMX patch can be pretty small, although I agree the equivalent JSON would be smaller.
If "slow" means high latency, then you're right, a thick client can let the user interact with local state and the latency is only a concern when state is being synchronized (possibly with a spinner, or in the background while the user does other things).
Unreliable internet is unclear to me. If the download of the JS bundle fails, then the thick client never loads. A long download time may increase the likelihood of that happening. Once both are loaded, the thick client wins as the user can work with local state. Both need to sync state sometimes. The thin client probably needs the user to initiate retry (a poor experience) and the thick client could support retry in the background (although many don't support this).
It described the general steps and seemed to be able to describe how htmx works pretty well, including hx-get and hx-target, etc., but then said "As an AI language model, I am not able to write full applications with code".
I replied "do the same thing in bash" (which I knew would be different in significant ways, but just to check) and it provided the code.
I wonder, is this a function of recency of htmx or something else? Do other htmx developers encounter this? I imagine it's at least a little bit of a pain for these boilerplate cases, if it's consistent vs. access to the same GPT tooling for other languages.
https://www.wunderground.com/forecast/us/ak/north-pole
It isn't clear what you were asking ChatGPT to provide, therefore not surprised it didn't come up with the exact answer you expected. I'd suggest learning HTMX by reading the docs, the majority is just a single page.
Is this suggesting writing any language we want in the browser? I have wondered for a couple decades why Python or some other open source scripting language wasn't added to browsers. I know Microsoft supported VBScript as an alternative to JavaScript in Internet Explorer and had it not been a security nightmare (remember the web page that would format your hard drive, anyone?) and not a proprietary language it might have a rival to JavaScript in the browser. In those days it wouldn't have taken much to relegate JavaScript to non-use. Today we just get around it by compiling to WASM.
Nope, server
> SPAs have allowed engineers to create some great web applications, but they come with a cost:
> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks.
Yes, better quality software usually packages a bit more complexity.
SPAs are popular, just like native apps, because people don't like jarring reloads. Webviews in native apps are panned for a reason; turning your whole app into a series of webviews would be stupid, right?
> Tooling is an ever-shifting landscape in terms of building and packaging code.
I've used these 4 libraries to build apps since 2015:
* React * MobX * D3 * Webpack
The only one I have had pain with is react-router-dom, which has had 2 or 3 "fuck our last approach" refactors in this time. And I added TypeScript in 2018.
PEBCAK
> Managing state on both the client and server
It's a lie that a thin client isn't managing state; it's just doing a static, dumb job of it.
Imagine some cool feature like... collaborative editing.
How would you pull that off in HTMX?
> Frameworks, on top of libraries, on top of other libraries, on top of polyfills. React even recommend using a framework on top of their tech:
Yes, React is famously not a batteries-included library, while Angular is. But, as addressed, you need about 3 other libraries.
Besides, did you know: HTMX is also a framework. Did you know: HTMX also has a learning curve. Did you know: HTMX forces you to be able to manipulate and assemble HTMLstrings in a language that might not have any typing or tooling for that?
Anyways, I've said enough. I should've just said what I really think: someone who can't even get their nested HTML lists to actually indent the nesting shouldn't give advice on building UIs.
That view (+quality = +complexity) is actually flip sided, isn't it? [1]
[1] https://www.infoq.com/news/2014/10/complexity-software-quali...
What are you gaining by writing something like that in java/type-script rather than like rust and webassembly?
To me javascript is in a sort of uncanny valley where you probably want to be either making a real app and compiling it to wasm or using something like htmx.
In my opinion, the whole point of the article and for everyone who is backing htmx is that SPA frameworks are too complex (and a liability) for solo/small teams or projects that don't need `collaborative editing`(or other advanced stuff).
A highly complex stock-trading application should absolutely not be using Htmx.
But a configuration page? A blog? Any basic app that doesn't require real-time updates? Htmx makes much more sense for those than React. And those simple needs are a much bigger part of the internet than the Hacker News crowd realizes or wants to admit.
If I could make one argument against SPA's it's not that they don't have their use, they obviously do, it's that we're using them for too much and too often. At some point we decided everything had to be an SPA and it was only a matter of time before people sobered up and realized things went too far.
It's like with static websites - we went from static to blogs rendered in php and then back to jekyll...
I've been on the sidelines for the better part of a decade for frontend stuff, but I was full-stack at a tiny startup in 2012ish that used Rails with partial fragments templates for this. It needed some more custom JS than having a "replacement target" annotation everywhere, but it was pretty straightforward, and provided shared rendering for the initial page load and these updates.
So, question to those who have been active in the frontend world since then: that obviously failed to win the market compared to JS-first/client-first approaches (Backbone was the alternative we were playing with back then). Has something shifted now that this is a significantly more appealing mode?
IIRC, one of the big downsides of that "partial" approach in comparison with SPA-approaches was that we had to still write those JSON-or-XML-returning versions of the endpoints as mobile clients became more prevalent. That seems like it would still be an issue here too.
> one of the big downsides of that "partial" approach in comparison with SPA-approaches was that we had to still write those JSON-or-XML-returning versions of the endpoints as mobile clients became more prevalent. That seems like it would still be an issue here too.
Yup. Still, if you're at the scale where you need to support multiple clients, things should be going well enough where you can afford the extra work.
As soon as multiple clients are involved, you're writing SOMETHING to support specifically that client. 10+ years ago, you'd be writing those extra conditionals to return JSON/XML _and_ someone is building out this non-browser client (mobile app, third party API, whatever). But you're not rearchitecting your browser experience so that's the tradeoff.
> Has something shifted now that this is a significantly more appealing mode?
React especially led from one promise to another about _how much less code_ you'd have to write to support a wide range of clients, when in reality there was always another configuration, another _something_ to maintain when new clients were introduced. On top of that, the mobile device libraries (React Native, etc), were always steps behind what a true native app UX felt like.
I think a lot of us seasoned developers just feel burned by the SPA era. Because of how fast it is to iterate in js, places like npm would seemingly have just the right component needed to avoid having to build custom in-house, and its simply an `npm add` and an import away. Meanwhile, as the author states, React and company changed a lot under the hood rapidly, so dependencies would quickly become out of date, now trying to maintain a project full of decaying 3rd party libs because its own tech debt nightmare. Just for, say, popper.js or something like that.
I'm just glad the community seems to actively be reconsidering "the old ways" as something valuable worth revisiting after learning what we learned in the last decade.
SEO I personally think is a questionable motivation except in very specific use cases.
Speed is almost compelling but the complexity cost and all the considerations around how a page is structured (which components are server, which are client, etc) does not seem worth the complexity cost IMO. Just pop a loading animation up in most cases IMO.
I think I'm stuck somewhere in the middle between old-hacker-news-person yelling "lol were just back at index.html" and freshly-minted-youtube-devs going "this is definitely the new standard".
I mean, aren't these baseline "get computers to do stuff" things?
There are many use cases out there where not treating a browser as a container to run an actual application is the right way to go. On the other hand, there's many use cases where you want the browser to be, basically, a desktop app container.
The big bold letters at the top of the article declaring htmlx is the future is a bit much. It has its place and maybe people are re-discovering it but it's certainly not the future of web development IMO. The article gives me kind of web dev career whiplash.
We had the same and worse problems with "thick clients" that came before the web grew. With the right requirements, team, tools etc., you could sometimes build great apps. This was incredibly difficult and the number of great apps was relatively small. Building with earlier server-side web tech, like PHP, isolated everything on the server and it was easier to iterate well than with the "thick clients" model.
SPA reinvents "thick clients" to some degree and brings back many of the complications. No one should claim you can't build a great SPA, or that they have few advantages, but the probability of achieving success is frequently lower. Frameworks try to mitigate these concerns, but you are still only moving a closing some of the gaps and the probability of failure remains higher. Depending on the app you can move the success metrics, but we often end up fudging on items like performance.
We get to a point where there is current model is fraying and energy builds to replace it with something else. We end up going back to old techniques, but occasionally we learn from what was done before.
I find that it's surprisingly rare for people with 1-2 years of experience to be able to give an accurate overview of the last 10 years of web development. A better understanding of this history can help with avoiding (or targeting) problems old timers have encountered and complain about in comments.
There is a big downside though: weak error handling. It just assumes that your call will get a response.
But I'll be honest. I'll believe it when I see it. It's not that htmx is bad, but given the complexity of client-side interactions on the modern web, I can't see it ever becoming really popular.
Some of the specifics in the comparisons are always weird, too.
> Instead of one universal client, scores of developers create bespoke clients, which have to understand the raw data they fetch from web servers and then render controls according to the data.
This is about client side apps fetching arbitrary JSON payloads, but your htmx backend needs to do the same work, right? You have to work with the raw data you get from your DB (or another service) and then render based on that data.
You're still coupled to the data, and your htmx endpoint is just as "bespoke" as the client code which uses it. It's not wrong to prefer that work be done on the server instead of the client, or vice versa, but we're really just shuffling complexity around.
In your analogy, the client JS code is like the serverside code, fetching over the network instead of directly from the DB, and then doing essentially the same work from there... materializing html and a set of controls for the user to interact with.
In a sense, I see your point.
But there's a difference: When you materialize the html on the server and send that over the wire, the browser does all the work for you. When you take the SPA approach, you must re-implement much of what the browser does in JS, and hence the well-known trouble with routing, history, and so on. You can argue that React/Angular/whatever takes care of this for you at this point, and to some extent it's true, but you're still cutting against the grain. And even as mature as the frameworks are, you will hit weird edge cases sometimes that you'd never have to worry about with the browser itself.
With that being said, I imagine it would become unmaintainable very quickly. The problems htmx is solving are better solved with other solutions in my opinion, but I do think there's something that can be learned or leveraged with the way htmx goes about the solution.
Per se. It's Latin for “in itself”; has nothing to do with saying anything. Think about it: What would “per-say” even mean?
What I mean is, different websites work differently, and do different things. For example, you might imagine a single desktop app that replaces multiple news aggregators, like Reddit or HN. It would ignore the style of both sites, and replace it with a single, uniform way of displaying posts and threads. But, what features from each does it implement? Does it have both upvoting and downvoting, like Reddit, or just upvoting, like HN? Does it support deeply nested threads, like Reddit, or only a couple levels, like HN? You'd run into limitations like this when trying to have a single app do everything, so you'd end up having to have n applications, one for each website you were replacing...
I'm also not with you on the "gnashing of teeth" point. I've never struggled to install, uninstall, or upgrade a website I was browsing.
I'm genuinely curious what OS and tooling you use that you find so much better, because every time I've tried desktop development I eventually give up and go back to the web. It might be because Linux support is always a requirement for me.
src/index.php
---------
<!DOCTYPE html>
<html>
<head><title>Hey look ma, we're back to PHP</title></head>
<body>
<? include "navbar.php" ?>
<p>Don't forget about PHP - a hypertext preprocessor!</p>
<? include footer.php ?>
</body>
</html>
src/navbar.php
----------
<div>
<ul>
<li>Home</li>
<li>About</li>
</ul>
</div>
Makefile to generate a static site:
-----------------------------------
dist/index.html: src/index.php
dist/about.html: src/about.php
dist/%.html: src/%.php
@mkdir -p ${dir $@}
php $< > $@A lot of the comments here seem to have the approach that there is a single best stack for building web applications. I believe this comes from the fact that as web engineers we have to choose which tech to invest our careers in which is inherently risky. Spend a couples years on something that becomes defunct and it feels like a waste. Also, startup recruiters are always looking for the tech experience that matches the choice of their companies. VCs want to strike while the iron is hot.
Something that doesn't get talked about enough (which the author does mention near the end of article) is that different web apps have different needs. There is 100% a need for SPAs for certain use cases. Messaging, video players, etc. But there are many cases where it is overkill, like the many many CRUD resource apps I've built over the years. Say you have a couple hundred users that need to manage the state of a dozen interconnected resources. The benefits of an MPA are great here. Routing is free, no duplication of FE / BE code. Small teams of devs can ship code and fix bugs very fast which keeps the user feedback loop tight.
A hypermedia approach is the nice happy medium between a very static website and an SPA, not sure why so many people are close-minded about this possibility.
I'm not seeing it. SPAs can be overly complex and have other issues, but I'm not seeing HTMX as a particular improvement.
Also, a bunch of this article doesn't make sense to me.
E.g, one of the listed costs of SPAs is managing state on the client and server... but (1) you don't have to -- isn't it rather common to keep your app server stateless? -- and (2) HTMX certainly allows for client-side and server-side state, so I'm not sure how it's improving things. That is, if you want to carefully manage app state, you're going to need a mechanism to do that, and HTMX isn't going to help you.
It also doesn't somehow prevent a rats nest of tooling or dependencies. It isn't an application framework, so this all depends on how to solve that.
SPA's also aren't inherently "very easy to make [...] incorrectly".
Also, the suggested HTMX approach to no browser-side javascript is very crappy. Your app would have to be very specifically designed to not be utterly horrible w/o JS with such an approach and instead be just pretty horrible. There are just so much more straightforward ways to make apps that work well without JS. Also, this isn't exactly a mainstream requirement in my experience.
I could go on and on. "caching" - htmx doesn't address the hard part caching. "seo-friendliness" - Like all the benefits here attributed to htmx, htmx doesn't particularly help with this and there are many other available way to achieve it.
IDK. These kinds of over-promising hyped up articles give me the feeling the thing being hyped up probably doesn't have a lot of real merit to be explored or else they'd talk about that instead. It also feels dishonest to me, or at least incompetent, so make all of these claims and assertions that aren't really true or aren't really especially a benefit of htmx vs many numerous other options.
Judging from the ones one encounters in the wild, yes they are.
HTMX is cool. HTMX may fit your needs. But it’s not enough for providing the best possible user experience.
Indeed, the creator of htmx has created another library called hyperscript which he's described as a companion to htmx.
I've seen this architectures quickly ruined by 'can-do' people who butcher everything to get a feature done _and_ get a bonus from the management for quick delivery.
This seems like the real problem we need to solve, but not sure how?
If anyone is looking to discuss making Hypermedia Driven Applications with HTMX in Python, head over to the discussions there!
Bloated JS frameworks like Angular, React, Vue, and Electron have big learning curves and a jillion gotcha's because they have to reinvent long-known and loved GUI idioms from scratch, but DOM is inherently defective for that need, meant for static documents. There are just too many GUI needs that HTML/DOM lacks or can't do right: https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...
Let's byte the bullet and create a GUI markup standard. Perhaps base it off Tk or Qt kits to avoid starting from scratch.
Heh, fun pun.
> Perhaps base it off Tk or Qt kits to avoid starting from scratch.
VCL / LCL.
Talk about the positives of YOUR approach, don't tear down a different approach that half the industry is using. You're not going to say anything new or interesting to the person you are trying to convince this way. Experienced engineers already know the trade-offs between an SPA and a server rendered experience.
AIUI TFA wasn't by the creators of HTMX, so it isn't the author's approach.
Hell, the term “frontend developer” exists only because they are writing JS! Tell them it’s better to write HTM?, and you are removing the “developer” from their titles!
Same reason why backend developers use K8s. There’s little money on wiring together bash scripts.
Now, if you’re working on your side project alone, then sure HTMX is nice.
Backend devs just lampoon it because they assume it must be simple.
Sorry, I read a load of stuff about React, before I came to any explanation of HTMX. Turns out, it's loading fragments of HTML into the DOM (without reload), instead of loading fragments of JSON, converting them to HTML fragments client-side, and injecting the resulting HTML into the DOM (without reload).
So I stopped reading there; perhaps the author explained why HTMX solves this at the end (consistent with the general upside-down-ness), but the "is the future" title was also offputting, so excuse me if I should have read the whole article before commenting.
I never bought into the SPA thing. SPAs destroy the relationship between URLs and the World Wide Web.
Sorry, but that's just... Silly. HTML is what the Web is all about.
A conceptual roadmap of where this journey could take us and, ideally, some production quality examples of solving important problems in a productive and fun way would increase the fan base and mindshare. Even better if it show how to solve problems we didn't know we had :-). I mean the last decade has been pretty boring in terms of opening new dimensions.
Just my two cents.
i read most htmx threads on hn and it's clear that people are looking for alternatives from react et al. they have a quick look, maybe implement an example and they are angry that it can't do everything they want cause the js ecosystem fatigue is real.
the centerpiece of the htmx site is an actual in-production app that was converted from react and it's better because of that. again, it will not be everybody's case.
htmx will let a lot of developers go all the way without bringing node into their ruby/python/php world for certain workloads. for them it is the future. the rest should stop reading.
our policy is that for widgets that are like browser components e.g. search as you type with keyboard shortcuts, we just use the off the shelf react component for that purpose and use it from htmx like it’a browser input element. for all other business logic (almost all of which has no low latency requirements and almost always involves a server requets), we use htmx in our server side language of choice.
our designer who knows a bit of react is not happy, but the 12 engineers on our team who are experts in $backend_lang and who are tired of debugging react race conditions, cache errors, TypeScript front end exceptions, js library churn, serialisation bugs, etc. are very happy indeed.
it doesn’t fit every app, but it fits our app like a glove and many others that I’ve considered writing that I didn’t feel like bothering to do so before discovering htmx.
2) The missing piece is how you can achieve this "collapsing" back of functionality into single SSR deployable(s) while still preserving the ability to scale out a large web application across many teams. Microfrontends + microservices could be collapsed into SSR "microapplications" that are embedded into their hosting app using iframes?
In my opinion, the future of the web as a platform is about viewing the web browser as an operating system with basic composable primitives.
HTMLX adds attributes to HTML using JS, and the argument about "no-JavaScript" is misleading: with HTMLX you can write interactions without JS, but HTMX uses JS. But, as it forces you to use HTML constructs that will work without scripts (such as forms), the page will fall back. It doesn't means that the fallback is usable.
The custom HTMLX attributes work because the browser supports extensions of its behavior using JS. If we add those attributes to the standard HTML, the result is more fragmentation and an endless race. The best standard is one that eliminates the need for creating more high-level standards. In my view, a possible evolution of WASM could achieve that goal. It means going in the opposite direction of the article, as clients will do more computing work. In a future like that, you can use HTMLX, SwiftUI, Flutter, or React to develop web apps. The biggest challenge is to balance a powerful OS-like browser like that with attributes like searchability, accessibility, and learnability (the devtools inspect and console is the closest thing to Smalltalk we have today)...even desktop OSs struggle today to provide that.
> without the annoying full-page load refresh.
This fixation on the page refresh needs to stop. Nearly every single website which has purportedly "saved" page refreshes has brutalized every other aspect of the UX.
This is a good article, and I agree that Htmx brings sanity back to the frontend, but somewhere along the line frontend folks got it in their head that page refreshes were bad, which is incorrect for essentially all CRUD / REST APIs. Unless you're specifically making a complex application that happens to be served through the web, like Kibana or Metabase, then stop harping on page refreshes.
Even this article calls it the annoying refresh. Not the impediment refresh, or the derisive refresh, or the begrieved refresh. Moreover, what exactly is annoying about page refreshes? That there's a brief flash? That it takes ~0.3 seconds to completely resolve?
Users don't care about page refreshes, and in fact they are an indication of normalcy. Upending the entire stack and simultaneously breaking expected functionally to prevent them is madness.
The killer feature of Htmx is that it doesn't upend the entire stack, and you can optimize page refreshes relatively easily. That's great! But even then I'm still not convinced the tradeoff is worth it.
These kind of takes fall in the bullseye of "I don't want to program with Javascript". The subtext is all about this.
Perhaps.. maybe.. Htmx won't be the future because there are a lot of people that like programming in Javascript?
I don't see the point by the way, I think htmlx is here to stay and a good choice for many, but it's clearly not a silver bullet. You make decently fast UIs, not blazing fasts, there are no (proper) offline first apps with htmlx, caching is likely more difficult or impossible sometimes and the load for your server is inevitably greater (of course it could be more than acceptable in some cases, so why not?), that also means more bandwidth for your cloud provider as opposed for you cdn. You will still have to write javascript sooner or later.
It depends on what you're doing. Nothing is aprioristic ly "the future", the future is "the future", and it has yet to come.
The future is whatever works best for your use-case.
So, I posit that the churn, while definitely real, is not actually intrinsic.
Right now, at Latacora, we're writing a bunch of Clojure. That includes Clerk notebooks, some of which incorporate React components. That's an advantage I think we shouldn't ignore: not needing to write my own, say, Gantt chart component, is a blessing. So, specifically: not only do I think the churn is incidental to the problem, I don't even believe you need to give up compatibility to get it.
Fun fact: despite all of this, a lot of what we're writing is in Clerk, and while that's still fundamentally an SPA-style combination of frontend and backend if you were to look at the implementation, it absolutely _feels_ like an htmx app does, in that it's a visualization of your backend first and foremost (React components notwithstanding).
The concept is great but why has it taken so long?
Backend engineers are now able to write management tools and experimental products faster - and then pass the winning products off to a fluttr team to code for all environments. The backend could be converted into a django rest api if the code is properly refactored.
Moreover, REST APIs - and I mean the simple ones people actually want to use, none of that HATEOAS BS - are ubiquitous for all sorts of interactions between web and nonweb clients. Are you going to ship an MPA as your mobile apps, or are you going to just use REST plus whatever clients make sense?
It also makes a lot of sense in terms of organization. Your backend developers probably suck at design, your frontend developers suck at databases.
However, I'm not sure if this is actually a problem or rather depends on how much interaction the user does (so where is the "turning point" of the overhead of having all in the bundle vs full HTML responses). What does everyone think?
Certainly it's possible to take on that burden and execute it well, but I think a lot of teams and businesses don't fully account for the fact that they are doing so and properly deciding if that extra burden is really necessary. The baseline for nailing performance and correctness is higher with an SPA.
I think what is needed is to recognize that the SPA architecture isn't actually just a view processor. IMO it is a very shitty designed:
View rendered <--> client process <--> server process
So it seems that SPA apps load an absolute mountain of javascript into the view (the tab/page) and then that starts (crudely IMO) running as client-side daemon tracking messy state and interfacing with local storage, with javascript (opinion: yuck) ferreted away in a half dozen divs.
IMO, what has been needed since you have local storage and local session state and all that is ... a client daemon that the web page talks to that offers data services, and then that client daemon if it needs server data calls to the internet.
That way local state tracking, transformation, and maintenance can be isolated away from the code of the view. Large amounts of javascript (or maybe all with CSS wizardry is dropped). The "client daemon" can be coded in webassembly, so you aren't stuck with javascript (opinion: yuck).
You can even have more efficient many views/tabs interfacing with the single client daemon, and the client daemon can track and sync data between different tabs/views/windows.
Now, of course that is fucking ripe as hell for abuse, tracking. Not sure how to solve it.
But "separation of concerns" in current web frameworks is a pipe dream.
Luckily, after 3 decades, there is some sobering realization that typesetting engine is not a good foundation for modern apps. https://news.ycombinator.com/item?id=34612696
Web development without HTML/CSS/JS is the future.
When I compare this to Phoenix LiveView I much prefer LiveView, because it both provides the markup templating engine and tracks the meaning of the relationship, with server-side tokens and methods.
There's no "the future" in this area, because demands are very different; a heavily interactive SPA like GMail or Jira has requirements unlike an info page that needs a few bits of interactivity, etc.
Yes you could make a CORBA or DCOM object almost indistinguishable from a local object, except for the latency when it was actually remote. And since it looked like a normal object it encountered “chatty” interface which exacerbated the latency cost.
Htmlx seems pretty chatty to me, which I’m sure works OK over the LAN, but what about the “real” internet?
The js-ajax-button has similar approach. Add class to button that have data-url and it will make request to it. This is small func I use, but with uajax is so powerful, I don't need react or htmx.
But it is hard to sell something that eliminates using javascript.
Ideas aside, the web app future belongs to those with the resources to sustain a response, or those who can restore the ability to capture/monetize developers and users in a closed system.
The scope of web apps is broad enough that many technologies arguably have their place. The open javascript ecosystem reduced the cost of creating candidates, but has no real mechanism to declare winners for the purpose of consolidating users, i.e., access to resources.
Careers and companies are built on navigating this complexity, but no one really has the incentive to reduce it unless they can capture that value.
I really appreciate Cloudflare because they are open about both their technology and their business model. They thus offer a reasonable guarantee that they can sustain their service and their technology, without basing that guarantee on the fact that they are a biggie like AWS, Microsoft, or Google (i.e., eating their own dog food, so we can join them at the trough).
The biggest cost in IT is not development or operating fees but reliance and opportunity.
Relevant code:
https://github.com/ldyeax/jimm.horse/blob/master/j/j.php
https://github.com/ldyeax/jimm.horse/blob/master/j/component...
The JS would be a bit more elegant if script tags didn't need special handling to execute on insertion.
The experience is very seamless this way - I'm very pleased with it. It's live at https://jimm.horse - the dynamic behavior can be found clicking on the cooking icon or N64 logo.
On reading the article, I'll definitely make use of this if it becomes well-supported. It does exactly what I wanted here.
The LivewView/Hotwire/LiveWire way of building applications make a really great tradeoff—the ease of building websites with the speed and power of webapp UX.
I wanted something simple to use with Express and it's been very productive.
There's a few things to get used to, but overall like it and plan to keep using it in my projects.
The build for the system took about 20 minutes, and part of the complexity was that every new task (form where somebody had to make a judgement) had to be built twice since both a front end and back end component had to be built so React was part of the problem and not part of the solution. Even in a production environment this split would have been a problem because a busy system with many users might still need a new task added from time to time (think AMZN's MTurk) and forcing people to reload the front end to work on a new task defies the whole reason for using React.
It all was a formula for getting a 20 person team to be spinning its wheels, struggling to meet customer requirements and keeping our recruiters busy replacing developers that were getting burnt out.
I've built several generations of my own train-and-filter system since then and the latest one is HTMX powered. Each task is written once on the back end. My "build" process is click the green button on the IDE and the server boots in a second or two. I can add a new task and be collecting data in 5-10 minutes in some cases, contrasted to the "several people struggling for 5 days" that was common with the old system. There certainly are UIs that would be hard to implement with HTMX, but for me HTMX makes it possible to replace the buttons a user can choose from when they click a button (implement decision trees), make a button get "clicked" when a user presses a keyboard button and many other UI refinements.
I can take advantage of all the widgets available in HTML 5 and also add data visualizations based on d3.js. As for speed, I'd say contemporary web frameworks are very much "blub"
http://www.paulgraham.com/avg.html
On my tablet via tailscale with my server on the wrong end of an ADSL connection I just made a judgement and timed the page reload in less than a second with my stopwatch. On the LAN the responsiveness is basically immediate, like using a desktop application (if the desktop application wasn't always going out to lunch and showing a spinner all the time.)
Is this really the future?
This approach has been implemented in most popular programming languages used for backend development: https://github.com/liveviews/liveviews
Using custom html attributes as the base for complex client-side interactions is arguably a step backwards when considering the story around maintenance.
Right now, if you are building a robust component library - it's much easier to maintain using a template language with strong Typescript / IDE support, like JSX or similar.
The more realistic and practical read is https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...
That said for my next hobby project I will probably go even simpler than HTMX, and use classic server side rendering. Then add some Vanilla JS where needed.
I keep going around in circles, but I have tried NextJS and while pretty cool there are a class of problems you need to deal with that simply don't exist in simpler apps.
> Working with HTMX has allowed me to leverage things I learned 15-20 years ago that still work, like my website.
Yes, a website is different than a webapp and has different requirements.
In a quote:
> "So much complexity in software comes from trying to make one thing do two things." - Ryan Singer (Basecamp/37Signals)
Okay, now you have half the code base, but need a round trip to the server for every interaction.
You could also remove the server and let people download your blog, where they can only post locally. No server-side input validation needed!
I’d really rather see strongly typed markup that can easily be checked for correctness and who’s behavior is well defined. Something Modular too with profiles and designed for extensibility.
At one point we experimented with the server returning the stuff to replace the HTML with. We support that in our framework natively (through a mechanism called “slots”).
That said, I have come to believe that people this decade will (and should) invert the idea of progressive enhancement to be client-first.
Imagine your site being composed of static files (eg served on Hypercore or IPFS via beaker browser). As more people use it, the swarm grows. No worries about being DDOSed. No having to trust a server to not send you the wrong interface one day. The software is yours. It just got delivered via a hypercore swarm or whatever, and your client checked the Merkle trees to prove it hasn’t been tampered with.
The you just interact eith a lot of headless web services. Rather than bearer tokens and cookies, you can use webauthn and web crypto to sign requests with private keys. You can do a lot more. And you store your data WHERE YOU WANT.
Sure, htmx can be used there. But there, too, it’s better to fetch JSON and interpret it on the client.
Returning markup language like HTML actually mixes data with presentation. Consider what happens when you want to return a lot of rows. With JSON, you return just the structured content. With HTML, there is a lot of boilerplate <li class=“foo” onclick=“…”> mixed in there which is a lot of extra weight on the wire.
If you are interested in learning more, I gave a whole talk about it:
https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
I don't get this. To use htmx one has to load 14 KB of gzipped JS. How does this make it easy to support clients that don't support JS?
Please just use the damn full-stack JS frameworks, they make life simpler, just wait for WebAssembly to allow us to have full-stack Rust/Go/whatever frameworks, and then you can abandon JavaScript, otherwise you get the mess of websites like this one where the developer has not written JavaScript, but the website still needs it for me to be able to read a _damn blog post_.
Otherwise, stick with RoR, Django, Laravel, or whatever ticks your fancies, but HTMX just ain't for everyone and everything, it's supposed to be used for hypermedia, not for web apps or anything else, just that: hypermedia.
And no, JavaScript libraries aren't all "complicated" and "full of churn", React is. Stop using React, or otherwise accept the nature of its development, and stop complaining. There are hundreds of different JavaScript libraries and yet every single time I see people bashing on full stack JavaScript they just keep repeating "React" like it's the only library in the world and the only way developers have written code for the last decade.
Also, tangentially related, can we as an industry stop acting like kids and stop following these "trends"? The author talks about a "SPA-craze" but what I've been seeing more and more now is the contrary movement, however it's based on the same idea of a hype cycle, with developers adopting technology because it's cool or whatever and not really considering what are their actual needs and which tools will provide them with that.
Rant over.
The one single strong point of the front/back split is the famous Strangler Fig Pattern which takes away a lot of stress when making decisions.
* NextJS provide a holistic solution to backend code. Right now it's missing an ORM that works with serverless postgres. Given their recent additions of serverless postgres to Vercel I expect this will happen in 6-12 months.
* RedwoodJS become more mature.
The issues with SPAs IMO come from having to cobble together your full stack app, which requires making a ton of hard decisions in predicting the future of each major library you use. And then there's limited coherence between your ORM, API, and client without extra work. A mature, well designed, and financially supported full stack JS solution that truly rivals Rails would be perfect.
Having a separation of concerns between server and client is the whole point, and replacing JSON APIs with data trapped in HTML fragments is a massive step backwards.
>Here we are getting a bit fancy and only allowing one row at a time to be edited, using hyperscript. https://hyperscript.org
it does not work for resource restricted (i.e. embedded) devices where you just can't do server-side rendering, CSR SPA is the future there as the device side just need return some json data for browser to render.
You have to learn something. You can claim bloat in JS frameworks, but that isn’t solved by simply moving it to the server.
Is htmx lean and nice today? Probably! But does it handle the same use cases that the React users have? What happens to it under pressure of feature bloat? Small-core frameworks like Elm who resisted this pressure were abandoned by big shops. You can’t just take something immature (however good) and simply extrapolate a happy future.
> Tooling is an ever-shifting landscape in terms of building and packaging code.
Yes. JS is not the only language with churn issues and dependency hell.
> Managing state on both the client and server
Correct me if I’m wrong, but state can change for something outside of a htmx request, meaning you can end up with stale state in element Y in the client after refreshing element X. The difference is that your local cache is in the DOM tree instead of a JS object.
> By their nature, a fat client requires the client to execute a lot of JavaScript. If you have modern hardware, this is fine, but these applications will be unusable & slow for those on older hardware or in locations with slow and unreliable internet connections.
On unreliable connections you want as thick of a client as possible. If you have server-in-the-loop for UI updates, you quite obviously have latency/retry issues. It’s much preferable to show stale state immediately and update in the background.
> It is very easy to make an SPA incorrectly, where you need to use the right approach with hooks to avoid ending up with abysmal client-side performance.
Bloat comes from reckless software development practices, and are possible in any technology. Angular and React have a shitton of features and ecosystem around it, whereas say Svelte is more lean. Enterprisey shops tend to prioritize features and not give a flying fuck about performance. This is a business choice, not a statement about technology.
> Some SPA implementations of SPA throw away progressive enhancement (a notable and noble exception is Remix). Therefore, you must have JavaScript turned on for most SPAs.
Finally, we cut to the chase. This is 100% true, and we should be talking about this, because it’s still not settled: do we want web pages or web apps? If both, where is the line? Can you expect something like Slack to work without JavaScript? What about a blog with interactive graphs? Should everything degrade or should some things require JS/WASM?
I love that htmx exists. I have absolutely nothing against it. It honors some of the early web philosophy in an elegant and simple manner. It may be a better model for server-centric apps and pages, which don’t need offline or snappy UIs. But it cannot magically solve the inherent complexities of many modern web apps.
Two years ago I distinctly remember server side rendering piped thru websocket was future.
I also like how demo is visibly ugly, jQuery-style ugly. It's nostalgic in a way. And I swear to gods this approach will break back button. And resending form after network error. And expired cookie will of course result in your input being lost.