Reactivity
Svelte has cool and simple reactive model. Really easy to understand and use, when I read docs for the first time I had thoug...
For further actions, you may consider blocking this person and/or reporting abuse
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.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?
Totally agree!
requestIdleCallbackis an experimental API and is not supported in Safari.requestAnimationFrameis 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.Good points, thanks for explanation!
It has been done before. RiotJS is very similar and has been around considerably longer
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
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:valueis 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.It is. Read about reactive statements. svelte.dev/docs#component-format-s...
As far as I understand, mutate methods like ‘array.push’ won’t trigger updates. Take a look there svelte.dev/tutorial/updating-array...
After push you may write like
array = array😉 This works and even is suggested by tutorialsExactly! But my point is to avoid an additional assignment; I believe the comiler could do it.
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.
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.
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
Great post