[dmix]

The obsession with DX tooling is exactly why JS is such an awful developer experience. They always chase something slightly better and constantly change things.

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.

[pier25]

> The obsession with DX tooling is exactly why JS is such an awful developer experience.

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.

[ToucanLoucan]

> I used to agree but these days with Vite things are a lot smoother.

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

[petre]

Except you can't really build PWAs with those technologies and most web content is now consumed on mobile. I used to do it like that as well, but clients want a mobile app and management decided to give them a PWA, because then we could use the existing backend (Perl, Mojolicious, SQL). I now agree with them if it keeps the lights on.

[jjani]

> I used to do it like that as well, but clients want a mobile app and management decided to give them a PWA

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?

[ivan_gammel]

People outside tech just get installation instructions and do not care if it’s app store or something else. This is how sanctioned Russian banks continue to serve their customers via apps, when they cannot get into app store. The number of users of PWA is probably on the scale of millions.

[jjani]

I had no idea! Cool to learn.

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.

[pjmlp]

For me the whole worker setup filtering requests and storing results on local storage, looks like gimmicks.

They should have designed it as a proper native experience.

[petre]

They don't want to be subject to app store approval policies, shitty TOS, nor pay Google or Apple a 30% cut. Installing the app is easy, visit the web site, clck the install banner, add to home screen and you're good to go. On the developer side you get to deploy as iften as needed.

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.

[pjmlp]

Just focus on being mobile friendly, hardly anyone cares about PWAs and the crazy setup of JavaScript workers to make it work.

[dmix]

> 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.

[pier25]

> Rails has a library that will refresh the page when files change without a full reload

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.

[timr]

> What if you have a modal opened with some state?

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.

[pier25]

> Stimulus controllers can store state.

Yes, obviously, but do these maintain state after hot reload?

[timr]

We're talking about two entirely different things that lead to the same outcome. The approach we're describing is not a "hot reload" per se, it's just selectively updating the changed contents of the page. For the vast majority of the changes you do during development, this is invisible to you.

If you change the JS or the controller itself, obviously, state stored in JS would be lost unless you persisted it locally somehow.

[ivan_gammel]

Eh, I recently stumbled into an open bug in Npm/vite and wasted two days before just reinstalling everything and re-creating frontend app. Hot UI reloads are cool, but such things kill any productivity improvements.

[ezekiel68]

>To the point that I wouldn't want to work on UI without fine-grained hot reloads.

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.

[qudat]

Hmm, JS is "different" because it has completely unique challenges that no other programming language has to deal with: https://bower.sh/my-love-letter-to-front-end-web-development

[jimbob45]

There’s just no way for the abominations that are HTML, JS, and CSS to be used in an accessible and maintainable way. It’s absurd that we haven’t moved on to better technologies in the browser or at least enabled alternatives (I weep for Silverlight).

[hirvi74]

> (I weep for Silverlight).

'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?