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

Svelte 3: Rethinking Reactivity

svelte.dev

Post reply on HN
Print view View original

161–170 of 186 posts

Re: Svelte 3: Rethinking Reactivity

#161

Post by Vinnl »

Improvotter wrote: post #128
rich_harris wrote: post #90

Earlier quoted context omitted.

Allow me to try and convince you of its importance :) https://svelte.dev/blog/write-less-code

What are your opinions of Go where it is the general idea to only have 1 way to do something, and make that way the best way?

I have not used Go, or even looked at it, so I can't really give a well-reasoned comment about it. As for the general principle of having just one way to do something: I don't think that's a general rule that I'd prefer, because I don't believe there's always a clear best way.

I think my problem with two-way data binding is not so much that it's an additional way to update a value, but that it doubles up as reading and writing a value, and with that makes code somewhat harder to read. However, as I noted in response to Rich, that might not be a problem if that is only limited to variables bound to forms, but I'd have to try it to get a better feeling for that.

But I'm getting off-topic, so the answer is: I don't really have an opinion about Go, but the general principle you describe is not one that attracts me.

Re: Svelte 3: Rethinking Reactivity

#162

Post by PudgePacket »

nojvek wrote: post #154

I went through the tutorial. It’s quite confusing. I’ve been doing front-end SPA apps for about 10 years now. The framework that has blown me away with it’s simplicity and elegance but power is snabbdom. It’s small, it’s fast, it’s modular. You can use it with jsx, you can use it with webcomponents if you want. You can type it with typescript. Animations check, custom module extensions, check. As the recent experimen…

The whole point is that there is even less magic than react, vue etc. If you have time I'd strongly encourage you to watch the video shown in the post.

https://svelte.dev/examples#dom-events Look at the compiled output (the "JS output" tab), it's so readable and stepping through it with a debugger is actually possible for mortals unlike trying to step through code using react (I know, I've had to do it..).

Re: Svelte 3: Rethinking Reactivity

#163

Post by TeMPOraL »

bjz_ wrote: post #113
tux3 wrote: post #5

I'm really impressed that the release announcement starts by explaining what Svelte is. It's a little thing, but it's appreciated.

Yeah, I first saw this approach taken by the Rust announcements in the early days. It's a great demonstration of empathy to the reader!

In particular, I think this is a recognition of the fact that people these days don't follow random projects, but they do follow social media feeds and news aggregators like HN or Reddit. So an average reader may come to the post not because they know and care about Svelte, but because the link being on their favourite aggregator lent it credence as something worth reading.

Re: Svelte 3: Rethinking Reactivity

#164

Post by eliseumds »

How easy would it be to "hook into" Svelte's compilation pipeline so that users can create their own optimisations? I ask that because I work in a huge codebase with many layers of component abstraction and performance is starting to take a hit. For example, most of these components:

  
    
      Profile info
    
    
      
      
        {displayName}
would be compiled into their simplest forms:

  
    
      Profile info 
    
    
      
      
        {displayName}
I believe the technique is called "component folding". I tried to do it with Babel but it's a real pain.

Thanks for putting so much work into exploring alternative ways of making the web faster, because, at the moment, it still requires an immense effort.

Re: Svelte 3: Rethinking Reactivity

#166

Post by artemir »

eliseumds wrote: post #164

How easy would it be to "hook into" Svelte's compilation pipeline so that users can create their own optimisations? I ask that because I work in a huge codebase with many layers of component abstraction and performance is starting to take a hit. For example, most of these components: Profile info {displayName} would be compiled into their simplest forms: Profile info {displayName} I believe the technique is called "c…

Yeah, I search the same solution. Because, I don't like write CSS and prefer use component abstraction layer, which allow write much simple code and it's really nice to read

Re: Svelte 3: Rethinking Reactivity

#168

Post by vladimir-y »

inglor wrote: post #18
stupidcar wrote: post #7

Odd that they don't mention Angular amongst the component-based frameworks, as what they're describing sounds very similar to Angular's compiler and change-detection system.

Actually Angular does this with Zones which is a different Reactivity system. This is actually quite similar to what PostSharp did with WPF where it injected INotifyPropertyChanged and WPF compiling its getters and setters. Then it's also similar to KnockoutJS (inspired by WPF), MobX (inspired by Knockout) and Vue (also inspired by Knockout)

Zones is only responsible for triggering change detection caused by user/external input. It's possible to use Angular without Zones.

Re: Svelte 3: Rethinking Reactivity

#169

Post by vladimir-y »

rajangdavis wrote: post #120

What I think is really interesting is that the Virtual DOM was touted as the better abstraction when React came out (in comparison to Angular 1's dirty checking). I think Svelte is doing a lot of things right (simple code, computing CSS animations, accessibility built in, focusing on a compiler versus a full on framework) and I can't wait until Sapper is updated to dig in.

> focusing on a compiler versus a full on framework

Angular goes a similar way, just look up Ivy renderer on the internet.

Re: Svelte 3: Rethinking Reactivity

#170

Post by gregwebs »

reminds me a bit of a very old project called FlapJax: https://www.flapjax-lang.org/tutorial/

Elm is a compile to JS language with a small footprint (it does still use a virtual-dom though). It would be nice to see a size comparison of the two. https://elm-lang.org/blog/small-assets-without-the-headache

Post reply on HN