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

211–220 of 236 posts

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

#211

Post by danmaz74 »

rich_harris wrote: post #82
danmaz74 wrote: post #14

Earlier quoted context omitted.

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.

The biggest problem with web apps today is the initial load time, not the total size of the app. If you can't render the first page the user lands on without serving a large framework, you're stuck. But yes, an app built entirely out of standalone components would eventually overtake the total size of an app built using a more conventional framework. (By the time you get there, your app is probably already too big an…

This approach looks very interesting for javascript-enriched pages, but not as much for SPAs. Anyway, interesting to know about the deduping idea.

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

#212

Post by theasker »

majewsky wrote: post #210
theasker wrote: post #154

Earlier quoted context omitted.

Also doesn't work on Safari 9. Why not transpile the Svelte compiler to ES5 so it will run on all browsers? Otherwise devs may get the impression Svelte generated applications will not work on all browsers.

Exactly. My main gripe is that it won't even display the source code. I would be okay with the execution part of the REPL not working, but this just creates the impression that Svelte literally cannot display a block of text without ES6.

I don't want to be too harsh on the Svelte author. It's a minor inconvenience.

The guy did some incredible work - he wrote all of this code in a week. I'll look at the REPL code to see if there's a simple fix. All the levels of indirection, code generation and bundling may take a while for my non-Rich-Harris brain to sort out.

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

#215

Post by ergo14 »

ChemicalScum wrote: post #7

I like how they solved scoped css. Looks way more elegant than most css-in-js solutions I've seen. I could give it a shot for this reason alone.

Web components and polymer solve this problem "completly" by full encapsulation.

With some css preprocessing + vulcanizing you can even use separate js/css files from your component templates if that is your thing - they can get inlined in the build process.

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

#216

Post by nitrogen »

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…

Two-way binding is being used without popular mention in some industry-specific areas. The area I'm familiar with is control software for audio processing hardware. Lots of different processing platforms allow the creation of control panels with a drag-and-drop UI, and all widgets assigned to the same hardware state variable are also linked to each other, in all directions.

I also implemented my own two-way/omnidirectional data binding system ages ago (before I knew what it would even be called) in Java Swing for another audio UI, and all the challenges you mention are real, but as you say, not insurmountable. Multiple copies of my UI can be controlling the same hardware, and they will all remain in sync without infinite feedback loops, but getting there took lots of work.

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

#217

Post by camwest »

fnordsensei wrote: post #205
camwest wrote: post #179

Earlier quoted context omitted.

Don't quote me on this but I'm pretty sure gmail uses it. I'd say that's a pretty big endorsement.

From what I've read, also Docs/Drive and Maps. It IS old (well, 2009 counts as old I guess), but it's still maintained, and still doing what it says on the tin. That's quite an achievement in and of itself.

Yeah I think I read it here: http://shop.oreilly.com/product/0636920001416.do

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

#218

Post by mpweiher »

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…

That's a nice description of the problems.

Dataflow constraints with solvers like DeltaBlue solve these problems and allow you to incrementally add additional constraints.

I show how this works for a simple example in my paper "Constraint as Polymorphic Connectors"[1]. I also show that constraints are useful for expressing the high-level architecture of many interactive systems and suggest how to two might be connected.

[1] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

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

#219

Post by spraak »

rich_harris wrote: post #161
spraak wrote: post #107

Earlier quoted context omitted.

Er, can you explain further with an example? I'm confused about using both something like {{#if}} and pure JS

See e.g. http://bit.ly/2fRcyJq . The {{#if ...}} part is a control flow directive that allows Svelte to understand the structure of your app, but the condition of that if block is just a JS expression

But it's limited to if, else, and elseif expressions?

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

#220

Post by TheAceOfHearts »

boubiyeah wrote: post #77
devdoomari wrote: post #54

Earlier quoted context omitted.

checkout css-modules! https://github.com/css-modules/css-modules

Yep, happily using css modules too. The only tiny issue left with that approach is that you still can't share code (for instance, colors) between JS & CSS. but overall, I think it's the best compromise today.

Look at css-module-values [0]. It's not perfect, but it lets you share values between JS and CSS. All values in the file are visible on the imported module.

[0] https://github.com/css-modules/postcss-modules-values

Post reply on HN