Comments (15)
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 [email protected] 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.
from svelte.
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.
from svelte.
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 :)
from svelte.
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...)
from svelte.
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
from svelte.
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.
from svelte.
@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).
from svelte.
@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 ;)
from svelte.
@yyx990803 something like that ;)
from svelte.
@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.
from svelte.
@mrkishi was faster!
I think, DocumentFragment is an alternative, but <template>
is rather in the process of standardising.
from svelte.
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.)
from svelte.
Implemented this in 1.39.4 โ we now use textContent
and innerHTML
where it makes sense to do so.
from svelte.
"What, this new framework has a runtime? Ugh. Thanks, I'll pass" -- developers in 2018
Sadly not.
from svelte.
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
from svelte.
Related Issues (20)
- Add .effect() Method for State Changes in Svelte 5 HOT 2
- Dynamic loading of cdn-hosted Svelte 5 component HOT 8
- Svelte 5: If the reference of restProps changes, all the bindable props will revert back to their default value.
- Svelte 5 TS: `class` property in template literal causes Unterminated template / Unexpected token! HOT 3
- Svelte 5: $derived from context state causes extra renders in List/Item scenario (performance bug) HOT 2
- Custom action event typings don't get picked up properly
- Svelte 5: How to debug effect_update_depth_exceeded in a Svelte 4 library? HOT 5
- Svelte 5: `style:property="value"` doesnโt apply reliably HOT 5
- Unicode alphanumeric characters HOT 1
- Using `Component` for typing doesn't allow for any other props outside the required. HOT 5
- value change should not trigger when typeing ( compositionstart -> compositionend ) HOT 11
- Svelte 5: Add the ability to bind to snippet parameters HOT 2
- Svelte 5: Nested CSS does not work with the `:has` pseudo-selector.
- Svelte 5: Add ability to manually specify dependencies for `$effect` rune HOT 1
- Nested if blocks fail validation without a separating space
- When passing an imported $state as Object.values() to an external component reactivity does not work HOT 13
- Svelte 5: Event handlers are not working if thereโs `stopPropagation` between `<body>` and target element HOT 2
- Svelte 5: generated `strict_equals` causes cross-origin iframe SecurityError due to `get_proxied_value` attempting to read a property on a secure context HOT 3
- Deprecate `<svelte:self>`? HOT 2
- Effects require explicit property access to track properties of objects that are $state HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from svelte.