4 ms·

Hmm, I wonder if and what people will switch to when they're not forced to use Javascript. Now any language could become a server side + client side language li

by iLoch 11y ago

Hmm, I wonder if and what people will switch to when they're not forced to use Javascript. Now any language could become a server side + client side language like JS is now. Will I have the ability to write a library in one language and use it in another as long as they both compile to wasm?

netghost 11y ago
Finally I can write in HyperTalk!
- pekk 11y ago
  The point being that nobody uses or has any good reason to use HyperTalk these days. But the same is not true of many other languages. Javascript is not the last language anyone will ever need.
- xigency 11y ago
  HyperCard predates the world wide web. It was pretty awesome, too.
tracker1 11y ago
WASM can't talk to the DOM directly, you'll still need JS, or a compile-to binding layer. That said, modern JS, aside from getting all the tooling bootstrapped, is pretty nice to work with imho. There are also a lot of compile-to-js options, and with better sourcemap support, it's pretty clean to use. wasm will lean heavily towards code that needs to be more secure, as well as code that needs absolute performance (gaming mostly)... As to security, using a redux-like workflow, where all action creators use message calls to a websocket connected server-side redux store, then the updates dispatched to the client's store to the UI, so that all logic is at the server would probably be a cleaner and more secure abstraction than wasm though.
- michaelwww 11y ago
  > WASM can't talk to the DOM directly It will according to multiple sources: "In fact, not only will the JavaScript engine be exposed to WebAssembly modules, but so will the DOM. This means you could, in theory, write whole web applications in C and/or C++ and/or other languages that compile into WebAssembly" [1] "Beyond the MVP (Minimum Viable Product), another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects." [2] [1] http://moduscreate.com/webassembly-explained/ http://moduscreate.com/webassembly-explained/ [2] https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md
  - iLoch 11y ago
    I figured this would be the case. This fact will contribute to lots of interesting discussions in the future regarding whether or not we should move away from JS and if so, how. Obviously having something like React is still hugely beneficial for reducing the logical complexity of creating UI, but you'd need to reconsider how you'd write your components without JSX or perhaps some language agnostic version of JSX would need to be created.. Or maybe we just implement E4X type syntax in other languages.
  - bobajeff 11y ago
    "Beyond the MVP" is the key phrase here. The first version of webassembly will not be able do that. Just like it won't have dynamic linking, SIMD, shared memory (pthreads) or support for garbage collected languages. It's worth noting that those features were already on the path to being added to it asm.js before webassembly was even being worked on. Most of them are still going to make it to asm.js first.

by iLoch 11y ago

netghost 11y ago

Finally I can write in HyperTalk!

pekk 11y ago
The point being that nobody uses or has any good reason to use HyperTalk these days. But the same is not true of many other languages. Javascript is not the last language anyone will ever need.
xigency 11y ago
HyperCard predates the world wide web. It was pretty awesome, too.

tracker1 11y ago

WASM can't talk to the DOM directly, you'll still need JS, or a compile-to binding layer. That said, modern JS, aside from getting all the tooling bootstrapped, is pretty nice to work with imho. There are also a lot of compile-to-js options, and with better sourcemap support, it's pretty clean to use. wasm will lean heavily towards code that needs to be more secure, as well as code that needs absolute performance (gaming mostly)... As to security, using a redux-like workflow, where all action creators use message calls to a websocket connected server-side redux store, then the updates dispatched to the client's store to the UI, so that all logic is at the server would probably be a cleaner and more secure abstraction than wasm though.

michaelwww 11y ago
> WASM can't talk to the DOM directly It will according to multiple sources: "In fact, not only will the JavaScript engine be exposed to WebAssembly modules, but so will the DOM. This means you could, in theory, write whole web applications in C and/or C++ and/or other languages that compile into WebAssembly" [1] "Beyond the MVP (Minimum Viable Product), another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects." [2] [1] http://moduscreate.com/webassembly-explained/ http://moduscreate.com/webassembly-explained/ [2] https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md
- iLoch 11y ago
  I figured this would be the case. This fact will contribute to lots of interesting discussions in the future regarding whether or not we should move away from JS and if so, how. Obviously having something like React is still hugely beneficial for reducing the logical complexity of creating UI, but you'd need to reconsider how you'd write your components without JSX or perhaps some language agnostic version of JSX would need to be created.. Or maybe we just implement E4X type syntax in other languages.
- bobajeff 11y ago
  "Beyond the MVP" is the key phrase here. The first version of webassembly will not be able do that. Just like it won't have dynamic linking, SIMD, shared memory (pthreads) or support for garbage collected languages. It's worth noting that those features were already on the path to being added to it asm.js before webassembly was even being worked on. Most of them are still going to make it to asm.js first.