I'm very much of the opinion that progressive enhancement leads to lowest common denominator and you should just do a static MPA (nothing wrong with that). Modern browsers are a combination of HTML+CSS+JS and you should just embrace that as what modern hypermedia is. We aren't fighting against the browser. If you want just links and forms, you should just do that and have less code to maintain. But in my experience that's not what most are looking for in their apps.
> But in my experience that's not what most are looking for in their apps.
What are they looking for (in your experience)?
In my experience, most people use an app (website) to solve some problem (buy something, pay taxes, whatever). They care more about functionality than how smooth the loading animation and transition was. Progressive enhancement seems like a very good way to build something people actually use (and rely on).
Progressive enhancement is about accommodating JS being disabled. You have missed, in your description of what users care about, anything about disabling JS. Having JS disabled is a preference observable among Opinion Havers which crawl out of the woodwork on HN, but not observable among your target audience, even when your target audience is mostly HN.
Progressive enhancement isn't about supporting the minority of users that disable JavaScript. It's about sound engineering and building a robust system that is tolerant to errors. A system that can fail gracefully.
There's nothing wrong with using JavaScript. There's nothing wrong with depending on JavaScript for specific functionality. However, I don't think it's acceptable to completely break down if that JavaScript fails to load.
With SPAs and "modern" web development practices, it's all or nothing. Either everything works, or nothing works.
Have you ever given an iota of thought to how your website looks when the CSS doesn't load? Contemplated arranging elements into `<table>`s to preserve some semblance of formatting, crammed some truly necessary styling into `style=`? If not, then the users that disable JS are the primary driver of thinking about how your website looks when the JS doesn't load; any two given files are about equally likely to not load, JS isn't privileged here compared to CSS (and is much harder to gracefully handle its absence).
I do a fair amount of thinking around all failure states (CSS included).
I think you may be overthinking the appearance aspect of a failure state. The application doesn't need to look the same when CSS fails to load. However, the application should be functional.
This thinking carries over to the backend as well. My application server doesn't require all services to be up and running. Instead, it's able to query and tell what is working and what isn't. That information is then bubbled down to the UI in one way or another. That may mean certain functionality is unavailable (ex, if solr isn't reachable then search is disabled).
My impression is people really like frameworks because they all ultimately end up with a plugin system. Then the use of the "the framework" really just becomes "gluing a bunch of plugins together."
I've never liked where those code bases ultimately end up, which seems to be just a twisted maze of hacky solutions to make a bunch of poorly aligned code to work together.
I'm am not of that opinion at all. I'm all about optimization but then people will say "that's not how web pages are made". Can't win opinions but can say, Datastar is not the bottleneck. You send as much, as often as you choose.
I agree! That's kinda the point with Datastar. EVERYTHING is a plugin, the core is a < 300 LOC engine for parsing data-* attributes and making available to plugins. You can pick and choose what makes sense for you. If you want to have declarative spec compliant interfaces, it can't get any smaller from what I've seen in the wild. Happy to get help to shrink it even more!
UPDATE: I have no idea why fly.io hate the TODO, but https://example.andersmurphy.com/ is a decent example (that's way more fun) that's running now. I'm commenting out that demo until I have more time to investigate. If y'all find other ones that are acting up please let me know. Looks likes it might be time to actual host this thing on a real server.
It's a DOM render stress test. It's trying to show the network is not the bottleneck. TL;DR do this in React or any other framework compared to a one time tiny shim and see if you get better results.
Yeah something is DEFINITELY up. This is not the norm, we haven't seen this before. Fly.io free tier is not happy and I'm not sure why (we've been on it for years at this point). I'm gonna disable until I can dig deeper. Have day job stuff to attend to, this is not my ideal Friday afternoon :P
If you're on shared CPU you probably got throttled. Dig into the grafana dashboard and you'll see it somewhere...it's not nearly prominent enough in their UI.
I think, at least as the creator, I've seen the "fight" be MPA vs SPA. IMO, both are wrong. It's about state management. MOST state lives in the backend but you still need fine grain reactivity on the frontend. On the number line between React and HTMX; Datastar is complex :)
Data may live in the backend, but it is used more in the frontend. Having it local (in memory, or even indexeddb) makes more responsive apps, especially if it's a typical CRUD app with 70/30 or more split between reads/writes.
Where the data is used most will vary by app. Some applications are really heavy in the backend, dealing with integrations to other systems, file processing, etc. and the UI is for setting up all that processing, some workflows and business logic.
We'll just have to disagree here. The browser is REALLY smart about caching and no amount of JS localStorage is gonna match proper E-Tags and CDNs. If it's dynamic content your point is moot anyways.
Its possible to run the datastar TS/JS SDK in a service worker, if you want to do (isomorphic with the backend) templating from there or just returning pre-cached html fragments.
Datastar is fully plugin based. If you don't like my take on SSE, cool let's talk. The core is just making data-* attribute into reactive expressions, everything else is a plugin by design. I want it to be OK for me to be wrong without losing the declarative approach
Did you mean to respond to another comment? Because I'm not following either the relevance or tone of your comment.
The parent comment wanted a way to "serve" requests on the client device, so I suggested a way to do that that is also compatible with normal d* usage...
How to get the data to the client and keep it in sync is an entirely other problem that they'd face with any framework/approach. Would be foolish for some applications and perfectly possible for others. Offline/local-first apps are getting considerable attention these days, for good reason.
I'm a big fan and cheerleader of everything you've done. Keep up the great work.
