9 ms·

What's the latest with WebAssembly? I must admit, I'm not fully sure I understand what its goals are and what we should expect its usecases to be. For a time t

What's the latest with WebAssembly? I must admit, I'm not fully sure I understand what its goals are and what we should expect its usecases to be. For a time there seemed to be a lot of hype around writing SPAs in whatever language you like, not just JavaScript, but that seems to have cooled off somewhat - at least that's my impression. Last time I checked in it seemed to be actually quite the opposite - good for low level stuff, data processing, graphics, things in other threads essentially, but if you want to touch the DOM at all just use JS seemed to still be the standard advice. I haven't looked again since. Have things progressed on that front, and if not was that ever really a goal of WebAssembly anyway?

butterthebuddha 7y ago
I would love an expert's thoughts on whether something like MathJax/KaTeX can take advantage of WebAssembly for faster rendering. Seems like a perfect use case to me.
- saagarjha 7y ago
  A better solution would be to improve MathML support in browsers.
  - xmmrm 7y ago
    There’s good news on that front: https://mathml-refresh.github.io/mathml-core/ https://mathml-refresh.github.io/mathml-core/
- klodolph 7y ago
  MathJax will probably not benefit much from WebAssembly. It doesn't actually render math itself. It just creates HTML + CSS (or MathML), and the browser renders it using the normal, highly-optimized rendering paths.
  - elcritch 7y ago
    But it does parse and compile latex expressions right?
    - klodolph 7y ago
      It's more of a macro system stapled to a layout engine, which emits a DOM tree. WebAssembly sucks at DOM. It sucks huge. WebAssembly can't hold a reference to a DOM object and can't even create strings. You have to do that all in JavaScript, and then import that JavaScript code into your WebAssembly module. You'll end up doing something weird like sticking your DOM objects in an array and then passing indexes into the array to your WASM code. Strings have to be encoded/decoded to get them in/out of WASM. MathJax is written in TypeScript. If you want WASM, that means rewriting large parts of MathJAX, keeping other parts in JS, bridging them, and dealing with all of the resource dependencies (i.e. dealing with WebPack). And anyway, JavaScript is decent at string processing.
      - elcritch 7y ago
        Good points! It doesn't seem like it'd help unless there's a really compute expensive portion. I doubt any parsing would be a limiting factor.
        klodolph 7y ago
        Most people don’t think parsing is the limiting factor—which is why we’re always surprised when we measure and it ends up being the slowest part of the process (not common, but it does happen) It would be interesting to know what the slowest parts of MathJax are.
tester756 7y ago
I've been messing a lot of with Blazor (an implementation of wasm support for .NET) and it was possible to write decent CRUD stuff with it, but tooling support isn't great yet It's tricky to develop "standard" frontend when support for hot reload isn't "by default","dll's" size is far from being small and having to perform workarounds in order to manipulate DOM. I think it needs to mature - both wasm and blazor because all of those issues were said to be addressed
glouwbug 7y ago
I think the ultimate goal was getting GIMP to run in the browser. Javascripters aren't going anywhere anytime soon
- SaxonRobber 7y ago
  It would be better if GIMP ran nowhere tbkh
  - devbat8712 7y ago
    May I ask why
dstaley 7y ago
> but if you want to touch the DOM at all just use JS seemed to still be the standard advice This is still the current state of WebAssembly. There's several proposals out there that, if implemented, could change the situation. The primary one that I'm aware of is the interface types proposal [1]. [1] https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p...
- dmitriid 7y ago
  And Garbage Collection. Without it, you can't touch DOM IIRC.
vbezhenar 7y ago
AFAIU main point of WebAssembly is to provide a performant way to use existing C/C++ libraries for some functionality that's won't work fast enough with JavaScript. Current JavaScript engines are very tricky when it comes to optimize JavaScript while WebAssembly is expected to execute in a more obvious way in regards to performance. So if you want to implement cryptography or codec, WebAssembly is a good tool. If you just want to write some browser code, JavaScript is enough. Another use of WebAssembly probably is to serve a better compilation target. While you can compile anything to JavaScript, it makes more sense to compile to WebAssembly if you don't need GC. So with enough time there will be more languages available for web application development. That said, without GC support in WebAssembly, for most interesting languages it's still not usable.
- wahern 7y ago
  Even with GC it won't be a great target for pre-existing languages. Whatever WebAssembly's future GC semantics, I can guarantee you they won't be the same GC semantics as for Go, Java, Lua, Perl, Python, or Ruby because they all have different semantics--semantics which interleave with other design choices in those languages. Bridging those semantics will either require similar workarounds as currently required, or modifying the behavior of the language. WebAssembly with a deep GC model will at best be a slightly better environment for writing JavaScript extensions and at worst a way to write really obtuse JavaScript code.
  - jashmatthews 7y ago
    What do you mean by GC semantics? Like when finalizers are run, what's a value type vs a reference type, or? I would imagine any code which relies on the semantics of a GC implemnentation is pretty broken. In the Ruby community we discourage anyone from doing crazy stuff like using Objectspace.id2ref
    - wahern 7y ago
      The most obvious semantic is persistence or lack thereof. Java and JavaScript can use a copying collector because addresses aren't exposed. JNI/JNA is the exception, though the JVM has a particular model for pinning memory that is in design chummy with JVM's GC model. All the others, AFAIK, use persistent memory, usually for the FFI semantics. Presumably WebAssembly would end up with a persistent model, as well, if the GC model went deep enough. But right off the bat you're losing a unique option available to some very high performance VMs--compaction and defragmentation. (Notwithstanding the Go paper from a few years ago that shows fragmentation isn't a serious issue these days, or the fact that WASM's singular, linear heap and 32-bit addressing is far more limiting--which on second thought actually might make compaction even more desirable.) Less obvious (though as you pointed out) are things like finalizers. In Lua finalizers are guaranteed to run in the reverse order of allocation, and that's an important guarantee when writing C modules. Finalizers in Lua can also resurrect dead objects, which isn't always the case in other languages, and indeed some languages don't even support finalizers at all, which simplifies their GC model. Lua also has an optimization/simplification constraint that finalizers must be attached at object construction (specifically, metatable assignment). If WASM copied something like this, it might disadvantage other languages; if it didn't have such a constraint then the GC implementation might be unnecessarily complex relative to Lua's needs. Another example would be support for ephemerons, which are more powerful than weak references. Only a few languages support this, such as Lua, Smalltalk, and more recently OCaml and JavaScript. AFAIU ephemeron support bleeds into many aspects of the GC. Supporting that in WASM might be tricky and, I'd bet, not something likely to happen--you can't just hoist v8's or SpiderMonkey's GC engine into WASM wholesale, even though I suspect the prospect of doing that motivates some of the interest in adding deep GC support to WASM. If and how WebAssembly's GC model supports these constructs matters greatly to whether other languages can run as first-class citizens in the WASM VM. As an example for the headaches caused when support is lacking, think about exceptions. the standard C API setjmp/longjmp is ridiculously slow in WASM, yet it's how Perl and Lua (and possibly other languages) implement exceptions. Exceptions are on the roadmap for WASM, but they look to be more tailored to Java/C++ exceptions, which iteratively unwinds the stack; Perl and Lua don't need to unwind the stack because they carefully maintain and preserve internal state consistency and can jump across deeply nested function invocations. That's hardly a blocker, but in practice it's incongruent and I would expect Perl and Lua to either suffer for doing things differently, end up having to rearchitect their VMs to suite WASM, or more likely motivate the emergence of a WASM-specific VM (e.g. Iron Python on .NET), which all but guarantees second-class status, either for the new or old project. None of these are deal breakers. You can synthesize behaviors and hack your way around all of this. My point is merely that the prospect of a glorious execution model that unifies the diverse world of languages is naive. Languages are designed and implemented around a core set of primitives and concepts; and many of these primitives and concepts either won't exist in WASM, or will behave so differently as to be effectively useless, especially when cross-compiling existing implementations.
dmit 7y ago
One cool application that cropped up in the Rust ecosystem is to use WASM for procedural macros. That way not only can they be distributed as precompiled (arch-agnostic) blobs from crates.io, but you also get all the benefits of the sandbox environment to guarantee freedom from malicious side effects. The W in "WASM" doesn't have to limit possible applications to just the web browser. https://github.com/dtolnay/watt https://github.com/dtolnay/watt
- antpls 7y ago
  And once there is a GC, it will be a good target for script languages on the OS, as wasm compilers are optimized for fast starting.
dmitriid 7y ago
> I must admit, I'm not fully sure I understand what its goals are and what we should expect its usecases to be. I think the project itself lost its track. It started as an admirable goal of being a common low-level-ish compilation target for the browser. They managed to ship an MVP targeting C semantics. But now it looks that now people are more interested in writing a yet another compiler to WebAssembly (which isn't even in a beta phase) than developing WebAssembly further. And pushing WebAssembly (which, once again, isn't even in beta) into all sorts of weird stuff like server-side apps. And this is occurring even in the orgs responsible for developing WebAssembly, like Mozilla. WebAssembly was announced in 2015. In 2017 they had a Minimum Viable Product that was supported in all major browsers. We are a third way in 2020, and there's hardly anything beyond MVP.
- dmitriid 7y ago
  Interestingly, I've been downvoted, and yet there's no answer in the comments as to what's the latest with WebAssembly or what is the state of the project.
dan-robertson 7y ago
One potential future use could be as a better llvm bitcode. Bitcode isn’t portable but wasm is, and wasm has plans to be a much better platform for a variety of languages (eg with gc support and delimited continuations) whereas making gc compatible llvm code is basically impossible because you need to write the gc yourself but can’t control what’s in the registers or on the stack. Perhaps an optimised wasm compiler/runtime could be used to get a good compiler for a new language without doing as much work. Or perhaps a general vm will never work as well as a custom one and the trade off won’t be worth it.
thefounder 7y ago
>> For a time there seemed to be a lot of hype around writing SPAs in whatever language you like, not just JavaScript, but that seems to have cooled off somewhat - at least that's my impression. I'm building exactly that. A SPA using Go compiled to WASM. Some issues seem to be the startup time and the payload size.
- justinclift 7y ago
  Similar kind of thing for myself. --- Standard Go: The resulting .wasm sizes aren't practical. 2MB+ for "hello world". That being said, it was only ~2.5MB for an inital mock 3d on 2d canvas test thing: https://justinclift.github.io/wasmGraph1/ https://justinclift.github.io/wasmGraph1/ (~550k when gzip compressed, as is commonly done when sending over a network) --- TinyGo: Much better sized .wasm files. ~500 bytes for "hello world". ~65k for a mock 3d on 2d canvas test: https://justinclift.github.io/tinygo_canvas2 https://justinclift.github.io/tinygo_canvas2 (~26k compressed) --- Rust: ~110k for a port of the same mock 3d on 2d canvas test: https://justinclift.github.io/rust_canvas_2d/ https://justinclift.github.io/rust_canvas_2d/ (~44k compressed) Note that this is done with lousy Rust code, as I'm still in the early stages of getting the hang of it. --- Rust (so far) seems to be the best trade off, at least for now. Although TinyGo's binary sizes are much better than it and standard Go, TinyGo breaks far too often, and reported blocker bugs aren't addressed for months. :(
  - thefounder 7y ago
    The resulting .wasm size of my app is about 70MB so at this time I believe you can only develop enterprise apps or very simple stuff.
    - justinclift 7y ago
      Yeah. That's why I'm doing stuff with Rust atm. I'd prefer TinyGo, but this seem to be working "ok" for now.
austincheney 7y ago
The goal: Allow a uniform execution context (compile target) in the browser via a standard byte code. That means executing an application written in any language, provided a corresponding compiler, as an island in a web page. In practical terms the language of the browser is JavaScript, but what if JavaScript doesn't do what you need, or it isn't fast enough, or you simply don't like JavaScript. Instead you want to write some application in Rust (just using that as an example). The language of the web is still JavaScript and not Rust so your new application will not run directly in a web page. That's unfortunate, because the web is a fantastic distribution platform because things that run in web pages do not require a separate installation step or a separate download step, since web page assets are downloaded automatically as called by the web page. If you compile your Rust application to WASM it can run in a web browser. To be clear though WASM isn't replacing JavaScript or even in any way competing with JavaScript, because that is certainly what it sounds like. WASM is a separate and isolated execution instance in the browser, even from the page that contains it. JavaScript, on the other hand, executes directly in the context of the page that requests it. You might hear some discussion of wanting WASM to replace JavaScript, but that is clearly stated by the WASM project as not a design goal. You might also hear that if only the containing page's DOM were available to WASM it would replace JavaScript, but that isn't a design goal either. That part about the DOM is the confluence of a misunderstanding about the DOM and about WASM's security goals of a separate execution context. There is work, however, on providing some Web API capabilities to WASM so that a WASM instance may have some awareness of its execution context or to allow some manner of external interaction of the WASM instance from the surrounding page. I don't know the status of that work though. * WASM project site - https://webassembly.org/ https://webassembly.org/ * Web APIs, a list of de facto standards for interacting with web browsers from JavaScript - https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API * DOM specification, the DOM is a language agnostic dynamic tree model that represents markup and containing content - https://dom.spec.whatwg.org/ https://dom.spec.whatwg.org/
- justinclift 7y ago
  > You might hear some discussion of wanting WASM to replace JavaScript, but that is clearly stated by the WASM project as not a design goal. Unfortunately, that appears to be a huge miss. There are a lot of programmers in other (non-JS) languages that would very much like to create front end pieces for their web applications. Hopefully when the interface types proposal (or whatever) happens, direct access to the DOM does become a thing and non-JS programmers really can do their front end work without JS.
kbumsik 7y ago
Here is the simple answer: as W3C stated, it is a new "language" for the web [1]. So you get alternative language options other than JS. That's it. Admittedly, The current state of WASM is somewhat limited. For example, it cannot touch DOM directly without JS now. One of the goals of WASM is that making it more browser-native module (just like ES6 modules) to remove such JS dependency. This goal will take years I guess. Of course, things make people confused as many guys are experimenting with WASM outside of the browser. But this is the initial goal in the web browser context. [1]: https://www.w3.org/2019/12/pressrelease-wasm-rec.html.en https://www.w3.org/2019/12/pressrelease-wasm-rec.html.en

butterthebuddha 7y ago

I would love an expert's thoughts on whether something like MathJax/KaTeX can take advantage of WebAssembly for faster rendering. Seems like a perfect use case to me.

saagarjha 7y ago
A better solution would be to improve MathML support in browsers.
- xmmrm 7y ago
  There’s good news on that front: https://mathml-refresh.github.io/mathml-core/ https://mathml-refresh.github.io/mathml-core/
klodolph 7y ago
MathJax will probably not benefit much from WebAssembly. It doesn't actually render math itself. It just creates HTML + CSS (or MathML), and the browser renders it using the normal, highly-optimized rendering paths.
- elcritch 7y ago
  But it does parse and compile latex expressions right?
  - klodolph 7y ago
    It's more of a macro system stapled to a layout engine, which emits a DOM tree. WebAssembly sucks at DOM. It sucks huge. WebAssembly can't hold a reference to a DOM object and can't even create strings. You have to do that all in JavaScript, and then import that JavaScript code into your WebAssembly module. You'll end up doing something weird like sticking your DOM objects in an array and then passing indexes into the array to your WASM code. Strings have to be encoded/decoded to get them in/out of WASM. MathJax is written in TypeScript. If you want WASM, that means rewriting large parts of MathJAX, keeping other parts in JS, bridging them, and dealing with all of the resource dependencies (i.e. dealing with WebPack). And anyway, JavaScript is decent at string processing.
    - elcritch 7y ago
      Good points! It doesn't seem like it'd help unless there's a really compute expensive portion. I doubt any parsing would be a limiting factor.
      - klodolph 7y ago
        Most people don’t think parsing is the limiting factor—which is why we’re always surprised when we measure and it ends up being the slowest part of the process (not common, but it does happen) It would be interesting to know what the slowest parts of MathJax are.

tester756 7y ago

I've been messing a lot of with Blazor (an implementation of wasm support for .NET) and it was possible to write decent CRUD stuff with it, but tooling support isn't great yet It's tricky to develop "standard" frontend when support for hot reload isn't "by default","dll's" size is far from being small and having to perform workarounds in order to manipulate DOM. I think it needs to mature - both wasm and blazor because all of those issues were said to be addressed

glouwbug 7y ago

I think the ultimate goal was getting GIMP to run in the browser. Javascripters aren't going anywhere anytime soon

SaxonRobber 7y ago
It would be better if GIMP ran nowhere tbkh
- devbat8712 7y ago
  May I ask why

dstaley 7y ago

> but if you want to touch the DOM at all just use JS seemed to still be the standard advice This is still the current state of WebAssembly. There's several proposals out there that, if implemented, could change the situation. The primary one that I'm aware of is the interface types proposal [1]. [1] https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p...

dmitriid 7y ago
And Garbage Collection. Without it, you can't touch DOM IIRC.

vbezhenar 7y ago

AFAIU main point of WebAssembly is to provide a performant way to use existing C/C++ libraries for some functionality that's won't work fast enough with JavaScript. Current JavaScript engines are very tricky when it comes to optimize JavaScript while WebAssembly is expected to execute in a more obvious way in regards to performance. So if you want to implement cryptography or codec, WebAssembly is a good tool. If you just want to write some browser code, JavaScript is enough. Another use of WebAssembly probably is to serve a better compilation target. While you can compile anything to JavaScript, it makes more sense to compile to WebAssembly if you don't need GC. So with enough time there will be more languages available for web application development. That said, without GC support in WebAssembly, for most interesting languages it's still not usable.

wahern 7y ago
Even with GC it won't be a great target for pre-existing languages. Whatever WebAssembly's future GC semantics, I can guarantee you they won't be the same GC semantics as for Go, Java, Lua, Perl, Python, or Ruby because they all have different semantics--semantics which interleave with other design choices in those languages. Bridging those semantics will either require similar workarounds as currently required, or modifying the behavior of the language. WebAssembly with a deep GC model will at best be a slightly better environment for writing JavaScript extensions and at worst a way to write really obtuse JavaScript code.
- jashmatthews 7y ago
  What do you mean by GC semantics? Like when finalizers are run, what's a value type vs a reference type, or? I would imagine any code which relies on the semantics of a GC implemnentation is pretty broken. In the Ruby community we discourage anyone from doing crazy stuff like using Objectspace.id2ref
  - wahern 7y ago
    The most obvious semantic is persistence or lack thereof. Java and JavaScript can use a copying collector because addresses aren't exposed. JNI/JNA is the exception, though the JVM has a particular model for pinning memory that is in design chummy with JVM's GC model. All the others, AFAIK, use persistent memory, usually for the FFI semantics. Presumably WebAssembly would end up with a persistent model, as well, if the GC model went deep enough. But right off the bat you're losing a unique option available to some very high performance VMs--compaction and defragmentation. (Notwithstanding the Go paper from a few years ago that shows fragmentation isn't a serious issue these days, or the fact that WASM's singular, linear heap and 32-bit addressing is far more limiting--which on second thought actually might make compaction even more desirable.) Less obvious (though as you pointed out) are things like finalizers. In Lua finalizers are guaranteed to run in the reverse order of allocation, and that's an important guarantee when writing C modules. Finalizers in Lua can also resurrect dead objects, which isn't always the case in other languages, and indeed some languages don't even support finalizers at all, which simplifies their GC model. Lua also has an optimization/simplification constraint that finalizers must be attached at object construction (specifically, metatable assignment). If WASM copied something like this, it might disadvantage other languages; if it didn't have such a constraint then the GC implementation might be unnecessarily complex relative to Lua's needs. Another example would be support for ephemerons, which are more powerful than weak references. Only a few languages support this, such as Lua, Smalltalk, and more recently OCaml and JavaScript. AFAIU ephemeron support bleeds into many aspects of the GC. Supporting that in WASM might be tricky and, I'd bet, not something likely to happen--you can't just hoist v8's or SpiderMonkey's GC engine into WASM wholesale, even though I suspect the prospect of doing that motivates some of the interest in adding deep GC support to WASM. If and how WebAssembly's GC model supports these constructs matters greatly to whether other languages can run as first-class citizens in the WASM VM. As an example for the headaches caused when support is lacking, think about exceptions. the standard C API setjmp/longjmp is ridiculously slow in WASM, yet it's how Perl and Lua (and possibly other languages) implement exceptions. Exceptions are on the roadmap for WASM, but they look to be more tailored to Java/C++ exceptions, which iteratively unwinds the stack; Perl and Lua don't need to unwind the stack because they carefully maintain and preserve internal state consistency and can jump across deeply nested function invocations. That's hardly a blocker, but in practice it's incongruent and I would expect Perl and Lua to either suffer for doing things differently, end up having to rearchitect their VMs to suite WASM, or more likely motivate the emergence of a WASM-specific VM (e.g. Iron Python on .NET), which all but guarantees second-class status, either for the new or old project. None of these are deal breakers. You can synthesize behaviors and hack your way around all of this. My point is merely that the prospect of a glorious execution model that unifies the diverse world of languages is naive. Languages are designed and implemented around a core set of primitives and concepts; and many of these primitives and concepts either won't exist in WASM, or will behave so differently as to be effectively useless, especially when cross-compiling existing implementations.

dmit 7y ago

One cool application that cropped up in the Rust ecosystem is to use WASM for procedural macros. That way not only can they be distributed as precompiled (arch-agnostic) blobs from crates.io, but you also get all the benefits of the sandbox environment to guarantee freedom from malicious side effects. The W in "WASM" doesn't have to limit possible applications to just the web browser. https://github.com/dtolnay/watt https://github.com/dtolnay/watt

antpls 7y ago
And once there is a GC, it will be a good target for script languages on the OS, as wasm compilers are optimized for fast starting.

dmitriid 7y ago

> I must admit, I'm not fully sure I understand what its goals are and what we should expect its usecases to be. I think the project itself lost its track. It started as an admirable goal of being a common low-level-ish compilation target for the browser. They managed to ship an MVP targeting C semantics. But now it looks that now people are more interested in writing a yet another compiler to WebAssembly (which isn't even in a beta phase) than developing WebAssembly further. And pushing WebAssembly (which, once again, isn't even in beta) into all sorts of weird stuff like server-side apps. And this is occurring even in the orgs responsible for developing WebAssembly, like Mozilla. WebAssembly was announced in 2015. In 2017 they had a Minimum Viable Product that was supported in all major browsers. We are a third way in 2020, and there's hardly anything beyond MVP.

dmitriid 7y ago
Interestingly, I've been downvoted, and yet there's no answer in the comments as to what's the latest with WebAssembly or what is the state of the project.

dan-robertson 7y ago

One potential future use could be as a better llvm bitcode. Bitcode isn’t portable but wasm is, and wasm has plans to be a much better platform for a variety of languages (eg with gc support and delimited continuations) whereas making gc compatible llvm code is basically impossible because you need to write the gc yourself but can’t control what’s in the registers or on the stack. Perhaps an optimised wasm compiler/runtime could be used to get a good compiler for a new language without doing as much work. Or perhaps a general vm will never work as well as a custom one and the trade off won’t be worth it.

thefounder 7y ago

>> For a time there seemed to be a lot of hype around writing SPAs in whatever language you like, not just JavaScript, but that seems to have cooled off somewhat - at least that's my impression. I'm building exactly that. A SPA using Go compiled to WASM. Some issues seem to be the startup time and the payload size.

justinclift 7y ago
Similar kind of thing for myself. --- Standard Go: The resulting .wasm sizes aren't practical. 2MB+ for "hello world". That being said, it was only ~2.5MB for an inital mock 3d on 2d canvas test thing: https://justinclift.github.io/wasmGraph1/ https://justinclift.github.io/wasmGraph1/ (~550k when gzip compressed, as is commonly done when sending over a network) --- TinyGo: Much better sized .wasm files. ~500 bytes for "hello world". ~65k for a mock 3d on 2d canvas test: https://justinclift.github.io/tinygo_canvas2 https://justinclift.github.io/tinygo_canvas2 (~26k compressed) --- Rust: ~110k for a port of the same mock 3d on 2d canvas test: https://justinclift.github.io/rust_canvas_2d/ https://justinclift.github.io/rust_canvas_2d/ (~44k compressed) Note that this is done with lousy Rust code, as I'm still in the early stages of getting the hang of it. --- Rust (so far) seems to be the best trade off, at least for now. Although TinyGo's binary sizes are much better than it and standard Go, TinyGo breaks far too often, and reported blocker bugs aren't addressed for months. :(
- thefounder 7y ago
  The resulting .wasm size of my app is about 70MB so at this time I believe you can only develop enterprise apps or very simple stuff.
  - justinclift 7y ago
    Yeah. That's why I'm doing stuff with Rust atm. I'd prefer TinyGo, but this seem to be working "ok" for now.

austincheney 7y ago

The goal: Allow a uniform execution context (compile target) in the browser via a standard byte code. That means executing an application written in any language, provided a corresponding compiler, as an island in a web page. In practical terms the language of the browser is JavaScript, but what if JavaScript doesn't do what you need, or it isn't fast enough, or you simply don't like JavaScript. Instead you want to write some application in Rust (just using that as an example). The language of the web is still JavaScript and not Rust so your new application will not run directly in a web page. That's unfortunate, because the web is a fantastic distribution platform because things that run in web pages do not require a separate installation step or a separate download step, since web page assets are downloaded automatically as called by the web page. If you compile your Rust application to WASM it can run in a web browser. To be clear though WASM isn't replacing JavaScript or even in any way competing with JavaScript, because that is certainly what it sounds like. WASM is a separate and isolated execution instance in the browser, even from the page that contains it. JavaScript, on the other hand, executes directly in the context of the page that requests it. You might hear some discussion of wanting WASM to replace JavaScript, but that is clearly stated by the WASM project as not a design goal. You might also hear that if only the containing page's DOM were available to WASM it would replace JavaScript, but that isn't a design goal either. That part about the DOM is the confluence of a misunderstanding about the DOM and about WASM's security goals of a separate execution context. There is work, however, on providing some Web API capabilities to WASM so that a WASM instance may have some awareness of its execution context or to allow some manner of external interaction of the WASM instance from the surrounding page. I don't know the status of that work though. * WASM project site - https://webassembly.org/ https://webassembly.org/ * Web APIs, a list of de facto standards for interacting with web browsers from JavaScript - https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API * DOM specification, the DOM is a language agnostic dynamic tree model that represents markup and containing content - https://dom.spec.whatwg.org/ https://dom.spec.whatwg.org/

justinclift 7y ago
> You might hear some discussion of wanting WASM to replace JavaScript, but that is clearly stated by the WASM project as not a design goal. Unfortunately, that appears to be a huge miss. There are a lot of programmers in other (non-JS) languages that would very much like to create front end pieces for their web applications. Hopefully when the interface types proposal (or whatever) happens, direct access to the DOM does become a thing and non-JS programmers really can do their front end work without JS.

kbumsik 7y ago

Here is the simple answer: as W3C stated, it is a new "language" for the web [1]. So you get alternative language options other than JS. That's it. Admittedly, The current state of WASM is somewhat limited. For example, it cannot touch DOM directly without JS now. One of the goals of WASM is that making it more browser-native module (just like ES6 modules) to remove such JS dependency. This goal will take years I guess. Of course, things make people confused as many guys are experimenting with WASM outside of the browser. But this is the initial goal in the web browser context. [1]: https://www.w3.org/2019/12/pressrelease-wasm-rec.html.en https://www.w3.org/2019/12/pressrelease-wasm-rec.html.en