3 ms·

"To summarize: scripting languages are useful, but they’re all pretty much the same, " Yeah ... I'm just going to have to go ahead and um disagree about that.

"To summarize: scripting languages are useful, but they’re all pretty much the same, " Yeah ... I'm just going to have to go ahead and um disagree about that. But I agree with the point that a higher level and well defined universal container/vm can be valuable. I think it'll be wasm-based though, not js.

lucasyvas 5y ago
It should be WASM - I hope it will be WASM. JS leaves a lot to be desired and there are some things that will just be too hard to change.
- beeandapenguin 5y ago
  It is WASM. This is implied in the post, even though the emphasis is on JS. WASM is still early and has a young ecosystem. Only now are we really starting to explore what WASM can do and I predict that will only accelerate.
  - vinnymac 5y ago
    Yea, I believe they made that fairly clear in this paragraph of the article. > Instead of invoking Linux executables, like shell does, the JavaScript sandbox can invoke Wasm. If you have some computational heavy lifting, like image resizing, it probably makes sense to use Wasm rather than writing it in JS. Just like you wouldn’t write image resizing code in bash, you’d spawn imagemagick. I agree with you all. WASM should be the solution to the problem in this space.
throwaway894345 5y ago
Agreed. The only thing JS has over WASM is that you don't need to ship a language runtime or standard library with your application. The counterpoint is that the JS standard library is pretty anemic so the savings might not be that great, and applications might need a more recent runtime version than the host offers (e.g., Java applications often bundle the JVM so they don't have to worry about the version installed on the target platform).
DrFell 5y ago
If you polled all the engineers that work on actually designing and building browsers, I bet they would all say "Of course Wasm containers sounds way better than JavaScript containers. What are you, a pathetic frontend noob? Oh, wait, even they don't use JavaScript anymore. They all use a superset of it that's slighly less stupid. JavaScript containers, sheesh. Go be quiet in the corner."

lucasyvas 5y ago

It should be WASM - I hope it will be WASM. JS leaves a lot to be desired and there are some things that will just be too hard to change.

beeandapenguin 5y ago
It is WASM. This is implied in the post, even though the emphasis is on JS. WASM is still early and has a young ecosystem. Only now are we really starting to explore what WASM can do and I predict that will only accelerate.
- vinnymac 5y ago
  Yea, I believe they made that fairly clear in this paragraph of the article. > Instead of invoking Linux executables, like shell does, the JavaScript sandbox can invoke Wasm. If you have some computational heavy lifting, like image resizing, it probably makes sense to use Wasm rather than writing it in JS. Just like you wouldn’t write image resizing code in bash, you’d spawn imagemagick. I agree with you all. WASM should be the solution to the problem in this space.

throwaway894345 5y ago

Agreed. The only thing JS has over WASM is that you don't need to ship a language runtime or standard library with your application. The counterpoint is that the JS standard library is pretty anemic so the savings might not be that great, and applications might need a more recent runtime version than the host offers (e.g., Java applications often bundle the JVM so they don't have to worry about the version installed on the target platform).

DrFell 5y ago

If you polled all the engineers that work on actually designing and building browsers, I bet they would all say "Of course Wasm containers sounds way better than JavaScript containers. What are you, a pathetic frontend noob? Oh, wait, even they don't use JavaScript anymore. They all use a superset of it that's slighly less stupid. JavaScript containers, sheesh. Go be quiet in the corner."