Lit-html is faster than react + vdom - and has 6kb instead of 60kb. And back in the time everyone used jquery, the arguments are always the same.

heh, I've worked for companies that hit the max on cookie size (which I think is around 60kb). For an entire framework to be 60kb would be amazing for these companies :)

Wow - 60kb for cookies is crazy.

Where's the benchmark showing this?

https://stefankrause.net/js-frameworks-benchmark8/table.html - thats old lit release there vs react 16 (react pre 16 would be slower and everyone agrees its generally fast already), on slack channel I believe I saw newer release benchmarks that are better (it also depends at which specific test you look at).

New version of repeat is interesting:

https://slack-files.com/T03PF4L4C-FCY51FZAB-c2fcf32931

I compared my usual candidates: vue, inferno, Surplus and vanillajs, and lit-html was dead last overall in almost every category. Also slower than Preact now that I checked, so I'm not sure that performance benefits are one of lit-html's unique strengths.

Yup, notice that from the slack screenshot that I posted it has speed mark 1.18 that puts it before Vue in terms of speed (which makes it plenty fast IMO, and its not even stable yet), I never claimed it is the fastest one of the bunch.

Nicoburns said that "performance question is not solved" - I think we can agree than svelte and lit are fast in general, that was the point I wanted to make that it is the implementation that matters here.

There you go, https://rawgit.com/krausest/js-framework-benchmark/master/we..., much faster than vue and react (still not inferno speed yet, but the gap is closing).

Not bad. I'm always amazed at Surplus though, that's the one to beat!

I don't know what you mean by "the performance question". A web component uses the same DOM APIs that React/etc. uses so it can have performance as good or better depending on how it is written.

The problem is coordinating rendering between components. React and similar frameworks optimise performance by batching DOM updates in one big read-compute-write cycle. With web components that don't share centralised DOM manipulation code its hard to see how that would work, and this can be a big performance problem.