6 ms·

Let's make no mistake about it: Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. It's more ac

by Refefer 13y ago

Let's make no mistake about it: Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. It's more accurate to say that Javascript has succeeded despite its limitations. There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. That said, a well entrenched language supported (and, crucially, maintained) by multiple vendors with loads of developer intellectual investment should win this competition.

natural219 13y ago
I think that's the thesis of the "worse is better" approach. http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
azakai 13y ago
> There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. Not necessarily. That has been discussed at length many times here and elsewhere. PNaCl's approach is interesting and technically has much merit, but also has significant downsides (startup speed, complexity, size of implementation, reliance on LLVM for something it was not intended, risks of undefined behavior, PPAPI, etc.). It's technically an impressive technology but also one with fundamental compromises. Instead, an undeniably superior approach could be to start entirely from scratch, not JS nor LLVM nor anything else, and work to design something truly optimal for the use case we are talking about here (code shipped over the network, to run securely inside a browser, at near-native performance, with fast warm and cold startup). That would look very different from both JS and PNaCl, and could avoid the compromises that both have.
- Refefer 13y ago
  Most of the negatives are heavily focused on implementation rather than design, which I don't disagree with. However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. That said, as browsers act more like operating systems, it makes me wonder if we've somewhat missed the point. I agree with you about starting from scratch. I think if history is any indication, ultimately we'll end up having to write a new 'web' with very different semantics and design philosophies; goodness knows the old metaphor is starting to creak in a number of problematic ways.
  - azakai 13y ago
    > However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages. Worth reading this about the limitations of LLVM IR as a bytecode: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... I've also written a post about the limitations of any single bytecode to achieve all the goals the web needs: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
  - BrendanEich 13y ago
    Java has a bytecode for its client embedding; so does Flash ActionScript. This led to trouble. From http://brendaneich.github.io/Strange-Loop-2012/#/27 http://brendaneich.github.io/Strange-Loop-2012/#/27, some pros for JS and cons for bytecode: * Dynamic typing ⇒ no verification * Type inference ⇒ delayed optimization * Would bytecode compress as well? * Bytecode standardization would suck * Bytecode versioning would suck more * Low-level bytecode is future-hostile Remember Java bytecode backward compatibility hampering language evolution, in the generics (erasure) debate and result. Then they broke bytecode compat anyway. Flash has two language implementations in it, one for AS2 and the other (Tamarin) for AS3. Only way to be sure about AS2 compat! In many ways, with JS you have one problem; add bytecode and now you have two.
    - drdaeman 13y ago
      But asm.js is a bytecode, isn't it? Just with a clever-but-weird encoding that allows a backward compatibility. In a same manner, one can deliver, for example, an x86 bytecode in JS-encoded form. Just encode opcodes as, say, "eax = 1" instead of "\xB8\x01\0\0\0".
      - BrendanEich 13y ago
        No, asm.js is a JS subset. "bytecode" as boosted here would be a non-subset, like JVML to Java source. Sure, bits is bits. Doesn't matter if you're after gzipped good results. But bytecode hopes spring eternal and the hopers do not want gzipped, minified, Emscripten-produced asm.js. They want a different syntax.
- georgewfraser 13y ago
  What about JVM, if oracle can solve the security issues. Back to the future?
  - BrendanEich 13y ago
    Forget it. JS VMs in browsers are required, JVMs are dead weight. Reversing the trend against the Java plugin, which accelerated due to malware (Brian Krebs said Java was the #1 paid-for malware vector some years ago) but which began with declining plugin share re: Flash, is very unlikely. #1 reason: mobile -- plugins don't fly there, not just because Jobs was mean to Flash.
Ygg2 13y ago
That's kinda my point as well. If we are to wipe clean. Nothing in browser for scripting exists. Some kid from Zambia develops JavScript 2.0 in two weeks. Entire Google team works out a specification for LLWM (Low Level Web Machine) and it's pretty close to LLVM. They take how long to implement it?! People need to get their browser scripted so they look around shopping for a new language. Oh, cool the awesome LLWM spec is out there. Wow. It's got all the thing they want. Let's wait.... A month passes. People look again but no LLWM. On the other hand there is this JavScript 2.0 that kind of works. It's ugly, but Mark took a look at it and he uses to make dancing kittens. In 3D (i.e. the picture just rotates around axis, using CSS). Another month passes. Is LLWM done yet? Hmm, the clients are itchy, they want their browser scripted. Maybe dabbling in that JavScript 2.0 doesn't sound so bad. Third month passes. LLWM is still being worked on. Your clients have employed Mark and dumped you. Yeah, life is cruel and JavScript 2.0 is more cruel - Integers overflow when adding two numbers with more than six digits each, it confuses 0 and o, no local variables, just global vars. ... Fourth month passes. LLWM is still being worked on. JavScript 2.0 sucks but everyone tolerates it. Also there is JavScript 2.1 comming out that allows variables to not be in UPPERCASE. And there is a nice library for dancing kittens called dance.jv2 ... Year passes. LLWM ships. JavScript 2.123 is out and it's about the same in terms of speed and features. Sure there are few warts here and there, like lack of static typing, but overall it's quite solid. Compare this situation with many other examples of Worse is Better.
- cromwellian 13y ago
  How long between Javascript's "it only took 2 weeks" until now though? Is this is an example of "worse is better" innovating at faster speed, when in fact, Javascript performance has moved at a glacial pace until recently and it took enormous investment to get there. I think it is fair to say that if someone started with today's web/mobile requirements and designed a language from scratch to meet performance, latency, and memory requirements as well as portability/cross platform execution, it probably would not take as long as Javascript did to reach the current levels of performance. That is, you're comparing 15+ years of Javascript JIT engineering activity with what, 2-3 years of PNaCL activity by a much smaller team?
  - 13y ago
BrendanEich 13y ago
> Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. No, that's an exaggeration in time and dollars. JS was one full-time person, me, till fall 1996, then two. Growth after that was to about eight max, and less than the Java crew at Netscape, until Netscape folded on Java and laid off a bunch of people in late 1997. Call the Netscape investment 8 years x 8 people = 64. On the IE side, the JScript engine reused a common assembly-coded COM-dispatching indirect-threaded (I think) interpreter, and seemed from what I could tell to take about 6 people, but I'll round up to 8. No LiveConnect and COM based infrastructure saved them compared to Netscape. Ignoring JScript.net in Y2K era, the investment until the IE6 stagnation (skeleton crew) looks like at most 6 x 8 = 48. Apple did not start with KJS till 2001, I believe. They've always had at most 3 people on JavaScriptCore, they run a tight ship: 14 x 3 = 42. Chrome started V8 in 2006, as far as I can tell. Lars and a team of U. Aarhus and Google on his farm wrote four versions I hear (good idea: prototype, learn, tear up and rewrite). Call that 2 x 10 = 20 for first two years, then since I think it is more like 5 x 20 = 100. 64 + 48 + 42 + 120 = 274 person-years. Even at $1M/person/year, well high even with Google wealth effect of RSUs (for most; I'm guessing, but an outlier like Lars or Kaspar getting rich does not count; really we should stick to base salary + benefits/burden overhead), that's well shy of "multi-billion". You can say JS learned from all the JIT research before it. You'd be right, but your statement was exclusive to JS and so excluded that upstream, and fair's fair: that helped other languages who could read the literature and code. EDIT: Eric Lawrence on twitter reminds me that Chakra has a big team, I hear ~60 heads. That seems to be since 2009. Still well south of "multi-billion", even with my absurdly high $1M/year burdened engineer price. /be
- magicalist 13y ago
  It's pretty interesting to see it laid out there in person years. It really is a small number (especially compared to the much larger number of bodies working on other parts of those browsers). I'll still take umbrage with the "MIT approach over Hacker approach" comment by the OP. "Worse is better" is fairly independent of that, and I think it does do disservice not only to the academic shoulders that the modern JS engines stand on, but also the academic brains packed into most of the JS engine teams (even just starting with the backgrounds of the editors of the asm.js spec). It's also amusing, of course, that the submitter of this article is bzbarsky, who has done amazing work for the web and whose mailing list correspondence, at least, all comes from an address ending with "@mit.edu" :)

by Refefer 13y ago

natural219 13y ago

I think that's the thesis of the "worse is better" approach. http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html

azakai 13y ago

> There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. Not necessarily. That has been discussed at length many times here and elsewhere. PNaCl's approach is interesting and technically has much merit, but also has significant downsides (startup speed, complexity, size of implementation, reliance on LLVM for something it was not intended, risks of undefined behavior, PPAPI, etc.). It's technically an impressive technology but also one with fundamental compromises. Instead, an undeniably superior approach could be to start entirely from scratch, not JS nor LLVM nor anything else, and work to design something truly optimal for the use case we are talking about here (code shipped over the network, to run securely inside a browser, at near-native performance, with fast warm and cold startup). That would look very different from both JS and PNaCl, and could avoid the compromises that both have.

Refefer 13y ago
Most of the negatives are heavily focused on implementation rather than design, which I don't disagree with. However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. That said, as browsers act more like operating systems, it makes me wonder if we've somewhat missed the point. I agree with you about starting from scratch. I think if history is any indication, ultimately we'll end up having to write a new 'web' with very different semantics and design philosophies; goodness knows the old metaphor is starting to creak in a number of problematic ways.
- azakai 13y ago
  > However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages. Worth reading this about the limitations of LLVM IR as a bytecode: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... I've also written a post about the limitations of any single bytecode to achieve all the goals the web needs: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
- BrendanEich 13y ago
  Java has a bytecode for its client embedding; so does Flash ActionScript. This led to trouble. From http://brendaneich.github.io/Strange-Loop-2012/#/27 http://brendaneich.github.io/Strange-Loop-2012/#/27, some pros for JS and cons for bytecode: * Dynamic typing ⇒ no verification * Type inference ⇒ delayed optimization * Would bytecode compress as well? * Bytecode standardization would suck * Bytecode versioning would suck more * Low-level bytecode is future-hostile Remember Java bytecode backward compatibility hampering language evolution, in the generics (erasure) debate and result. Then they broke bytecode compat anyway. Flash has two language implementations in it, one for AS2 and the other (Tamarin) for AS3. Only way to be sure about AS2 compat! In many ways, with JS you have one problem; add bytecode and now you have two.
  - drdaeman 13y ago
    But asm.js is a bytecode, isn't it? Just with a clever-but-weird encoding that allows a backward compatibility. In a same manner, one can deliver, for example, an x86 bytecode in JS-encoded form. Just encode opcodes as, say, "eax = 1" instead of "\xB8\x01\0\0\0".
    - BrendanEich 13y ago
      No, asm.js is a JS subset. "bytecode" as boosted here would be a non-subset, like JVML to Java source. Sure, bits is bits. Doesn't matter if you're after gzipped good results. But bytecode hopes spring eternal and the hopers do not want gzipped, minified, Emscripten-produced asm.js. They want a different syntax.
georgewfraser 13y ago
What about JVM, if oracle can solve the security issues. Back to the future?
- BrendanEich 13y ago
  Forget it. JS VMs in browsers are required, JVMs are dead weight. Reversing the trend against the Java plugin, which accelerated due to malware (Brian Krebs said Java was the #1 paid-for malware vector some years ago) but which began with declining plugin share re: Flash, is very unlikely. #1 reason: mobile -- plugins don't fly there, not just because Jobs was mean to Flash.

Ygg2 13y ago

That's kinda my point as well. If we are to wipe clean. Nothing in browser for scripting exists. Some kid from Zambia develops JavScript 2.0 in two weeks. Entire Google team works out a specification for LLWM (Low Level Web Machine) and it's pretty close to LLVM. They take how long to implement it?! People need to get their browser scripted so they look around shopping for a new language. Oh, cool the awesome LLWM spec is out there. Wow. It's got all the thing they want. Let's wait.... A month passes. People look again but no LLWM. On the other hand there is this JavScript 2.0 that kind of works. It's ugly, but Mark took a look at it and he uses to make dancing kittens. In 3D (i.e. the picture just rotates around axis, using CSS). Another month passes. Is LLWM done yet? Hmm, the clients are itchy, they want their browser scripted. Maybe dabbling in that JavScript 2.0 doesn't sound so bad. Third month passes. LLWM is still being worked on. Your clients have employed Mark and dumped you. Yeah, life is cruel and JavScript 2.0 is more cruel - Integers overflow when adding two numbers with more than six digits each, it confuses 0 and o, no local variables, just global vars. ... Fourth month passes. LLWM is still being worked on. JavScript 2.0 sucks but everyone tolerates it. Also there is JavScript 2.1 comming out that allows variables to not be in UPPERCASE. And there is a nice library for dancing kittens called dance.jv2 ... Year passes. LLWM ships. JavScript 2.123 is out and it's about the same in terms of speed and features. Sure there are few warts here and there, like lack of static typing, but overall it's quite solid. Compare this situation with many other examples of Worse is Better.

cromwellian 13y ago
How long between Javascript's "it only took 2 weeks" until now though? Is this is an example of "worse is better" innovating at faster speed, when in fact, Javascript performance has moved at a glacial pace until recently and it took enormous investment to get there. I think it is fair to say that if someone started with today's web/mobile requirements and designed a language from scratch to meet performance, latency, and memory requirements as well as portability/cross platform execution, it probably would not take as long as Javascript did to reach the current levels of performance. That is, you're comparing 15+ years of Javascript JIT engineering activity with what, 2-3 years of PNaCL activity by a much smaller team?
- 13y ago

BrendanEich 13y ago

> Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. No, that's an exaggeration in time and dollars. JS was one full-time person, me, till fall 1996, then two. Growth after that was to about eight max, and less than the Java crew at Netscape, until Netscape folded on Java and laid off a bunch of people in late 1997. Call the Netscape investment 8 years x 8 people = 64. On the IE side, the JScript engine reused a common assembly-coded COM-dispatching indirect-threaded (I think) interpreter, and seemed from what I could tell to take about 6 people, but I'll round up to 8. No LiveConnect and COM based infrastructure saved them compared to Netscape. Ignoring JScript.net in Y2K era, the investment until the IE6 stagnation (skeleton crew) looks like at most 6 x 8 = 48. Apple did not start with KJS till 2001, I believe. They've always had at most 3 people on JavaScriptCore, they run a tight ship: 14 x 3 = 42. Chrome started V8 in 2006, as far as I can tell. Lars and a team of U. Aarhus and Google on his farm wrote four versions I hear (good idea: prototype, learn, tear up and rewrite). Call that 2 x 10 = 20 for first two years, then since I think it is more like 5 x 20 = 100. 64 + 48 + 42 + 120 = 274 person-years. Even at $1M/person/year, well high even with Google wealth effect of RSUs (for most; I'm guessing, but an outlier like Lars or Kaspar getting rich does not count; really we should stick to base salary + benefits/burden overhead), that's well shy of "multi-billion". You can say JS learned from all the JIT research before it. You'd be right, but your statement was exclusive to JS and so excluded that upstream, and fair's fair: that helped other languages who could read the literature and code. EDIT: Eric Lawrence on twitter reminds me that Chakra has a big team, I hear ~60 heads. That seems to be since 2009. Still well south of "multi-billion", even with my absurdly high $1M/year burdened engineer price. /be

magicalist 13y ago
It's pretty interesting to see it laid out there in person years. It really is a small number (especially compared to the much larger number of bodies working on other parts of those browsers). I'll still take umbrage with the "MIT approach over Hacker approach" comment by the OP. "Worse is better" is fairly independent of that, and I think it does do disservice not only to the academic shoulders that the modern JS engines stand on, but also the academic brains packed into most of the JS engine teams (even just starting with the backgrounds of the editors of the asm.js spec). It's also amusing, of course, that the submitter of this article is bzbarsky, who has done amazing work for the web and whose mailing list correspondence, at least, all comes from an address ending with "@mit.edu" :)