Well, size isn't the only metric. CPU usage on re-render especially on low perf mobile devices is something to look into.
And from my analysis svelte's way of updating DOM elements (which btw is the heaviest operation during re-renders) is O(1) for primitive data type. i.e. if you update "count" variable, svelte knows exactly which DOM elements to update.
Contrast this with React or Vue which renders a virtual DOM in memory and then diffs and finds which real DOM elements to update (the diff algo is O(n)). The react/vue approach has an overhead. Yes, with redux + having smaller redux props will mitigate this, but the overhead is still there.
Svelte makes performance the default which makes it attractive for say embedded systems, low perf phones etc.
Also, yes, robustness matters, developer experience matters... but I think svelte as an idea is indeed unique.
Thanks for this. I agree, Svelte is unique, and from what I've seen it's great.
I believe your analysis of the DOM update algorithm. Of course, theoretically, depending on the application, it may not have a significant effect on overall performance. O(1) can be worse than O(n) if its constant factor is greater and n is always sufficiently small, and anyway, DOM updating is only one of many things going on in an application.
That's just an academic argument, though. The most persuasive factor for me is not specifically that Svelte has an O(1) update algorithm, or that it's compiled. It's that Rich Harris and the Svelte team take performance seriously, and it's evident throughout their work and in the way they discuss it. The algorithm and the compiler are results of that underlying attitude.
"Of course, theoretically, depending on the application, it may not have a significant effect on overall performance."
Yes, like I said, if you are targeting low perf devices/embedded devices, it would matter.
But again... in some cases it's better to have perf as default rather than later realizing and spending significant effort on perf optimisation.
Some would be quick to call it "premature optimisation!".. it's not, if its free.
"That's just an academic argument...
It's that Rich Harris and the Svelte team take performance seriously.."
I think most of the frameworks take perf seriously. But not all of them are equal in the end. How would you know how much they achieve in perf, without, say, benchmarking.. or dissecting their work and reviewing it? 🙂
Well, size isn't the only metric. CPU usage on re-render especially on low perf mobile devices is something to look into.
And from my analysis svelte's way of updating DOM elements (which btw is the heaviest operation during re-renders) is O(1) for primitive data type. i.e. if you update "count" variable, svelte knows exactly which DOM elements to update.
Contrast this with React or Vue which renders a virtual DOM in memory and then diffs and finds which real DOM elements to update (the diff algo is O(n)). The react/vue approach has an overhead. Yes, with redux + having smaller redux props will mitigate this, but the overhead is still there.
Svelte makes performance the default which makes it attractive for say embedded systems, low perf phones etc.
Also, yes, robustness matters, developer experience matters... but I think svelte as an idea is indeed unique.
Thanks for this. I agree, Svelte is unique, and from what I've seen it's great.
I believe your analysis of the DOM update algorithm. Of course, theoretically, depending on the application, it may not have a significant effect on overall performance. O(1) can be worse than O(n) if its constant factor is greater and
nis always sufficiently small, and anyway, DOM updating is only one of many things going on in an application.That's just an academic argument, though. The most persuasive factor for me is not specifically that Svelte has an O(1) update algorithm, or that it's compiled. It's that Rich Harris and the Svelte team take performance seriously, and it's evident throughout their work and in the way they discuss it. The algorithm and the compiler are results of that underlying attitude.
"Of course, theoretically, depending on the application, it may not have a significant effect on overall performance."
Yes, like I said, if you are targeting low perf devices/embedded devices, it would matter.
But again... in some cases it's better to have perf as default rather than later realizing and spending significant effort on perf optimisation.
Some would be quick to call it "premature optimisation!".. it's not, if its free.
"That's just an academic argument...
It's that Rich Harris and the Svelte team take performance seriously.."
I think most of the frameworks take perf seriously. But not all of them are equal in the end. How would you know how much they achieve in perf, without, say, benchmarking.. or dissecting their work and reviewing it? 🙂
Fair enough.