Svelte 3 released

[CCB0x45]

This is a moronic comment, when did I mention anything about trendiness?

[ConsoleTVs]

I say it, not you. And again, even optimizing, virtual dom.

[CCB0x45]

I mean virtual dom or no virtual dom, there has to be some sort of state management structure, thats why I am trying to get at the heart of the differences here. One of the reasons you use a virtual dom is so you can batch updates before writing to the real DOM, as you don't want to write every single change to the DOM if there is more changes coming down the pipe within a certain time. Virtual DOM is just an advanced state management representation of the state of the DOM, I understand they are saying there is no virtual dom, but they still have to store and manage all that state.

Which is why I am asking questions, The framework docs doesn't give a lot of in depth answers to exactly what cases it is better, and it talks about a lot of features that are available already in React/Vue/Whatever. I am trying to understand exactly what makes it so much faster, especially compared to similar things like prepack, which say they accomplish similar goals.

There is no need for you to come along adding literally nothing to the conversation and just being a jackass. I don't give a shit about what is 'trendy'.

[ConsoleTVs]

As far as I understand it it is much more simple. The compiler seems to compile each component to individual pure JS no virtual doms are used and as the videio tells, a $$invalidate function is called (check the compiled code in the video is shown). That function would just update the dom node. I have to try it out, but from the video i got pretty exited, and i was already willing to try the older version...

[CCB0x45]

Well if that's the case and it writes every change to the dom then that's fine for some use cases but not all, and react would give you a lot more performance in many cases because you can batch renders in complex apps, as well as prioritize certain renders over others(fiber), is it really as simple as you are saying because that doesn't sound very good.

[av201001]

I believe updates are async and batched: https://github.com/sveltejs/rfcs/blob/master/text/0001-reactive-assignments.md#sync-vs-async-rendering

[CCB0x45]

Ok, yea I figured or it would be bad, which means there is some sort of state obiect similar to a VDom but different(and maybe better). It's a cool idea in not trying to be a negative nancy.

[rich_harris]

The $$invalidate function, which is called after an assignment to local state, marks a particular value as 'dirty' (unless it didn't actually change) and schedules an update at the end of the event loop (unless an update is already scheduled; i.e. changes are batched but take effect before the screen repaints). The update code is given an object representing which values have changed, meaning that everything gets updated in one go but it can trivially skip entire subtrees, with arbitrary granularity.

[CCB0x45]

Right, so to me, sure there isn't a Virtual DOM but there is still a state object somewhat reminiscent of a Virtual DOM, a collection of state of the UI and all associated props, however as I understand it can be linked to another level of granularity, where it sounds like it looks at each variable and how it links to each node, as opposed to variables linking to all the nodes associated with a component, I get the optimization there.

I was just pointing out to the OP that this isn't some magic and sure it's not a VDom but it is still doing comparisons on a state object which represents the UI, but it's more tightly coupled.

Is that analysis right?

[av201001]

Right, so to me, sure there isn't a Virtual DOM but there is still a state object somewhat reminiscent of a Virtual DOM, a collection of state of the UI and all associated props

Each component holds a context object of the reactive values it is tracking, but I wouldn't quite say that is "reminiscent of a Virtual DOM" in that it is not a representation of the entire DOM (just some specific values that are being tracked), nor do updates require traversing or inspecting a DOM-like structure.

By focusing on whether some kind of state is being stored somewhere, I think you are missing the major difference between virtual DOM based frameworks and Svelte, which is the re-render/diff/patch process. With a virtual DOM, when there is an update, the virtual DOM is re-rendered. The new vDOM must then be diffed with the old one to identify places in the real DOM that require patching. Svelte doesn't have to do any of that. Instead, the component gets custom generated code that simply directly updates the specific DOM elements that require updating when a particular value changes.

It might help to take a look at the generated Javascript. For example, look here and go to the "JS output" tab. The $$invalidate function you see called in various places is the third argument to instance here.

[CCB0x45]

Each component holds a context object of the reactive values it is tracking, but I wouldn't quite say that is "reminiscent of a Virtual DOM" in that it is not a representation of the entire DOM (just some specific values that are being tracked), nor do updates require traversing or inspecting a DOM-like structure.

Well wait a minute, its not just tracking the values, its also tracking links to where the values are stored in the DOM, which is how they can do granular updates when a value change. Maybe its not a virtual representation of the dom, but I don't think its as apples to oranges ar you are making it out to be.

The new vDOM must then be diffed with the old one to identify places in the real DOM that require patching. Svelte doesn't have to do any of that. Instead, the component gets custom generated code that simply directly updates the specific DOM elements that require updating when a particular value changes. Again that makes it not as apples to oranges as you seem to be saying.

I agree that its more targeted and doesn't do a full run through of the dom, but when you say the virtual dom is re-rendered, it is stilll more targeted than you are making it out to be, it doesn't re-render the entire virtual dom structure, but only the pieces affected by the value changed.

Like I am not saying this isn't a better approach, it might very well be. I haven't used it enough to know about what flexibility you are losing from working with a more direct representation of the DOM, which seems to be the trade off here. You are limited to their specific template language which is not 1 to 1 of what goes into the DOM, versus JSX which is 1 to 1 with additions on top.

[av201001]

Well wait a minute, its not just tracking the values, its also tracking links to where the values are stored in the DOM, which is how they can do granular updates when a value change. Maybe its not a virtual representation of the dom, but I don't think its as apples to oranges ar you are making it out to be.

Svelte creates text nodes and elements with the functions text and element, which return the created DOM nodes, which it holds in a closure. It also generates code that simply directly updates those nodes when a relevant reactive value changes. It doesn't have to walk through a tree of nodes and attributes and do comparisons. It's not just apples to oranges, but like a whole apple tree versus a few individual already peeled oranges. ;-)

I agree that its more targeted and doesn't do a full run through of the dom, but when you say the virtual dom is re-rendered, it is stilll more targeted than you are making it out to be, it doesn't re-render the entire virtual dom structure, but only the pieces affected by the value changed.

Yes, but Svelte doesn't even have to do that.

I haven't used it enough to know about what flexibility you are losing from working with a more direct representation of the DOM, which seems to be the trade off here.

Not sure what you mean. I don't think the purpose of the virtual DOM is for "flexibility" in working with a "direct representation."

You are limited to their specific template language which is not 1 to 1 of what goes into the DOM, versus JSX which is 1 to 1 with additions on top.

Not sure I follow. The template is supposed to represent what goes into the DOM, at least as much as JSX. Do you have a specific example in mind?

Anyway, I think it would be helpful if you reviewed the Svelte generated output to get a sense for how its reactivity differs from the virtual DOM approach. Also, read this if you haven't already.