[Refefer]

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.

[BrendanEich]

> 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

[lstamour]

This kind of post and response, meaningless in the grand scheme of things, is why I come to HN. You never know who will be next to say X sucks and then have someone personally involved in creating X speak up unexpectedly. Makes you want to apologize for saying X sucks in the first place, except you're not because without it you wouldn't get the resulting conversation. ;-) It does make me wonder, what things have I said about somebody's creation and then have them come along and see it. Sometimes it's just hard to remember there are real humans on the other side of this screen. ... And with that, I know I'm up too late. Good night all, and thanks for the post, Brenden. I did want to point out though... You forgot IE 10 and especially 11, plus the fun Opera Mini must have had remotely executing JS for a brief time. But these wouldn't significantly revise the numbers up too much. I'd add Adobe to the mix, but ActionScript and AIR are maybe too far from a browser to count for much evolution in JS terms.

[BrendanEich]

Right, see EDIT for Chakra, and yes, I forgot Opera. Lars Thomas Hansen, then Chris Pine, on LinearB and Futhark; then Jens Lindstrom and (I heard) a small team in Sweden on Carakan.

Also (ahem), I forgot Mozilla in the post-2003 era.

Still, no matter the addenda and the crazy $1M/person-year, nowhere near even $1B.

[stcredzero]

You never know who will be next to say X sucks and then have someone personally involved in creating X speak up unexpectedly.

So then HN is now the /. of the mid 201X? /. Was at its best when people in the know were finally pissed off enough to chime in and set the hooligans straight.

[Benvie]

It does make me wonder, what things have I said about somebody's creation and then have them come along and see it

I passingly wrote some disparaging remarks in a github issue about the ES6 binary data strawman spec written by Dave Herman, pretty much out of my own ignorance, only to get a message from him a few months later asking for feedback on it and what I thought was wrong.

By this point I had learned more about the topic and reading the spec language and knew enough to know I had just been an idiot. I ashamedly responded with an apology and basically told him that my criticism could be ignored because it came from my lack of understanding and not a real problem with the spec.

[magicalist]

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" :)

[bzbarsky]

In fairness, that's just the address I use for most of my email in general. My only affiliation with MIT at this point is being an alum.

That said, I do have a tendency to err on the "not worse" side, I think. And yes, we did read "Worse Is Better" in http://ocw.mit.edu/courses/electrical-engineering-and-comput... (or rather its decade-older incarnation). ;)

[Ygg2]

It's not my name: http://www.jwz.org/doc/worse-is-better.html

And I don't feel one bit sorry about it. I guess I could call it Stanford(/MIT) way, but MIT is nicer, juicer target.

Also asm.js is the Worse is Better compared to PNaCl. It's simpler, it's a 'hack' of JS compiler, it's not as fast as native performance of PNaCl. But it epitome of the said approach.

C is also Worse is Better approach compared to Lisp and it had some of amazing people, work on it.

[azakai]

> 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]

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]

> 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/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-we...

[BrendanEich]

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, 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]

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]

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.

[lucian1900]

In all the ways that matter, asm.js is a bytecode with a funny encoding and peculiar semantics related to that. Denying it doesn't really help.

We're all wishing for a sane bytecode for a change. It's not just syntax.

[pacala]

JVML is not a bytecode. The bytecode syntax is just a disguise . JVML is a high level language that prescribes a certain object / method / inheritance model. Methods are associated with objects according to specific vtable / vinterface rules.

OTOH, asm.js is defined in terms of value types + function pointers. Just call the function pointer with the right arguments. Bring whichever objects / closures you like.

PS. Gripe of the day: 64bit computing is here (even ARM supports it) and asm.js doesn't seem to be prepared.

[drdaeman]

> No, asm.js is a JS subset. "bytecode" as boosted here would be a non-subset, like JVML to Java source.

Sorry for quoting Wikipedia, but bytecode is just a form of instruction set designed for efficient execution by a software interpreter.

Maybe I'm mistaken on this, but from reading about asm.js I got an impression that asm.js-aware browsers use different approach to asm.js code and treat it more like a weirdly-encoded bytecode, not as an ordirary JS source. Or I'm misunderstanding things?

If so, asm.js is a bytecode. Whenever there's a correspondence between it and other languages doesn't matter for determining if it's bytecode or not, it's another (useful, but not related to being bytecode) property.

> They want a different syntax.

I don't think syntax matters that much, it's mostly semantics. Probably.

[georgewfraser]

What about JVM, if oracle can solve the security issues. Back to the future?

[BrendanEich]

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]

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]

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?

[bzbarsky]

Are you sure it's a much smaller team? Do you have any data on how many people are working on PNaCl or have been?

Opera had fewer than 5 people working on their JIT, I believe. I don't think Apple has had a particularly huge JIT team either...

[Ygg2]

>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

True, but so is that developing a simpler, cruder and slower but Fast Enough alternative to said language, would take less time and by the time the said alternative would developer, they would be on same feature parity.

> 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?

No, I'm comparing asm.js engineering (if you can call it that), to (P)NaCl.

JS performance improvements was a weird road to take, but JS of old days wasn't the JS of new days. It's use case was significantly different and Google wanted to enable new use cases for it to run it's Gmail program. So they did.

[BrendanEich]

Enormous investment? See my estimate (generous) above.

Contrast with the Dart (nee Dash) investment, where a team of at least 60 now labors on a language+VM that cannot cross the chasm to other browsers in any foreseeable future where there are multiple browsers with disjoint source that have significant market share.

Evolution doesn't care about aesthetics (my pelican slide from JSConf.{us,eu}). It doesn't care about wealth-effect follies that can't be standardized among developers without a compile-to-JS plan that undermines the native-VM plan. It does not care about roads-not-taken in the past, so long as the road from here is clear.

Bet on evolution.

/be

[cromwellian]

Bet on punctuated equilibrium. Both PNaCL and asm.js are could follies if you consider mobile games. There is no incentive for someone developing games for consoles or phones to use either of those technologies.

[BrendanEich]

Game devs code to metal, use C++ and OpenGL. This is why Jobs went from web apps to allowing native in iPhone 1 era.

Both PNaCl and Emscripten (or Mandreel -- the relevant comparison, not asm.js which is a different category) work on such source. This is how Firefox OS runs games (Disney Where's My Water, many others). Cross-compilation works.

(Punctuated equilibrium is a bio-crock.)

[cromwellian]

Coding to metal isn't just about source language, it's about optimizing system level performance. Top tier game devs use vTune, GPU profilers, system level analyzers, to maximize overall system performance for a given workload. Developers at studios like Naughty Dog, Bungie, DICE, Infinity Ward, et al don't just delegate to the C compiler and call it a day.

Leaving aside casual games, which are mostly not performance sensitive, top tier game development is very high risk and expensive. One reason why developers like consoles and the iPhone/iPad is absolute predictability when it comes to target platform. Even branching over into the Desktop PC, game tuning requires a ton of testing on a huge matrix of platforms, chipsets, drivers, and other configurations, all of which is a big expense, as well as a big support cost.

What is the motivation for say, Infinity Ward to port Call of Duty to asm.js or PNaCL? Most of the people who would actually buy it will do so on a console, or through something like Steam. You'd be asking them to add an immature and unproven technology into the mix that sacrifices multithreading, or drops a big chunk of performance on the floor, and in return, add back millions of frustrated web users who will be making customer support claims.

I love the web, I have the tons of "native" apps on mobile that don't really deserve to be native apps at all and would work equally well as a URL to a web site that doesn't force an install. But --

Games are not webby. They are not the web, and treating the browser like a C virtual machine that throws away pretty much most of the browser's machinery in favor of just OpenGL bindings is not what the browser was designed to do, and the fact that it does it at all is amazing, but it is not helping the web.

I think both Chrome and Firefox would do the world a much bigger favor concentrating on making the other parts of the browser rendering engine a lot faster. JS performance is not the primary reason that Web apps feel janky compared to native ones, the entire development model for web development is a minefield full of performance hazards.

For years, the JVM had huge performance advantages on JS. It had native code interfaces, it had off-heap non-GCed memory allocation capability, it had high performance, and yet, Minecraft is pretty much the only success story. Now why is that? And why NaCL, which has a rich father (Google) behind it, and the world's largest browser marketshare of hundreds of millions, can't convince many developers to port to it. You think Emscripten ports are easier than NaCL? The best explanation is that the return on investment in making a game that is shoe horned into the browser is not worth it.

If given the option to buy a game on Steam, or buy it via Chrome Web Store or Firefox store, I would buy the Steam version. I bet the majority of people reading this would do the same.

I see that casual, simple mobile games might be suitable for this, but that's a problem for FirefoxOS and ChromeOS to solve. Most game devs will continue to target iOS and Android until FireOS gets a non-trivial marketshare. Crossing that chasm is going to be hard.

To make a TL;DR short, I am frustrated that native is taking over in the non-games space, and the efforts by both Google and Mozilla to get at the real heart of the matter, of making jank-free, buttery smooth, mobile apps easy to develop for web developers is moving far slower than it needs to be.

All this games stuff is a huge distraction.

[natural219]

I think that's the thesis of the "worse is better" approach.

http://www.jwz.org/doc/worse-is-better.html