Comment by pifflesnort | Hacker News Reader

Comment by pifflesnort | Hacker News Reader

Parent Full thread

> The point is you seem to treat Google as more benign and non-commercial. That's not credible based on many pieces of evidence, including their public company performance scrutiny by Wall Street. I admire Google for some things they do, and believe they do not over-optimize their share price, but they cannot ignore it, either. Also, they are a house divided, with many conflicting agendas not directly related to business goals.

Absolutely not; I consider Google to be an organization whose commercial interests are ultimately far more aligned with my own than Apple's or Microsoft's. It has nothing to do with being benign or non-commercial -- my interests are in no small part commercial.

> No, for Emscripten/ASM.js, you still need a C or C++ runtime, not just libc/stdio/stdlib stuff but various graphics, audio, and other APIs.

Sure, but we (the systems/games development community) are well equipped to create common runtime libraries, especially on a platform that provides an anemic set of platform standards and components, in which case custom libraries won't suffer from QT or Swing's uncanny valley problem.

> Now you tell me why the shoe isn't on the other foot. Why did Google "ignore" what we've been doing to advance JS for the last two years, and move all its Aarhus talent onto Dart, at some cost to V8?

It seems to me that Google made a rational decision that JavaScript is not a technologically sound foundation upon which to build, and made the first moves to find alternatives.

> You really do have a pro-Google, anti-Mozilla animus -- good/bad or purple/shiny, I don't care.

It's actually an anti-JavaScript animus. The idea that JavaScript ought to be the foundation of the next generation of modern computing platforms runs counter to everything I know about language and runtime design.

It seems to be an entirely market-driven solution, not a technologically-driven one -- but those market circumstances are something you have far more influence over than I do.

> It's actually an anti-JavaScript animus.

You just wrote that I "ignored" Google's NaCl and Pepper work. That is not true, and yet you didn't hold Google to account anywhere on this thread (or others) for "ignoring" opportunities such as asm.js which were latent in Emscripten (in spite of their commercial support for Mandreel-compiled CWS games).

There's more to what you wrote than just anti-JS animus. But let's not get stuck on this dispute; let's be unstuck like JS :-P.

> It seems to be an entirely market-driven solution, not a technologically-driven one -- but those market circumstances are something you have far more influence over than I do.

Look deeper. The market is responding to cost structures ultimately based on how hard it is to do PNaCl + Pepper vs. Emscripten + asm.js + (Web APIs that devs need anyway).

This is not about "best tech" or "marketing" or "market power". (Firefox doesn't have Google's marketing budget, and we definitely do not have decisive market power, as Netscape and then IE did -- but neither does Chrome.)

This is about "shortest path" or "worse is better" -- who gets adoption first with something "good enough" wins, and can keep winning if the good-enough thing keeps evolving and doesn't get stuck.

JS is "good enough" and manifestly capable of evolving cross-browser via the Ecma TC39 standards process and some coopetition to be even better.

Anyway, at the asm.js level, apart from syntax aesthetics, why do you care how an int32 cast or type annotation is encoded? The semantics are sufficient, as proven by UE3 in Firefox. They only get richer as we do SIMD, task ||ism, etc.

/be

> This is about "shortest path" or "worse is better ...

I think we're in agreement there.

> JS is "good enough" and manifestly capable of evolving cross-browser via the Ecma TC39 standards process and some coopetition to be even better.

Perhaps in disagreement there, especially when you're competing against Apple's user-first focus, and especially when I'm on the receiving end of being forced to use a JS-based stack as a developer. I do mean the full stack, too -- instruction level profiling, debugging, failure reporting, consistent performance profiles, the whole nine yards.

> Anyway, at the asm.js level, apart from syntax, why do you care how an int32 cast or type annotation is encoded? The semantics are sufficient, as proven by UE3 in Firefox. They only get richer as we do SIMD, task ||ism, etc.

Well, as an implementor of systems software, I can't help but be wary that asm.js brings along with it the entire JS language and (in practice) web stack, too. It means that the likelihood that 'web' applications will ever be free of the enormous web stack is lowered, though alternative implementations (eg, NaCL) reduce some of that risk.

I guess we'll see how it goes.

Thanks for the thoughtful reply.

I share some concern about Apple, but less so in this "post Apple" era (Google, Samsung, up-and-comers from China).

On asm.js, the subset is verified at parse time and also as needed at link time, so there's no taint of "full JS" -- yet. We do expect the heaps to cross-connect, and want that. It won't make the parts of JS you dislike live much longer, from what I can tell.

To be perfectly candid, my goal is to evolve standardized JS, and therefore its implemented and widely distributed VMs, to be a good multi-language target language (and runtime).

This is eminently doable and closer than many people think. If it succeeds, then JS-the-handcoded-source-language can live or die on its (as evolved by then) language merits, and I won't cry if it dies.

But I wouldn't bet on its fan base dropping it even if they can choose other languages.

/be

Reply on news.ycombinator.com