> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks.
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.
> 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?
BINGO. At times, it seems everyone is talking through each other because we are thinking of different things: static pages, dynamic websites, web apps, etc. all require different approaches to development. Honestly, what gets me real mad is when you need to run JavaScript to see a static page, I just can't stand it, one lovely example is the blog post we are talking about which displays awful without running JavaScript, this proves that indeed HTMX is not a panacea, and you can also "hold it wrong" (the blog post in question uses HTMX in the backend).
Overall, I believe most applications do well with a graceful degradation approach similar to what Remix offers and then everyone copied (the idea of using form actions webforms-style for every interactivity, so it works with and without JavaScript). I do agree that things like Slack, Discord, Element, or otherwise things we would call web apps are acceptable to be purely SPAs or not gracefully degrade without it enabled, the biggest problem I have with these is that they exist as web clients in the first place: the world would be a different place if approaches such as wxWidgets has paid off and gotten adopted, imagine how many slow and bloated web apps could've been beautiful and fast native applications. One can dream. I'm not that pessimistic, not yet.
> BINGO. At times, it seems everyone is talking through each other because we are thinking of different things
Glad to hear. Yes, it seems like the post and the comments are largely missing the functional issue at play.
> the blog post we are talking about which displays awful without running JavaScript
Yeah, case in point, perhaps.. I mean if you have two paths (incremental and full) to reach the same state, you better be careful to ensure those are functionally equivalent. This is surface are for bugs, so the very least you need to do is turn off JS and test all flows. To me, the value add of SPAs is the snappy UI, and offline-capabilities, so if you’re gonna roundtrip to the server anyway, then you may as well just re-render the entire page old-school to greatly reduce complexity.
> the biggest problem I have with these is that they exist as web clients in the first place: the world would be a different place if approaches such as wxWidgets has paid off and gotten adopted, imagine how many slow and bloated web apps could've been beautiful and fast native applications.
I actually disagree with this (the opinion, not the problem statement). The main players, Apple, Microsoft, Google, have known about the cross-platform issues and haven’t done jack in decades (perhaps flutter deserves an honorary mention though). Meanwhile, the web, with all its problems, have gotten so much better. Getting the web to the point of native standards seems much more feasible than establishing new open standards for app development. The bloat issue is largely a red herring imo. A well made web app is snappy, and importantly, can be sandboxed. The issue is that people don’t care. You can find equally shitty and bloated apps in the sea of crap on the app stores. With webview support in the OS, bundles can be small. I have an app based on Tauri which is web based, and the msi is 10Mb. It’s never had any perf issues.
> I have an app based on Tauri which is web based, and the msi is 10Mb. It’s never had any perf issues.
And that's on the heavy side! Tauri is awesome, it's unfortunate most developers opt for Electron to reduce the amount of testing needed between browser engines.
I agree with you that a well-made web app is snappy and works well. I don't think we'll go back to native apps (for now), what I hope for is simply that it could become an _option_ as right now it's just basically trying to swim upstream.
Web apps do a lot of things really well that native applications always had difficulty with, such as accessibility and distribution. Still, I feel that even when doing web apps that are snappy they miss out on some cool features of native applications such as consistent theming, reduced memory usage, reduced CPU usage (regardless of how well the web app is written), and just the simplicity of it.
Perhaps the ship has already sailed, and native applications will never make a comeback, in which case I hope lighter weight engines purpose-made for web applications get adopted as an alternative to shipping the entirety of Chromium with each program I download. Projects like Servo [0] show me that's possible, it's just that there is currently no interest from the big players to keep funding these developments and provide them as an alternative to Chromium.
> And that's on the heavy side! Tauri is awesome, it's unfortunate most developers opt for Electron to reduce the amount of testing needed between browser engines.
The browser engine differences isn’t that big of a deal, because you already have standard ways of dealing with it on the web. I think today the main reasons people pick Electron today are tooling, desktop integration features and Node. Tauri is catching up insanely fast though. I am very happy that I jumped on the bandwagon fairly early.
> in which case I hope lighter weight engines purpose-made for web applications get adopted as an alternative to shipping the entirety of Chromium with each program I download
Absolutely, shipping a browser engine is insanity and should always have been a stopgap at best imo. Even servo is way too heavyweight to ship with each app. Good news is with OS having native webviews we’re 80-95% there already, so we don’t even have to deal with that tradeoff – this let’s an app have a perf overhead of ~1 typical browser tab. It’ll take a moment to iron out all kinks but it’s already perfectly acceptable on most deployment targets. Honestly, Linux is just as bad when it comes to distribution. Distros have been in some perpetual siloing mindset and have not been able to get behind a decent and unified distribution story. It has nothing to do with web though.
> it's just that there is currently no interest from the big players to keep funding these developments
The big players have been so awful that even if you disregard the abysmal interop story, distributing native apps is still orders of magnitude more hassle than the web ecosystem. Imo Electron was born as an escape hatch from that disaster, not because frontend developers conspired to eat all the worlds RAM for fun. I absolutely agree that the big players should passively fund projects like servo and tauri. I don’t want them anywhere near strategic decision making though.
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.