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.
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.
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?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.
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.
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).
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.
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.
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.
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.