For the sake of an example, let's stop "pure, simple" hello world with `let x = 1;`.
Instead, please put some real async stuffs, how to manage state, how to put state into many small components.
Examples, not just documentation matters.
Svelte 3: Rethinking Reactivity
151–160 of 186 posts
Re: Svelte 3: Rethinking Reactivity
#152For the sake of an example, let's stop "pure, simple" hello world with `let x = 1;`. Instead, please put some real async stuffs, how to manage state, how to put state into many small components. Examples, not just documentation matters.
There's an incredibly thorough tutorial with an IDE and examples of all of the things you mentioned plus TONS more. It was super easy to find... https://svelte.dev/tutorial/writable-stores
Re: Svelte 3: Rethinking Reactivity
#153This is really cool. That said, I noticed that it cites performance vs vdom as a selling point. Something I've been wondering lately is how big of an issue is UI performance for most web apps really? So many of the little apps and prototypes I develop aren't hurting for performance. It seems to me the industry made a huge leap from JQuery/Backbone/etc to reactive/vdom. But declarative UIs and virtual doms don't solve…
Large React apps get slow very easily once the component density gets high in a complex web app. Part of the reason for that is actually the overhead of a virtual DOM.
Re: Svelte 3: Rethinking Reactivity
#154I 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 experiments in wasm has shown, you can make extremely fast vdom diffing that is memory allocator friendly.
So my bet in the future is this. Vdom will be here for a while. It’s simple, elegant and we’ll figure out how to make it faster with newer tricks.
More non web UI frameworks will use similar approaches. React Native is paving wave here but I can see desktop apps and terminal apps embrace the same concepts too.
View as function of state is a very powerful paradigm. State being a simple dumb old nested object. No magic tricks.
Svelte feels too magical. Vue has same issues. It’s hard to reason with magic when you hit edge cases.
You ideally want a simple model in your head so you can build really complex apps by connecting simple axioms of logic.
Re: Svelte 3: Rethinking Reactivity
#155For the sake of an example, let's stop "pure, simple" hello world with `let x = 1;`. Instead, please put some real async stuffs, how to manage state, how to put state into many small components. Examples, not just documentation matters.
He did that. Go through the tutorial, it is extensive.
Re: Svelte 3: Rethinking Reactivity
#156Re: Svelte 3: Rethinking Reactivity
#157I 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…
Did you watch the video embedded in the blogpost? Rich Harris talks about both speed (including the Dodrio vdom in Rust/WASM experiment) and magicalness.
Re: Svelte 3: Rethinking Reactivity
#158I'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…
Do you have any estimate on how much work that'll be? Do you think you'll be able to land TS support (including type-checking through the command line) within half a year, or is that a bigger thing?
Re: Svelte 3: Rethinking Reactivity
#159In case you're reading this, Rich, thank you for choosing the term "compiler" and not "transpiler" when describing what Svelte is!
Re: Svelte 3: Rethinking Reactivity
#160Earlier quoted context omitted.
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…
> more characters typed does not necessarily directly result in more bugs, as far as I know Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed does result in more bugs. I learned that from the internet though, so take it with a grain of salt! It's true t…
> Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed does result in more bugs. I learned that from the internet though, so take it with a grain of salt!
It's an interesting subject, but I'd like a causal explanation rather than just the correlation. For example, this would imply that TypeScript code would be more buggy than its Javascript equivalent, since it's the same code I'd write otherwise, with additional annotations. (Then again, there is some code, like null checks, that I don't have to write with TypeScript, so perhaps that evens out.)
> I think that's less effective at capturing the intent of your code
It's been a while since I've worked with Angular.js, the last framework I used with two-way databinding, but now having this conversation I think I recall the main reason it was confusing. A pattern that would sometimes arise is e.g. for a component to receive data through a two-way databinding from its parent, and then likewise passing that on to a child. That could make it very hard to trace where a change was coming from.
It might well be the case that it is far less problematic when e.g. only used to bind form values. Again, I'd have to try it to get a proper feel for it, so I'm looking forward to doing that.