This post first appeared on www.mikenikles.com.
Photo by Aryan Singh on Unsplash
React was my go-to choice for many years
On October 1...
For further actions, you may consider blocking this person and/or reporting abuse
I always find it funny when I see a post about comparing frameworks or languages
and they would start comparing
whateverlanguage1withwhateverlanguage2, to convince others whywhateverlanguage2is better thanwhateverlanguage1, using arguments, likeI 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
whateverlanguage2is 3 lines less thanwhateverlanguage1. That alone doesn't make one better at all.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.
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.
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.
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.
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 ;)
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.
Really?
on:submit|preventDefaultIs this a new incredibly ugly way to define inline JS? Is that a...pipe in there?
htmlForNever seen that HTML attr before 🤔
Hi Avon,
Thanks for your feedback.
The
on:submit|preventDefaultsyntax is optional. We could use the regularevent.preventDefault();call in thehandleSubmit()function to keep the HTML cleaner.In case of the
htmlFor, thanks for pointing that out. I copied the initial source code from the React website to make sure I don't miss any feature in the Svelte version. I've updated the blog post and the interactive demo to usefor.Good to know; appreciate you clarifying!
More accurate critic would be: svelte is not html at all.
Rich Harris introduce this language as htmlx github.com/htmlx-org/HTMLx.
If it has different parser from html, it is a different language.
I've been thinking it might be worthwhile to use Svelte within DEV in addition to Preact. We choose Preact over React because we want to be minimal with our underlying bundles. The small footprint of Svelte in this regard makes me feel like we can offer up both underlying libraries for our developers to choose from based on preference for different parts of the site without going over our bytes budget.
I like everything I'm seeing about Svelte and feel like we can adopt it without throwing out our other approaches.
I think that's one of the very cool aspects of Svelte. It doesn't have a ton of baggage with it ( loading a whole lib before you can use it) and you can just sprinkle it in on top of other frameworks / languages and feel confident that it will not interfere or add too much pageweight. It's very "subversive" in that way.
Right, Svelte fits in well in terms of its bundle sizes.
I haven't mixed (P)react & Svelte components on the same page, but there is an example at github.com/Rich-Harris/react-svelte with Svelte 2.x. Likely a good starting point for an experiment.
As a beginner web dev I recently discovered React and built a few bits and pieces in it and I find it fairly intuitive. That said, I also discovered Svelt and am totally swept with it. It's so intuitively simple. My favourite thing about it is that any React app I've made (always with
create-react-app) just feels huge. Even the base project just feels like a monster, whereas my Svelte app feels tiny and simple. I'm looking forward to developing more in Svelte soon!That’s because CRA is a bundle with lot of stuff that you will never understand just by studying React.
React Itself it’s just a package to import.
This reminds me of Vue. When I tried Vue after React it seemed very simple
Thank you for a nice article. Really shows up advantages of Svelte.
Svelte is great for small apps, widgets, forms, perhaps medium sized projects as well.
However, to be used in larger apps, I would like to see routing and state solutions built for Svelte, kinda Vue has, devtools to debug the code. While Svelte is not providing anything alike it will be used as a side, great tool to cover quicck and simple needs. Other way it is pretty hard to convince managers to use it for company's development needs.
Anyway it is a fresh tech in the FED tooling and we are all really looking forward for Svelte to grow and mature in 2020.
Ho ho ho :)
how often do you take an open source React component and integrate it without any issues or unnecessary overhead. Very often, I don't know what you have been working with lately...I really don't understand how this "downside" is leaned as a positive aspect in your article.
too reliant on npm install ...that's, like, one of the most important upsides of modern web development: there are a lot of code out there that one can easily import and use it on its project.Often building your own components, especially in Svelte, leads to less time spent overall.It would be really nice if you provided one real-life example of this, because that phrase doesn't make sense in my head for most of the web-development that I do (landing pages, ecommerce stores...), specially when using something like MaterialUI.I don't like Svelte, I may take it for its allegedly perfomance benefits, but explaining why one needs to add a
$in the code when it "depends" on something seems way harder than explaining about renders and the hole component as a function. I still didn't grasp its "simplicity", but I value innovation and support Svelte, still not seeing why would anybody leave React as of now, it's a way different momentum than the AngularJS migration.Hi Luciano,
Thank you for taking the time to provide your feedback.
In a scenario where a web app's design is based on MaterialUI, I agree that using an existing component library is the best and most efficient approach. For Svelte, there's sveltematerialui.com/ as a starting point.
The use cases I encounter most often is where web apps are designed by an in-house design team and the web developers develop according to the design specifications. While there are many open source calendar components for example, they often provide features that are not needed. In my experience, this can add complexity, unnecessarily increase JS bundle and CSS file sizes and make it more complicated to add features that are unique to a business. On the flip side, developing custom components requires more testing (e.g. cross browser compatibility) so it is a bit of a balancing act on a case by case situation I'd say.
As for my comment on being too reliant on
npm install: Imagine a situation with 15 frontend developers working in 3 teams. What I think tends to happen is that developers' first instinct is to search NPM for a component, install it and use it. Each component often comes with its own dependencies (both direct & transient) and sometimes developers on different teams add different npm packages to solve similar needs. This slows down the build pipeline & potentially increases the final bundle size. With good internal team communication and a share component library, this kind of duplication should be kept under control.As with many things in tech, whether Svelte is the right decision or not depends on many factors. In my case, so far, I've had a good experience.
Have you learn and dive into VueJS?
You said that you have looked for Angular 2 and VueJS.
I think if you have learnt about VueJS, even for the simple "Getting Started" part in its docs, you will recognize the Svelte almost in similar in style with VueJS, the Single File Component (SFC) style.
As you said have looked for Vue, I expect that you would say something like "Svelte is VueJS with ReactJS combined plus blablabla"
😁
Because it really is.
The separation of html, script and style, is what the SFC doing (template, script, style (scoped or global)).
The 'on:click' syntax, what the different with 'v-on:click' (or the shorten version '@click') in VueJS.
But the '{handleClick}' syntax is React way.
So, the 'on:click={handleClick}' is the VueJS combined with ReactJS.
Oh, I almost forget, the "store" for global state is also similar to Vuex (State Management for VueJS), ofcourse with different code to write and concept.
But anyway, nice post.
Thanks for sharing.
I almost consider using Svelte, when my friend and boss tell me about it.
But, we don't use it already.
And I didn't have yet plan to jump into company which using it.
😅
P.S: I still wandering the future where, people don't need to learn new (and always new) way to write Front End codes. The future where there are no Angular, VueJS, ReactJS, Svelte or whatever-will-be.
Just HTML, CSS/SASS, and JS.
But in a way that can harness the power of those framework, i.e: the reactivity, modular component, data binding, style binding, etc.
And people will stick to it for decades.
I don't know why, but I always think that the new framework is somehow better than previous one but always keep introducing new term, syntax, concept.
In my opinion, it looks so selfish improvement.
"on:click" (Svelte)
"v-on:click" (VueJS)
"@click" (VueJS)
Why don't we just stick with html syntax "onclick".
I know perhaps it has something to do with the parser for each framework.
But guys who develop those framework are genious. They would have found the way.
If they want to keep it that way.
But yeah, here the result.
Another syntax to learn.
FYI your "A Component using External Modules" seems to have an error in the Svelte repl: svelte.dev/repl/28f4b2e36e4244b8b2...
It's showing:
Cannot read property 'Remarkable' of undefined
Nice catch Andrew, it looks like there was a race condition where the external JS file didn't provide its global
window.remarkableobject quickly enough.That's fixed now - thank you for letting me know.
Thanks for responding and getting it to work! I learned more about Svelte looking at how you fixed it.
As a brand new developer I'm so glad Svelte is available. It's helped me to create projects that work while I learn the fundamentals of JavaScript. The ability to declare variables and functions and use them directly in the markup is the first thing I found attractive. I know it's not all that different than template literals but it's been very helpful.
The other thing I find helpful for learning is that components are separated into script, markup, and style sections. It's very easy to keep track of what's happening inside of a component. That and safe component scope has really helped.
Finally, and this was a big deal, I was able to finish a simple teleprompter app within a couple of weeks and upload the contents of the build directory to a plain-old Apache web server and everything worked. I didn't have to learn how to deploy, didn't have to push anything to github etc.
I'm sure I'll explore other frameworks but I have to say Svelte has been a fantastic way to learn.
At one point I was an evangelist of svelte for quite a while to my friends who work on js projects. The thing it does to optimize your code is great.
One thing that stopped me from moving to svelte was its lack of TypeScript support. It's weird though because svelte was created with TypeScript and it wasn't in Rich Harris's priority to put into.
Once, I opened up svelte's compiler's parser to see if TypeScript could fit into the loop and it's more complicated because it's a whole new language, not just simple old javascript.
But let's see if Rich Harris would do his magic one more time to put TypeScript into it.
It's like you moved from Country Reactia to Svelte .
Thank you, Mike, for this post. It is pretty amazing to see the community being interested in something new far from React or Vue worlds.
Completely true. I remembered when AngularJs was presented the first time in late 2011, I was blown away by its simplicity and the logic, it was, by the way, the reason why I switched definitely to frontend development. A few years later it ends up being deprecated because of its performance issues and its massive learning curve, which pushed the google team to completely rewrite it from scratch.
What I want to highlight here is a Hello World example, never tells you the reality of things as it's always simple and small, it is only meant to sell you the idea.
I am not saying Svelte is not easy or I don't like it, it's completely the other way around, I am really amazed about and so far it sounds promising. My issue is basically regarding all frameworks out there because of the mindset they are trying to spread by only showing you the visible portion of the iceberg with no need to worry about how things really work underneath, which is for me is the real problem, it will push you far away from learning the root which is Javascript. jQuery is a great example
I recommend you read this article from @stefannieuwenhuis
Hi Othmane, I appreciate you took the time to share your feedback. Hello World examples are about as useless as trying to buy a watermelon based on its shape ;-).
I've used Svelte in a production app for about a year. The blog post was inspired by a number of people who asked me why I chose Svelte over React since I had been invested heavily in React. The simplest way I could think of to show the difference was to use the React examples from their homepage, hence it's fairly basic.
I am planning a much more in-depth online course, likely by open-sourcing my web application I've been working on for a year to give people a much better picture of how Svelte (and Sapper) behave in a real world example.
Thank you for sharing Stefan's blog post. I like this comment thread as it aligns closely with what I do.
I haven't looked into web components recently, but did read most major browsers now support them.
Hi Mike,
I am a react developer. Working on react for some 3.5 yrs now for organization like JP Morgan and UBS. I would like to know more about Svelte and it's job opportunities you spoke about.
Hi, it looks like the link I shared lists two jobs at the moment. They also have a Twitter profile at twitter.com/sveltejobs worth following to see when new jobs become available.
To get up to speed with Svelte, I suggest you work your way through svelte.dev/tutorial/. It's all you need to fully understand how to work with Svelte. Later, the docs at svelte.dev/docs list all features and Ctrl + F is your friend to find what you look for.
If you have specific questions or situations to discuss, let me know and I will do my best to support you.
Nice comparison. Even I am in the svelte exploration phase. Reactivity as you mentioned is an amazing feature. I hope there is plenty to come from svelte js.
I used react for a short while then jumped to Vue and never looked back, thanks for the article it has given me a quick preview on svelte.
Thank you for your article !! ... now trying to use Svelte as the people at Spotify do ... it's really cool !! ;) :)
Awesome, I'm glad you enjoy it. Contact me if I can help in any way :-)
Actually, if you watch the Rethinking Reactivity video mentioned in the article it explains why the virtual Dom in react isn't fast or performant at all!
Watched it and I'm blown away. I think the video explains a lot more, if you have the time to sit for it.
Take a look at Riot JS - it's a lot like Svelte, but has been around longer. In my opinion it's even closer to normal JS/HTML
I really leaned towards svelte what prevents me is lack of equivalent to react native for ... web ;) blog.logrocket.com/the-state-of-re...
I've heard of that, but don't have enough experience to comment. What may be of interest to you is svelte-native.technology/. It'll be a separate code base from Svelte on the web though, but check it out.