6 ms·

The official FAQ specifically states the opposite of the second bullet point. Web Assembly is not meant to be a replacement for JavaScript. And although the bl

The official FAQ specifically states the opposite of the second bullet point. Web Assembly is not meant to be a replacement for JavaScript. And although the blog doesn't explicitly say it, it's alluding to it being easy to create entire applications without using JavaScript at all. JavaScript is going to continue to be used as "glue code" at the very least, and UI code in the majority of cases. I think it's really important to make this distinction. Trying to use web assembly as a solution to problems it's explicitly not meant to solve is only going to lead to pain and frustration. Furthermore, things like "static type checking", easy functional programming, and making application coding "less painful" aren't really goals as the post seems to make them out to be as well.

jjn2009 9y ago
the roadmap for WebAssembly does include interfaces into DOM manipulation, it's not the highest priority but allowing javascript replacement isn't completely out of the scope of web assembly. Just don't expect it to be a good idea for quite some time.
- michaelchisari 9y ago
  Yeah, I think people are being conservative about where WebAssembly will lead us. Which I think is smart. Promise little, deliver big never hurt anyone, especially not open standards. But I would love to have an Elm that compiles directly to wasm. I'd love to write a front-page app in Go or Python, or mix in some Rust code. People talk about Javascript fatigue, and it's real and exhausting to keep up with the constant framework churn. But I think the biggest reason at the root of it all is Javascript. Nobody talks about Unix fatigue, and all the different languages and frameworks that you can use to build your backend services. When we have a truly open-ended platform to build on, we're not going to feel this fatigue, I don't think.
  - couchand 9y ago
    If the problem is really just JavaScript itself WASM won't be able to help -- WASM is basically just asm.js, which is just a restricted subset of JavaScript, but easier to parse and optimize.
    - jjn2009 9y ago
      >a restricted subset of JavaScript This actually isn't the case. Browsers provide a virtual machine which can run assembly code with web assembly, its that simple, nothing about it necessitates javascript except that its the interface to the DOM, in the future it could very well be possible to have a new script tag type which is ASM and requires zero javascript or javascript runtime.
      - couchand 9y ago
        I didn't say WASM was a restricted subset of JavaScript. I understand that it is a lower-level virtual machine, and that in fact it provides some primitives that asm.js doesn't (e.g. 64 bit integers). My point was that if you're looking to WASM to be some kind of silver bullet, you've got the wrong expectations. The causes of people's JavaScript fatigue have little if anything to do with JavaScript the language.
  - jjn2009 9y ago
    Well on one hand you will definitely increase the number of ways to do DOM manipulation, but on the other isolated communities could move at different paces. I think its hard to say if the dominate mode of ui web dev will slow down, I've definitely experienced this fatigue, its a huge issue. Some how the unix way of small composable parts which work well needs to find its way to the browser.
bluejekyll 9y ago
> Web Assembly is not meant to be a replacement for JavaScript. This seems like a very short sighted view. It's meant to offer options other than JavaScript. For many of us who dislike JS, this is exactly what webassembly represents, a way to deploy applications without JavaScript to the browser, in effect finally achieving the full dream of the JVM. And yes, DOM integration isn't there right now, but it will be. It makes sense to me that this is initially being limited for a number of reasons. It definitely means people won't immediately glob onto it, reducing the potential of accidentally locking in implementation bugs/features. Some people think the DOM is unnecessary even in a webassembly world, but I think CSS and the DOM are generally good, what I've always wanted is a better language option. I'm practically giddy with the potential for all of this finally happening!
- couchand 9y ago
  I'm excited but I'm also cautious. I'm not sure that WASM has a slam dunk story in terms of many web-native concepts, for instance asynchronous execution. The browser APIs will likely lag far behind JS, and DOM integration is just one thing there - also fetch, indexeddb/localstorage, and so forth. WASM gives us some additional tools for the web toolbelt, but it will be a long, long time before it's mature enough to completely replace JS. That being said, I hope I'm proven wrong.
- zurn 9y ago
  JS is a much better compile target for many languages for the foreseeable future. "Without JS" is not a sensible end in itself.
- TheAceOfHearts 9y ago
  I think people are severely underestimating the challenges of integrating WASM with JS an DOM. Right now styling and DOM are the two biggest performance bottlenecks. No doubt it'll happen, but I'd be amazed if performance weren't terrible out of the box. Plenty of DOM APIs are terrible. Oh, you want a database? Tough luck, here's IndexedDB.
  - pjmlp 9y ago
6nf 9y ago
> JavaScript is going to continue to be used as "glue code" This is a temporary situation. Eventually you'll be able to do everythign in WebAssembly, including DOM access etc. How long that will take is anyone's guess but it's certainly on the minds of the wasm team.

jjn2009 9y ago

the roadmap for WebAssembly does include interfaces into DOM manipulation, it's not the highest priority but allowing javascript replacement isn't completely out of the scope of web assembly. Just don't expect it to be a good idea for quite some time.

michaelchisari 9y ago
Yeah, I think people are being conservative about where WebAssembly will lead us. Which I think is smart. Promise little, deliver big never hurt anyone, especially not open standards. But I would love to have an Elm that compiles directly to wasm. I'd love to write a front-page app in Go or Python, or mix in some Rust code. People talk about Javascript fatigue, and it's real and exhausting to keep up with the constant framework churn. But I think the biggest reason at the root of it all is Javascript. Nobody talks about Unix fatigue, and all the different languages and frameworks that you can use to build your backend services. When we have a truly open-ended platform to build on, we're not going to feel this fatigue, I don't think.
- couchand 9y ago
  If the problem is really just JavaScript itself WASM won't be able to help -- WASM is basically just asm.js, which is just a restricted subset of JavaScript, but easier to parse and optimize.
  - jjn2009 9y ago
    >a restricted subset of JavaScript This actually isn't the case. Browsers provide a virtual machine which can run assembly code with web assembly, its that simple, nothing about it necessitates javascript except that its the interface to the DOM, in the future it could very well be possible to have a new script tag type which is ASM and requires zero javascript or javascript runtime.
    - couchand 9y ago
      I didn't say WASM was a restricted subset of JavaScript. I understand that it is a lower-level virtual machine, and that in fact it provides some primitives that asm.js doesn't (e.g. 64 bit integers). My point was that if you're looking to WASM to be some kind of silver bullet, you've got the wrong expectations. The causes of people's JavaScript fatigue have little if anything to do with JavaScript the language.
- jjn2009 9y ago
  Well on one hand you will definitely increase the number of ways to do DOM manipulation, but on the other isolated communities could move at different paces. I think its hard to say if the dominate mode of ui web dev will slow down, I've definitely experienced this fatigue, its a huge issue. Some how the unix way of small composable parts which work well needs to find its way to the browser.

bluejekyll 9y ago

> Web Assembly is not meant to be a replacement for JavaScript. This seems like a very short sighted view. It's meant to offer options other than JavaScript. For many of us who dislike JS, this is exactly what webassembly represents, a way to deploy applications without JavaScript to the browser, in effect finally achieving the full dream of the JVM. And yes, DOM integration isn't there right now, but it will be. It makes sense to me that this is initially being limited for a number of reasons. It definitely means people won't immediately glob onto it, reducing the potential of accidentally locking in implementation bugs/features. Some people think the DOM is unnecessary even in a webassembly world, but I think CSS and the DOM are generally good, what I've always wanted is a better language option. I'm practically giddy with the potential for all of this finally happening!

couchand 9y ago
I'm excited but I'm also cautious. I'm not sure that WASM has a slam dunk story in terms of many web-native concepts, for instance asynchronous execution. The browser APIs will likely lag far behind JS, and DOM integration is just one thing there - also fetch, indexeddb/localstorage, and so forth. WASM gives us some additional tools for the web toolbelt, but it will be a long, long time before it's mature enough to completely replace JS. That being said, I hope I'm proven wrong.
zurn 9y ago
JS is a much better compile target for many languages for the foreseeable future. "Without JS" is not a sensible end in itself.
TheAceOfHearts 9y ago
I think people are severely underestimating the challenges of integrating WASM with JS an DOM. Right now styling and DOM are the two biggest performance bottlenecks. No doubt it'll happen, but I'd be amazed if performance weren't terrible out of the box. Plenty of DOM APIs are terrible. Oh, you want a database? Tough luck, here's IndexedDB.
- pjmlp 9y ago

6nf 9y ago

> JavaScript is going to continue to be used as "glue code" This is a temporary situation. Eventually you'll be able to do everythign in WebAssembly, including DOM access etc. How long that will take is anyone's guess but it's certainly on the minds of the wasm team.