4 ms·

The way I see it, most application software is moving to the browser (compare the number of greenfield desktop apps that show up on HN to the number of browser-

by paulgb 3y ago

The way I see it, most application software is moving to the browser (compare the number of greenfield desktop apps that show up on HN to the number of browser-based apps). In a world without WebAssembly, this would mean that all application software will be written in JavaScript. This is a bad outcome! JavaScript is a fine DSL for GUIs, but it is not a great programming language for applications, especially when you get into graphically-intensive, data-intensive, scientific, etc. software. Wasm is an out that allows developers to write the application core in another language like Rust or C++, as they would on the desktop, while still delivering software in the browser. A bunch of products are quietly doing this already. (One is in the process of a $20bn acquisition.)

austin-cheney 3y ago
JavaScript is bad for graphically intense application for the same reasons Java, C#, and host of other language families are bad at it, they are garbage collected languages. Garbage collection imposes a processing jitter. That is certainly a valid use case for WASM, but I am not this take hold in the wild. Again, valid use cases aside its not what most developers want to use it for.
- Pannoniae 3y ago
  You can pause GC and pre-allocate memory in C# in addition to stack-allocating anything you want. Just because people don't do it it doesn't mean it's not possible. Of course in reality almost no one bothers because "the user can buy a newer machine anyway"-sort of thinking, sadly.
- kaba0 3y ago
  > JavaScript is bad for graphically intense application Are they? It’s not like C++ is tossing around pixels itself, it commands the GPU to do so. Sure, there is a point where the speed at which the CPU side of data being supplied will be the bottleneck, but it is so far above typical desktop applications that it is incorrect to call managed languages unfit for graphically intensive applications (as shown by all those indie games). Also, there are many different kinds of GCs, and you can limit the max pause time to very low values for a slightly lower throughput (note: this same tradeoff will happen without a GC also, these two are very often opposite ends of the same spectrum) to the point that unless you are using special real-time kernel with all the necessary process configs, your OS’s scheduler will introduce bigger pauses.

by paulgb 3y ago

austin-cheney 3y ago

JavaScript is bad for graphically intense application for the same reasons Java, C#, and host of other language families are bad at it, they are garbage collected languages. Garbage collection imposes a processing jitter. That is certainly a valid use case for WASM, but I am not this take hold in the wild. Again, valid use cases aside its not what most developers want to use it for.

Pannoniae 3y ago
You can pause GC and pre-allocate memory in C# in addition to stack-allocating anything you want. Just because people don't do it it doesn't mean it's not possible. Of course in reality almost no one bothers because "the user can buy a newer machine anyway"-sort of thinking, sadly.
kaba0 3y ago
> JavaScript is bad for graphically intense application Are they? It’s not like C++ is tossing around pixels itself, it commands the GPU to do so. Sure, there is a point where the speed at which the CPU side of data being supplied will be the bottleneck, but it is so far above typical desktop applications that it is incorrect to call managed languages unfit for graphically intensive applications (as shown by all those indie games). Also, there are many different kinds of GCs, and you can limit the max pause time to very low values for a slightly lower throughput (note: this same tradeoff will happen without a GC also, these two are very often opposite ends of the same spectrum) to the point that unless you are using special real-time kernel with all the necessary process configs, your OS’s scheduler will introduce bigger pauses.