Maybe the answer was never in JS eating the entire frontend, and changing the tooling won’t make it better, as it’s always skirting what’s actually good for the web.
I used to agree but these days with Vite things are a lot smoother. To the point that I wouldn't want to work on UI without fine-grained hot reloads.
Even with auto reload in PHP, .NET, etc you will be wasting so much time. Especially if you're working on something that requires interaction with the page that you will be repeating over and over again.
That’s honestly not that many things IRL. If you look at all the things you build only a minority actual demand high interactivity, or highly custom JS. Otherwise existing UI libraries cover the bulk of what people actually need to do on the internet (ie, not just whatever overly fancy original idea the designers think is needed for your special product idea).
It’s mostly just dropdowns and text and tables etc.
Once you try moving away from all of that and questioning if you need it at every step you’ll realize you really don’t.
It should be server driven web by default with a splattering of high functionality islands of JS. That’s what rails figured out after changing the frontend back and forth.
> Even with auto reload in PHP, .NET, etc you will be wasting so much time
Rails has a library that will refresh the page when files change without a full reload, using Turbo/Hotwire. Not quite HMR but it’s not massively different if your page isn’t a giant pile of JS, and loads quickly already.
What if you have a modal opened with some state?
Or a form filled with data?
Or some multi-selection in a list of items that triggers a menu of actions on those items?
Etc.
And it's true Vite can't always do HMR but it's still better than the alternative.
Stimulus controllers can store state.
> Or a form filled with data?
Again, you can either use a Stimulus controller, or you can just render the data into the form response, depending on the situation.
> Or some multi-selection in a list of items that triggers a menu of actions on those items?
So, submenus? Again, you can either do it in a Stimulus controller (you can even trivially do things like provide a new submenu on the fly via Turbo), or you can pre-render the entire menu tree server-side and update just the portion that changes.
None of these are complex examples.
Yes, obviously, but do these maintain state after hot reload?
If you change the JS or the controller itself, obviously, state stored in JS would be lost unless you persisted it locally somehow.
No -- but you could. And it wouldn't be the end of the world. So I'm just saying, DX doesn't eclipse all other considerations.
Didn't everybody say the exact same thing about Node, React, jQuery...? There is always a new and shiny frontend JS solution that will make the web dev of old obsolete and everyone loves it because it's new and shiny, and then a fresh crop of devs graduates school, the new shiny solution is now old and boring, and like a developer with untreated ADHD, they set out to fix the situation with a new frontend framework, still written in JavaScript, that will solve it once and for all.
I still build websites now the same as I did when I graduated in 2013. PHP, SQL, and native, boring JavaScript where required. My web apps are snappy and responsive, no loading bars or never-ending-spinning emblems in sight. shrug
I'm quite surprised to hear this is a common thing. Besides myself, I don't know a single person who has ever installed a PWA. For people in tech, despite knowing they exist. For people outside tech, they don't know they exist in the first place.
Does management actually have any PWAs installed themselves?
They should have designed it as a proper native experience.
Yes, the service worker thing is annoying but you possibly don't need it if you have a server backend. It's basically a glirified website with a home screen icon. Most of the native vehicle, asset or fitness tracking apps need a backend anyways and they fail miserably when disconnected from the network.
Better do a mobile Web friendly website and leave it at that.
Most users hardly tell the difference anyway.
And the metrics are saying that people click it?
It definitely makes complete sense in that scenario, but remains a very niche usecase where people have no other option.
>People outside tech just get installation instructions
People outside of tech don't need instructions to install non-PWA, store apps. So all this does to me is reinforce that no one is installing PWAs outside of niche scenarios where 1. people basically have to use the app due to a connection to a physical institution 2. they are explicitly told how to do it 3. the app is not available on the stores for legal reasons.
Depends on age and tech awareness. Many still do, when they cannot rely on a family member to do it for them. Overall installing PWA is no more complicated than getting something from a store.
'Twas before my time. What was so great about it? I remember needing it installed for Netflix like 15 years ago. Did you ever work with Flash? How was that?