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
I usually shit off on the posts like "stop using xxx" but this time I decided to teach you why you are wrong. And what I'm about to tell you is applicable to angular and other frameworks too.
You are wrong because you may have learned how to code a react App but you don't know where to use it.
It's not meant to be the base of a public web page of for SEO landing pages. It's about scalability and easy-to-build front-end views consuming back-end APIs on a services or microservices architecture.
I also use React, and Angular, let's put the use cases on the table:
First the differences:
Angular is a full-fledged framework, while React is a library. React. js uses virtual DOM and one-way data binding while Angular operates on real DOM & two-way data binding. There's also a difference in bundle size (React's smaller) and speed (React works a bit faster).
We use Angular to provide a stand-alone App for a given department to manage their complex stuff.
We use React to provide a webApp to our customers. They are customers right now, no need to SEO but you want good speed due to user experience. What we did? Use Preact and optimize it as possible. Custom css framework, well optimized JS. Now we get a fast app that we didn't get using entire react or importing all unneeded react packages.
For example if you gonna code a form, why do you want the entire react form? you can pick another lighter or build your own if you're going for performance. If you don't need ALL features on a lib, don't load it to your project, that simple way you get better performance.
Of course you need SSR (Server Side Rendering) if you want to publish your APP public, for performance and SEO (also use a valid cache service and policy) as you need on a non-js webapp.
Also we have a third webapp which is made by html, scss and few js possible to obtain the fastest possible experience. Here's where SEO applies and where potential customers land.
Why you should use React?
Creating an App to your customers could be tricky and giving this "reactive" content to your customers improves the usability A LOT.
Contrary what you said, users (even on a 2G connection) will download a bunch of about, let's say 400Kb at the beggining, then they press a button and they doesn't need to load the entire page again, only a part of the content is replaced so this operation could take like 20kb. Then 15kb and then 25kb.
Without react you'll be reloading the entire page (lets say 200kb) 4 times.
400 + 20 + 15 + 25 = 500.
200 x 4 = 800.
well, appart from that if javascript is cached, those 2G people can use your react app when on wifi, and getting a faster experience when not later.
Of course there's ways fot all things to do to increase performance or another points like usability, accessibility and so.
If you want to use "plain html" (i mean no js) you'll need a back end that interacts with other APIs or that is a monolith app along your html (which could be fine depending on what you want to achieve).
There's no reason for "stop using framework/lib/methodology" unless there's something that covers the needs better.
If you learn something and you think it's shit, but there's millions of programmers across the world that uses that, think twice and say to yourself "if programmers are using that I'll try to understand where it fits before learning to code it as is", we are not silly, no one will be using things that doesn't fit well for the job or that are worse on every aspect than other alternatives (apart from Apple users).
The reasons for using something can fit into one of this (add some if i left something):
Cost (development time -> money)
Cost (computational, long term server spend -> money)
Scalability
Efficiency
Team background
Future refactoring costs
React permits you to build Apps on nice timings, the js computation happens on user's machine instead on yours, it's scalable and if coded well it's enough efficient too. Also the refactoring cost will be low due to componentization.
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
If you visit each view for the first time your browser will need to create that cache AFTER downloading it, so the numbers are right for the first time you visit that web app and also for each time you visit it after cache lifetime ends or cache flush, which actually it's needed after each deployment into production so, on a modern development cycle will be each few days as min.
Think on how many times your customers' browsers will need to download the entire view and then create a new cache.
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.
I usually shit off on the posts like "stop using xxx" but this time I decided to teach you why you are wrong. And what I'm about to tell you is applicable to angular and other frameworks too.
You are wrong because you may have learned how to code a react App but you don't know where to use it.
It's not meant to be the base of a public web page of for SEO landing pages. It's about scalability and easy-to-build front-end views consuming back-end APIs on a services or microservices architecture.
I also use React, and Angular, let's put the use cases on the table:
First the differences:
Angular is a full-fledged framework, while React is a library. React. js uses virtual DOM and one-way data binding while Angular operates on real DOM & two-way data binding. There's also a difference in bundle size (React's smaller) and speed (React works a bit faster).
We use Angular to provide a stand-alone App for a given department to manage their complex stuff.
We use React to provide a webApp to our customers. They are customers right now, no need to SEO but you want good speed due to user experience. What we did? Use Preact and optimize it as possible. Custom css framework, well optimized JS. Now we get a fast app that we didn't get using entire react or importing all unneeded react packages.
For example if you gonna code a form, why do you want the entire react form? you can pick another lighter or build your own if you're going for performance. If you don't need ALL features on a lib, don't load it to your project, that simple way you get better performance.
Of course you need SSR (Server Side Rendering) if you want to publish your APP public, for performance and SEO (also use a valid cache service and policy) as you need on a non-js webapp.
Also we have a third webapp which is made by html, scss and few js possible to obtain the fastest possible experience. Here's where SEO applies and where potential customers land.
Why you should use React?
Creating an App to your customers could be tricky and giving this "reactive" content to your customers improves the usability A LOT.
Contrary what you said, users (even on a 2G connection) will download a bunch of about, let's say 400Kb at the beggining, then they press a button and they doesn't need to load the entire page again, only a part of the content is replaced so this operation could take like 20kb. Then 15kb and then 25kb.
Without react you'll be reloading the entire page (lets say 200kb) 4 times.
400 + 20 + 15 + 25 = 500.
200 x 4 = 800.
well, appart from that if javascript is cached, those 2G people can use your react app when on wifi, and getting a faster experience when not later.
Of course there's ways fot all things to do to increase performance or another points like usability, accessibility and so.
If you want to use "plain html" (i mean no js) you'll need a back end that interacts with other APIs or that is a monolith app along your html (which could be fine depending on what you want to achieve).
There's no reason for "stop using framework/lib/methodology" unless there's something that covers the needs better.
If you learn something and you think it's shit, but there's millions of programmers across the world that uses that, think twice and say to yourself "if programmers are using that I'll try to understand where it fits before learning to code it as is", we are not silly, no one will be using things that doesn't fit well for the job or that are worse on every aspect than other alternatives (apart from Apple users).
The reasons for using something can fit into one of this (add some if i left something):
React permits you to build Apps on nice timings, the js computation happens on user's machine instead on yours, it's scalable and if coded well it's enough efficient too. Also the refactoring cost will be low due to componentization.
Now explain me why I should not be using react.
You're so wrong,
There's something called caching
Yup, and do you even know how cache works?
If you visit each view for the first time your browser will need to create that cache AFTER downloading it, so the numbers are right for the first time you visit that web app and also for each time you visit it after cache lifetime ends or cache flush, which actually it's needed after each deployment into production so, on a modern development cycle will be each few days as min.
Think on how many times your customers' browsers will need to download the entire view and then create a new cache.
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