You clearly don't understand how the browser works, React apps are also susceptible to browser clearing cache. It's even worse with React apps, cause you'd have to download the whole bundle all over again, compared to just getting the single page for traditional websites.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
?? on a "traditional" website you need to download the current view and all related assets (including scripts, styles, and resources such images, fonts or videos). The point here would be the size of that data in one compared to another which, coding a "traditional" website using Twitter's Bootstrap for example puts you in need to download jquery, bootstrap.js, bootstrap.css apart from your resources.
Same happen when you import packages into your react App, can't see the difference here.
Anyway as I told on the comment above react is not meant to being used for a public web page, it's meant to code web apps. And apart from that, regarding at what you are talking about, you don't know about how react works. You'll get the app first, then you only ask for content so the first load will be slower but the rest of each user interactions will be faster (no matter if it's 1 or 100000).
Of course using a simple html + css + few possible js your app will perform better. That's because Js needs to be evaluated and executed while js and css does not. If you read my posts you'll see i'm a big defender of using plain CSS for coding things that are usually done with js (modal windows, accordions and so) but that's another point, we're talking about react and where it fits because according to the OP, it's nowhere.
Do you like react? well, use it. Don't you like it? Don't use it. It's possible you've no use cases for react to fit, it's ok. Only note you're trying to argue about caching, which is a thing that has nothing to do when choosing one technology or another. You'll cache things with a policy or another, you'll add server side cache or not, caching services such cloudflare or none regardless of the tech you used to build your web app.
There's a limit where things are better with a technology or another. Facebook performs better on the newer react based version than ever performed without it for example.
You're the one that brought up asset loading, and I pointed that out. I use react, I kind of like it. But I still think, for most part of it - it's ridiculous.
Going the no-framework way would always beat going the react way, without doing any crazy optimizations. You can't argue that.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
On the performance side? Yes it should of course, no doubt on that.
On scalability? Let me check your architecture first.
On development time (and cost)? Sure a big Not.
You can't generalize a method as good for everything
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You clearly don't understand how the browser works, React apps are also susceptible to browser clearing cache. It's even worse with React apps, cause you'd have to download the whole bundle all over again, compared to just getting the single page for traditional websites.
?? on a "traditional" website you need to download the current view and all related assets (including scripts, styles, and resources such images, fonts or videos). The point here would be the size of that data in one compared to another which, coding a "traditional" website using Twitter's Bootstrap for example puts you in need to download jquery, bootstrap.js, bootstrap.css apart from your resources.
Same happen when you import packages into your react App, can't see the difference here.
Anyway as I told on the comment above react is not meant to being used for a public web page, it's meant to code web apps. And apart from that, regarding at what you are talking about, you don't know about how react works. You'll get the app first, then you only ask for content so the first load will be slower but the rest of each user interactions will be faster (no matter if it's 1 or 100000).
Of course using a simple html + css + few possible js your app will perform better. That's because Js needs to be evaluated and executed while js and css does not. If you read my posts you'll see i'm a big defender of using plain CSS for coding things that are usually done with js (modal windows, accordions and so) but that's another point, we're talking about react and where it fits because according to the OP, it's nowhere.
Do you like react? well, use it. Don't you like it? Don't use it. It's possible you've no use cases for react to fit, it's ok. Only note you're trying to argue about caching, which is a thing that has nothing to do when choosing one technology or another. You'll cache things with a policy or another, you'll add server side cache or not, caching services such cloudflare or none regardless of the tech you used to build your web app.
There's a limit where things are better with a technology or another. Facebook performs better on the newer react based version than ever performed without it for example.
dev.to/ender_minyard/comment/14nd4
You're the one that brought up asset loading, and I pointed that out. I use react, I kind of like it. But I still think, for most part of it - it's ridiculous.
Going the no-framework way would always beat going the react way, without doing any crazy optimizations. You can't argue that.
On the performance side? Yes it should of course, no doubt on that.
On scalability? Let me check your architecture first.
On development time (and cost)? Sure a big Not.
You can't generalize a method as good for everything