Virtual DOM is pure overhead (2018) • Hacker News Board

Re: Virtual DOM is pure overhead (2018)

#341

Post by nsonha » Sun, May 26, 2019, 9:14 AM UTC

spankalee wrote: post #329

nsonha wrote: post #301

Earlier quoted context omitted.

the main reason templates are bad is not that it needs a build step, it's more about being non-standard (a problem lit-html doesn't have), and not statically analyzable (think typescript's jsx), which lit-html doesn't solve.

lit-html does solve the static analyzable problem, see https://marketplace.visualstudio.com/items?itemName=runem.li...

that's interesting to know.

Correct me if I'm mistaken since the motivation of the project isn't that clear on the home page: the main thing that makes lit-html special is the fact that it's just standard javascript.

This won't appear to typescript developers because they have jsx already built into the compiler. They can use lit-html and have their template type-checked too but it requires extra setup. What's the benefit here? That they can use class= and for=?

Re: Virtual DOM is pure overhead (2018)

#342

Post by nsonha » Sun, May 26, 2019, 9:29 AM UTC

lenkite wrote: post #304

nsonha wrote: post #301

Earlier quoted context omitted.

the main reason templates are bad is not that it needs a build step, it's more about being non-standard (a problem lit-html doesn't have), and not statically analyzable (think typescript's jsx), which lit-html doesn't solve.

Web Templates support slots and are analyzed at definition time. All this is native code supported by the browser so big heavy JS doesn't need go be sent across the network and then run even more slowly in order to produce HTML. All web-template based libraries beat React/Angular/any VDOM based alternative in performance and footprint.

"...support slots and are analyzed at definition time"

I don't know what you meant by this. As we speak, is there a standard implementation of this "Web Templates" thing? Can I open an editor, type "native" html, incorrectly assign to some attribute some callback with the wrong type and the editor tells me it's wrong without running the website?

As for "ALL web-template based libraries beat React...", is there evidence to substantiate such claim? Surely SOME of them are not that performant.

Also slots exist in most frameworks including Angular and in various 3rd packages in the React ecosystem.

Re: Virtual DOM is pure overhead (2018)

#343

Post by spankalee » Mon, May 27, 2019, 3:49 AM UTC

nsonha wrote: post #341

spankalee wrote: post #329

Earlier quoted context omitted.

lit-html does solve the static analyzable problem, see https://marketplace.visualstudio.com/items?itemName=runem.li...

that's interesting to know. Correct me if I'm mistaken since the motivation of the project isn't that clear on the home page: the main thing that makes lit-html special is the fact that it's just standard javascript. This won't appear to typescript developers because they have jsx already built into the compiler. They can use lit-html and have their template type-checked too but it requires extra setup. What's the be…

lit-html isn't _just_ about using standard JavaScript syntax. It's also about being more efficient than VDOM, very small, and having great HTML integration (you can set any property, attribute, or listen to any event, unlike with React).

Yes, you need a plugin for type checking with TypeScript. That doesn't seem to be a huge problem for users so far.

Re: Virtual DOM is pure overhead (2018)

#344

Post by nsonha » Fri, Jun 07, 2019, 2:45 AM UTC

spankalee wrote: post #343

nsonha wrote: post #341

Earlier quoted context omitted.

that's interesting to know. Correct me if I'm mistaken since the motivation of the project isn't that clear on the home page: the main thing that makes lit-html special is the fact that it's just standard javascript. This won't appear to typescript developers because they have jsx already built into the compiler. They can use lit-html and have their template type-checked too but it requires extra setup. What's the be…

lit-html isn't _just_ about using standard JavaScript syntax. It's also about being more efficient than VDOM, very small, and having great HTML integration (you can set any property, attribute, or listen to any event, unlike with React). Yes, you need a plugin for type checking with TypeScript. That doesn't seem to be a huge problem for users so far.

I appreciate that it's more efficient than VDOM, if it's true and continue to be true in larger scale apps. I don't see "can set any property, attribute, or listen to any event" a benefit though. To me it's such an unpleasant way of writing code to have to keep in your brain a map of all these event and prop bindings.

If you need events, Rx is much better to work with. Probably the one thing react is not as good as html elements is the lack of attributes, this causes a lot of defaultValue and shouldComponentUpdate kind of complications. However, if you really think about it all props should just be immutable (attributes) and if you want some to be updated or emit events, just make them Observable and Observer accordingly.