More articles you can read:
Using Golang to Build a Real-Time Notification System - A Step-by-Step Notification System Design Guide
JSON is Slow...
For further actions, you may consider blocking this person and/or reporting abuse
Highly optimised VanillaJS will always be faster than any framework. Period
That said, such code would likely be a nightmare to work with. It's a trade-off
(Many frameworks are also faster than React. It normally doesn't do all that well in benchmarks)
I used to say that too, but I have learned it isn't necessarily the case. Some frameworks add features that improve performance, so it really comes down to how much overhead they add, and is it a net loss. With most frameworks, especially those that use a virtual DOM like React, they will indeed always be slower. Others, like SolidJS, will either be very very close to vanilla JS, or in some tests will exceed it. That is because there is no render loop, because it knows exactly what changed, down to the element, and only updates those elements that have changes. Check out the performance at shorturl.at/vS346 (links to krausest.github.io/js-framework-be... with a few key frameworks selected). Solid is a tiny bit faster at load time than vanilla. In the past I've also seen it beat some of the row-related operations too. In the latest benchmarks above, it only beats vanilla JS on the "partial update" test. I don't want to sound like Solid fanboy but really, it is React done right.
What is "fast"? Server load time? First contentful paint? Time to interactive? Perceived responsiveness by the user when interacting with your app? If you want to optimize for all those metrics you are going to be building a framework... Those are not things you want to constantly reinvent for every app you build imho.
As for really dry code execution performance... React = JS, there's no difference in execution performance. A line of JS code executes exactly as fast as a line of JS code. It's not a different language in that regard like rust for example.
We really need to stop saying React is just JavaScript. That is false. Much of React's code doesn't even work outside of React components. Plus, using VDOM will always have overhead.
Highly recommend taking a look at the react source code and you will see, it is infact JavaScript 😊 github.com/facebook/react
That wasn't the point. Of course it's built with JS, the problem is that it's not transferable JS that you can use outside of React
Yes obviously if you import a function from some package, you wont be able to use that function if you delete the package, as is the same for all JS code.
Agree. Often things that make programming faster, also makes it slower. Especially if its some sort of layer. 4gen. Languages are slower then js, js it slower then C, C is slower then Assembly.
I'm not sure I understand. React is written in vanilla JS. Of course it's only possible to be slower or at most as fast as any other JS.
React can be much faster than raw JS in this case. If it is a never ending and expanding list, you can't show all of that on the page. Simply rendering only data that is visible in viewport will gain performance many times greater than manipulating/reflow of a bloated DOM. Yes it's more complicated to implement scrolling logic but it's lightning fast to the user, regardless of data set size.
That's something you can do in Vanilla JS too. React is developped in Vanilla JS it can at much be as fast as Vanilla JS. What React brings to the table is not performance, it's maintainability, scalibility and DX.
You just gave me the best idea 💡. Now I know how to build my chat application.
God bless you
This sounds like the old, assembly language is faster than compiled languages debate. While that's potentially true in all cases, the amount of work you needed to do in assembly language would basically offset any of those gains. Now, hardly anyone knows how to use assembly language, so we can see where this argument is going.
That being said, I do wish frameworks like react and others were made to be more efficient and more importantly, I wish they would favor saving time in maintenance over initial crafting.
These frameworks are about the developer experience and they are still sorely lacking in that respect.
Why wouldn't you do a linked list in React anyhow? New item comes in, you modify the state of the item before and your component renders itself and then its sibling if it exists.
React is just JS, it doesn't tell you that you have to use arrays instead of lists.
React is a library that runs on top of ECMAScript (vanilla Javascript), React doesn't do anything that Javascript can't do, is important to remember that. What the article provides as arguments can all be applied to Javascript as well.
While working on a React app/site you are working on Javascript but React adds syntactic sugar so is easier to work with and at the same time it provides an opinionated way to do things.
JSX, hooks, virtual DOM, fast hydration... All of React's features can be accomplish without React.
That being said I'm not saying "don't use React!" or "React is a bad library!", might be less performant but is not just about performance. It has it's benefits, one of them being that provides a great dev experience and is much easier and faster to get a finished product and much easier to maintain.
The more interesting question is: how could React be faster than Javascript as it is written in Javascript and why in the world would someone ask a question like this with the intention to get a good answer?
Can Tailwind be faster than css?
Can Unity be faster than C++?
Can NumPy be faster than Python?
You can't compare things written in a language with the language itself. You can only compare frameworks/libraries/code but not a language with code.
If you want your frontend code to be future-proof, fast, and free from the hassle of constant upgrades or weird issues caused by third-party libraries, then just write your code in vanilla JavaScript. Don't be lazy!
Every single library or framework out there comes with a lot of strings attached, though most of their creators and fanboys won't admit it. All that "fast and easy to use, implement, etc." talk is just urban myth. Sooner or later, these tools will turn into nightmares if your product evolves long enough.
They'll tell you, "Hey, use frameworks because they're more secure than writing your own code." Yeah, sure... Any zero-day vulnerability found in the framework will affect you too.
Diversity is more secure than uniformity. Nature figured this out a long time ago, but today's so-called security experts are too blind to recognize it, pushing for uniformity instead.
If you're lazy at the beginning and don't want to write your code directly in JavaScript, you'll pay for that laziness a hundredfold in the future.
And seriously, JavaScript is already a framework. Why would you want a framework within a framework?
In most cases, the reason existing JavaScript frameworks came into existence is because their creators didn't want to inherit the garbage from earlier frameworks. But by doing so, they just created more garbage for future lazy developers to inherit...
If you want to build an F1 car, then build it from scratch (use vanilla Javascript). If you want to build an RV then go buy the parts from Home Depot (use any framework or library you want).
No one should be surprised by this. React ships hundreds of kbs, which takes time to download for a poor mobile connection. Additionally, it's quite CPU intensive, which many mobile devices are lacking in. For desktops with good wifi, it's not too much of a concern, but if you're building an app for an e-commerce company (which generally have a high percentage of mobile users), and the app needs to serve above the fold content, I wouldn't recommend react.