6 ms·

Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. J

by brabel 5y ago

Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS! Jokes aside: this is actually quite interesting, the demo is very impressive (except for the "only works in Chromium-based browser" message on the next.js demo, where the preview should be - despite Mozzila being one of the main WASM backers and Firefox having arguably the best WASM engine).

kevingadd 5y ago
Typically when you see stuff like this be Chromium-only, it's because Chromium has a bunch of non-standard/one-vendor-only stuff enabled in production builds and neither Firefox or Safari have it enabled (or implemented at all). A few examples include Bluetooth, MIDI and USB.
- pantelisk 5y ago
  I don't understand why you are downvoted. Filesystem access is another big one! Chrome has the technological advantage and sports an enormous kitchen sink of features. One has to make the hard decision, work on a concept that will work only on one browser, try to cut corners with graceful (or crippling) degradation, or wait potentially a long time until a spec is standardized and implemented. The latter may result in others hitting the market sooner, so it is understandable why we end up with web-apps that function in a single browser only. Hopefully this improves in the future.
  - mr_toad 5y ago
    The down side is that some of these technologies never get standardised and eventually get dropped. Like NaCl and PNaCl.
    - WorldMaker 5y ago
      Or for an example that caused a lot more havoc comparatively: WebSQL.
emteycz 5y ago
I think the issue isn't with Wasm support, it's the filesystem API. They could've included a polyfill though... But as that API is new it might not be available yet.
- dfabulich 5y ago
  It's the "File System Access API," the one that allows the browser to read/write files on your actual computer. It's an I/O feature, impossible to polyfill. The similarly named "FileSystem API" gives you access to a sandboxed "virtual drive" in the browser. Firefox has supported that for years, and polyfills are possible, but it's irrelevant in this case. https://caniuse.com/?search=file%20system https://caniuse.com/?search=file%20system
  - slver 5y ago
    I believe it still counts as a polyfill, even if it doesn't do what it says on the can (but it has compatible interface, so your app runs).
jrockway 5y ago
Browser Javascript suffers from not producing a single "binary" as its build system output. You do get one bundle, but none of the parts know anything about each other, and it limits the ability to optimize. (It is a lot more like the C preprocessor, rather than a C compiler.) Methods that can't possibly ever be called end up being sent to each user, for no reason other than "well someone could write an eval() that needs that". (I was surprised how poorly tree-shaking works in practice, and how even "light" frameworks like Svelte ship a huge runtime to every user, unrelated to what features the code actually uses.) Meanwhile, WebAssembly suffers from there not being a good programming language that compiles to it natively. I think the Go support is great, but there's no library support for building the webapps that people get paid to build (React, Apollo, etc. all exist for a reason, however much you hate that reason). AssemblyScript was supposed to be this language, but it's just a Typescript-inspired programming language, it's not Typescript and the npm ecosystem. I don't know what the details of this implementation are, but the direction I'd like to see web development move is having a statically typed language that compiles to VM bytecode. This sounds like the first step for removing Javascript as a Typescript intermediary. Once that happens, then modern programming language features can be bolted on, people can add good compiler optimizations that result in minimal bytes output for users to download, the module system can be made stricter (like "go mod"), etc. Javascript is just a little bit more dynamic than anyone really wants, and it makes the build/deployment tooling complicated and, frankly, kind of bad.
- slver 5y ago
  Tree shaking works poorly, but is also thankfully not that important, unless you're terrible with managing dependencies. Why? Because the initial parser is relatively cheap. This makes all of the code available, even if a stray eval() calls something unexpected. The real resource expense comes when it's time to JIT a hotspot. But a hotspot is by definition code you use for sure. And code you use a lot. JS engines use tracing JIT. Tracing allows JIT compilers to see how code runs in practice, and compile THAT to machine language. How it's organized on the file system etc is entirely irrelevant. So basically in a trace JIT system, code that isn't hot is interpreted, and code that is hot is JIT-ted (and code that's very hot, gets JIT-ted with higher optimization). Interpreting is the new "tree shaking". It saves the compiler a lot of work, but also it won't crash your app (unlike bad tree shaking).
bryanrasmussen 5y ago
>JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS! I remember back when SOAP still had the upperhand against REST but just barely the W3C published a document where they showed how you could implement HTTP over SOAP to basically mass ridicule. Unfortunately can't find it anymore, but it was pretty funny.
- shoo 5y ago
  searching "HTTP over SOAP" finds a few leads: Tim Bray, 2004, "HTTP over SOAP!?!?!?": https://www.tbray.org/ongoing/When/200x/2004/05/01/SRRH https://www.tbray.org/ongoing/When/200x/2004/05/01/SRRH Erik Wilde, 2008, "HTTP over SOAP over HTTP": https://dret.typepad.com/dretblog/2008/11/http-over-soap-over-http.html https://dret.typepad.com/dretblog/2008/11/http-over-soap-ove... William Vambenepe, 2008, "WS Resource Access working group starting at W3C": http://stage.vambenepe.com/archives/436 http://stage.vambenepe.com/archives/436 Here are some of the specs: Web Services Transfer (WS-Transfer). This specification describes a general SOAP-based protocol for accessing XML representations of Web service-based resources. https://www.w3.org/Submission/WS-Transfer/ https://www.w3.org/Submission/WS-Transfer/ Web Services Resource Transfer (WS-RT). This specification defines extensions to WS-Transfer. While its initial design focuses on management resource access its use is not necessarily limited to those situations. https://www.w3.org/Submission/WSRT/ https://www.w3.org/Submission/WSRT/
  - bryanrasmussen 5y ago
    it was the document referred to by Tim Bray, 2004, "HTTP over SOAP!?!?!?", I also remember the Tim Bray article as one of the top pieces of ridicule.
dfabulich 5y ago
> Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... > WebAssembly is a different language from JavaScript, but it is not intended as a replacement. Instead, it is designed to complement and work alongside JavaScript, allowing web developers to take advantage of both languages' strong points "Not intended as a replacement" WASM is a math coprocessor for JS. WASM can't even talk to the DOM API directly (which is the API you use to build web pages in JS); you have to write JavaScript glue code for any/all I/O in WASM.
- slver 5y ago
  > WASM can't even talk to the DOM API directly For now. It's planned.
  - mr_toad 5y ago
    For existing code bases that don’t already do DOM manipulation (so, all of them) other parts of the Web API might be more useful, like the canvas, the video API, the RTC API etc.
    - slver 5y ago
      The issue in general is how to bridge these JS OOP APIs to something that's basically assembler. If WASM gains a foreign object model calling convention or whatever, we're in game.
      - emteycz 5y ago
        Wasm is not basically assembler, it's (going to be) very high level: - https://github.com/WebAssembly/reference-types https://github.com/WebAssembly/reference-types - https://github.com/webassembly/threads https://github.com/webassembly/threads - https://github.com/WebAssembly/exception-handling https://github.com/WebAssembly/exception-handling - https://github.com/WebAssembly/function-references https://github.com/WebAssembly/function-references - https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc Though it is true that the original MVP was very barebone and could be compared to assembler. However, the reference types proposal has been shipped in all major browsers and is considered "finished".
jcuenod 5y ago
I wonder if this would work in electron?

by brabel 5y ago

kevingadd 5y ago

Typically when you see stuff like this be Chromium-only, it's because Chromium has a bunch of non-standard/one-vendor-only stuff enabled in production builds and neither Firefox or Safari have it enabled (or implemented at all). A few examples include Bluetooth, MIDI and USB.

pantelisk 5y ago
I don't understand why you are downvoted. Filesystem access is another big one! Chrome has the technological advantage and sports an enormous kitchen sink of features. One has to make the hard decision, work on a concept that will work only on one browser, try to cut corners with graceful (or crippling) degradation, or wait potentially a long time until a spec is standardized and implemented. The latter may result in others hitting the market sooner, so it is understandable why we end up with web-apps that function in a single browser only. Hopefully this improves in the future.
- mr_toad 5y ago
  The down side is that some of these technologies never get standardised and eventually get dropped. Like NaCl and PNaCl.
  - WorldMaker 5y ago
    Or for an example that caused a lot more havoc comparatively: WebSQL.

emteycz 5y ago

I think the issue isn't with Wasm support, it's the filesystem API. They could've included a polyfill though... But as that API is new it might not be available yet.

dfabulich 5y ago
It's the "File System Access API," the one that allows the browser to read/write files on your actual computer. It's an I/O feature, impossible to polyfill. The similarly named "FileSystem API" gives you access to a sandboxed "virtual drive" in the browser. Firefox has supported that for years, and polyfills are possible, but it's irrelevant in this case. https://caniuse.com/?search=file%20system https://caniuse.com/?search=file%20system
- slver 5y ago
  I believe it still counts as a polyfill, even if it doesn't do what it says on the can (but it has compatible interface, so your app runs).

jrockway 5y ago

Browser Javascript suffers from not producing a single "binary" as its build system output. You do get one bundle, but none of the parts know anything about each other, and it limits the ability to optimize. (It is a lot more like the C preprocessor, rather than a C compiler.) Methods that can't possibly ever be called end up being sent to each user, for no reason other than "well someone could write an eval() that needs that". (I was surprised how poorly tree-shaking works in practice, and how even "light" frameworks like Svelte ship a huge runtime to every user, unrelated to what features the code actually uses.) Meanwhile, WebAssembly suffers from there not being a good programming language that compiles to it natively. I think the Go support is great, but there's no library support for building the webapps that people get paid to build (React, Apollo, etc. all exist for a reason, however much you hate that reason). AssemblyScript was supposed to be this language, but it's just a Typescript-inspired programming language, it's not Typescript and the npm ecosystem. I don't know what the details of this implementation are, but the direction I'd like to see web development move is having a statically typed language that compiles to VM bytecode. This sounds like the first step for removing Javascript as a Typescript intermediary. Once that happens, then modern programming language features can be bolted on, people can add good compiler optimizations that result in minimal bytes output for users to download, the module system can be made stricter (like "go mod"), etc. Javascript is just a little bit more dynamic than anyone really wants, and it makes the build/deployment tooling complicated and, frankly, kind of bad.

slver 5y ago
Tree shaking works poorly, but is also thankfully not that important, unless you're terrible with managing dependencies. Why? Because the initial parser is relatively cheap. This makes all of the code available, even if a stray eval() calls something unexpected. The real resource expense comes when it's time to JIT a hotspot. But a hotspot is by definition code you use for sure. And code you use a lot. JS engines use tracing JIT. Tracing allows JIT compilers to see how code runs in practice, and compile THAT to machine language. How it's organized on the file system etc is entirely irrelevant. So basically in a trace JIT system, code that isn't hot is interpreted, and code that is hot is JIT-ted (and code that's very hot, gets JIT-ted with higher optimization). Interpreting is the new "tree shaking". It saves the compiler a lot of work, but also it won't crash your app (unlike bad tree shaking).

bryanrasmussen 5y ago

>JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS! I remember back when SOAP still had the upperhand against REST but just barely the W3C published a document where they showed how you could implement HTTP over SOAP to basically mass ridicule. Unfortunately can't find it anymore, but it was pretty funny.

shoo 5y ago
searching "HTTP over SOAP" finds a few leads: Tim Bray, 2004, "HTTP over SOAP!?!?!?": https://www.tbray.org/ongoing/When/200x/2004/05/01/SRRH https://www.tbray.org/ongoing/When/200x/2004/05/01/SRRH Erik Wilde, 2008, "HTTP over SOAP over HTTP": https://dret.typepad.com/dretblog/2008/11/http-over-soap-over-http.html https://dret.typepad.com/dretblog/2008/11/http-over-soap-ove... William Vambenepe, 2008, "WS Resource Access working group starting at W3C": http://stage.vambenepe.com/archives/436 http://stage.vambenepe.com/archives/436 Here are some of the specs: Web Services Transfer (WS-Transfer). This specification describes a general SOAP-based protocol for accessing XML representations of Web service-based resources. https://www.w3.org/Submission/WS-Transfer/ https://www.w3.org/Submission/WS-Transfer/ Web Services Resource Transfer (WS-RT). This specification defines extensions to WS-Transfer. While its initial design focuses on management resource access its use is not necessarily limited to those situations. https://www.w3.org/Submission/WSRT/ https://www.w3.org/Submission/WSRT/
- bryanrasmussen 5y ago
  it was the document referred to by Tim Bray, 2004, "HTTP over SOAP!?!?!?", I also remember the Tim Bray article as one of the top pieces of ridicule.

dfabulich 5y ago

> Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... > WebAssembly is a different language from JavaScript, but it is not intended as a replacement. Instead, it is designed to complement and work alongside JavaScript, allowing web developers to take advantage of both languages' strong points "Not intended as a replacement" WASM is a math coprocessor for JS. WASM can't even talk to the DOM API directly (which is the API you use to build web pages in JS); you have to write JavaScript glue code for any/all I/O in WASM.

slver 5y ago
> WASM can't even talk to the DOM API directly For now. It's planned.
- mr_toad 5y ago
  For existing code bases that don’t already do DOM manipulation (so, all of them) other parts of the Web API might be more useful, like the canvas, the video API, the RTC API etc.
  - slver 5y ago
    The issue in general is how to bridge these JS OOP APIs to something that's basically assembler. If WASM gains a foreign object model calling convention or whatever, we're in game.
    - emteycz 5y ago
      Wasm is not basically assembler, it's (going to be) very high level: - https://github.com/WebAssembly/reference-types https://github.com/WebAssembly/reference-types - https://github.com/webassembly/threads https://github.com/webassembly/threads - https://github.com/WebAssembly/exception-handling https://github.com/WebAssembly/exception-handling - https://github.com/WebAssembly/function-references https://github.com/WebAssembly/function-references - https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc Though it is true that the original MVP was very barebone and could be compared to assembler. However, the reference types proposal has been shipped in all major browsers and is considered "finished".

jcuenod 5y ago

I wonder if this would work in electron?