Is there a DevTools which allows us to view the tree of components and manipulate it, like Vue does? Is there a script tag mode so it can replace jquery?
Svelte 3: Rethinking Reactivity
171–180 of 186 posts
Re: Svelte 3: Rethinking Reactivity
#172Earlier quoted context omitted.
> 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…
> It's an interesting subject, but I'd like a causal explanation rather than just the correlation.
A large benefit with less code is about the signal/noise ratio. If you need plenty of boiler plate logic, you will have less signal that you can physically read & mentally process at a given time. We naturally ignore the noise, but the noise takes screen space & miscategorizing noise leads to bugs.
Less code leads to less bugs, especially high-level bugs, because the programmer can see more signal at a given time, thus being exposed to a larger system.
The study that Rich mentioned could be interpreted as relating to the comprehension of the code, where more code inherently means the system has more information & is more difficult to comprehend.
Re: two-way binding, the data flow is inherently confusing whether you use imperative or declarative logic. Do you want a clear concise representation or do you want to spread out the implementation over more code/files?
Re: Svelte 3: Rethinking Reactivity
#173Hooks 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.
I find this interesting. Could you give an example of a case you find hard to reason about?
Re: Svelte 3: Rethinking Reactivity
#174Is the frustration meter shown in the talk video part of that original benchmark? Or is it something we could run on top of any page?
I had a search around, but didn't find anything.
Re: Svelte 3: Rethinking Reactivity
#175Is the frustration meter shown in the talk video part of that original benchmark? Or is it something we could run on top of any page? I had a search around, but didn't find anything.
Re: Svelte 3: Rethinking Reactivity
#176Mithril.js has been doing plain javascript variables for years :) Basically, React's decision to use setState is an overoptimization. Mithril (and flutter, interestingly) opts for global redraws, greatly reduces end-user code complexity while still being fast for most all cases.
Thanks for mentioning Mithril. When I saw Svelte example output js, I thought it was actually a better developer experience layered on top of Mithril. (Mainly because of the similar m() mounting function)
```
function create_fragment(ctx) { var h1, t0, t1, t2;
return { c() { h1 = element("h1"); t0 = text("Hello "); t1 = text(name); t2 = text("!"); },
m(target, anchor) {
insert(target, h1, anchor);
append(h1, t0);
append(h1, t1);
append(h1, t2);
},
p: noop,
i: noop,
o: noop,
d(detaching) {
if (detaching) {
detach(h1);
}
}
};```
Re: Svelte 3: Rethinking Reactivity
#177Earlier quoted context omitted.
> 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…
> It's an interesting subject, but I'd like a causal explanation rather than just the correlation. A large benefit with less code is about the signal/noise ratio. If you need plenty of boiler plate logic, you will have less signal that you can physically read & mentally process at a given time. We naturally ignore the noise, but the noise takes screen space & miscategorizing noise leads to bugs. Less code leads to le…
Absolutely, and "higher signal-to-noise-ratio" is something I'd count as a selling point. However, I don't believe fewer characters necessarily result in a higher ratio.
So in the case of two-way data binding, if I'm trying to trace how a certain value was be modified, data flow in the opposite direction might count as "noise", in terms of extra cognitive load.
Again, this might not be something that is the case for Svelte, but it's what I observed in Angular.js.
Re: Svelte 3: Rethinking Reactivity
#178What 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.
That's very interesting! Stopped paying attention after Angular 2 was released... will take a look, thanks for the info!
Edit: It looks like the goals are a bit different with Angular's focus on Typescript (Svelte let's you do this but is not entirely focused on Typescript). Also not sure if Angular's compiler supports CSS compilation.
Re: Svelte 3: Rethinking Reactivity
#179This 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…
It's really surprising that people put faith in virtual Dom implementations, when browsers have been optimized for decades for efficiency. With the right batching strategy that minimalistic libraries like FastDom [1] offer, there's no real reason to use the virtual Dom. A frequent argument for the use of vdom has been that it reduces Dom trashing. I am willing to bet that if a vdom library has figured out what elemen…
People used to look at me like I was crazy when I told them that React is nice, but you can actually write faster code with alternative methodologies. It seems like other engineers are coming around to this and creating these faster alternatives.
React made writing frontends generally better, but often slower and as rich_harris points out that it entails a lot of developer work to build and use optimizations to speed it up.
Re: Svelte 3: Rethinking Reactivity
#180>> Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.
The best and self-defining para from article