3 ms·
> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks. You have t
by klabb3 4y ago
> 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.
- doodlesdev 4y ago> 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.
- klabb3 4y ago> 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.