4 ms·

The performance bottlenecks I mostly see as a frontend engineer are those related to the browser (execution speed, DOM manipulation, and painting). I'm curious

by morley 9y ago

The performance bottlenecks I mostly see as a frontend engineer are those related to the browser (execution speed, DOM manipulation, and painting). I'm curious what workloads wasm can improve, since I assume it'll mostly deal with operations in memory. Maybe physics or graphics calculations in JS game engines?

fiedzia 9y ago
> I'm curious what workloads wasm can improve Those where you have a significant amount of computation. Image/audio/video processing, neural networks, text analysis, games fall there too. Generally, those things are not done in the browser currently, but wasm will change that, so I'd say it will rather open new doors then fix existing ones.
moron4hire 9y ago
JavaScript as a language also doesn't make a lot of guarantees. Dynamic languages are great for small projects, but I think we've very clearly seen from the growing interest in linter tools and gradual type systems like TypeScript and Flow that there is huge interest in having more static guarantees. Compiling to WebAssembly has the added benefit of letting you work in a language that has them already, rather than having to shoehorn them into a language that wasn't ever designed for it. And if we are going to have a translation step regardless (ES2016 to ES5), then why not start with something better than ES2016?
- austincheney 9y ago
  I hear this a lot from people who have little or experience building large applications in high level languages. If you manage your code properly you can have strong/static typing in JavaScript. The difference is that nothing yells at you when you mess that up. Instead the application just runs a little bit slower. I have written large parsers and code beautifiers in JavaScript that blow the shit out of anything I have seen written in other low level languages. There are a couple of advantages that JavaScript provides for this. First of all you get immediate execution without a separate build or compile step. You can see that execution (on really large applications) is a bit slower the first time due to JIT compilation, but successive executions are faster because the code is already compiled in memory. Secondly JavaScript runs almost everywhere. I don't need a special run time or execution context. I can run JS apps on the command line or browser without having to push data to a server location and await a response. Finally, JavaScript is fast now. It executes almost as fast as Java and is only about 4x-8x slower than C++. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=gpp http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... The biggest limitation I have found with JavaScript is memory management. Trying to parse a 180mb (or larger) XML file in my JavaScript application can result in an application crash due to excess memory requirements.
  - dragonwriter 9y ago
    > I hear this a lot from people who have little or experience building large applications in high level languages. If you manage your code properly you can have strong/static typing in JavaScript. No, you can't. If you manage your code properly, you can have code without the kind of errors that would be prevented by static typing, but JavaScript does not have static typing, period. (I mean, you can have it via type annotations in comments and a separate static analyzer, but that's a type language on top of JS, not JS proper.) > The difference is that nothing yells at you when you mess that up. Which means you don't have static typing; static typing is when the types are statically verified prior to runtime, and something does yell at you when they are wrong. > Instead the application just runs a little bit slower. Performance problems are the least issue with uncaught type errors. Crashes and incorrect results are the more common results.
    - e12e 9y ago
      Just a small point: machine code/assembler has limited typing too, but that doesn't mean we say that Haskell isn't strongly typed. Using any number of languages that compile to javascript can give you just as strong typing in js as in any language. (I will grant you that you technically don't "get" strong typing in js, but rather in the language above it - but for practical purposes, you can have a language quite like js, with "actual" strong typing).
    - austincheney 9y ago
      > No, you can't. If, in an application, all your references are of a single data type and those data types never change the types in that application are static. This remains true even though the language is not statically typed. The language may be dynamically typed but all data types are static at execution, which is what static typing is. Also don't confuse static/dynamic type classifications for strong/weak type classifications. > Performance problems are the least issue with uncaught type errors. Crashes and incorrect results are the more common results. Absolutely not in this language.
- jmull 9y ago
  The idea that dynamic languages are OK for small projects but static languages are needed for big ones isn't valid. Static languages don't solve the kinds of problems large projects have over small projects. Static code analysis has its place, but it makes awfully weak guarantees itself. Can you ship a product because you got it to compile? Larger projects of any stripe will want unit tests and other automated tests to ensure it does what it is intended to do. They're also usually going to want linters and other tools to enforce policies. I think when you compare where you are with: 1. static language + linters + decent automated test coverage 2. dynamic language + linters + decent automated test coverage you are in the same place.
withjive 9y ago
While the DOM may always be slow, faster JS (ie. wasm) can provide faster calculations in pure javascript land and better efficiency (better memory management, similar to c++/native stacks). This is useful for optimizing DOM usage, such as using a virtual dom to avoid excessive real DOM access. So while it does not attack the bottle necks directly, it will increase the overal perceivable performance of a webapp.
IshKebab 9y ago
Once there are wasm native APIs you'll be able to do everything without touching Javascript at all, so it can improve all workloads. Some may not get a lot of improvement, if the bottleneck is in the browser engine, e.g. DOM manipulation. But there are many where the browser engine doesn't really do much - OpenGL, audio, any internal computation, etc.
slackingoff2017 9y ago
Wasm is basically a VM so we're going to see a lot of sites that look more like operating systems than HTML... For better or worse.
- hackcasual 9y ago
  Wasm operates using the same VM as JavaScript in the browsers currently supporting it. At this time it is nothing more than a compute optimized subset of JavaScript
haburka 9y ago
Actually WASM as it is right now will not help significantly with any of that. The main issue with javascript is that it is a script, so it has to be compiled before it can be run. Therefore, for decent sized scripts, it can take up to 1-3 seconds to actually parse the damn thing. With WASM, you can send up compiled code which will reduce that initial load time. If you tried to implement OpenGL in WASM, it would be incredibly slow and take a long time to load. You will always be constrained by the browser painting the DOM, or changing canvas, whatever. You can't display info to the user from javascript without modifying the DOM.

by morley 9y ago

fiedzia 9y ago

> I'm curious what workloads wasm can improve Those where you have a significant amount of computation. Image/audio/video processing, neural networks, text analysis, games fall there too. Generally, those things are not done in the browser currently, but wasm will change that, so I'd say it will rather open new doors then fix existing ones.

moron4hire 9y ago

JavaScript as a language also doesn't make a lot of guarantees. Dynamic languages are great for small projects, but I think we've very clearly seen from the growing interest in linter tools and gradual type systems like TypeScript and Flow that there is huge interest in having more static guarantees. Compiling to WebAssembly has the added benefit of letting you work in a language that has them already, rather than having to shoehorn them into a language that wasn't ever designed for it. And if we are going to have a translation step regardless (ES2016 to ES5), then why not start with something better than ES2016?

austincheney 9y ago
I hear this a lot from people who have little or experience building large applications in high level languages. If you manage your code properly you can have strong/static typing in JavaScript. The difference is that nothing yells at you when you mess that up. Instead the application just runs a little bit slower. I have written large parsers and code beautifiers in JavaScript that blow the shit out of anything I have seen written in other low level languages. There are a couple of advantages that JavaScript provides for this. First of all you get immediate execution without a separate build or compile step. You can see that execution (on really large applications) is a bit slower the first time due to JIT compilation, but successive executions are faster because the code is already compiled in memory. Secondly JavaScript runs almost everywhere. I don't need a special run time or execution context. I can run JS apps on the command line or browser without having to push data to a server location and await a response. Finally, JavaScript is fast now. It executes almost as fast as Java and is only about 4x-8x slower than C++. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=gpp http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... The biggest limitation I have found with JavaScript is memory management. Trying to parse a 180mb (or larger) XML file in my JavaScript application can result in an application crash due to excess memory requirements.
- dragonwriter 9y ago
  > I hear this a lot from people who have little or experience building large applications in high level languages. If you manage your code properly you can have strong/static typing in JavaScript. No, you can't. If you manage your code properly, you can have code without the kind of errors that would be prevented by static typing, but JavaScript does not have static typing, period. (I mean, you can have it via type annotations in comments and a separate static analyzer, but that's a type language on top of JS, not JS proper.) > The difference is that nothing yells at you when you mess that up. Which means you don't have static typing; static typing is when the types are statically verified prior to runtime, and something does yell at you when they are wrong. > Instead the application just runs a little bit slower. Performance problems are the least issue with uncaught type errors. Crashes and incorrect results are the more common results.
  - e12e 9y ago
    Just a small point: machine code/assembler has limited typing too, but that doesn't mean we say that Haskell isn't strongly typed. Using any number of languages that compile to javascript can give you just as strong typing in js as in any language. (I will grant you that you technically don't "get" strong typing in js, but rather in the language above it - but for practical purposes, you can have a language quite like js, with "actual" strong typing).
  - austincheney 9y ago
    > No, you can't. If, in an application, all your references are of a single data type and those data types never change the types in that application are static. This remains true even though the language is not statically typed. The language may be dynamically typed but all data types are static at execution, which is what static typing is. Also don't confuse static/dynamic type classifications for strong/weak type classifications. > Performance problems are the least issue with uncaught type errors. Crashes and incorrect results are the more common results. Absolutely not in this language.
jmull 9y ago
The idea that dynamic languages are OK for small projects but static languages are needed for big ones isn't valid. Static languages don't solve the kinds of problems large projects have over small projects. Static code analysis has its place, but it makes awfully weak guarantees itself. Can you ship a product because you got it to compile? Larger projects of any stripe will want unit tests and other automated tests to ensure it does what it is intended to do. They're also usually going to want linters and other tools to enforce policies. I think when you compare where you are with: 1. static language + linters + decent automated test coverage 2. dynamic language + linters + decent automated test coverage you are in the same place.

withjive 9y ago

While the DOM may always be slow, faster JS (ie. wasm) can provide faster calculations in pure javascript land and better efficiency (better memory management, similar to c++/native stacks). This is useful for optimizing DOM usage, such as using a virtual dom to avoid excessive real DOM access. So while it does not attack the bottle necks directly, it will increase the overal perceivable performance of a webapp.

IshKebab 9y ago

Once there are wasm native APIs you'll be able to do everything without touching Javascript at all, so it can improve all workloads. Some may not get a lot of improvement, if the bottleneck is in the browser engine, e.g. DOM manipulation. But there are many where the browser engine doesn't really do much - OpenGL, audio, any internal computation, etc.

slackingoff2017 9y ago

Wasm is basically a VM so we're going to see a lot of sites that look more like operating systems than HTML... For better or worse.

hackcasual 9y ago
Wasm operates using the same VM as JavaScript in the browsers currently supporting it. At this time it is nothing more than a compute optimized subset of JavaScript

haburka 9y ago

Actually WASM as it is right now will not help significantly with any of that. The main issue with javascript is that it is a script, so it has to be compiled before it can be run. Therefore, for decent sized scripts, it can take up to 1-3 seconds to actually parse the damn thing. With WASM, you can send up compiled code which will reduce that initial load time. If you tried to implement OpenGL in WASM, it would be incredibly slow and take a long time to load. You will always be constrained by the browser painting the DOM, or changing canvas, whatever. You can't display info to the user from javascript without modifying the DOM.