The joke in those slides was how I went from my before-Netscape health (the picture of me doing a back handspring was from 1993; I joined Netscape in April 1995) to the after-those-ten-days-in-May-1995 state (looking like Ash from Evil Dead 3, with chainsaw for hand).
So I indeed created JS in a mad rush to get it into Netscape 2, along with other things Netscape tried as part of a platform play against Microsoft.
If I had not rushed, I would have missed not only Netscape 2, but also Netscape 3. Netscape 3 was supposed to be version 2.1, a minor release, until a company Netscape had acquired was given the browser and screwed up their release schedule so badly that it slipped into 1997 and became Netscape 4.
In 1998 or even 1997 it would have been too late to ship JS and have it make a de-facto standard. MS had already shipped VBScript as a me-too, and if they did not have JS to imitate, it would have been even more Microsoftian.
VBScript was the alternative to the JS rush job, in my settled view. I don't write this out of pride, joy, or defensiveness. I simply think it's the likeliest alternative outcome.
(Updated to correct Netscape 4 date per http://en.wikipedia.org/wiki/Netscape_Communicator to June 1997. It was so buggy that a series of firedrill releases were required to get it into barely usable shape by '98, which is what burned that year into my memory.)
Wanted - Fullstack VBScript developers
Delivered a fully functioning single page application Using Vanilla VBS.
Delivered high performance backends with ASP(using VBScript)
Advantage - you've used Angular.vbs and Backbone.vbs, and are familiar with react.vbs
While this story keeps getting posted again and again, I'd like to step in and provide some first hand experience here instead of just claims, hearsay, or obviously biased opinion.
I had the... experience of working next to Brendan Eich for a while. His Throne of Skulls is no joke and I have no idea how it got past either HR or the ergonomics coach. I kept cutting myself on the damn thing when I'd bump against it, had to keep a first aid kit at my desk. We didn't even know where the skulls came from either, but more kept appearing mysteriously each day.
The laugh was annoying too. I'd be sitting there trying to work on the monolith of doom (which was actually the name for multiple technologies, but no one could decide which was doomier so we just called them all that) and all of the sudden, it's evil laughter time. Nothing breaks concentrating on code like a roar of pure malevolent guffawing. I'm sure many engineers at startups can sympathize.
Much like the rest of this comment thread, I have no idea how this much of the web happened around this man.
You didn't link to any of my comments, so let me help your reading comprehension.
My point then was that if Google had had MS's IE4-6-era market share and lack of scruples, they could have pushed Dart into Chrome and started using it in their web properties, and the lack of equivalent performance between DartVM and dart2js -- especially due to lack of bignums and other affordances in JS, which lack Google materially increased by choosing to invest in Dart over JS -- would have stunk. It would have verged on the monopoly abuse of which MS was in fact convicted.
My point was not that JS must be the only way to run Dart simply because I or anyone at Mozilla (or anywhere else, MS and Apple included) prefers JS. That would be dumb, and it's clearly not what I wrote.
Browser vendors have to keep JS improving. That's a given. Adding the extra costs of DartVM and the inter-heap GC and write barriers to glue it into the shared DOM client side is a huge tax, which would have helped kill Mozilla faster. MS and Apple wouldn't pay that tax. Why should anyone? Again it's not about JS being uncompetitive. "Competitive" is what browsers are when they run web content better and faster. Dart has very little to do with this.
JS is very, very hard to replace, for reasons I summed up as "physics" (apologies to Rutherford) and won't belabor here. Yet the Dash memo proposed to do just that, to replace JS, using lame assertions about how JS couldn't be fixed.
That was not just lame posturing and excuse-making for a Lars Bak retention program. Given Google's power, it was a disservice to the Web as a standards-based and ever-evolving platform, whose caretakers are obligated to keep working on it in the open, not try proprietary end-runs. (Yes, of course, many people at Google work hard to improve the Web. Good for them, but not relevant to what happened with Dash.)
I'm happy to say I was wrong to worry about Google succeeding in acting like MS did with ActiveX/VBScript. Not that some at Google didn't try (or won't again with other stuff), but they failed with Dart. I predicted that, too, as an ultimate outcome after wasting years and megabucks -- including real opportunity costs to V8 and JS. So too did many at Google predict this crater.
Dart's a compile-to-JS language now, not due to any preference for JS by anyone at any browser vendor.
> My point was not that JS must be the only way to run Dart simply because I or anyone at Mozilla (or anywhere else, MS and Apple included) prefers JS. That would be dumb, and it's clearly not what I wrote.
I've never suggested that this is what you were saying there. Here I pointed to it as evidence that I was right that "one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation", where by "competitive" I was obviously referring to performance. Since we're agreed on that, the claim that everything I wrote above was wrong 'including "the" and "and"' goes out the window. (What I did point out to you at the time is that this was hard to square with the claims being made elsewhere for JS' wonderfulness as a compile target.) Your take on Google's intentions in proposing Dart is also completely in line with my argument that the vendors of major browser engines have huge power basically not constrained by anyone besides the other three vendors, as well as motives that don't always align with the public interest.
The "and" and "the" line was from Mary McCarthy in reply to Lillian Hellman. You're Hellman :-|.
"As to support for other languages, I only have to point out that one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation."
The empty rhetorical flourish ("I only have to point out...") aside, this is rank question-begging. You assume that JS as Dart target being too slow must mean DartVM should win because of "competitive" force. Wrong on at least two counts (I'll ignore market power abuse):
First, DartVM may be faster at semantics JS supports due to optimization problems on the JS engine side. V8 in particular lost its founding team to DartVM, except for some moonlighting. Therefore "competitive" does not mean that JS cannot improve to be as fast when compiled from Dart as when the Dart source runs in DartVM.
Second, DartVM may have types and optimizations that JS lacks, bignums for example. Again "competitive" does not mean JS cannot change, and in fact bignums have been on the ECMAScript Harmony agenda since 2010, before "Dash" leaked.
In any competitive market with deep tech, there are lots of ways to meet a set of developer-facing language support/performance requirements. Even with all Google's billions, Dart and Chrome decision-makers couldn't ignore the compile-to-JS alternative and continue to justify developing and shipping DartVM + OilPan + all else not fully in hand to support JS and Dart with no performance regressions. Compiling to JS is the sole path forward for Dart on the Web precisely due to competition.
Citing my argument about bignums is perversely wrong, unless you assume DartVM is the only solution to any DartVM vs. dart2js performance disparity.
Such an assumption, like the one you seem to have made about NaCl, is anti-competitive, uneconomic, magical thinking. It requires indefinite amounts of time and money to fund all the work to have two VMs, a super-GC to collect cycles, write barriers as part of that super-GC, and more optimization to overcome the performance regressions imposed by those barriers (if possible). It assumes JS can't more cheaply be extended to be a fast-enough target language. You offer no proof.
BTW, you started out with NaCl and I still think you're mistaken about something pretty fundamental. NaCl was never proposed as a Web standard. Ok, suppose you mean PNaCl. The problem remains that PNaCl required a big API, Pepper, to reach the guts of chromium/Blink (originally WebKit) and the underlying OS. The problem with PNaCl was always Pepper, and again: competition killed Pepper as a cross-browser API.
It takes longer (it would have happened sooner with more cooperation from Google earlier, instead of the malinvestment on these two big follies), but JS is getting SIMD and shared memory threads, which are among the last few bricks still standing in the Pepper wall.
So PNaCl is evolving with Emscripten/asm.js now -- precisely due to competition -- and I would not hold my breath for PNaCl to remain based only on LLVM bitcode (with fixes requiring years and millions, to remove unspecified behavior). But feel free to hold your breath and then blame the "vendor cartel" if you like.
On that "vendor cartel" point, there are more web engines coming along, Servo (an open source project with multiple paying companies involved) among them. There's no cartel, just a big compatibility hill for any new engine to climb.
Adding gewgaws like NaCl and Dash slows down that climb. It's uncompetitive for the would-be market entrant. Why you think this requires collusion ("cartel") or Satanic pride ("reign in Hell") is unclear. Do you get many billion-dollar free lunches where you live?