DEV Community

Discussion on: A Look at Compilation in JavaScript Frameworks

Collapse
 
ryansolid profile image
Ryan Carniato • Edited

One day there probably will be something really powerful there. By that time will JavaScript be even more ubiquitous, and the reasons justifying it need to be greater? Maybe.

I think one of the interesting things is how much goes into what I describe in the article on the JavaScript side of things. I do a lot of benchmarking and we all know that hand optimized vanilla code is going to be the fastest. Rust+WASM has been closing the gap to the point now it is in dead heat in a JS targeted benchmark like the JS Frameworks Benchmark with a library like Solid.

However, that is low level vanilla code. We all acknowledge there there are more unlocks for WASM so I expect the gap to disappear with Vanilla JS and maybe even be quicker one day. However, the fastest WASM declarative libraries are much slower. Even ones using fine-grained reactivity. Now a portion of that is the same overhead I was referring to before that will be going away, but how much of it is because in JavaScript the template code we output doesn't even necessarily resemble what we input. We've added a layer to compile away the declarative code into more performant optimized code. By comparison I wonder how much longer before things built in Rust will follow suit. Will they ever be so inclined?

Size is also a real consideration in the browser. Every WASM solution I've seen is significantly larger. Maybe comparable to the larger JS frameworks like Angular or Ember but compared to say Svelte or HyperApp they seem monstrous. Something has to change in the way we consume/architect websites for this to be a reality.

So I think right now WASM delegated to special purpose things where high performance is necessary. Places where you can defer loading. Can we break free of that? Not sure. I watch WASM with great interest, but for different reasons. It seems as likely or more likely we see more performant server code written in JavaScript(TypeScript) than we get from Node today. Deno hints at it but I'm not sure that is the end of the story. Serverless WASM binaries seem pretty attractive as a deployment artifact for ecosystem flooded with JavaScript users.

EDIT: Speak of the devil this was posted today: bytecodealliance.org/articles/maki...

Collapse
 
december1981 profile image
Stephen Brown

Thanks for the very comprehensive response, and link. I didn't fully appreciate the issues with size, either.

Collapse
 
drsensor profile image
૮༼⚆︿⚆༽つ

What do you think about framework that mostly render in webgl/webgpu?
(e.g Flutter, PCUI, ...)

Thread Thread
 
ryansolid profile image
Ryan Carniato

I mean as long as the devices support them (which I imagine they do) there is a clear performance benefit here. I think there is concern that any work in this way to do general UI would involve basically re-inventing the core interaction points of the browser that we are used to. Things like accessibility etc.. I imagine any approach to do this in a general way basically would be building a DOM on top these technologies. You want declarative UIs etc... I think the biggest gap for them might simply being that they aren't the native implementation so there is always more work or code needed to run these. It is possible albeit unlikely at this point that a different standard could immerge.

I wanted to do some benchmarking with Flutter but the abstraction makes it hard to do apples to apples comparisons except with different versions of Flutter itself.