DEV Community

Cover image for My random thoughts on Svelte
GF
GF

Posted on

My random thoughts on Svelte

Reactivity

Svelte has cool and simple reactive model. Really easy to understand and use, when I read docs for the first time I had thought why is that wasn’t done before? However, I think there is could be more. I would like svelte to be more reactive, something like array.push could trigger render. As well as methods in custom classes, which mutate this. Probably, it’s possible to check in compile time is method mutate this or not and behavior corresponding.

Async

Asynchronous blocks look fantastic. There is even no need to have an async function in components - just pass promise as props, and Svelte will do everything that should be done. Also, I like how easy to handle exceptions and loading states. However, it's a bit unclear, at least right now, how is it possible to do some logic in case a promise fails? What if you need to repeat a request or make something else?

Template syntax

Do not like template syntax. Reminds some old times with template engines. It doesn’t look modern and elegant. Not really a downside, rather personal aesthetic preference

Event handling

Not sure about putting event modifiers into an event handler assignment. As long as we can write on JavaScript in a handler function body, we can call modifiers against event objects. Looks too much. I think a good solution should try to do as least as possible in general, and personally can't see how that feature makes code easier to read and write.

Custom events

Keeping consistent custom events names could be an annoying and bug-prone task when some wrapper could just propagate the event above in a tree. Maybe it's not a bad idea to make Svelte push developers declare an event name somewhere in a code and import it to the subscription's place

Media

Updating time for video and audio happens in requestAnimationFrame. Why don't in requestIdleCallback?

Lifecycle

Lifecycle functions remind me of old good react (before hooks era), but there is something good from hooks. For instance, the onMount callback could return a function invoked while destroying. It's really convenient, especially while we have the onDestroy lifecycle function. Also, it's excellent that Svelte allows unbound lifecycle functions with components and lets us reuse them just like React hooks! So in comparison to React, these lifecycle functions got the best parts from hooks and lifecycle class methods and did it better, in my opinion.

Layout

Tick - elegant solution, like it a lot. Easy concept, unlike useLayoutEffect. Just great.

Stores

Like everything else in Svelte, stores feel simple to use and understand. API has no complex concept; just subscribe if you wanna data! I have to admit, when I started reading the Svelte tutorial, I was preparing to understand a new complex framework with complex abstractions, etc. But instead, I see one of the best tutorials I’ve ever seen, simple, kind API (I don’t know, I feel that way), syntax, and it’s excellent! It’s like a breath of fresh air in the modern web (sorry, but especially after React hooks).

Transitions

Transitions are funky, but it looks like those features aim to substitute some CSS. To be honest, I have an undefined opinion about that. There is such a high abstraction, so it's easy to make something, but what is the price? Obviously, not performance - everything happens in compile time. Probably skill? It's incredibly newbie-friendly, in my opinion, but it is crucial to keep learning js and DOM fundamentals for beginners. There is a lot of magic under the hood; hence, it's fun and easy to make the frontend with Svelte, but it will end immediately when you need to write some code outside the framework.

Conclusion

Svelte made many common frontends development patterns less boilerplate and less annoying but left expressiveness and even added fun. Frankly, I'm a bit scared about how much framework is doing for me, like I lost control, but that fear isn't rational and shouldn't be considered as a reason to not use Svelte. Actually, the most important conclusion is that - Svelte made me want to write some frontend again 🙂

Photo by Jonny Gios

Top comments (19)

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

My experience with svelte has been very positive as long as the complexity was low; stuff that would be just as easy with vanilla JS and a fair bit beyond that. But once you get to the really complicated things many of svelte's abstractions become ugly and one starts to use lots of dollar-expressions with countless variables.

I also really dislike the way templating works. This is mostly a matter of taste, but the way certain expressions are a weird mix of JS and HTML syntax ({#if} being closed with {/if} for example) just seems confusing to me.

Collapse
 
gf_developer profile image
GF

In fact, I haven't written any Svelte code and wrote those notes while reading the tutorial. And while I was reading, I had similar thoughts about complex apps on Svelte. Are there some good approaches or solutions for dealing with complexity?

Collapse
 
dmitrysobolevsky profile image
Dmitry Sobolevsky

Totally agree!

Collapse
 
joelellis profile image
Joel Ellis

Updating time for video and audio happens in requestAnimationFrame. Why don't in requestIdleCallback?

  1. requestIdleCallback is an experimental API and is not supported in Safari.
  2. requestAnimationFrame is the correct function to use anyway - the data of playback position is typically a part of the UI, and it's both important that it's up to date and unnecessary to update many times per frame.
Collapse
 
gf_developer profile image
GF

Good points, thanks for explanation!

Collapse
 
jonrandy profile image
Jon Randy 🎖️

It has been done before. RiotJS is very similar and has been around considerably longer

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

If Svelte is made of a compiler and is more of a language than anything else, and not a framework, then no Riot (I have considered using, riot and read up on it in the past) is not the same. Riot might be kind of closer to Stencil in some ways

Collapse
 
anishde12020 profile image
Anish De

Svelte was a great experience to em for i could straight away starti writing HTMl instead of first writing a function and then exporting it (in React). I don't know why but this very small advantage is a hugeeee one for me. Also, some things like bind:value is a huge advantage. I didn often have to do some digging to find compatible libraries but I usually found one and vanilla js libraries usually work the way they should. I would raelly recommend Svelte to anyone making a simple website, trust me, you don't need React for a portfolio site.

Collapse
 
pavelloz profile image
Paweł Kowalski • Edited

I would like svelte to be more reactive, something like array.push could trigger render.

It is. Read about reactive statements. svelte.dev/docs#component-format-s...

Collapse
 
gf_developer profile image
GF

As far as I understand, mutate methods like ‘array.push’ won’t trigger updates. Take a look there svelte.dev/tutorial/updating-array...

Collapse
 
alekseiberezkin profile image
Aleksei Berezkin

After push you may write like array = array 😉 This works and even is suggested by tutorials

Thread Thread
 
gf_developer profile image
GF • Edited

Exactly! But my point is to avoid an additional assignment; I believe the comiler could do it.

 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

I kind of disagree though. Using a small abstraction layer to make custom elements more comfortable is still vastly different from using a complete framework that doesn't even use custom elements at all.

What's more, this often isn't even necessary for very simple components: the low-level APIs are often more than enough for those. And as they get more complex, you can first start using meta-programming directly inside the code of your component before moving to a microframework once even that becomes hard to handle, at which point you're probably already building a considerably big component.

As for web components 2.0, I think that's exactly where frameworks should come in. Whether you prefer a huge framework with thousands of lines of code or a small micro-framework like what I use, it's easy to make the current APIs much nicer to use at some performance cost by generating getters/setters or by looking up functions at runtime. The point is that the API leaves the decision to you whether you want to make those trade-offs.

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

A few of those reasons are a bit far-fetched though. Like complaining that web components will have to define countless getters for HTML attributes; you can easily just fix that with a bit of meta-programming.

Collapse
 
jonrandy profile image
Jon Randy 🎖️

To my knowledge - unless it has changed - Riot doesn't rely on web components either. It does have the option to compile to web components though

Collapse
 
sherrydays profile image
Sherry Day

Great post