Use innerHTML for static elements?

[Rich-Harris]

Would need to compare performance, but it's entirely possible that in cases where you just have a bunch of static markup inside an element, it would be quicker to use node.innerHTML = markup rather than constructing the DOM programmatically.

[evs-chris]

It seems that innerHTML is usually faster for larger bits of markup (according to jQuery, jsperf has been mia for a while so good cross browser comparisons are harder to come by). It also has the advantage of being considerably less code. Event listeners are a little trickier, but having a document ast means you could easily attach listeners with a direct path to the child. I believe the same approach to transitions would even be reasonable.

[trueadm]

Actually, in my testing, even with a large amount of node, createElement and appending it to the DOM is still quicker in all my testing. Good luck with svelte though – I like the name :)

[Rich-Harris]

Yeah, digging around it seems you get different answers depending on what browser you're looking at and what time of day it is! @trueadm are your tests in a reproducible form online somewhere? Would be keen to poke them a bit – Inferno is still a tiny bit quicker than Svelte at dbmonster, but if I steal enough of your research that may change 😀

Event listeners are a little trickier

By static I was excluding nodes with any kind of directive (on:, bind:, ref: and so on), but yeah, you're right – I guess it'd be just as easy to plonk some innerHTML in and do...

div.innerHTML = `<div class='inner'><span>click the button</span><button/></div>`;
var button = div.childNodes[0].childNodes[1];

...if there was a situation where that was faster. (I guess you could even optimise for specific browsers at build time if there was a difference...)

[trueadm]

I have the benchmarks somewhere. I'll dig around for them tonight. On a side note I need to update the inferno benchmarks online, they use a slower older version. I'd recommend doing the JS-framework benchmark too.

I know this is unrelated: but supporting JSX like Vue2 does would be a huge win. You'd be able to pull in a lot of users who have moved to that way of building components, even letter people mix it up a bit. Would that be possible?

On 23 Nov 2016, at 17:11, Rich Harris notifications@github.com wrote:

Yeah, digging around it seems you get different answers depending on what browser you're looking at and what time of day it is! @trueadm are your tests in a reproducible form online somewhere? Would be keen to poke them a bit – Inferno is still a tiny bit quicker than Svelte at dbmonster, but if I steal enough of your research that may change 😀

Event listeners are a little trickier

By static I was excluding nodes with any kind of directive (on:, bind:, ref: and so on), but yeah, you're right – I guess it'd be just as easy to plonk some innerHTML in and do...

div.innerHTML = <div class='inner'><span>click the button</span><button/></div>;
var button = div.childNodes[0].childNodes[1];
...if there was a situation where that was faster. (I guess you could even optimise for specific browsers at build time if there was a difference...)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Rich-Harris]

You mean https://github.com/krausest/js-framework-benchmark? Yeah, it's on my TODO list, once I've wrapped my head round it.

Would that be possible?

I thought about it, yeah. I don't think it is. Svelte works because it has very clear compile-time guarantees about the structure of your application. I don't really see a way that that's possible with JSX, since it's 'just JavaScript' and therefore impossible to fully statically analyse.

But I don't think that's a huge problem. I know a lot of people really like JSX, but in my experience people who are familiar with both React and Vue or React and Ractive prefer the Vue/Ractive style. Templates are just a better fit for the task of describing a UI, in my view. Rule of least power and all that. You probably disagree with me on that :)

I expect people to be sceptical at first, but to come round when they realise the benefits. Maybe not to Svelte in particular, but to the idea in general of declarative components that compile to raw JS.

"What, this new framework has a runtime? Ugh. Thanks, I'll pass" –developers in 2018

[yyx990803]

Re JSX: I actually thought about the possibility of writing an alternative Vue 2 codegen like this, but making it compatible with raw render function usage seems quite hard. You either have to include a vdom runtime (which defeats the purpose of svelte), or try to statically analyze the render function code. However templates are naturally much more statically-analyzable as compiler inputs - JSX/render functions involves too much runtime JS behavior to safely generate svelte-style output.

[trueadm]

@yyx990803 I've actually been playing around with the idea of compiling pure render functions into Rust and then using them in WASM. Hasn't been smooth, but I've not had a lot of time to invest into it to be honest. From my initial experiments, all I can say is: it's definitely the future in terms of raw performance. I wish I could show you benchmarks even if the render functions were trivial – you'd be stunned (legal reasons why I can't, sorry).

[yyx990803]

@trueadm wow, I assume the code compiled to WASM still needs to talk to the DOM? At that point the real bottleneck would be the browser not the frameworks ;)

[trueadm]

@yyx990803 something like that ;)

[mrkishi]

@trueadm Hey, did your benchmarks include a <template>-based solution, by any chance? I wonder if they might be competitive with createElement at this point.

[Ryuno-Ki]

@mrkishi was faster!

I think, DocumentFragment is an alternative, but <template> is rather in the process of standardising.

[PaulBGD]

Have there been any benchmarks in the last 8 months showing DocumentFragment performance? From what I've seen with a few searches, there aren't many benefits unless you're doing a lot of cloning (such as 2 copies of a component in 2 places in the DOM, assuming they have the same state.)

[Rich-Harris]

Implemented this in 1.39.4 — we now use textContent and innerHTML where it makes sense to do so.

[JadedBlueEyes]

"What, this new framework has a runtime? Ugh. Thanks, I'll pass" -- developers in 2018

Sadly not.

[nathancahill]

Found an interesting side effect/bug(?) with this. When a <script> tag is inserted via innerHTML the script isn't executed. In development mode, the script is executed since it's created as an element. This means that the problem only surfaces in production. The workaround is to add a variable to the <script> tag to force element creation.

Here's an example of the broken version and the workaround: nathancahill/split@ead9da3