
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.
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.
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?
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/
~ 🤡
I'd love to comply for a salary as your personal assistant, but in the meantime, feel free to look it up on your own. Cheers.
Wow, is that what "fast" looks like in React nowadays? So much for the Mr. Beast example, I suppose.
@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. 👌
Interesting reading. Thanks for sharing!
I wonder how would Promise.all work in practice. Won’t it take longer to wait for all promises?
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 see. Makes sense
Awsome Article ✨
Nice Article 👍
i don't but i just saw a post somewhere, they say next js makes it fast or something