3 ms·

> 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

by pier25 2y ago

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

ivan_gammel 2y ago
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.
dmix 2y ago
> 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 2y ago
  > 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 2y ago
    > 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 1y ago
      > Stimulus controllers can store state. Yes, obviously, but do these maintain state after hot reload?
      - timr 1y ago
        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.
ezekiel68 2y ago
>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.
ToucanLoucan 2y ago
> 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 2y ago
  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 2y ago
    > 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?
    - pjmlp 2y ago
      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 2y ago

by pier25 2y ago

ivan_gammel 2y ago

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.

dmix 2y ago

> 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 2y ago
> 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 2y ago
  > 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 1y ago
    > Stimulus controllers can store state. Yes, obviously, but do these maintain state after hot reload?
    - timr 1y ago
      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.

ezekiel68 2y ago

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

ToucanLoucan 2y ago

> 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 2y ago
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 2y ago
  > 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?
  - pjmlp 2y ago
    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 2y ago