3 ms·

Mr Crockford has done a lot for the JS world, but I think he's on the wrong track. The best thing we should be doing is focusing on building a best-of-breed VM

Mr Crockford has done a lot for the JS world, but I think he's on the wrong track. The best thing we should be doing is focusing on building a best-of-breed VM replacement in WebAssembly where the language is disconnected from the page itself. Build infrastructure and the right languages will come. Build another language, and we'll end up building a second Javascript.

devwastaken 4y ago
This is worse, the runtime overhead will always persist. It's nature is to be secure, not fast. It can be faster than JS in instances where you're doing heavy lifting of memory/algorithms. But that is limited to languages like C/Rust that are compiled directly without need for a runtime.
- mmastrac 4y ago
  There's no such thing as "not secure" for web-based languages. If the language is not secure, it's simply a non-starter. You cannot bolt on security to the web. You simply cannot build with "fast" as a primary motivation.
  - devwastaken 4y ago
    It's a spectrum. JIT is inherently insecure, but is "secure enough" given other guards. We use it because it's fast, at the added risk. We can infact make things provably safe within certain contexts. But we don't, because it's hard, and it can never perform as well. Wasms safety is dependent upon the runtime implementation, not the language. "Fast" is a motivation in web. If it renders slow, it loses money. We have 20 years of hacky methods to make JavaScript fast. These lead to security flaws.
out_of_protocol 4y ago
There was NaCl, PNaCl by google. Didn't fly though, i think because there was no fallback possible. Near-native performance (within 10% margin), any concurrency you can think of. Played Bastion game in browser on crappy old macbook Air many many years ago
- mmastrac 4y ago
  PNaCl was a terrible, terrible hack on top of LLVM's intermediate representation. The only good thing that came of it was paving the way for WebAssembly.

devwastaken 4y ago

This is worse, the runtime overhead will always persist. It's nature is to be secure, not fast. It can be faster than JS in instances where you're doing heavy lifting of memory/algorithms. But that is limited to languages like C/Rust that are compiled directly without need for a runtime.

mmastrac 4y ago
There's no such thing as "not secure" for web-based languages. If the language is not secure, it's simply a non-starter. You cannot bolt on security to the web. You simply cannot build with "fast" as a primary motivation.
- devwastaken 4y ago
  It's a spectrum. JIT is inherently insecure, but is "secure enough" given other guards. We use it because it's fast, at the added risk. We can infact make things provably safe within certain contexts. But we don't, because it's hard, and it can never perform as well. Wasms safety is dependent upon the runtime implementation, not the language. "Fast" is a motivation in web. If it renders slow, it loses money. We have 20 years of hacky methods to make JavaScript fast. These lead to security flaws.

out_of_protocol 4y ago

There was NaCl, PNaCl by google. Didn't fly though, i think because there was no fallback possible. Near-native performance (within 10% margin), any concurrency you can think of. Played Bastion game in browser on crappy old macbook Air many many years ago

mmastrac 4y ago
PNaCl was a terrible, terrible hack on top of LLVM's intermediate representation. The only good thing that came of it was paving the way for WebAssembly.