3 ms·

"It's important to point out that it is designed to complement JavaScript not replace it and that in a browser context it has no direct access to the DOM, only

"It's important to point out that it is designed to complement JavaScript not replace it and that in a browser context it has no direct access to the DOM, only via JavaScript." That maybe true of current implementations but the design docs[0] appear to suggest that you will be able to import platform features in WebAssembly. [0] https://github.com/WebAssembly/design/blob/master/Portability.md#api https://github.com/WebAssembly/design/blob/master/Portabilit...

flavio81 9y ago
Eventually it should replace Javascript. It ought to, because it defines a standard, versatile platform to execute code on the browser.
- limeblack 9y ago
  Although you may be right I hope you are not. I like the semi open source nature and high levelness of JavaScript. It's not perfect but it beats dissembling things. Yes I know there are obfuscators.
luke_wagner 9y ago
Agreed, there was active discussion about this at the last WebAssembly CG meeting even: https://github.com/WebAssembly/meetings/blob/master/2017/CG-07.md#host-bindings https://github.com/WebAssembly/meetings/blob/master/2017/CG-...
- ilaksh 9y ago
  The biggest issue that I see and mentioned before is that the APIs are not versioned and instead rely on 'feature detection' which seems to be due to poor support for/understanding of modern style versioned modules in C++.
  - tomjakubowski 9y ago
    > understanding of modern style versioned modules in C++. Could you enlighten us about this? Is this something to do with the eternal C++ modules proposal that never seems to make it into a standard? The thing that comes to my mind when I hear "versioned modules" and "C++" is the way you can use "versioned" namespace re-exports to avoid ABI breakage, like so: // header for version 1 of library namespace mylib { namespace v1 { struct Foo { int num_apples; }; } using namespace v1; } // header for version 2 of library namespace mylib { namespace v1 { class Foo { int num_apples; }; } namespace v2 { class Foo { int num_apples; int num_bananas; }; } using namespace v2; } But I don't think that's what you mean.

flavio81 9y ago

Eventually it should replace Javascript. It ought to, because it defines a standard, versatile platform to execute code on the browser.

limeblack 9y ago
Although you may be right I hope you are not. I like the semi open source nature and high levelness of JavaScript. It's not perfect but it beats dissembling things. Yes I know there are obfuscators.

luke_wagner 9y ago

Agreed, there was active discussion about this at the last WebAssembly CG meeting even: https://github.com/WebAssembly/meetings/blob/master/2017/CG-07.md#host-bindings https://github.com/WebAssembly/meetings/blob/master/2017/CG-...

ilaksh 9y ago
The biggest issue that I see and mentioned before is that the APIs are not versioned and instead rely on 'feature detection' which seems to be due to poor support for/understanding of modern style versioned modules in C++.
- tomjakubowski 9y ago
  > understanding of modern style versioned modules in C++. Could you enlighten us about this? Is this something to do with the eternal C++ modules proposal that never seems to make it into a standard? The thing that comes to my mind when I hear "versioned modules" and "C++" is the way you can use "versioned" namespace re-exports to avoid ABI breakage, like so: // header for version 1 of library namespace mylib { namespace v1 { struct Foo { int num_apples; }; } using namespace v1; } // header for version 2 of library namespace mylib { namespace v1 { class Foo { int num_apples; }; } namespace v2 { class Foo { int num_apples; int num_bananas; }; } using namespace v2; } But I don't think that's what you mean.