loading...

re: Svelte VS ReactJS Performance Report VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I've added the two bundles on a gist, so we can check and compare (I've tried to not minify it): React - 10572 loc: gist.github.com/marceloadsj/79...

The huge difference is obvious. If we do the same with any lighter framework it will be lesser than react/vue. That's not the point.

Yes, I shall try on a real time app but it takes a lot of time. I will pull out some and work on the same.

I don't know if you didn't got that, but, It's not lighter because the framework itself is smaller, but because Svelte don't inject unused code on the bundle! haha

And, of course, because svelte don't need to have a layer to match an in memory DOM, to extract which kind of update needs to be done. This mean less work, faster execution.

It's easy:
Both apps, at the end, will need to update the DOM, but just one will need to run an expensive comparison heuristic to know how to update it properly. The other already knows how to do it at compile time. :)

I get it. It's obvious. Svelte doesn't have boilerplate code and it compiles the code to javascript. Hence less work at run time.

Before any virtual-dom frameworks came up, we were always working without having a layer to match DOM. Svelte does a lot of optimization while it compiles the code but my concern is, it doesn't handle all the cases. But this I am not very sure about.

It's not that easy. If all that we need to do is a DOM update, even jquery did that and without a framework also people did that.

Nothing offensive, it's just that a lot of things to be analyzed before arriving at the conclusion.

Why you don't think it handle all the cases?

At runtime, react analysis the changes and create a list of updates.
At compile time, svelte analysis the changes and inject the list of updates.

The only difference, for me, it's the time it get the list of updates, isn't it?
I think I'm not getting the point you're trying to say with the posts.

And, you're right, the fastest way you can code is in vanilla js, but you'll have to code all the possible changes on the dom, in a performant way (without causing reflows). We current have only two solutions to not do all those things by hand: virtual dom runtime analysis and compile time analysis.

Well, consider a scenario where a Facebook live video of a president or a celebrity is happening.

A lot of users are commenting & reacting to the live video. And say another person who is watching live, also is getting an update on another post on the same page.

Here is where the run time comparision comes in. I am yet to know how svelte handles this.

This is one of the case. What will I answer by "all the cases"? Simple answer will be it is not that simple.

Let's think on that the problem describing as a mind exercise.

First, we can assume the browser running at 60 fps to be a smooth experience.

That means the js have 16.7ms on each tick to run + let the browser recalculate the layout and repaint.

Then, on the scenario you described, facebook have some ways to implement this, like:

  • websocket connection so the client get's all messages, one by one;
  • long polling, so the client send a request the server can hold until it get a new message, and repeat;
  • some interval implementation like, every 10 seconds, the client sends a request, the server send back a list of messages of the last 10 seconds, and the client render those one by one by the next 10 seconds;
  • some mix of those approaches;
  • other ways I can't remember or I don't know, haha;

The thing is, if at some exact time, the client receives a bunch of messages/comments, let's say, 100 new items, what can happen:

  • our react component will have an array of msgs, and a loop to render all. We received +100, so, we will render +100 new items on the list. It will basically run the reconcilliation algorithm and, 100 element.appendChild being called on the next tick;

  • on svelte, it will be exactly the same, 100 appendChild being called. The difference will be svelte already knowing that it needs to run appendChild (in that case, I think it will be insertBefore with an anchor, but we can consider the same);

Svelte implementation to see the insertBefore being called 100 times:
svelte.dev/repl/9e9e86a21f8c4c0ab6...

  • Just one detail, Svelte injects one empty text node at the end of the list to use as an anchor!

React implementation to see the appendChild being called 100 times:
jsfiddle.net/98puyLoz/

PS: on both, open the devtools and click on show, haha!


So, yep, the biggest impact will be on diff algorithm and the most important part to consider will be on the behavior you choose to code (receive and render one by one, receive a batch and render all, receive real time or each N seconds).

I am sorry to say but your "haha" is quite irritating. I wonder if it comes under "Code of conduct".

Anyway, before even I think of opening devtools, I would say the DOM structure in your example is nowhere near to real-time updates. Unless the DOM has complex structure Svelte will always be faster. The code that is written in the provided link is synchronous update whereas in realtime we receive lakhs of asynchronous updates for a celebrity live video. Please let's understand the basics of real-time updates.

I would prefer to work on it for a couple of days offline and then discuss again. I wouldn't be able to answer again on this thread. I would be grateful if you also help in closing this for now. Thanks for understanding.

[deleted]

They are nowhere realtime examples and that was judging & rude.

I'm a Svelte user. Can you record the Benchmark process and upload it on YouTube? I do not believe that React can be faster than the Svelte that has been built. I did a massive migration from React to Svelte. So I really got a feel for how fast Svelte is.

Code of Conduct Report abuse