But IMO this tracks back to the MPA vs. SPA problem.
Do we actually need to be using a SPA/JS framework (Angular, React, etc) and what do we get in return which outweighs the wildly agreed increased development effort of SPAs?
I think the author is referring to mainly "wrapped" SPA web apps that sit inside native apps with a "web view" rendering the SPA (like the browser would).
It's not just wrapped apps tho, many native apps have some kind of hybrid where you're using a library directly (React Native?.. dives for cover) which but a whole framework of abstractions on top of the native interfaces. With so many "layers" and all these things being new and vastly more complex than MPA web apps, the statistical likelihood of goofing things up is just very high.
Where are the days of old (what? 10 years?) where we got to the edge of MPAs (we didn't even call them MPAs then) and optimised the crap out of them making them fast, and simple and quick and a pleasant user experience? I think we come up with all sorts of poorly justified reasons to go to SPA/JS frameworks these days and the users are the ones who end up paying the price.
> But IMO this tracks back to the MPA vs. SPA problem.
It doesn't. You can have refresh buttons in SPAs that refresh correctly parts of their stores. You can have MPAs that incorrectly (or don't even try) invalidate local storage cache. You can have backends with bad cache invalidation. You can have SPAs that are also MPAs (nextjs+react, nuxtjs+vuejs, univeral angular, etc..).
Fact of life is, once your "page" needs more than a non-trivial amount of "GUI", solutions like react are far more maintainable, easier to develop, more portable, faster, and most importantly, build better user interfaces.
No need to blame SPAs using the 2012 concept of SPAs when the cause is clearly a rookie coder or a bad UX decision from upper management.
There's nothing about an SPA that inherently prevents you from having a button that force-refreshes the internal state from the server. This is what happens when you kill the app and re-open it -- it gets it's state from somewhere.
Man, leave it to HN to turn an article that has _nothing_ to do with a specific technology (notice how the app the author makes an example of isn't even a web app?) into an excuse to soapbox about modern web development.
It's not HN-specific thing. It's that in the new generation of developers, people sometimes miss that there are things that are not Web, and the Web is not be-all end-all of programming.
But IMO this tracks back to the MPA vs. SPA problem. Do we actually need to be using a SPA/JS framework (Angular, React, etc) and what do we get in return which outweighs the wildly agreed increased development effort of SPAs?
I think the author is referring to mainly "wrapped" SPA web apps that sit inside native apps with a "web view" rendering the SPA (like the browser would). It's not just wrapped apps tho, many native apps have some kind of hybrid where you're using a library directly (React Native?.. dives for cover) which but a whole framework of abstractions on top of the native interfaces. With so many "layers" and all these things being new and vastly more complex than MPA web apps, the statistical likelihood of goofing things up is just very high.
Where are the days of old (what? 10 years?) where we got to the edge of MPAs (we didn't even call them MPAs then) and optimised the crap out of them making them fast, and simple and quick and a pleasant user experience? I think we come up with all sorts of poorly justified reasons to go to SPA/JS frameworks these days and the users are the ones who end up paying the price.