3 ms·

I think this is a valid concern. It is very similar to ActiveX with Internet Explorer, and, with the browser share Chrome is gathering, it isn't unreasonable to

I think this is a valid concern. It is very similar to ActiveX with Internet Explorer, and, with the browser share Chrome is gathering, it isn't unreasonable to see people focusing on that. --BUT-- With ActiveX, there was no other way to accomplish the same task. With Dart versus JavaScript, I can't accomplish anything in Dart that I can't in JavaScript. And, even if I decided to use Dart for some reason, it would be idiotic of me not to provide a JS version for non-Chrome browsers. What would be really nice (heck, even something a standards body should have done) is coming up with a standard byte-code for browsers, so I can use any language I want. JavaScript isn't good enough, because I want my sites to load faster, and parsing the code shouldn't have to happen every time somebody visits a page.

haberman 15y ago
> What would be really nice [...] is coming up with a standard byte-code for browsers I used to think that too, until I read convincing arguments against it like this: http://www.2ality.com/2012/01/bytecode-myth.html http://www.2ality.com/2012/01/bytecode-myth.html
- cromwellian 15y ago
  However, Javascript as the intermediate language does not follow. It may be true that a source-level intermediate representation has benefits, but the idea that the best intermediate representation is JS doesn't follow. For example, late-binding, boxing/heap-numbers, etc all serve to make it extremely difficult to maximize startup performance, or heap overhead. It also makes the VMs much more complex to deal with optimizing such languages. TypedArrays don't really fix the problem, they just introduce others. For example, by forcing your to implement your own manual memory management everywhere. This is somewhat problematic if you're compiling a language with GC into TypedArray heavy code, since there's no finalizers in JS or Reference queues, you can't really do automatic release if a regular heap object holds into pseudo-objects in manually allocated memory. The problem is particularly acute on mobile devices which are very resource constrained.

haberman 15y ago

> What would be really nice [...] is coming up with a standard byte-code for browsers I used to think that too, until I read convincing arguments against it like this: http://www.2ality.com/2012/01/bytecode-myth.html http://www.2ality.com/2012/01/bytecode-myth.html

cromwellian 15y ago
However, Javascript as the intermediate language does not follow. It may be true that a source-level intermediate representation has benefits, but the idea that the best intermediate representation is JS doesn't follow. For example, late-binding, boxing/heap-numbers, etc all serve to make it extremely difficult to maximize startup performance, or heap overhead. It also makes the VMs much more complex to deal with optimizing such languages. TypedArrays don't really fix the problem, they just introduce others. For example, by forcing your to implement your own manual memory management everywhere. This is somewhat problematic if you're compiling a language with GC into TypedArray heavy code, since there's no finalizers in JS or Reference queues, you can't really do automatic release if a regular heap object holds into pseudo-objects in manually allocated memory. The problem is particularly acute on mobile devices which are very resource constrained.