Could you make a few examples?
> It uses a lot of javascript making many requests because we have to and the customers requires it.
Why couldn't the requests be done by the back-end?
> But I think even "simple" apps today often include some part of complexity that would be hard(er) to do in a "old style" multi page app.
Absolutely, but isn't that exactly the point of the article? Working with a framework can make development massively easier - however, the benefits of this only go to developers, while users have to bear the costs.
Sure, not in any particular order (and there's a lot more)
1. Users can use drag and drop functionality on areas, making updates to the backend as they are moving stuff around. To have the webpage reload would not be an acceptable experience.
2. File management. Users can upload files and create folders, refreshing the page after every update wouldn't be nice.
3. Users can retrieve data on many objects. Open specific objects and see it's data in popups. Edit the data, add comments, upload images etc. Wouldn't work very well with a refresh.
> Why couldn't the requests be done by the back-end?
When the backend can do the requests, it does. I meant doing requests to our backend and to static resources.
> Absolutely, but isn't that exactly the point of the article? Working with a framework can make development massively easier - however, the benefits of this only go to developers, while users have to bear the costs.
Not really. I am saying that many new apps aren't simple crud apps anymore.
I ended up having to cut a lot of features to make projects happen on time, and adding a new complex feature to an existing site coded with unobstrusive JavaScript was always felt like a full rewrite.
Doing it with React though is like being back to working with desktop GUIs. Anything you want we can do.
In the older days, anything that had to be a complex webapp would be easier done as a java applet, or a flash app.
What is it? Because I highly doubt that statement. Ajax, DHTML, ActiveX, and Java Applets offered effectively the same solutions in the late 90s.
Doubt it as much as you want but we use several newer apis and phones wouldn't be powerful enough to run the damn thing 10 years ago since it's a web app.
I remember a little of the pre smartphone days. Basically no one installed any apps that didn't come with the phone. I tried to download some apps on some symbian device but experience was shitty as hell and many times they didn't even work for some unknown reason.
No, it doesn't need to be. If you need to use hacks like SPAs to have the functionality you want, that is telling you that you're using the wrong tool for the job, and shouldn't be making a Web site.
What you and a lot of other Web developers have done is, when faced with a square peg and a round hole, break the peg and the hole. Worse yet, not just for you, but for everybody who has to use those pegs and holes. Now the Web is a terrible place even for the people who used it correctly. Now the desktop is a terrible place because Web people have infected it with Electron.
Web developers, if they can be called that, have set back the state of the art by several decades.
For example, I work on an app which wouldn't be possible on the web 5-10 years ago. It's a single page app because it needs to be. It uses a lot of javascript making many requests because we have to and the customers requires it. We could probably make it a lot faster, the issue is that the amount of functionality that we are trying to include in a short amount of time leaves us no other choice than to include yet another library etc.
I know this case maybe isn't the kind of app the article is targeting. But I think even "simple" apps today often include some part of complexity that would be hard(er) to do in a "old style" multi page app.
That being said, I use a lot of old style apps. I use the old reddit instead of the horrible new one. I use HN, I use fastmail so I do think speed is very important.