Svelte – A UI framework that compiles into tiny standalone JavaScript modules

Post by YCode » Wed, Nov 30, 2016, 3:42 PM UTC

danmaz74 wrote: post #14

dotancohen wrote: post #3

This looks nice: a Javascript framework for expressing _concepts_ that compiles down to vanilla JS. It looks like it ships a lot less code to the user. From the project's first [blog post]( https://svelte.technology/blog/frameworks-without-the-framew... ): > The Svelte implementation of TodoMVC weighs 3.6kb zipped. For comparison, React plus ReactDOM without any app code weighs about 45kb zipped. It takes about 10x a…

I didn't study the thing, but the first question that comes to my mind is: if each component is rendered as a self contained piece of vanilla js, isn't the size of an app with lots of components going to increase much faster than with the library approach? A complete library by itself can be pretty big, but it stays the same size no matter how many components you add.

Post by mvindahl » Wed, Nov 30, 2016, 3:50 PM UTC

boubiyeah wrote: post #132

mvindahl wrote: post #128

Earlier quoted context omitted.

Haven't studied the SvelteJS documentation but as far as I can reason there is nothing in their idea that prevents them from shielding the DOM behind a lightweight, virtual DOM, ReactJS style. In fact, I'd be slightly disappointed if they don't shield the DOM somehow. It's the #1 bottleneck, after all.

Check the generated code in the REPL, it's straight DOM manipulations.

Post by JDDunn9 » Wed, Nov 30, 2016, 3:59 PM UTC

mvindahl wrote: post #128

fzaninotto wrote: post #123

The precompilation is a nice idea, but I'm not buying the "vanilla JS" argument. The reason why React and other frameworks have a runtime is also because they optimize rendering. The Svelte doc says: every call to `component.set()` produces a synchronous DOM update. I can already see how this leads to very poor rendering performance in applications with a large number of nested components. React and the Virtual DOM s…

Haven't studied the SvelteJS documentation but as far as I can reason there is nothing in their idea that prevents them from shielding the DOM behind a lightweight, virtual DOM, ReactJS style. In fact, I'd be slightly disappointed if they don't shield the DOM somehow. It's the #1 bottleneck, after all.

Post by TeMPOraL » Wed, Nov 30, 2016, 4:01 PM UTC

bryanrasmussen wrote: post #118

ryanbrunner wrote: post #90

Earlier quoted context omitted.

If the thing that I'm abstracting is routine, and unrelated to the business problem I'm solving, I don't need to know what's happening (at least in the sense of me or someone else coming back to read the code later). I don't need to know how an HTTP server, or the particulars of an AJAX request work most of the time.

true, but when there is something unexpected about how the AJAX request or the HTTP server are working then debugging is going to be harder because of the abstraction.

Post by eob » Wed, Nov 30, 2016, 4:03 PM UTC