51–60 of 97 posts
Earlier quoted context omitted.
For now, JavaScript is required to initialize the WebAssembly module.
Why was it not given same level usage?
(This would be one of the major design questions with such a thing. Not insurmountable! But given you’re already connecting it to JS functions...)
Earlier quoted context omitted.
Why was it not given same level usage?
How do you set up the imports with script? (This would be one of the major design questions with such a thing. Not insurmountable! But given you’re already connecting it to JS functions...)
Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web development.
That overhead has been greatly reduced in Firefox recently.
Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web development.
Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web development.
This is a constant theme on Reddit at r/programming. It is based upon nothing but fear of web technologies (yes, I literally mean fear as a raw and savage emotion) and a lack of understanding what WASM is. It is best to think of WASM as an embeddedable VM for JavaScript rather than opposed to JavaScript. https://webassembly.org/
First of all JS cannot ever be replaced by WASM. This is a stated project design goal of WASM. You have to understand that Web Assembly is there to fill the proprietary application add-in void of things like Flash using open standards safely in a way that is technology agnostic. Web Assembly is not there to serve as a crutch for people afraid of web technologies.
Secondly, there will never be direct DOM access from WebAssembly for security reasons. While that is the nail in the coffin on this matter there is the more practical consideration that developers, even those who write JavaScript full time for a living, tend to be deathly afraid of touching the DOM. If this were a reality the inevitable overhead (think of all the dependencies, frameworks, and abstractions developers cannot live without because the DOM is scary) would likely be just as high, or higher, than writing your own DOM library embedded within your WARM instance.
Thirdly, you can have a DOM interface in a WASM instance. This is part of the web components API, but DOM trees created for the WASM instances are islands to the WASM instance created from external JavaScript - https://medium.com/coinmonks/develop-w3c-web-components-with...
Wouldn't SPARK (and Ada) be better suited for WebAssembly than rust? Because SPARK is built to be formally provable and Ada being pretty damn safe?
Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web development.
That is never going to happen. This is a constant theme on Reddit at r/programming. It is based upon nothing but fear of web technologies (yes, I literally mean fear as a raw and savage emotion) and a lack of understanding what WASM is. It is best to think of WASM as an embeddedable VM for JavaScript rather than opposed to JavaScript. https://webassembly.org/ First of all JS cannot ever be replaced by WASM. This is a…
I agree with you that that doesn’t mean anything with regards to “killing JS” or anything.
Earlier quoted context omitted.
> As I understand it, there's no current plans for WebAssembly to include a garbage collector There are plans to add a garbage collector. See https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu... . But meanwhile, Webassembly is mainly just for C and Rust.
The "problem" with integrating with the host gc is that it means language who have subtly different approaches to garbage collection can't trust compiled code behavior to be identical in the browser. This is probably not a terrible thing, since a native garbage collector in WASM (unless it was designed in an extremely simplistic, low-level form) would also probably not be suitable for the diversity of the languages t…
The big drawback is that, unlike Javascript or Python, there is just no way I'm going to be able to teach Rust to previously non-technical people. The learning curve is just too damn hard.