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

131–140 of 186 posts

Re: Svelte 3: Rethinking Reactivity

#131

Post by Aeolun »

Tade0 wrote: post #85

Hooks have some intriguing properties, but they also involve some unnatural code and create unnecessary work for the garbage collector. Thank you for pointing this out. To me hooks were always a way to solve problems in React that wouldn't be there if it weren't for React. They help, but come at a cost which barely anybody seems to talk about. We really want to add first-class TypeScript support. Yes, please!

Hooks solve a definite problem that I’m not sure is limited to React, but at the end of the day they feel too much like magic to me.

Reasoning about hooks is hard.

Re: Svelte 3: Rethinking Reactivity

#132

Post by atiredturte »

I'm currently working on a giant React frontend codebase and it's baffling how slow certain simple things are for our users. Yes it makes it easier for us to reason about, but performance should be able to scale without hacks.

Svelte seems to show a lot of promise, but I have a few things that I'm not 100% on.

1. How are the higher level abstractions for Svelte? Any framework can be easy for simple applications, but how easy will this be to reason about as we get to larger applications? React deals with this through a semi-functional mindset. What does Svelte offer?

2. Is there any plans for facilitating incremental rollouts? Changing your application to an entire new framework is not always worth it, and is greatly difficult. I could imagine Svelte being incredibly useful for large-scale, performant applications. However, unless it can be incrementally rolled out, then I can't see how the biggest players will be able to utilise the power of Svelte.

I'd love to see the game changed in web frameworks, and I love the idea of using compilers where possible. If anyone could answer these queries, I'd be very much grateful.

Re: Svelte 3: Rethinking Reactivity

#133

Post by tlrobinson »

atiredturte wrote: post #132

I'm currently working on a giant React frontend codebase and it's baffling how slow certain simple things are for our users. Yes it makes it easier for us to reason about, but performance should be able to scale without hacks. Svelte seems to show a lot of promise, but I have a few things that I'm not 100% on. 1. How are the higher level abstractions for Svelte? Any framework can be easy for simple applications, but…

> I'm currently working on a giant React frontend codebase and it's baffling how slow certain simple things are for our users. Yes it makes it easier for us to reason about, but performance should be able to scale without hacks.

What's the underlying reason for the slowness?

React applications can definitely be written to be performant without resorting to "hacks", typically using immutable data structures (that support reference equality checking) in combination with judicious use of PureComponent/shouldComponentUpdate/React.memo. Also using something like react-virtualized/react-window for large lists/grids.

Re: Svelte 3: Rethinking Reactivity

#134

Post by ummonk »

bauerd wrote: post #36

"The magical disappearing UI framework" was a much better tagline than "Cybernetically enhanced web apps" …

Yeah as someone who hasn’t heard of this before the first tagline would be far preferable.

It gives an inkling of the functionality and most importantly avoids “cybernetically” which makes the framework sound kooky.

Re: Svelte 3: Rethinking Reactivity

#135

Post by rich_harris »

atiredturte wrote: post #132

I'm currently working on a giant React frontend codebase and it's baffling how slow certain simple things are for our users. Yes it makes it easier for us to reason about, but performance should be able to scale without hacks. Svelte seems to show a lot of promise, but I have a few things that I'm not 100% on. 1. How are the higher level abstractions for Svelte? Any framework can be easy for simple applications, but…

Our vision for how to build large apps with Svelte is best represented by Sapper — https://sapper.svelte.technology — which is a Next.js-style framework. Right now it's a bit out of date, we need to spend some time bringing it in line with Svelte 3. That'll happen fairly soon.

Svelte is pretty well suited to incremental rollouts, because it doesn't have a chunky runtime foundation — it's not as though you have to ship two full frameworks simultaneously. There are some community-maintained adaptors for using Svelte components inside apps for other frameworks, I believe. You basically have to start at the leaf components and work your way in. An alternative approach would be to compile Svelte components to custom elements instead, since they can (in theory!) be used anywhere.

Re: Svelte 3: Rethinking Reactivity

#136

Post by oatmealsnap »

tlrobinson wrote: post #133
atiredturte wrote: post #132

I'm currently working on a giant React frontend codebase and it's baffling how slow certain simple things are for our users. Yes it makes it easier for us to reason about, but performance should be able to scale without hacks. Svelte seems to show a lot of promise, but I have a few things that I'm not 100% on. 1. How are the higher level abstractions for Svelte? Any framework can be easy for simple applications, but…

> I'm currently working on a giant React frontend codebase and it's baffling how slow certain simple things are for our users. Yes it makes it easier for us to reason about, but performance should be able to scale without hacks. What's the underlying reason for the slowness? React applications can definitely be written to be performant without resorting to "hacks", typically using immutable data structures (that supp…

I've never worked with React, but I have worked on giant AngularJS (1.x) apps and medium-sized Vue apps. I've only seen performance issues on pages with long repeated lists that create a lot of $watchers. This is fairly straight-forward to solve, and I know that Vue and Angular are both a lot smarter about tracking changes than AngularJS was.

Is React more difficult to keep responsive as an app grows? What sort of UI paradigms lead to poor performance? Just the phrase "using immutable data structures (that support reference equality checking) in combination with judicious use of PureComponent/shouldComponentUpdate/React.memo" makes it seem like you need lots of in-depth React knowledge and additional packages to write a performance React app.

Re: Svelte 3: Rethinking Reactivity

#137

Post by DonHopkins »

rich_harris wrote: post #82
dictum wrote: post #79

Earlier quoted context omitted.

"Less code" implies less authored code, which may be a benefit of Svelte (is it? I haven't been able to use it much but it's on my radar) but doesn't necessarily map to its technical goals (less built code, less runtime processing). (Quick example: the countless hello world projects that result in >100KB bundles)

Authoring less code is definitely an explicit goal: https://svelte.dev/blog/write-less-code

Ryan Tomayko would agree that's a noble goal!

http://lesscode.org/

Re: Svelte 3: Rethinking Reactivity

#138

Post by DonHopkins »

rich_harris wrote: post #101
dictum wrote: post #97

Earlier quoted context omitted.

Obligatory fanboy comment: it seems that every project you create moves web dev in a better direction, and you don't seem like a bad chap either!

Thank you, that means a lot!

You're not just moving web dev in a better direction, but also fact and data based journalism and visualization! I first learned of Svelt and Rollup (and became your fan) when I asked how you made that great NYT article, The Follower Factory! I'm glad you've kept working on Svelt, and I can't wait to see what you do next.

https://www.nytimes.com/interactive/2018/01/27/technology/so...

https://news.ycombinator.com/item?id=16247571

Re: Svelte 3: Rethinking Reactivity

#139

Post by tambourine_man »

The style of the talk was a bit overly confident to my taste, almost presumptuous.

But the idea of replacing a framework with a compiler blew my mind, so thank you.

And subverting the labeled statement is a wonderful hack. The kind that sticks.

I’m very impressed overall even if a bit scared from the “bad kind of magic” cited.

Re: Svelte 3: Rethinking Reactivity

#140

Post by wintorez »

revvx wrote: post #8

Immer.js (a library to work on data structures, not a framework) uses a similar concept, using Proxies. The gist of Immer is that your framework needs immutable structures, but you want to interact with them imperatively. It's very interesting, and a reversal of the traditional "functional core, imperative shell" architecture. https://github.com/immerjs/immer

I'm a huge fan of immer. I use it in all my React projects. It makes writing reducers a lot easier. Highly recommended.
Post reply on HN