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

91–100 of 186 posts

Re: Svelte 3: Rethinking Reactivity

#91

Post by Vinnl »

rich_harris wrote: post #35
wontoncc wrote: post #33

I'm wondering how good Typescript support is. Can I use Typescript in the component script?

Sort of, via preprocessing, but you won't get any real benefit from it at present. There are two barriers: the compiler itself needs to become TS-aware, and we need to teach editors like VSCode how to typecheck inside blocks. It's very much on the radar (I'm a TS convert, personally — Svelte itself is written in TypeScript), we just need to get round to it. The version 3 rewrite was largely about laying the foundatio…

Svelte itself has been on my radar for quite a while - I think when proper TypeScript support lands, that will be the first time I'll actually give it a try for one project or another. The idea is intriguing, thanks for working on it!

Re: Svelte 3: Rethinking Reactivity

#93

Post by rich_harris »

davnicwil wrote: post #87
burrox wrote: post #73

Earlier quoted context omitted.

I think he means 'classical'as in class based. Just like you'd refer to 'classical' inheritance.

You might be right - I've never heard 'classical' used in that way, interesting!

You're both right — it's intended to be a slightly ambiguous low-key pun :)

Re: Svelte 3: Rethinking Reactivity

#94

Post by arxpoetica »

moosingin3space wrote: post #92

Very happy for this. I wrote a Firefox extension with Svelte v1, and will take this release of Svelte v3 as an opportunity to refactor my extension. Thank you, contributors!

Would be interested in learning the size difference. What does your extension do?

Re: Svelte 3: Rethinking Reactivity

#95

Post by rich_harris »

potiuper wrote: post #66

> Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. So, Svelte is compiled into web assembly? If not, given the emitted imperative code is less efficient than emitted web assembly and the emitted imperative code is less concise than the original declarative code, then what would be the advantage of an imperative translation of the dec…

See here for a discussion of WASM https://youtu.be/AdNJ3fydeao?t=1410

Re: Svelte 3: Rethinking Reactivity

#96

Post by rich_harris »

PKop wrote: post #89
rich_harris wrote: post #10

Earlier quoted context omitted.

Yep, and Svelte <3 Immer — they work nicely together.

Great work, just looking in to Svelte now after reviewing your latest release and video. First thing I looked for was routing, and I see Sapper is essentially batteries-included solution to using Svelte. Will these always be separate libraries? Is Sapper basically the create-svelte-app for your framework? What's the roadmap for Sapper and integrating Svelte v3 changes?

Bringing Sapper up to date is the next big task. In some ways yes, it's a bit like create-svelte-app, though a closer reference point if you're versed in the React world would be Next.js.

We've also mulled creating a React Router equivalent, for people who prefer components-as-routes to files-as-routes.

Re: Svelte 3: Rethinking Reactivity

#97

Post by dictum »

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

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!

Re: Svelte 3: Rethinking Reactivity

#98

Post by craftoman »

I was giving a chance to Svelte when it was upgrading to version 2 and releasing this compilation thing but it failed badly during a project that I was building due to some bugs of Svelte had with transpiling. Should I give it another chance?

Re: Svelte 3: Rethinking Reactivity

#99

Post by jarpineh »

Yes, the release I've been waiting for. I started to dabble with Svelte v2 right before coming of v3 was announced.

Are web component going to happen with v3? I am trying to combine Python server app with Svelte enhanced HTML and got good results on v2. I noticed they are marked as todo: https://svelte.dev/docs#Custom_element_API

Re: Svelte 3: Rethinking Reactivity

#100

Post by Vinnl »

rich_harris wrote: post #90
Vinnl wrote: post #88

Earlier quoted context omitted.

Funny: problems I think are important are "ship less code" and "read less code" (and perhaps "require reading less code to understand what's going on"). The writing part is not something I've considered to be especially problematic, thus far.

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

I actually read that just before this comment :)

Edit: Some more clarification about why the arguments don't hold for me.

- More code = more bugs

I think code that is harder to understand leads to more bugs, but more characters typed does not necessarily directly result in more bugs, as far as I know.

- Writing code takes more time

Again, it's not the typing that takes time, but thinking of which code to write. If I have to type more, but there's less for me to keep in mind while typing (i.e. lower cognitive load), I'll be faster at that.

As said: yes, readability is important, but that's a different value than "write less code".

I'm trying not to make a judgment about Svelte here specifically since I haven't worked with it yet, and the general concept (of being a compiler rather than working during run-time) appeals to me. That said, concepts like bindings do scare me - with e.g. `useState` I know that the only places that can change `a` are those that call `setA`, whereas it appears that with Svelte, it can also change e.g. in response to `bind:value` attributes? I'm (perhaps misguidedly) afraid that that's saving a few characters at the cost of readability.

Post reply on HN