Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

svelte.technology

Post reply on HN
Print view View original

141–150 of 236 posts

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

#141

Post by erydo »

jerf wrote: post #71
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…

My understanding is that there are two issues with two-way binding that are structural, and will be difficult to fix no matter how you approach it. First is that if you look at the system as a graph of updates, automatically closing all cycles between variable update and widget means that any additional two-way binding links you add become a cycle, which makes it difficult to implement, model, and debug. If the frame…

This is a really helpful way of describing the problem. Concretely describing behavioural coupling in terms of graphs is much less hand-wavy than the normal, "things become tightly coupled and which becomes hard to deal with."

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

#142

Post by boubiyeah »

eob wrote: post #139

Looks neat, but also like a non-standard implementation of Web Components, which, though slow coming, already have universal browser support with a small shim. What's the advantage of this over something like Google's Polymer library, which is a toolkit for rapidly creating reactive web components?

Polymer is an enormous library.

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

#143

Post by eob »

boubiyeah wrote: post #142
eob wrote: post #139

Looks neat, but also like a non-standard implementation of Web Components, which, though slow coming, already have universal browser support with a small shim. What's the advantage of this over something like Google's Polymer library, which is a toolkit for rapidly creating reactive web components?

Polymer is an enormous library.

Polymer offers a lot of UI widgets, which are enormous when you glob them together, but the base polymer library is actually incredibly small due to the fact that's it's leveraging the browser's native custom element functionality.

Can't reply to your comment so editing here:

Works natively on IE11+, Edge, Safari 9+, Chrome, Opera, Firefox, and mobile browsers. The polyfill for everyone else (webcomponents-lite.js) is 41kb.

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

#144

Post by mwcampbell »

I like the idea of abstractions that exist only in the source code and at compile time, and have zero runtime footprint.

How does this compare to Google's Closure compiler and library? Does Svelte's compiler do anything that the Closure compiler cannot? Or how about running the source through a hygienic macro system like sweet.js and feeding the output of that to the Closure compiler?

I ask because I'm skeptical of a new, unproven compiler. Google has been using the Closure compiler on production code for years, and its optimizations are pretty awesome.

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

#145

Post by hbbio »

Why didn't we think of this sooner?

Because we did! For instance, this is exactly the approach that we have released back in 2009 with http://opalang.org

Naturally, there are things we would implement differently today, but the OCaml codebase of the compiler is still, in my humble and biased opinion, pretty valid.

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

#146

Post by boubiyeah »

eob wrote: post #143
boubiyeah wrote: post #142

Earlier quoted context omitted.

Polymer is an enormous library.

Polymer offers a lot of UI widgets, which are enormous when you glob them together, but the base polymer library is actually incredibly small due to the fact that's it's leveraging the browser's native custom element functionality. Can't reply to your comment so editing here: Works natively on IE11+, Edge, Safari 9+, Chrome, Opera, Firefox, and mobile browsers. The polyfill for everyone else (webcomponents-lite.js) i…

Ok, it has been some time since I checked. Don't you need lots of big polyfills ?

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

#147

Post by TeMPOraL »

draw_down wrote: post #110
goliatone wrote: post #105

This looks interesting. For the past 3 years I've been using ractivejs and really enjoy it. I'm wondering if Svelte will take away development efforts from ractivejs? OT >The web's obesity crisis, solved. Svelte turns your templates into tiny, framework-less vanilla JavaScript. Made me think of [idlewords][1] website obesity presentation... [1]: http://idlewords.com/talks/website_obesity.htm

I think Rollup already took time away from Ractive. It's really too bad, I think Ractive has some great ideas and I really enjoyed working with it. It was the best way to build web UIs I've come across. But I feel its future is uncertain so it's hard to recommend others begin using it.

> I feel its future is uncertain so it's hard to recommend others begin using it.

Self-fulfilling prophecy unfortunately.

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

#148

Post by boubiyeah »

mwcampbell wrote: post #144

I like the idea of abstractions that exist only in the source code and at compile time, and have zero runtime footprint. How does this compare to Google's Closure compiler and library? Does Svelte's compiler do anything that the Closure compiler cannot? Or how about running the source through a hygienic macro system like sweet.js and feeding the output of that to the Closure compiler? I ask because I'm skeptical of a…

But the google closure compiler have no concept of a tree of components and their lifecycle. The library is old, java-like and I never heard about someone using it :p

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

#149

Post by grzm »

boubiyeah wrote: post #148
mwcampbell wrote: post #144

I like the idea of abstractions that exist only in the source code and at compile time, and have zero runtime footprint. How does this compare to Google's Closure compiler and library? Does Svelte's compiler do anything that the Closure compiler cannot? Or how about running the source through a hygienic macro system like sweet.js and feeding the output of that to the Closure compiler? I ask because I'm skeptical of a…

But the google closure compiler have no concept of a tree of components and their lifecycle. The library is old, java-like and I never heard about someone using it :p

It's a key component of the ClojureScript tool chain.

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

#150

Post by arohner »

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…

One counter argument to the author's point is that there were many not-very-popular 2WB frameworks, until React and Angular came along. 1-way, top down clearly outcompeted 2WB.

In my own experience, I worked on an app that migrated from a 2WB (forgot the name, sorry) to React, and it was night-and-day difference.

Post reply on HN