As I mentioned in my comment, JS frameworks by adopting a reactive model are getting closer to how desktops apps function. That has always been the goal, making interactivity as capable and flexible as 'native' desktop software while still remaining consistent, accessible, and cross-platform in the browser.
One of the biggest motivations of these JS frameworks early on was due to the adoption of smartphones becoming the primary computer interactions. The other was the SaaS model, creating far greater demands on what needs to be done in a web form.
I've developed VB and cross-platform stuff like Qt and wxWidgets, and that stuff is no easier than the stuff I'm building with JS every day. HTML templates + automatic reactive bindings via Vue and a Redux/Vuex 'backend' are very simple.
What's more complicated and still shitty with JS frontends is the wider frameworks with Webpack, that come with a hundred packages that break often. That is the most painful thing I have to deal with day-to-day. The learning curve once you add in Babel, PostCSS, the various code optimizers and linters, TypeScript, etc can be quite intimidating.
But that has more to do with the tooling than the general approach being taken in modern frontend development.
Re: As I mentioned in my comment, JS frameworks by adopting a reactive model are getting closer to how desktops apps function. That has always been the goal
And they keep failing because they throw layers at the problem: chicken-wire is used to fix problems caused by the duct-tape on the prior layer, etc.
It's becoming pretty obvious that Yet-More-Layers only exacerbates the problem. It may get "solved" by having fewer browser choices, but then the evil of oligopolies will kick in and we'll be back to the IE-esque problems, one of the most hated browsers.
Re: I've developed VB and cross-platform stuff like Qt and wxWidgets, and that stuff is no easier than the stuff I'm building with JS every day. HTML templates + automatic reactive bindings via Vue and a Redux/Vuex 'backend' are very simple.
My experience is different, and I observe similar bottlenecks at various orgs. Those JS-centric frameworks are harder to trouble-shoot when things go wrong, and different browser brands/versions render them different and/or wrong. With the VB/Delphi-esque tools, things show up exactly on the screen where I tell them to go: there is no if, ands, and buts. They follow my exact commands like dutiful robots. The technology is MY slave instead of the other way around: Thou Shalt Go At X=37 and Y=200. My Will Be Done! (Cue thunder clap.) React/Vue et. al. often go, "Sorry Dave, I cannot do that, but I'll do it my way anyhow." (I recommend GUI's use vectors instead of pixels these days, by the way. They are potentially equivalent when needed.)
Further, the quirks in pre-web GUI tools were getting ironed out over time: they got better with age. The web seems to get messier with age because of the layer-to-fix-layer problem above.
One of the biggest motivations of these JS frameworks early on was due to the adoption of smartphones becoming the primary computer interactions. The other was the SaaS model, creating far greater demands on what needs to be done in a web form.
I've developed VB and cross-platform stuff like Qt and wxWidgets, and that stuff is no easier than the stuff I'm building with JS every day. HTML templates + automatic reactive bindings via Vue and a Redux/Vuex 'backend' are very simple.
What's more complicated and still shitty with JS frontends is the wider frameworks with Webpack, that come with a hundred packages that break often. That is the most painful thing I have to deal with day-to-day. The learning curve once you add in Babel, PostCSS, the various code optimizers and linters, TypeScript, etc can be quite intimidating.
But that has more to do with the tooling than the general approach being taken in modern frontend development.