Yeah the backlash against SPAs doesn’t make any sense. Server side rendering is fine for documentation etc. but full applications don’t want to be simulated on a server, client-server makes complete sense.
Webservers shall create and provide the readily HTML so browsers can render the website without JavaScript. Actually text-browsers should render it and also allow disabled persons using it without hassle.
Instead SPA (or more direct JavaScript) is used to force the browser to assemble the HTML and it is slow and waste resources. Creating website which create load on the client-site is bad because we’ve power on the server dedicated for this task - not so on client.
Looking back web-developers need something imperative and more direct than CGI, PHP or JSP. The initial backslash against JS was right. I sadly shipped JS.
When a powerful application is needed? Make a native application and use an appropriate toolkit (Gtk or QT).
I agree you’re right in that the current tech stack is bad. But the answer is to fix that, and I think (very) slowly we will.
JS was a terrible language but nowadays it is pretty good in some areas, passable in others, with some horror shows left in. The ecosystem and tooling are the real problems. I don’t understand why these issues haven’t been addressed by Google et al.
Native applications are just so much more expensive to develop and maintain. Given the nuances of different platforms, it’s also very difficult to keep different versions in sync. People expect collaboration as table stakes, which makes that task even harder.
I agree accessibility is a problem.
Ironically the Java applet had the right idea, as a compromise between our positions, but wrong time and maybe wrong language? Its Swiss cheese security didn’t help either.
> Native applications are just so much more expensive to develop and maintain.
Quality isn't free, yes.
> Given the nuances of different platforms, it’s also very difficult to keep different versions in sync.
Don't tightly couple applications and backend service versions (where a backend is even needed, otherwise make it all local) and this is not a problem. You should be using open (relatively stable) protocols wherever possible anyway.
Web apps "solve" platform differences by completely disregarding them and expecting users to adapt to the application instead. This does not make them better.
Quality isn’t free and native applications provide quality (reliance, performance, integration, usability).
The platform issues just moved to WebKit, Blink and Gecko. New platform issues and the web developers complain like application developers ;)
Companies favor the web usually to lower their own cost, give them control over users and being free of rules. Users pay for it. With higher hardware requirements (Electron), loss of data, loss of control and the absence of usability. And as states above, a website shall not stress my CPU or RAM.
The worst example is Microsoft Teams.
The best example is your preferred Matrix client application.
Theres about zero websites I use that I want to be "full applications". For things that should be applications I prefer native (open source) desktop programs.
Webservers shall create and provide the readily HTML so browsers can render the website without JavaScript. Actually text-browsers should render it and also allow disabled persons using it without hassle.
Instead SPA (or more direct JavaScript) is used to force the browser to assemble the HTML and it is slow and waste resources. Creating website which create load on the client-site is bad because we’ve power on the server dedicated for this task - not so on client.
Looking back web-developers need something imperative and more direct than CGI, PHP or JSP. The initial backslash against JS was right. I sadly shipped JS.
When a powerful application is needed? Make a native application and use an appropriate toolkit (Gtk or QT).