My personal pet-peeve everytime a "you don't need JS" post comes up on HN, is the disconnect between the interface designers and the developers. In my dayjob as a (mostly react) freelance contractor doing B2B and LoB apps, there are always UX designers coming up with the screen- and interface designs. I don't think any project I ever were, could have matched a screen design I was passed without JS. Whether it being business requirements (has to work in IE, or nowadays has to work in Edge), or simply hard visual design choices.
My favorite example is that of a date, date-time or date-range picker. Yes, there are HTML native elements. But they look absolutely ugly, styling only goes so far, and good luck with requirements such as "oh, but in the popup on the date-range picker, add a topbar with 3 buttons that trigger preselection and a dropdown". Now you can argue and communicate back that we save a lot of technical complexity in the stack if we stick to the HTML native solutions. But all those discussions basically end up managers and UX designers having no clue about the actual complexity and savings (time and money wise for future maintenance) and simply don't care.
And if I am the one telling them "Look, in the HTML native date-time picker, you can't add custom elements, you can't fully customize every bit and piece of behaviour so change the screen designs" they will just fire up random corporate website XYZ and show a similar version of what they have in mind (and it is always JS-based) and suddenly it looks like me being unable or unskilled to achieve something, that is clearly doable as others have done it.
Now not all is nice and shiny in the JS/React world. We use MaterialUI in a current project, and the commercial MUI-X DatePickers. They also come with their limitations, but it is just they are far more powerfull and customizable to actually meet the requirements and demands of UX and management, compared to the HTML versions.
My favorite example is that of a date, date-time or date-range picker. Yes, there are HTML native elements. But they look absolutely ugly, styling only goes so far, and good luck with requirements such as "oh, but in the popup on the date-range picker, add a topbar with 3 buttons that trigger preselection and a dropdown". Now you can argue and communicate back that we save a lot of technical complexity in the stack if we stick to the HTML native solutions. But all those discussions basically end up managers and UX designers having no clue about the actual complexity and savings (time and money wise for future maintenance) and simply don't care.
And if I am the one telling them "Look, in the HTML native date-time picker, you can't add custom elements, you can't fully customize every bit and piece of behaviour so change the screen designs" they will just fire up random corporate website XYZ and show a similar version of what they have in mind (and it is always JS-based) and suddenly it looks like me being unable or unskilled to achieve something, that is clearly doable as others have done it.
Now not all is nice and shiny in the JS/React world. We use MaterialUI in a current project, and the commercial MUI-X DatePickers. They also come with their limitations, but it is just they are far more powerfull and customizable to actually meet the requirements and demands of UX and management, compared to the HTML versions.