> And, contra what Mr. Harris says, today the trend is not obviously in javascripts favor. Five years ago, we, as founding members of the javascript resistance, were despairing of any hope of stopping the Javascript juggernaut. But then something unexpected happened: Python took off and, at the same time, javascript flat lined:<p>Why yes... if you use Stack Overflow usage as your measurement.<p>The problem is that doesn't tell you anything about JavaScript or Python... except whom is using Stack Overflow.<p>As a JavaScript developer (primarily), I use Stack Overflow far less than I did in years past, not just because I need less help in general as a senior, but because SO is so littered with JS answers that are outdated, poor quality, and conflate JavaScript with <i>jQuery</i>, that it's simply not worth using 99% of the time because MDN provides excellent documentation.<p>It's been a while since I've used Python, so maybe things have changed, but I remember the documentation not being comparable. It's <i>good</i> documentation, but MDN is <i>excellent</i>.<p>I'm not saying that either one is better, but that to use Stack Overflow trends to prove a point seems very fallacious. By that point I couldn't finish the rest of the article.
Anyone who claims one language or tech stack is going to become the be-all, end-all of how we build things on the web is either naive or selling something.<p>I've gotten a lot of mileage out of ignoring grandstanders and focusing my time and energy on learning how browsers work. If you understand the DOM, CSS and core JavaScript fundamentals, you can apply your skills to virtually any front-end stack.<p>In the end, the thing that hurts the web the most is complexity in the name of DX. We are tricked into thinking that the simple thing is too hard to learn on the one hand, while being asked to juggle multiple layers of "sophisticated" abstraction on the other. These days there are entire businesses rising on the need to reduce the cognitive load created by our layers of sophisticated abstraction. But, I bring you the good word: you can still build incredible experiences without pulling in most of the complexity (and without sacrificing as much DX as you think).
hello, I am the author of this article<p>it is a response to a talk that Mr. Harris gave at JamStack entitled "Have Single-Page Applications Ruined the Web?":<p><a href="https://www.youtube.com/watch?v=860d8usGC0o" rel="nofollow">https://www.youtube.com/watch?v=860d8usGC0o</a><p>in the article I show how a hypermedia-oriented (rather than javascript-oriented) library like htmx can address many of the usability concerns that Mr. Harris raises with MPAs, without abandoning the fundamental REST-ful architecture of the web for a more RPC-like javascript architecture.
One misconception about Hypermedia-driven applications is the belief that you can't / shouldn't use JS or other new technologies. You can create a Cloudflare Worker returning HTML[0], which you can call using HTMX in the frontend.<p>Using HTML to drive an app's interface has nothing to do with the tech stack, in fact, I think it opens the door to a more diverse tech stack. Optimistic UI updates, state management, and other "modern" JS techniques are cool, but often, the complexity is not worth it.<p>Also, let's not forget that web browsers are already good at taking HTML/CSS and showing it in your screen. Somehow, we decided it was better to make all your users waste CPU cycles to do the same with Javascript and a Virtual DOM (but only after 10MB of JS files have finished downloading)<p>[0] <a href="https://developers.cloudflare.com/workers/examples/return-html" rel="nofollow">https://developers.cloudflare.com/workers/examples/return-ht...</a>
This is absolutely the right approach for building web sites IMO. It's the best mix of whatever-server-you-want-to-use and minimal JS on the client.<p>I built my own (proprietary for my employer) general-purpose AJAX etc framework that uses minimal javascript to produce flexible, interactive web sites with 1/100 the bulk of React. It even degrades gracefully for clients that don't run JS. But I'm tired of maintaining it. HTMLX looks like an even better approach because it doesn't seem to require me to add explicit event handlers all over the place and it's open source so I won't be the sole maintainer.<p>Looking forward to evaluating HTMLX as a replacement for my stuff.
contrary to most of the comments I'm in full agreement with the hypermedia approach.
This is an exciting development, especially with hyperscript!<p>I actually attempted to make a "simplified" "js" framework (where you just had some html tags and it did things for you) for tasks congruent to alpine (since I found alpine rather complex, or that it comes with so much but you still have to do a good amount of work to get things working) but I'm not as savvy; using the DSL you all have in hyperscript is real smart, simple.<p>Not too long ago I looked into using Svelte for a one-off project (since it was the highest rated framework at the time) which then prompted me to look into the current state of web development.<p>It's absurd, and left such a sour taste that I just shelved the project for another time.<p>Great stuff you guys got going here, it makes me excited to see what'll turn into in the future!
Looking forward to trying this out later.
God, I am so tired of these arguments. We need to stop bike-shedding web technology. You will never, ever convince me to go back to server-side rendering for the type of work I do. Are there other domains where that would be the wrong choice? Absolutely.<p>The web is a platform and we should not treat these tools as one-size-fits-all. Use the tools that fit your use case; there's no use in talking about the how without the why.
I'm not sure these are actual problems (other than JS tooling, which I find opaque.) Instagram works just fine for the vast majority of people. It's taken as gospel that Javascript frameworks are "bloated" but 1) is this really true; and 2) if true does this really matter if the page loads fast enough? React is only 5.3kB and gives a very simple model for reasoning about code. Making code smaller or faster has a cost.<p>I'll also note that htmx is making a programming language, but they don't seem to understand they are making a programming language, and that usually ends up a disaster. See all the YAML stuff in the devops world.
Having written SPAs in multiple frameworks over the years, I am finally starting to favour the author's perspective.<p>That said, the one criticism I can lob is toward the assumption that JavaScript / TypeScript will be the only path for SPAs, creating a full-stack monoculture. Web Assembly is on its way to negating this point long term.<p>I don't think this affects the position on MPAs, but weakens that one particular argument against SPAs.
We also have to accept that some dynamic page problems are completely unsolvable or have horrible solutions.<p>For instance, with infinite scroll - I spend 10 minutes scrolling down through 7000 rows, with all but the first few loaded dynamically.<p>I now want to send what I'm looking at to a friend. Or I want to bookmark it. Sure, I can have my app put the scrollposition in an anchor tag in the URL, but what happens when that URI is navigated to? Whatever solution you pick, it is horrid.
I like the potential for sending minimal document elements/objects, though it seems like HTMX/Intercooler/Unpoly features should be built into the browser. Unpoly, for example, has its own entire reimplementation of fetch():<p><a href="https://github.com/unpoly/unpoly/blob/4854c7ccb268890a9522c68d4b60951cf1bd0c58/src/unpoly/network.js" rel="nofollow">https://github.com/unpoly/unpoly/blob/4854c7ccb268890a9522c6...</a><p>and it uses several X-HTTP-Headers, which could be standardized.<p>Do any browsers have the early workings of a "native web application sdk"?
I'm sorry but what's the point here? Rich's talk was not even remotely aimed at HTMX yet this article is nothing but a shameless list of HTMX features.
I dont think it has to be all or nothing. I think the best answer is to use both technologies as appropriate even in the same app.<p>I was writing something like htmx without intercooler with Angular with Django (which I fondly called Djangular) in 2013.<p>It just needed yet another framework type abstraction to reduce the boiler plate.<p>Send json with the html on initial page load, use the json api to load addition data, hard navigate between "sections" of the app but tabs and such were SPA pattern.<p>I think a middle ground combo of svelte and htmx is a killer idea (similar to all the "live view" stuff people are loving).
SPAs are fundamentally flawed. I am making a webapp with lots of images and media resources to download, when the user click to another page, the media on the previous page are being still downloading in the background and choked the 6 connection limit. To avoid this I have to encapsulate the download queue to each "page" manually.<p>Another issue is how browser cache 404, for SPA app, the "known" routes are stored in main.js rendered in browser, the nginx doesn't know which page is not defined, so every page is 200 and then rendered 404 in browser only, the browser would still cache the "wrong" 404 page because nginx has to serve index.html with main.js as 200 first.
I watched the Jamstack talk and I dont think Rich quite grasp why some people are against SPA.<p>The first thing being, 95% of what I do on the web doesn't need to be an SPA. Most of what I do is content consumption. HN doesn't need to be SPA. NewsReading doesn't need to be an SPA.<p>The second thing being once you allowed developers of SPA, and break free of the browser default usage pattern, there are very few SPA I have used that I even considered to be decent. Actually there is only one, Feedly. And yes, as pointed out in the video, even instagram cant do the basic right. Not Facebook web, and not Twitter. Look at new Reddit.<p>The problem with SPA is once you try to make a Web App, aka Reddit, I will instantly try to compare it with a Native App. And I have yet to see a single decent Web App that compares to "<i>average</i>" native app. It is far easier to make a very decent MPA with added magic like HTMX or Hotwire than a decent SPA.<p>The third being transitional design. Which is a compromise or taking best of both worlds. Interestingly HTMX or Hotwire are also considered as Transitional, since they try to make the those web page that needs a little more interactively without switching to SPA.<p>There are some things that are better for SPA, so far most them for me tends to be financial tools and graph based.<p>One argument for SPA is that your backend is just an API, your front end could now work not only in browser but even compiled natively into Apps. But so far none of them worked flawlessly across all platform without a team of expert.<p>And for simplicity, PHP is still by far the best in modern web backend tool kit. I am not advocating for PHP, I hate the syntax but other than that it is dead simple to use and set up. Considering both Hotwire / HTMX with Django and SPA camp with Svelte just shows how little the vocal web developer community value simplicity.
HOWl is a good idea.. either it will catch on and make web development fun again, or it will at least force the JS ecosystem to wake up and fix its terrible tooling and bloat.
Doesn't using something like hx-preserve effectively make it an SPA? It makes an AJAX request and replaces part of the DOM. What's the difference?
I think they're overlooking a very big issue which is trying to do any sort of business logic in a markup language is terrible. HTML is good for presentation, trying to embed logic like retrying requests in it can lead to weird code. The reason people like Javascript is having a fully C-style language for things makes logic easier to read and maintain.
I don't understand how you could do complex logic using this way. Is it possible and easy to say have multiple form elements share validation logic? It definitely looks great in many ways but I'm unsure how I wouldn't need to use a more complex framework like Svelte eventually anyway.
Regular server/client beats SPA because each request starts with an empty state, whereas SPAs build up bugs as they try and fail for mutate state over time.<p>What about an SPA that made internal requests to a server backend, running in the browser?
> CPU is cheap, network speeds are fast and increasing and microservices are a mess.<p>Is CPU cheap? I can literally host a static site or SPA on GitHub Pages for free. Where can I get free CPU time for an htmlx application?
So, does KnockoutJs[0] represent the "transitional applications" framework as described in the article?<p>[0] <a href="https://knockoutjs.com" rel="nofollow">https://knockoutjs.com</a>
I’m confused here: htmx is not an MPA. If it were, then you’d call a SSR React site a MPA too.<p>The core behavior of a SPA is that it loads pages via ajax and just replaces content in the current “document”. The difference between a simple SSR React site and this is that React will only fetch JSON and templates after the first load, whereas this one fetches whole chunks of HTML.<p>An htmx site still has to deal with all the pitfalls of SPAs, namely non-native navigation and history, and memory leaks.<p>Just like htmx may have solved some of these issues, a (other framework) SPA can do too.
I don't mean to belittle anyone, but libraries like htmx are rather primitive compared to tools like svelte. What makes them see themselves so important?
So if 5MB is considered large, why don't we just go back to instructing people to download all of Java or .NET to get the app needed to control their home (real), or generate a temp credit card number (real), designing a home (real).<p>I'm not saying that all sites need to migrate to SPAs but there is a HUGE market segment that has been replaced with a React SPA over custom apps that had to be downloaded. And now those same SPAs work in your phone and your computer.<p>HTML POST REDIRECT HTML is dead, get over it.