(As a marginally related aside, I've recently spun up my mother's old 12" Powerbook G4 from 2005 or so. It worked fine and was reasonably fast and snappy (for a HD based machine), except when I opened the browser. A few tabs brought the machine to a standstill. Goes to show how much crap is on the modern web.)
These laptops had <1gb RAM. You should be amazed if you could open multiple website.
Each website is essentially a full program with sandboxing etc - and surely you'd be aware that opening I.e. Photoshop 4 times on such a resource restricted system would be just as impossible.
And it wasn't any different back then. At last not on Mac, as I had an iMac and vividly remember the same issue.
The last devices before they switched to Intel had pretty bad performance, that was the reason why they switched soon after.
Times have changed, Dropbox removed that feature - and no one uses Dropbox even anymore.
I'm not saying that situation is ideal. Most of the web should be less JavaScripty.
EDIT: For example: manager/designer wants to add an assistant to the website; it should be draggable; it should also animate and keep animating smoothly no matter where the user navigates on the website. If your website is a SPA, this is conceptually easy. If your website is static this is going to be a nightmare and suddenly a simple change requires lots of work.
All of this matters because the person that has to do this setup might not be you. It's certainly a problem with the frameworks themselves that porting a website (even just to add a little functionality) isn't as easy as setting one up initially but there's not really much an individual can do here. It's one reason I like frameworks like Preact so much, they're actually trying to fix this.
How you bundle react is left as an exercise to the reader but the data is still there?
The Francis Scott Key of web development
"...and the data was still there!"
There are plenty of things you can do with static websites, especially given you can have site generators and/or can write javascript by hand too (shock!).
For example if the requirement is to have website editable by non-programmers, that's where static site generators shine. Sure, one has to press "deploy" button and wait a minute before changes are visible... but you get to keep all the features of static pages, like trivial scalability and very high security and availability.
Even if you have to have dynamic functionality (like a shopping cart), there is no need to do the whole website dynamically. Sure, have an API server which may even render the cart page, but the rest of the website can be fully static, maybe with a tiny bit of javascript to render the "number of items in the cart" icon.
I re-used it later on in university to hand it in as a project (easiest course ever) and got commended for not putting load on the servers and making the site slow for users by using something like PHP to re-generate the same stuff over and over as users browsed the site. A+
You aren't gonna to need it[1]
Do the simplest thing that can possibly work[2]
1. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it 2. https://www.ronjeffries.com/xprog/articles/practices/pracsim...
"That's a very nice car you've made. Unfortunately, if the designer later decides that it needs to survive artillery rounds, you'll wish you had built it out of armor steel as I recommended in the first place."
... I guess this season some of us have more time to overthink things.
Still, YAGNI needs careful consideration. What looks like YAGNI right now might be reasonable flexibility that will be needed as the project matures. YAGNI makes perfect sense when delivering a proof of concept, but it's not that straightforward when designing for long-term use.
The parent comment is a bit exaggerated but it still has a point. One needs to be able to predict things and make sure whatever you do today isn't so rigid that it can't adapt to other things in the future without a major overhaul. Typically this means being cognizant of the assumptions made along the way, and making the minimal set of them. This kind of insight requires experience. People preaching YAGNI just don't seem to have much of it. They just read "YAGNI" in a blog post and then yell it at other people.
When it comes time to make a change, it's often not as big a deal as it was made out to be, and you have the benefit of everything that has been learned along the way. No one gets it right the first time anyway, so don't overthink it.
Multiple options around, I personally love this
You can develop that element and then just drop that onto your static page via /assets/ and you're golden. Easy to develop, simple to deploy and tiny file size.
That's one of the selling points of react that was initially important that you can use it in limited fashion.
This would maybe be a few hours of work if going from a static site to a SPA was actually in scope. Strip headers from the current pages and now serve the body as content from an API.
You don't need your entire site to be built with react to use react within your site and building a JS based router is not very difficult and will get even easier if the Navigation API[1] becomes better supported.
This would actually be harder if you now still need a static site with an across page assistant. I would probably push back on some requirements and store state locally in the browser. Effectively hot reload the assistant on each navigation but even then it's doable, even using react.
1. https://html.spec.whatwg.org/multipage/nav-history-apis.html...
Everything is React and SSR these days - like people please - it's not that complicated. TypeScript is an acceptable amount of overhead. Use React only if you absolutely need it and even then, use it super carefully because it has no seatbelts.
Petite-vue is a nice middle ground for 99% of websites and I am sad that this approach (templating) to build dynamic content doesn't have more investment.