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

Post by majewsky » Wed, Nov 30, 2016, 12:38 PM UTC

callumlocke wrote: post #13

bryanlarsen wrote: post #12

Precompilation is cool, but please don't imply that your framework is the first to do it. Precompiled templates significantly predate HTML, they were common in the mainframe world. In the HTML world there are tons of other templaters that allow precompilation. Handlebars is a common one: http://handlebarsjs.com/precompilation.html This is a huge part of Javascript fatigue for me. I love the fact that we're recycling…

Handlebars templates have a runtime dependency (even when precompiled). Svelte does not. Also, a precompiled Handlebars template is just a function for outputting an HTML string (with a runtime dependency). By comparison, the compiled Svelte output is a dependency-free JavaScript module for a dynamic view, which knows how (and when) to granularly update the browser DOM in response to state changes. It's unprecedented…

Post by ricardobeat » Wed, Nov 30, 2016, 12:40 PM UTC

callumlocke wrote: post #13

bryanlarsen wrote: post #12

Precompilation is cool, but please don't imply that your framework is the first to do it. Precompiled templates significantly predate HTML, they were common in the mainframe world. In the HTML world there are tons of other templaters that allow precompilation. Handlebars is a common one: http://handlebarsjs.com/precompilation.html This is a huge part of Javascript fatigue for me. I love the fact that we're recycling…

Handlebars templates have a runtime dependency (even when precompiled). Svelte does not. Also, a precompiled Handlebars template is just a function for outputting an HTML string (with a runtime dependency). By comparison, the compiled Svelte output is a dependency-free JavaScript module for a dynamic view, which knows how (and when) to granularly update the browser DOM in response to state changes. It's unprecedented…

Post by k__ » Wed, Nov 30, 2016, 12:42 PM UTC

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…

Post by ryanbrunner » Wed, Nov 30, 2016, 12:46 PM UTC

k__ wrote: post #16

skrebbel wrote: post #15

Love it. I think the most discussion-worthy quote I found in the docs is this: > It's currently fashionable to avoid two-way binding on the grounds that it creates all sorts of hard-to-debug problems and slows your application down, and that a one-way top-down data flow is 'easier to reason about'. This is in fact high grade nonsense. It's true that two-way binding done badly has all sorts of issues, and that very la…

Yes. I have the feeling most programmers are just lazy, that's why they use 2WB. And I can't blame them. Redux is much more boilerplate than MobX, for example.

Post by k__ » Wed, Nov 30, 2016, 12:49 PM UTC

ryanbrunner wrote: post #27

k__ wrote: post #16

Earlier quoted context omitted.

Yes. I have the feeling most programmers are just lazy, that's why they use 2WB. And I can't blame them. Redux is much more boilerplate than MobX, for example.

Trying to avoid boilerplate is in my experience not about laziness - especially when you consider the extreme lengths a lot of developers will go to to eliminate duplication and boilerplate from their codebases. Copying a Redux reducer that implements a standard set of CRUD actions is lazier in my mind than trying to abstract common patterns away. For me at least, the reason boilerplate bothers me so much is that it…