10 ms·

Is there still a need for performant JavaScript now that we have WebAssembly? Edit: Apologies for wording this poorly. Clearly there is a need for performant J

Is there still a need for performant JavaScript now that we have WebAssembly? Edit: Apologies for wording this poorly. Clearly there is a need for performant JavaScript. My question is more about how much we expect WebAssembly to take over from what JavaScript is currently used for. Thank you for all the insightful comments!

bioemerl 9y ago
Absolutely
izacus 9y ago
WebAssembly has no access to DOM so you still need JS to drive the UI in most cases.
- pjmlp 9y ago
  There is WebGL. DOM access to WebAssembly will come. https://github.com/WebAssembly/design/labels/Phase%201%3A%20Feature%20Proposal https://github.com/WebAssembly/design/labels/Phase%201%3A%20...
  - abritinthebay 9y ago
    And it will be incredibly slow. The DOM is slow. WebAssembly is not much faster than JS, harder to develop and debug, and requires even more extra tooling. It’s a useful technology but it’s never going to be the primary choice for application development on the web - merely a tool in the toolbox.
    - pjmlp 9y ago
      Yet Qt, .NET, Java, Go, C, C++ are all getting ready for the plugins renaissance.
      - marktangotango 9y ago
        Can you clarify what exactly you’re referring to here?
        pjmlp 9y ago
        Basically targeting WebAssembly as if it was just yet another hardware architecture. So expect the comeback of Flash, Silverlight, Applets, ActiveX, .... What to do a Flash like game without anything related to JavaScript? Pure C, C++, Rust with SDL, Unreal, Unity, .... Miss Silverlight? Check Blazor with Ooui bindigs for Xamarin.Forms. Go devs already have their design document for WebAssembly runtime ("WebAssembly architecture for Go"). Qt already has a prototype for WebAssembly, with improvements planned on 2018's roadmap. And many other projects are ongoing. The pandora box is open, the only back is if the browser vendors stop developing WebAssembly.
  - lhorie 9y ago
    No one's going to use WebGL as an alternative to the DOM until it supports accessibility (read: being visible to googlebot) Even if it did, you'd still lose a lot of productivity with it if you're used to working with the high level of abstraction of the DOM, e.g. line wrapping. There are certainly cases where dropping to GLSL is the only way to get a UI to work at all, but most of the time the metadata-providing feature of HTML is far more important than squeezing some milliseconds of performance.
    - pjmlp 9y ago
      Not everyone cares about accessibility. They did not care with Flash, neither they will care now. Just wait until we get Flash like tooling for WebAssembly.
      - lhorie 9y ago
        Flash had better accessibility support than WebGL does today. Google could even crawl Flash content to a certain extent. Besides, I said _WebGL as an alternative to the DOM_. Of course a complex visualization that can't be properly described with text will not care about supporting jaws (even though it might have gotten some free accessibility out of the box with Flash). If you rely on the DOM like most people do, there's a huge chance that you care about your text being machine-readable. Accessibility is just one of the showstoppers for generalized WebGL adoption. SEO is another. I think some people severely underestimate the barrier of entry that WebGL/wasm needs to overcome to displace Javascript/DOM as general purpose tools.
fvdessen 9y ago
JavaScript ES6 is actually a very pleasant language to program in. JS already had good foundations with first class JSON, closures and event based asynchronous programming. Now it has a modern syntax with await, classes, destructuring, default parameters, the spread operator, etc. Add to that an incredible debugger and amazing performance. Frankly at this point JS can stand on its own as a great programming language.
- tim_hutton 9y ago
  I like JavaScript a lot, I've got no problem with it. But when WebAssembly can access the DOM (or replace it) it seems likely that performance-critical code will use that instead.
  - m0meni 9y ago
    But how often do front end applications have performance critical code that operates on the DOM? Even then, it's more likely that if you need to render something that requires that much processing power it'd make more sense to use something like canvas with WebGL.
  - chatmasta 9y ago
    Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6. That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
    - notheguyouthink 9y ago
      > Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6. Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer. Especially since many people don't want to use JS to begin with, but have been forced to. > That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases. I'll be sad if that is true. Though, I'd even be willing to take minor performance hits to use the languages/etc I want. How much of a hit I'd be willing to take would really depend on the application needs, of course.
golergka 9y ago
Node?
k__ 9y ago
I had the impression that JS is the language spoken by most devs. WebAssembly is for the nieche languages ;)
vanderZwan 9y ago
I love WebAssembly, but it is only as good as how easy it is to pass raw bytes between its modules and the rest of the browser environment. For example, if you want to do anything involving strings, you have to convert it to a typed array. So that is invoking charCodeAt for every character and saving it to an index in such an array. If you want to get a string out, you have to convert uint charcodes to single-char strings and append them together one at a time. The overhead of these things alone probably makes WASM useless for almost all code involving string manipulation (that also interacts with the rest of the browser). That is not to say that WASM is useless for strings either: if you have one huge string, only need to convert it to bytes once, and then do repeated operations on the resulting data within WASM, there is a bigger chance that it works out. For example, parsing source code: one conversion to WASM is enough, the rest can be handled from within WASM. Fast search using a prefix trie also sounds plausible: the trie can be built up within WASM, and for searching one only needs to return the indices of matching substrings within the original string. That is a lot less overhead. Anyway, my pint is: yes, we definitely need performant JavaScript. And I wouldn't be surprised if faster WebAssembly leads to faster JavaScript as well: sorting Typed Arrays used to be so slow that a custom radix sort implemented in JavaScript beat the built-in sort by 4-10x. Somewhere in the last five versions of Chrome the Uint32Array and Int32Arrays got an enormous speed boost. My guess is: because of the demand of faster interop with WASM, something under the hood was improved, directly or indirectly leading to faster sorting as well.
- jsheard 9y ago
  The TextDecoder/TextEncoder APIs are a much easier and faster way to handle WASM strings, and most browsers already support them (Edge doesn't but can be polyfilled). https://caniuse.com/#feat=textencoder https://caniuse.com/#feat=textencoder
  - vanderZwan 9y ago
    Hadn't heard of those yet, thanks! TextDecoder looks fine, but I'm a bit wary of using TextEncoder naively. It requires allocating a Uint8Array for each string. Each Uint8Array comes with 200 bytes of overhead[0]. Depending on your algorithm you can end up with thousands if not millions of tiny strings. While even phones will probably have enough RAM to handle a few hundred megabytes these days, that will slow things down simply from an allocation/garbage collection perspective. Furthermore, typed array allocation used to be incredibly slow compared to array allocation - the gap is smaller now but it is still slow enough to be a bottle-neck in my code. The quote below is from a V8 dev replying to someone who opened an issue about this slow allocation. It is from 2012, but it still applies: > The reason is simply that while constructing Array is done exclusively in the Javascript virtual machine and an allocation in the VM's heap, constructing a TypedArray involves the browser binding (at least in Chrome) and allocation outside the VM's heap. The former can be properly optimized, while the latter cannot. Future optimizations in this area are already on our radar, but have rather low priority. > Generally speaking, typed arrays are good if you want to allocate a long-living dense array with a certain type and size. Array objects are better if you want to create temporary arrays often. I hope things will improve now that Typed Arrays finally get some proper love thanks to WASM. [0] https://stackoverflow.com/questions/45803829/memory-overhead-of-typed-arrays-vs-strings https://stackoverflow.com/questions/45803829/memory-overhead... [1] https://bugs.chromium.org/p/v8/issues/detail?id=2190 https://bugs.chromium.org/p/v8/issues/detail?id=2190 [2] https://jsperf.com/typedarray-create https://jsperf.com/typedarray-create
bryanlarsen 9y ago
Even if everybody stopped writing Javascript tomorrow, the massive installed base of Javascript would justify effort for optimization.
- tim_hutton 9y ago
  Yes, you are quite right. My question was poorly worded.
pvg 9y ago
We've had regular assembly for decades and it doesn't seem to have stopped people from trying to make higher-level languages faster. Just the opposite, somehow!
Thaxll 9y ago
WebAssembly will probably not take off anyway, no one want to dev in C++ or equivalent for web you know.
- akmittal 9y ago
  There's Rust, Swift, C#, Go. Plenty of people would like to(many do already) write in these languages.
  - abritinthebay 9y ago
    I’d amend that to “Some would like to (a few do already)…” The user base of those languages that wants to do this is incredibly small right now
  - lhorie 9y ago
    I think the argument is that the set containing people who work with web UIs and the set of people who use Rust/Swift/C#/Go don't overlap very much, and generally people aren't going to learn a new stack unless there's an extraordinary external motivation to do so.
- titzer 9y ago
  A lot of legacy apps want to bring their party to the web, and game engines are using WebAssembly as a replacement for NaCl and Flash. Even big engines like Unreal are coming. It's a different kind of application and use case.
ggregoire 9y ago
I want to keep writing code in JavaScript.
mschuetz 9y ago
V8 is a great scripting engine on its own. I've been using it to allow some runtime scripting in my C++ App, which also makes things a lot easier to debug. It's always nice to see improvements to it, especially since I'm considering to do some core features, such as the rendering pipeline, through js bindings instead of C++. Would make it easier to quickly prototype, test and benchmark different OpenGL calls, shaders, etc. JS has also become nice to work with since ES6. Incredibly easy to set up a working environment, amazing debugging capabilities, you can just change a few lines and instantly get to see your result by pressing F5, etc. The only really big downside is that static typing is missing, but right now I'd rather not have static typing than go through the additional hoops of setting up transpiler builds. I'd probably switch to typescript if it was natively supported by browsers and V8, but JS is just fine till then.
- sifoo 9y ago
  There are several leaner alternatives for application scripting, is it really worth dragging V8 around to get that capability? Lua would be one alternative. The reason I'm asking is that I'm working on a more Forth-inspired alternative[0] for application scripting myself, and I'm curious about the reasons for defaulting to the crappiest language ever invented and an implementation controlled by one of the biggest corporate bullies around. [0] https://github.com/basic-gongfu/cixl https://github.com/basic-gongfu/cixl
  - mschuetz 9y ago
    > defaulting to the crappiest language ever invented Since we're trolling now, there is plenty worse around, like Python(the only language that manages to have worse scoping rules then pre-ES6 javascript, which is quite a feat), Cobol and LUA. JS ES6 is just fine. The trick is not to use the crap parts.
    - sifoo 9y ago
      Not my intention at all, I have been writing code for 32 years, including several years of web/JS and I have yet to come across anything worse. If you can't even deal with other people having different perspectives on your choice of technology without calling them trolls, maybe you should consider untangling your identity from your choices.

bioemerl 9y ago

Absolutely

izacus 9y ago

WebAssembly has no access to DOM so you still need JS to drive the UI in most cases.

pjmlp 9y ago
There is WebGL. DOM access to WebAssembly will come. https://github.com/WebAssembly/design/labels/Phase%201%3A%20Feature%20Proposal https://github.com/WebAssembly/design/labels/Phase%201%3A%20...
- abritinthebay 9y ago
  And it will be incredibly slow. The DOM is slow. WebAssembly is not much faster than JS, harder to develop and debug, and requires even more extra tooling. It’s a useful technology but it’s never going to be the primary choice for application development on the web - merely a tool in the toolbox.
  - pjmlp 9y ago
    Yet Qt, .NET, Java, Go, C, C++ are all getting ready for the plugins renaissance.
    - marktangotango 9y ago
      Can you clarify what exactly you’re referring to here?
      - pjmlp 9y ago
        Basically targeting WebAssembly as if it was just yet another hardware architecture. So expect the comeback of Flash, Silverlight, Applets, ActiveX, .... What to do a Flash like game without anything related to JavaScript? Pure C, C++, Rust with SDL, Unreal, Unity, .... Miss Silverlight? Check Blazor with Ooui bindigs for Xamarin.Forms. Go devs already have their design document for WebAssembly runtime ("WebAssembly architecture for Go"). Qt already has a prototype for WebAssembly, with improvements planned on 2018's roadmap. And many other projects are ongoing. The pandora box is open, the only back is if the browser vendors stop developing WebAssembly.
- lhorie 9y ago
  No one's going to use WebGL as an alternative to the DOM until it supports accessibility (read: being visible to googlebot) Even if it did, you'd still lose a lot of productivity with it if you're used to working with the high level of abstraction of the DOM, e.g. line wrapping. There are certainly cases where dropping to GLSL is the only way to get a UI to work at all, but most of the time the metadata-providing feature of HTML is far more important than squeezing some milliseconds of performance.
  - pjmlp 9y ago
    Not everyone cares about accessibility. They did not care with Flash, neither they will care now. Just wait until we get Flash like tooling for WebAssembly.
    - lhorie 9y ago
      Flash had better accessibility support than WebGL does today. Google could even crawl Flash content to a certain extent. Besides, I said _WebGL as an alternative to the DOM_. Of course a complex visualization that can't be properly described with text will not care about supporting jaws (even though it might have gotten some free accessibility out of the box with Flash). If you rely on the DOM like most people do, there's a huge chance that you care about your text being machine-readable. Accessibility is just one of the showstoppers for generalized WebGL adoption. SEO is another. I think some people severely underestimate the barrier of entry that WebGL/wasm needs to overcome to displace Javascript/DOM as general purpose tools.

fvdessen 9y ago

JavaScript ES6 is actually a very pleasant language to program in. JS already had good foundations with first class JSON, closures and event based asynchronous programming. Now it has a modern syntax with await, classes, destructuring, default parameters, the spread operator, etc. Add to that an incredible debugger and amazing performance. Frankly at this point JS can stand on its own as a great programming language.

tim_hutton 9y ago
I like JavaScript a lot, I've got no problem with it. But when WebAssembly can access the DOM (or replace it) it seems likely that performance-critical code will use that instead.
- m0meni 9y ago
  But how often do front end applications have performance critical code that operates on the DOM? Even then, it's more likely that if you need to render something that requires that much processing power it'd make more sense to use something like canvas with WebGL.
- chatmasta 9y ago
  Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6. That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
  - notheguyouthink 9y ago
    > Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6. Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer. Especially since many people don't want to use JS to begin with, but have been forced to. > That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases. I'll be sad if that is true. Though, I'd even be willing to take minor performance hits to use the languages/etc I want. How much of a hit I'd be willing to take would really depend on the application needs, of course.

golergka 9y ago

Node?

k__ 9y ago

I had the impression that JS is the language spoken by most devs. WebAssembly is for the nieche languages ;)

vanderZwan 9y ago

I love WebAssembly, but it is only as good as how easy it is to pass raw bytes between its modules and the rest of the browser environment. For example, if you want to do anything involving strings, you have to convert it to a typed array. So that is invoking charCodeAt for every character and saving it to an index in such an array. If you want to get a string out, you have to convert uint charcodes to single-char strings and append them together one at a time. The overhead of these things alone probably makes WASM useless for almost all code involving string manipulation (that also interacts with the rest of the browser). That is not to say that WASM is useless for strings either: if you have one huge string, only need to convert it to bytes once, and then do repeated operations on the resulting data within WASM, there is a bigger chance that it works out. For example, parsing source code: one conversion to WASM is enough, the rest can be handled from within WASM. Fast search using a prefix trie also sounds plausible: the trie can be built up within WASM, and for searching one only needs to return the indices of matching substrings within the original string. That is a lot less overhead. Anyway, my pint is: yes, we definitely need performant JavaScript. And I wouldn't be surprised if faster WebAssembly leads to faster JavaScript as well: sorting Typed Arrays used to be so slow that a custom radix sort implemented in JavaScript beat the built-in sort by 4-10x. Somewhere in the last five versions of Chrome the Uint32Array and Int32Arrays got an enormous speed boost. My guess is: because of the demand of faster interop with WASM, something under the hood was improved, directly or indirectly leading to faster sorting as well.

jsheard 9y ago
The TextDecoder/TextEncoder APIs are a much easier and faster way to handle WASM strings, and most browsers already support them (Edge doesn't but can be polyfilled). https://caniuse.com/#feat=textencoder https://caniuse.com/#feat=textencoder
- vanderZwan 9y ago
  Hadn't heard of those yet, thanks! TextDecoder looks fine, but I'm a bit wary of using TextEncoder naively. It requires allocating a Uint8Array for each string. Each Uint8Array comes with 200 bytes of overhead[0]. Depending on your algorithm you can end up with thousands if not millions of tiny strings. While even phones will probably have enough RAM to handle a few hundred megabytes these days, that will slow things down simply from an allocation/garbage collection perspective. Furthermore, typed array allocation used to be incredibly slow compared to array allocation - the gap is smaller now but it is still slow enough to be a bottle-neck in my code. The quote below is from a V8 dev replying to someone who opened an issue about this slow allocation. It is from 2012, but it still applies: > The reason is simply that while constructing Array is done exclusively in the Javascript virtual machine and an allocation in the VM's heap, constructing a TypedArray involves the browser binding (at least in Chrome) and allocation outside the VM's heap. The former can be properly optimized, while the latter cannot. Future optimizations in this area are already on our radar, but have rather low priority. > Generally speaking, typed arrays are good if you want to allocate a long-living dense array with a certain type and size. Array objects are better if you want to create temporary arrays often. I hope things will improve now that Typed Arrays finally get some proper love thanks to WASM. [0] https://stackoverflow.com/questions/45803829/memory-overhead-of-typed-arrays-vs-strings https://stackoverflow.com/questions/45803829/memory-overhead... [1] https://bugs.chromium.org/p/v8/issues/detail?id=2190 https://bugs.chromium.org/p/v8/issues/detail?id=2190 [2] https://jsperf.com/typedarray-create https://jsperf.com/typedarray-create

bryanlarsen 9y ago

Even if everybody stopped writing Javascript tomorrow, the massive installed base of Javascript would justify effort for optimization.

tim_hutton 9y ago
Yes, you are quite right. My question was poorly worded.

pvg 9y ago

We've had regular assembly for decades and it doesn't seem to have stopped people from trying to make higher-level languages faster. Just the opposite, somehow!

Thaxll 9y ago

WebAssembly will probably not take off anyway, no one want to dev in C++ or equivalent for web you know.

akmittal 9y ago
There's Rust, Swift, C#, Go. Plenty of people would like to(many do already) write in these languages.
- abritinthebay 9y ago
  I’d amend that to “Some would like to (a few do already)…” The user base of those languages that wants to do this is incredibly small right now
- lhorie 9y ago
  I think the argument is that the set containing people who work with web UIs and the set of people who use Rust/Swift/C#/Go don't overlap very much, and generally people aren't going to learn a new stack unless there's an extraordinary external motivation to do so.
titzer 9y ago
A lot of legacy apps want to bring their party to the web, and game engines are using WebAssembly as a replacement for NaCl and Flash. Even big engines like Unreal are coming. It's a different kind of application and use case.

ggregoire 9y ago

I want to keep writing code in JavaScript.

mschuetz 9y ago

V8 is a great scripting engine on its own. I've been using it to allow some runtime scripting in my C++ App, which also makes things a lot easier to debug. It's always nice to see improvements to it, especially since I'm considering to do some core features, such as the rendering pipeline, through js bindings instead of C++. Would make it easier to quickly prototype, test and benchmark different OpenGL calls, shaders, etc. JS has also become nice to work with since ES6. Incredibly easy to set up a working environment, amazing debugging capabilities, you can just change a few lines and instantly get to see your result by pressing F5, etc. The only really big downside is that static typing is missing, but right now I'd rather not have static typing than go through the additional hoops of setting up transpiler builds. I'd probably switch to typescript if it was natively supported by browsers and V8, but JS is just fine till then.

sifoo 9y ago
There are several leaner alternatives for application scripting, is it really worth dragging V8 around to get that capability? Lua would be one alternative. The reason I'm asking is that I'm working on a more Forth-inspired alternative[0] for application scripting myself, and I'm curious about the reasons for defaulting to the crappiest language ever invented and an implementation controlled by one of the biggest corporate bullies around. [0] https://github.com/basic-gongfu/cixl https://github.com/basic-gongfu/cixl
- mschuetz 9y ago
  > defaulting to the crappiest language ever invented Since we're trolling now, there is plenty worse around, like Python(the only language that manages to have worse scoping rules then pre-ES6 javascript, which is quite a feat), Cobol and LUA. JS ES6 is just fine. The trick is not to use the crap parts.
  - sifoo 9y ago
    Not my intention at all, I have been writing code for 32 years, including several years of web/JS and I have yet to come across anything worse. If you can't even deal with other people having different perspectives on your choice of technology without calling them trolls, maybe you should consider untangling your identity from your choices.