React exposes more hooks or states so you can inform it how to be more performant.
ShouldComponentUpdate, ShouldComponentMount, or what have you. It’s been a while.
The reality is, you should not need those, if it was not for a systemic performance issue. Look at 2016 articles of optimizing React before react 16. Sure it got better since, but so has our devices, internet and browsers.
Run that code in a nexus 5 with a 3G connection in Puerto Rico inside a Facebook webview.
Sorry to differ it does handle more scenarios. One of them is, it compares the dom and then updates. A read is much faster than the write as write has to alter the entire dom tree.
It does not matter the library does more work. What matters is the speed for the user. It’s great they do that. But you are downloading a much larger bundle size to get that benefit. And in 95 percent of SPA sites, it’s not needed.
When we talk about performance, we have a habit of saying “this is faster” or “this updates more elements” or “it’s smarter about how it does it”.
The reality is, touching the DOM is not bad. And in most cases the added benefit of a virtual DOM is not felt. And Svelte performance actually shows its faster without the virtual DOM than react is with it.
This will keep going back and forth as both libraries keep optimizing. The big thing here, is to understand that a virtual dom is not a requirement for a fast experience. And the cost of it, is a larger bundle size.
When you remove the developer experience, and your look at the performance realistically (perception and what is needed) your left with bundle size. And react can’t touch svelte on that.
Look, what you are doing in your comparison here; dev.to/svaani/is-virtual-dom-neede..., is just bad practice - it is really not even related to Svelte. You are comparing apples and oranges and like someone else already stated, you can do batch updates to the DOM with Svelte without having it continuously update on every fired event.
I have rebuilt complex UIs from React to Svelte that way outperforms the previous version in React, but you need to have a good understanding of what you are doing and how you structure your code.
Also, note that Svelte compiles on component level, not holistically, which means that you do not or should not build your complex UI the same way you would with React.
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.
Thanks for the comment.
I didn't mean one line update in the latter example. It's supposed to be this
let number = 1;number++;
number=+2;
number=+3;
let displayNumber = number
So, the empty comparison doesn't hold good.
Trying new ways to speed up is good. Svelte is an awesome framework. But react is a lot mature and handles more scenarios to optimize performance.
I could see layout taking a lot more time in Svelte which is also a major concern.
I will also make more study on the same and update the same on data basis next time.
React does not handle more scenarios.
React exposes more hooks or states so you can inform it how to be more performant.
ShouldComponentUpdate, ShouldComponentMount, or what have you. It’s been a while.
The reality is, you should not need those, if it was not for a systemic performance issue. Look at 2016 articles of optimizing React before react 16. Sure it got better since, but so has our devices, internet and browsers.
Run that code in a nexus 5 with a 3G connection in Puerto Rico inside a Facebook webview.
Sorry to differ it does handle more scenarios. One of them is, it compares the dom and then updates. A read is much faster than the write as write has to alter the entire dom tree.
Your missing my point.
It does not matter the library does more work. What matters is the speed for the user. It’s great they do that. But you are downloading a much larger bundle size to get that benefit. And in 95 percent of SPA sites, it’s not needed.
When we talk about performance, we have a habit of saying “this is faster” or “this updates more elements” or “it’s smarter about how it does it”.
The reality is, touching the DOM is not bad. And in most cases the added benefit of a virtual DOM is not felt. And Svelte performance actually shows its faster without the virtual DOM than react is with it.
This will keep going back and forth as both libraries keep optimizing. The big thing here, is to understand that a virtual dom is not a requirement for a fast experience. And the cost of it, is a larger bundle size.
When you remove the developer experience, and your look at the performance realistically (perception and what is needed) your left with bundle size. And react can’t touch svelte on that.
The whole point is updating the Dom is 100% slower. Please have a look at the results here, dev.to/svaani/is-virtual-dom-neede...
Ok at this point your not really reading or consuming other viewpoints.
Tests I have seen that are not yours have shown otherwise, but please read everything else I said about performance.
I would also say the same, you are not reading all the points that I say.
Yes svelte is a lot better for not complex apps.
If you say 95% of the websites don't need that, we must see most percent of websites are wordpress without a thought on optimization.
Anyway, please have a look at this.
dev.to/svaani/svelte-vs-reactjs-pe...
Look, what you are doing in your comparison here; dev.to/svaani/is-virtual-dom-neede..., is just bad practice - it is really not even related to Svelte. You are comparing apples and oranges and like someone else already stated, you can do batch updates to the DOM with Svelte without having it continuously update on every fired event.
I have rebuilt complex UIs from React to Svelte that way outperforms the previous version in React, but you need to have a good understanding of what you are doing and how you structure your code.
Also, note that Svelte compiles on component level, not holistically, which means that you do not or should not build your complex UI the same way you would with React.