4 ms·
Some retrospective ... Ten years ago browsers were capable to do pretty much the same but with Java on board that they all had at those times. WebAssembly is
by c-smile 7y ago
Some retrospective ...
Ten years ago browsers were capable to do pretty much the same but with Java on board that they all had at those times.
WebAssembly is conceptually close to JavaVM (JITed bytecodes) but due to its architecture Java allowed as a) reflection (JS to Java calls) as b) exposure of DOM model into Java execution space - DOM API even now is defined in terms of Java interfaces by the way.
WebAssembly is a step in right direction but the evolution looks as Waltz - two steps forward two steps back with the twist.
Now we are able to run ray tracers compiled to WA on browser side but we've lost an option to apply the results to DOM elements directly.
To say in CSS:
my-component {
behavior: my-native-event-handler url(controllers/my-controller.class);
flow: my-native-layout-manager;
}
- nine_k 7y agoJVM is seriously more complex and heavier-weight. It does too much, and is shaped by Java the language too much (no functions, only objects!). It brings in mandatory GC. It's built around shared mutable data. WA is much smaller, assumes way less, is isolated from DOM and JS code way better, communicates with them via message-passing. It has a smaller attack surface, and less room to screw up in the implementation. Yes, I think not having WA married to DOM is a good idea from many angles. One of them is security, of course. Another is wider applicability: a WA VM could be useful outside the browser, and it already is.