Check out more articles:
Building a Scalable Notification System with gRPC and Microservices
Adding a Notification Feed in React Websites
A Compl...
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
I suggest Code Splitting:
Use code splitting to divide your application into smaller chunks, and load only the necessary parts when they are needed. This can be achieved using tools like Webpack.
Although with React you will never get rid of the initial bundle size upon page load, and you'll suffer that penalty each time loading the HTML page as React itself is unsplittable. With Node.js it gets even worse since then you also have it's code included as well so that you get client side routing and all the related issues that go alongside with that.
Unless React dramatically changes how it's been designed there is no way for it to get rid of that code. They must do things like abandon their own event system.
It isn't entirely about the speed of the connection, although that take is still a bit ignorant considering web speed is not always perfect depending on conditions and location.
The parsed JS is often the heaviest bytes on a website. So each time a HTML page boots that code will execute. Not a problem on your high end Apple Mac M(insert latest number here), but vast majority of devices are less performant. And at least I think most sites should work snappily regardless of the device capabilities.
Basically every take where you say "not a problem for me" is you not being aware that what is true for you does not apply to everyone else. Bundle size is both performance and accessibility concern. The bigger your bundle becomes and the heavier it becomes to execute, the more people are effected negatively.
Also in March Google starts to rank sites low if they score low on INP. That metric is awful on about every React site in existance, and that metric is related to initial JS bootstrap time.
So: bundle size does matter, a lot.
The power of microprocessors grow year after year, and yet you see constant performance enhancements in many projects, including .Net (to mention a very large one). What I'm trying to say is: People that say "we won't care about our memory consumption because RAM is cheap", or "bundle size doesn't matter becase Internet speeds are faster year after year", are people unwilling or unable to do the right thing.
Apologies if it feels like it goes your way. It is my honest opinion.
Do you know the size of the core React library bundle? It is less than 3 kB minified an gzipped. It is less than 100 ms of loading size even on 3G. Do you really think it is a bottleneck?
Interesting. Can you point me to a React project in GitHub or elsewhere where once compile will produce a less than 42kb bundle? Because this is the size it is always seen. If you have an example of a React project than bundles around 3kb, I'd love to see it because that's the SolidJS and Svelte bundle sizes, never React sizes.
bundlephobia.com/package/react@18.2.0
Svelte is bigger bundlephobia.com/package/svelte@4.2.8
Thanks. It is an interesting metric, but by all means an incorrect one. The cost of React is 40kb as a minimum. I wonder why bundlephobia reports such a low number? Anyway, thanks for the link. Interesting thing, this bundlephobia. However, it is completely off base when it comes to React at the very least.
Because it is true. Why do you think overthise?
Because I have done the exercise many times:
npm create vite@latest. SelectReact + Typescript + SWC.npm i.npm run build.I just did it. Here's the screenshot: Out of the box, the sample Vite project is over 143KB, 46kb gzipped.
Would you like to see a Svelte test?
Just FYI, about every React site requires React DOM:
bundlephobia.com/package/react-dom...
So it's 10 + 130 = 140 kilobytes just to parse React code.
Of course on a NextJS project you also need to add client router etc so it can work like a SPA, to make Link components work. That code needs to technically imitate actual page transition to ensure focus is in the right place, screen reader announces the right things and all the other stuff that is provided by native HTML page loading for no extra code.
And we got there because React DOM is so big that it does slow down app bootstrap time.
@webjose Look this:
Finding Svelte's Inflection Point / Calculating the Inflection Point
That was nice, @monoprosito. Definitely quite informative. One more star for Svelte, I suppose. 👌
or Qwik ;)
Nice write-up!
I think the key thing is understanding what you are asking of a framework, if you render thousands of components then it's going to be slow, it's just easy to not think of that when working with the basic principles in React and not accounting for how things will scale.
Your car is slow? May it help to put more fuel in? Likely not.
Just buy a new one...
First, define slow
Ok, wait a minute. I´ll tell you when this damn web site has been rendered....
React isn't as slow
No, but obviously there are a number of stumbling blocks that should be avoided. If it turns out you're spending more time finding the stumbling blocks, then maybe it's time to find a new platform.
AngularJS guys told 10 years ago that below 100ms of latency your users won't notice. Even in a complex app you have to do really crappy job to cross that limit.
If you look at complex & fucked up apps (look at jira for instance), latency is implied by a shitload of unnecessary XHR (graphql is our friend) not so much by the front-end library.
React is not slow enough to lose popularity.
Starbucks and McDonald's were able to expand globally because they were not tasteless...
React is a great piece of software in terms of engineering but it is a terrible choice for the vast majority of projects because it was never meant to be used in the kind of projects most people work on. React's biggest problem isn't React itself; it's the fact that too many people pick their tools because they are shiny, and not because they solve the specific problem they are working on. I wrote about this here (or here, if you want the original).
You can switch to Preact, a fast 3kB alternative to React with the same modern API.
Never heard, any resource?
The resource was on the link ;) Once again: preactjs.com/
Interesting reading. Thanks for sharing!
I wonder how would Promise.all work in practice. Won’t it take longer to wait for all promises?
It is faster in the case where you'll be doing all the requests anyway. It beats the waterfall case of request + wait + complete + request next + wait + complete + request another + wait + complete.
But in the overall picture it isn't a silver bullet, and you probably want to consider techniques that make things appear to be faster instead of being actually faster.
I see. Makes sense
~ 🤡
I have solved all the problems mentioned in this article in my web development framework. We use it endlessly at uiedbook.
github.com/Uiedbook/cradova
i don't but i just saw a post somewhere, they say next js makes it fast or something
Nice Article 👍
Awsome Article ✨