Earlier quoted context omitted.
If you think of js bundle size as a percentage of average hard drive space or compare to a ratio of broadband speeds then 30 megs doesn't seem so bad.
Still, seriously? 30MB to print "Hello, World"? I can drive a Hummer H3 the block away to the 7-11 but wouldn't it be better if I at least try to ride my bike up there whenever possible?
Introduction to Svelte
111–116 of 116 posts
Re: Introduction to Svelte
#112Re: Introduction to Svelte
#113Earlier quoted context omitted.
You’re welcome :) There’s more discussion here: https://mobile.twitter.com/Shub7241/status/11570049077753241... .
When discussing structural changes, it seems like lifting constant fragments a compile time wasn't discussed. There's a Babel React optimizer to do exactly this. Lift those to their own functions. Since those functions don't take any props or state, their values are cached almost indefinitely.
Re: Introduction to Svelte
#114Earlier quoted context omitted.
You’re welcome :) There’s more discussion here: https://mobile.twitter.com/Shub7241/status/11570049077753241... .
When discussing structural changes, it seems like lifting constant fragments a compile time wasn't discussed. There's a Babel React optimizer to do exactly this. Lift those to their own functions. Since those functions don't take any props or state, their values are cached almost indefinitely.
Re: Introduction to Svelte
#115Earlier quoted context omitted.
I don't see what stops you adding caching in Svelte for virtual lists.
Imagine you add a few attributes, some properties, and a couple event listeners to a node. In order to reuse the node, you have to reset it to factory settings. How would Svelte know what things had been changed when looking at a node saved in a cache? If it has to check every property, the cost to check will exceed the cost to create new. If it saves a list of changes, it's essentially created a vdom anyway.
Re: Introduction to Svelte
#116We need someone to take Svelte on a test drive for something more complex than a to-do list. I'm assuming the results will be favorable to svelte, but please blog after said exercise. The un-ending list of blogs and tutorials on to-do lists with svelte are certainly plentiful, repetitive, and not particularly convincing
In particular, there is a _lot_ of flakiness with reactivity and because reactive things are magical in Svelte, it's very hard to diagnose and correct such issues. Reactive code becomes spaghetti fairly quickly once you start adding logic to prevent it breaking.
Those neat out-of-the-box transitions completely break unmounting/remounting as would be the case with, say, changing "pages" (using a router). If there's any transition still going on, the unmount will fail and yet the replacement component will be mounted, resulting in a frankenpage.
It's also maybe _too_ declarative in the sense that certain things that are easy to do imperatively require you to coerce Svelte to achieve them. You sometimes find yourself deliberately trying to fool Svelte into doing an update.
__
But do I regret choosing it? Not really. All frameworks have flaws. IMHO: Angular is a convoluted spaghetti of nonstandardness, React has its head on backwards with JSX, Vue has too many quirks... I'm partial to riot.js which has just been updated to v4, but I have yet to try the latest version.