DEV Community

loading...

Discussion on: Why I moved from React to Svelte and others will follow

Collapse
weeb profile image
Patrik Kiss • Edited

I always find it funny when I see a post about comparing frameworks or languages

Why I switched from whateverlanguage1 to whateverlanguage2

Why whateverlanguage1 is better than whateverlanguage2

and they would start comparing whateverlanguage1 with whateverlanguage2, to convince others why whateverlanguage2 is better than whateverlanguage1, using arguments, like

whateverlanguage1: X lines
whateverlanguage2:Y lines

I mean, X|Y lines of code using what methods?

  • Line breaks after and before every brackets for example?

  • Each variable in new line?

  • Over engineering with whateverlanguage1|2, using some extreme functions?

Of course you can create a counter in a few lines, OR, you can do it in 100 lines too in every single language, if you are over engineering it.

My point is: use whatever language/framework you want to use, which you like better, which you're already used to, which you think is the best for a given task. Don't ever start compressions like whateverlanguage2 is 3 lines less than whateverlanguage1. That alone doesn't make one better at all.

Collapse
mikenikles profile image
Mike Nikles Author

Hi Patrik,

I agree with that. Lines of code should not be a reason to pick one framework over another. That wasn't the key message of my post. I kept the formatting of the Svelte components as close to the way React formats their code on the homepage for a 1:1 comparison. As I outlined below the comparisons, less code means fewer bugs, better performance, etc.

The fact that Svelte is generally smaller than React is a nice side benefit to me, but by no means the main reason I advocate for it.

Collapse
kelerchian profile image
Alan

Even though I like svelte, I quite agree with the line of codes metric being not a good metric to measure svelte's success over other framework.

I think what good svelte brought was the ease of use and optimization it brought to the fold.

It'll be cooler if svelte's module can be interoperated with other framework or plain js that does other type of job (e.g. headless state management, event sourcing, API call abstractions). Being able to be mix and matched ala functional programming modules / lego will punch svelte's value upward.

Collapse
notscottthompson profile image
Scott Thompson

I think the point about smaller code performing better is slightly moot in these examples. Remember that it is the respective compilers (svelte in general, react with jsx) that are ultimately responsible for the performance of the code that runs in the browser (ignoring the overhead of the framework in react's case). The svelte compiler will probably output a lot more code than what was input.
I am aware of svelte's benchmarks btw, I'm just highlighting the fact that you don't know it'll perform faster just because YOU'VE written less code ;)

Thread Thread
triptych profile image
Andrew Wooldridge

That is true, and Svelte might even output less code even if you had written MORE code. This is the true power of using a compiler like Svelte - any optimizations it comes up with as it develops, will benefit you even if you never write a new line of code.

Collapse
jonasbarka profile image
Jonas Barkå • Edited

As someone not versed in either framework, the Svelte code is not just shorter but also looks much easier. The two first examples are totally self explaining to any developer.

Your article makes me really consider picking up some front end skills.

Thread Thread
triptych profile image
Andrew Wooldridge

As a long time Front End Engineer, who's been through many frameworks, Svelte is a breath of fresh air and actually makes building components, etc. a nice experience. It also has accessibility out of the box, and feels closer to vanilla JS than other libraries/frameworks.