4 ms·
His points are why I like Svelte. YMMV, but for me it hits the sweet spot of not having to do a lot of stuff by hand like we did in the jQuery (and earlier) day
by dbrueck 3y ago
His points are why I like Svelte. YMMV, but for me it hits the sweet spot of not having to do a lot of stuff by hand like we did in the jQuery (and earlier) days while also not being this massive, intrusive thing.
- darylteo 3y agoAnd thus the cycle of JS libraries continues. - Large standard library exists - "It does too much! It's slow! It's too hard to use" - "Here's a new library. It's 28kb and lightning fast" - Becomes new standard library - "... but it doesn't do this thing" - 2 rewrites later - Large standard library exists
- jraph 3y agoSvelte, however, has its very specific way of working compared to all the other usual frontend frameworks: virtually no runtime (library) supporting the app and many things happening at compile time instead and via generated code. It also seems quite focused. If anything is to become bloated, I would expect SvelteKit rather than Svelte, to become larger. I also don't know how much of the bloat is to be attributed to React vs. its usual friends or their numbers, and maybe SvelteKit actually helps keeping things in order in the Svelte ecosystem. Svelte has also been around for a while now. (Note that I have only small experiences with Svelte, none yet with SvelteKit)
- pcthrowaway 3y agoI think it's more accurate to say that Svelte can create a build with no run-time for certain apps (so can React with SSR), but for the general case, the Svelte compiler basically builds a custom runtime that only works for your application
- jraph 3y agoYep, the custom runtime you mention would be the generated code I mentioned. When I said "runtime", I was thinking of some support library you'd need to include next to the code of your app (which is left intact by React, and mangled to death with Svelte).