Friday, June 14, 2013

A Tale of two Web Technologies

Let's play a quick game: I'm going to describe a relatively recently announced web technology, and I want you to guess what it is.
  • It was developed by a generally well respected company that focuses on moving the web forward.
  • It was started to enable the web to move beyond the inherent limitations of javascript.
  • It allows developers to run applications programmed in a language other than javascript.
  • The company behind it encouraged others to join in its development, and has actively been improving it themselves.
  • It was designed so that when run in a specialized VM it could run much faster than an equivalent Javascript app.
  • To preserve backwards compatibility, however, the code is cross-compiled into standard javascript, allowing it to run on most modern browsers.
So if I stop there, what's your guess? If you've been keeping up with these things I bet you're probably thinking asm.js, which is a good guess because it meets all the criteria up above. Let me add one more hint, though:
  • When announced this technology was regarded with skepticism and vocal opposition.
Ah, that makes a difference. What's your guess now?

"What is Dart, Alex?"

Bingo! We have a winner!

[Update: I originally had an item in the list implying that asm.js had been developed behind closed doors. I've been corrected on this point, as the asm.js project was open source on Github since its inception. It would be more correct to say that it was not publicized until they had enough complete to accurately benchmark. Thanks to the folks on Twitter that pointed this out to me, as it paints a more complete picture of the reasons behind public attitudes!]

Look, I know that this is not an Apples to Apples comparison. But if we're being honest both of these technologies are motivated by similar goals: Javascript is too slow and awkward for the demands of really high performance applications. (Like, say, Unreal Engine 3?) I know that that statement alone will annoy the Javascript faithful, who come out swinging Atwood's law around like a club. I actually like Javascript, and would be willing to argue the same in most cases. But there's a certain class of applications that it simply was never designed to handle. Technologies like NaCl, Dart, and (most recently) asm.js are all attempts to fix that.

So, getting to the point of this post: I'm a confused as to why something like Dart, which I have found to be a great language to code in, inspires either annoyance or apathy from many web developers while the same crowd seems largely enthusiastic about asm.js. 

For my part I think they're both awesome technologies with different use cases. If I were building a new web app from scratch I'd want to code it in Javascript or Dart but would prefer Dart due to its cleaner syntax, built-in libraries, and potential speed. (Not to mention it supports things like SIMD which is awesome for realtime 3D!) If I had an existing iPhone or Android game that I wanted to bring to the web asm.js (or NaCl, which the caveat of browser support) provides a great tool for expanding my audience with the minimal amount of effort. Likewise for non-trivial, pre-existing C/C++ libraries. Different tools for different purposes, both useful in their own right and both trying to let us do more than Javascript allows for today.

So I'd like to drum up some discussion on this one: What's your opinion on these (or any other similar) technologies? Why do you like them or dislike them? From some of the feedback I've already heard it seems like there's may be some confusion about what these various technologies actually do, and if so I'd like to do my part to clear that up. I'm also trying to get a bit of the community pulse to help inform the direction of some future posts.

(Oh, and I promise that my next post will be far more interesting to WebGL developers! Got something really cool on the way!)


  1. One of these things is not like the other, one of these things just doesn't belong. Where to begin?

    * asm.js does not "run in a specialized VM".

    * Performance gaps in JS engines get filled all the time. This is different in kind from potentially adding a second VM, requiring cross-VM-heap cycle GC, etc. See

    * Per the Dash memo, Dart was developed in secret with a "replace JS" goal. The leaked memo left a bad (Microsoftian -- hi, Brad!) taste.

    * asm.js is not a "web technology" any more than JS generated by Emscripten is a "web technology". But using that phrase does help you equate it to something that is single-vendor and so far (lacking a spec with second independent implementation with significant market share, or a governing standards body with multi-browser support) essentially proprietary to Google.

    * Market power matters. Mozilla could no more create a new "2nd VM" language and engine than we could fork WebKit or bundle Chrome with Flash and other distributions and foistware vehicles.

    On the other hand, putting Dart, PNaCl/Pepper, and other innovations in Chrome could abuse market power to push standards that lack specs and that have been insufficiently vetted by other browser vendors. This is the topic or subtext of a lively (sic) chromium-dev thread:!topic/chromium-dev/wDV9JHs0mBA.

    BTW, market-power-forged de-facto standardization happened big-time with JS 1.0 in 1995. I'm not saying otherwise, or trying to defend Netscape (or IE for its market-power-created de-facto standards). On that one, I've paid my dues starting in fall 1996 with ECMA standardization (note that JS was less than a year in the market at that point) and I have been avoiding more of the same, rather trying to increase "coopetition" via, ever since.

    * Wanting to create a coherent language before taking it to a standards body is fine, but JS didn't have that luxury. Dart does have the luxury thanks to Google's size and success, but a consequence of this is that DartVM is not going to be adopted in other browsers in the meanwhile.

    In contrast, asm.js code generated by Emscripten runs ok in Chrome Canary and will only get faster, in the same single VM all browsers must implement and optimize.

    * "Coopetition" (ugly but useful portmanteau word) depends on innovating in the open from the start, discussing ideas in standards bodies, trying (and re-trying) to get consensus. If an innovation is crucial for business reasons, it can be done even without hope of a standard, but we (Blink and Mozilla people) seem to be converging on keeping it behind a flag or otherwise out of the "Web Platform".

    This is important to avoid fragmentation and market-power wars. As I've joked, can you imagine MS's answer to Dart in the worst case? "Javelin!" (Apple would do "Flechette", sleeker and smaller. ;-)



    1. When I first heard about Dart, my hope was that Google was building a VM with a byte code that would run standards-compliant Javascript as well as other languages. I think the community would have had a very different reaction had they taken this approach.

      IonMonkey seems like a promising direction. Are there any plans to try targeting other languages to it? What are your thoughts on a byte code standard that would allow a language-independent web?

    2. See

      We have no plans to make IonMonkey multi-language. Dart folks had a good talk on the follies of trying to serve multiple language-masters from one VM a year or two back. Although having a shared GC heap is a win (see also the JVM and .NET), serving languages with drastically different paradigms (e.g., call/cc vs. not) is hard.

      People get hung up on asm.js's "ugly JS" syntax, but if we ever really need (for end to end efficiency) a bytecode syntax for some evolution of asm.js-as-future-JS-subset, we can do one. The downsides other than efficiency, mainly (a) never serving any but the "lead language" compiled to the bytecode very well, and (b) having two syntaxes, one lowered and future-hostile, will remain.

      But perhaps in terms of network traffic (not authored source), JS will fade away and only the bytecode transport syntax will survive (and serve which lead language best? Dunno -- probably JS, but not necessarily!). That's pretty far off, but a possible end-point in evolutionary phase-space.

      Which still leaves the "serving the lead language best" problem, although evolution (with the same backward compatibility issues we face today re: JS) would continue in the bytecode-syntax germ-line. And we'd go around the karmic wheel again, perhaps wiser but possibly not much better off.


  2. On SIMD extensions to Dart: obviously these could be added to JS too, they are on the ES7 agenda (RiverTrail, value objects). So when I saw John McCutchan tweet about them, I made contact, and we are working to get equivalent intrinsics into ES7 too.

    Adding something to Dart helps only Dartium. Dart2JS can't cope without equivalent uplift to JS. So touting Dart because SIMD intrinsics were added to it misplaces the hype: the class syntax with operators is not unique to Dart (ES6 has class, ES7 will have operators in my view).

    Uplift for JS helps all browsers and therefore Dart2JS, and it's a shorter path than saying "first add DartVM to all browsers... then add SIMD." The "first add DartVM" part is really hard and extremely unlikely.


    1. You're correct about Dart2JS, but you seem to imply that the feature is meaningless without either JS support or widespread Dart implementation in browsers. Allow me to point out, as you did, that Dart is not strictly a "web technology". The Dart VM runs perfectly well standalone.

      Additionally, it's nice that the addition of the feature to Dart was able to push forward it's inclusion in ES7.

    2. Sorry to stray the discussion a bit, but the SIMD thing is actually an interesting one to me personally. In the Web Audio WG we've been working on the DSP API[1] which is designed to be a high speed vector processing API, not restricted to taking advantage only of SIMD but also of parallelization, not to mention that unlike direct SIMD intrinsics, one doesn't need to add more types when we hopefully get larger SIMD registers in the future.

      I've quite actively been trying to get the relevant parties on board the standardization process ( and at ofmlabs we even made two prototype implementations, one for node.js, one for SpiderMonkey [unfinished] ) and was surprised when I talked to John McCutchan about his SIMD intrinsics proposal and suggested he brought his proposal to public discussion that he was already in touch with Brendan (you) and David (Herman, I assume). I have to say that I'm quite disappointed that the discussion hasn't been made in the public where it would've been obvious that we have two proposals that collide in features that they're trying to provide. If the discussion has been made in the public, I apologize, but I haven't been able to find any record.

      I hope that in the future there will be more transparency to bringing the high-speed JS forward. I understand that communication with parties such as Epic are quite impossible to be made transparent, but where possible, let's make it happen.


    3. Hi Jussi,

      First, I made contact with John McCutchan in public on twitter. Dave and I then followed up by email. We are still waiting for the scheduled meet-up with John to talk face to face about harmonizing Dart SIMD types with ES7 stuff. We'll make everything public on es-discuss as usual, and nothing gets decided without lots of review there.

      Second, that Opera "unofficial draft", while about as public as a tweet (arguably less so :-P), is not necessarily a direct competitor to what John did in Dart. River Trail also is higher-level, suitable for work-stealing and vectorization across different widths and architectures.

      Bottom line: it's early yet. Ecma TC39 members are exploring several overlapping but not equivalent approaches and we will not pick a winner early. John's point that game devs are used to selecting SIMD instructions manually is on-target for games, though. Gamers we are porting don't want high-level (abstracted over vector length, e.g.), they want low-level APIs.


    4. > We'll make everything public on es-discuss as usual, and nothing gets decided without lots of review there.

      Happy to hear that. :)

      > Second, that Opera "unofficial draft", while about as public as a tweet (arguably less so :-P)

      Hardly so, you and John have 41 followers in common, whereas the DSP API has been planned on the public mailing list of the Audio WG and I've linked to it several times on es-discuss, whatwg and public-webgl in relevant discussions. ;)

      > they want low-level APIs

      Fair enough, it's a sentiment I sympathise with. The DSP API can also be, for most parts, implemented on top of asm.js + SIMD types + River Trail, so there's no real problem either way.

      Anyway, I've strayed enough as it is, let's continue the discussion once we have more concrete proposals on the table. Thanks for the clarification. :)

  3. Seem to have lost a published comment, please delete if this duplicates one held up in moderation.

    I didn't discount Dart as standalone tech, but the topic here in your own words is "Web Technologies", so changing the subject to "Standalone Tech" doesn't help make that case. Also, I thought Dart2JS and DartVM were supposed to be kept in sync, otherwise you end up with two languages. The loss of Dart's bignum type ('int') was, I heard, due to the lack of bignums in JS.

    But see -- we have had bignums and other value types on the agenda for years. I heard about Dash in 1H2010 (and kept it secret). How much better could we have done via open collaboration, in uplifting JS and keeping Dart2JS on par with DartVM?

    It's a good thing I saw John's Dart SIMD tweet, but why is Mozilla doing the harmonizing here? Why isn't Google? No one from Google on Ecma TC39 brought up what Dart might need for Dart2JS.

    This is the big bi-polar problem. Many folks at Google work on the Web Platform in the open and consensus-oriented style, just as Mozillans try to do. That's great. But other parts go off on more proprietary tacks, yet in the end have to rendezvous with the standards. That makes for higher costs on both sides, in my experience.

    There's no free lunch: standards-oriented consensus-building work has overhead; work that aims farther ahead of consensus, or against consensus, faces different costs. There's a trade-off, and of course consensus can go wrong, too.

    But if you aim to make a "Web Technology", then absent another 80%+ market-share regime for Chrome, you have to consider standardization sooner or later. "Later" creates most of the friction that you observe re: Dart (and NaCl/PNaCl/Pepper, for that matter).


  4. Pragmatically for something to be a viable web technology it has to get deployed across practically all browsers in an interoperable way. Dart has a big hill to climb being a new language, and maybe also a VM. On the language side it's up against CoffeeScript, TypeScript and Are it's merits strong enough to attract developers? On the VM side it's up against asm.js, which has a massive headstart since that's "just" a subset of Javascript, so works everywhere already.

  5. This is just the opinion of an average developer..
    I see points from all angles, and this is what I think:
    - javascript currently is not a good solution to write large scale web applications (what I miss most are real classes, namespaces, types, lexical this and speed). I know JS is getting better with ES6, ES7, etc but due to it's fundamental issues it may never reach "good enough".
    - I like the concept of Dart and I'll probably start learning it once it makes it's way into Chrome.
    - I don't understand why people seem to stick with any technology in a religious way no matter what. This should be about the best technology for the developers and the users. I personally don't care whether it's called javascript or Dart that I'm programming it, I just want to be able to write code effectively that result in a maintainable codebase providing a nice, fast experience for the users. If javascript can get there fine, if not, why not change it to something else? It's the best interest for everyone isn't it? I'm probably naive and don't see into all the details of this, but Google obviously will not get any financial profit from people using Dart, nor does anyone now from people using javascript.
    It just seems like such a sad thing that there could be a better solution for everyone but people can't agree on it.

    1. People (even inside Google) do not agree on "best technology" or the answer to "if JS can get there". And who is to say there is only one right answer? Programming languages should be many and evolving, to serve diverse needs and maximize productivity along various axes that have inherent trade-offs.

      So it's naive to think everyone will agree to replace JS with another single VM. And I have already cited a link to Filip Pizlo's webkit-dev post on one of many high barriers to adding a second VM to browsers: GC barrier costs to collect cycles among the VM's heaps.

      Even before that barrier is the lack of a standards track for Dart. So I would not count on Dart "making its way into Chrome" soon, based on the Blink chromium-dev thread about standards and neo-standards policy.

      But say Google does push Dart into Chrome/chromium, against the Blink policy. Unless you see 80% or more Chrome usage, or are doing some kind of intranet or captive app, you will need Dart2JS parity to cover the other browsers. This brings us right back to evolving JS.

      Who says JS can't get "good enough"? The future's not set. ES6 has classes and modules and V8 is prototype-implementing it. Let's check back in three years. Of course some say "too long to wait!" but Dart/Dash has been going at least that long, and has years to go before either standardization or Dart2JS parity.

      So without any "religious" arguing, just from the logic of browser game theory, I think Google is committed to evolving JS toward Dart parity.


    2. "I think Google is committed to evolving JS toward Dart parity."

      This is worth reiterating. All of the tech that we've been talking about is new and experimental, but Javascript is here today and used EVERYWHERE. No browser that wants to stay relevant would stop improving their JS implementation. That goes for Google, Mozilla, Microsoft, Apple, and all of the smaller players too.

    3. Thanks for the answer! Well I too don't see Dart to be supported by the other browsers any time soon, and if JS can evolve well that's good for everyone. I agree it's nice to have many languages to choose from.

      'Who says JS can't get "good enough"?' Honestly this is something I can't determine, but I read and heard it many times from people smarter than me. For one it was stated in the Dash memo you mentioned above: "Javascript has fundamental flaws that cannot be fixed merely by evolving the language."
      Obviously, if those flaws can be fixed then there's no need to replace it. I believe this is something that we (you) should be able to decide judging from a technical point of view based on facts..but again I may be naive here.

    4. Javascript does have flaws, sure. Any language does. (Yes, even your favorite one.) The bigger issue, really, is that Javascript has the curse of popularity. There are many features is Javascript that don't optimize well, but they can't be removed because taking ANYTHING out of the language _will_ break websites. Period. As a result the language bloats over time because we want to both add shiny new features and keep all the old behavior as well.

      This isn't a fatal flaw though. We can work around it. The path V8 takes (and probably others, but I don't have first hand knowledge) is to encourage you to write your code using predictable and consistent patterns. (Basically: treat your code as if you were writing statically typed classes.) If the VM recognizes that your code is well behaved, it optimizes it better. If your code does something surprising the VM is forced to drop it's optimizations. This was old and crusty code may not run fast but at least it runs.

      There's still overhead inherit in this method, though, so to get "optimal" performance you'd need to take more drastic steps. One such step would be to flag sections of code as conforming to a stricter syntax and allowing the browser to fail if you don't live up to that promise. And, hey! Guess what! That's EXACTLY what asm.js does! It swings pretty far in this direction, and the restricted syntax is basically a non-human-writable bytecode, but it shows the potential benefits behind this type of code restriction.

      No matter what, though, browsers will likely never be able to completely drop the "old" JS syntax and the problems it carries. That's one of the reasons a shiny new VM (Dart style) is appealing to a browser authors, because it frees them from adhering to or tiptoeing around language choices that have proven problematic. Wether that's a benificial thing for everyone else, though, is a far more complicated question.

    5. "One such step would be to flag sections of code as conforming to a stricter syntax and allowing the browser to fail if you don't live up to that promise. And, hey! Guess what! That's EXACTLY what asm.js does!"

      I think "allowing the browser to fail" is inaccurate here, if "fail" means the program does not run. If asm.js type checking fails, the code just runs slower but with the same semantics (modulo bugs, as ever).

      If something at is unclear on this point, please cite it and we will endeavor to fix it. Thanks.


    6. Wow, Blogger's commenting system is on the fritz. Lost my comment from last night and apparently lost one of Brendan's too. Sorry! (I switched away from the G+ comments because I thought this would be more stable! *sigh*)

      Anyway, I meant to say that there's no confusion on the part of the asm.js spec (which I find to be quite clear). When I wrote "allowing the browser to fail if you don't live up to that promise." I was actually thinking of "use strict", and it was EXTREMELY poor framing for me to jump directly into the asm.js comparison.

      In related news, don't post technical things in blog comments while simultaneously attempting to soothe a screaming infant. Makes you really sloppy. :(

  6. ''For one it was stated in the Dash memo you mentioned above: "Javascript has fundamental flaws that cannot be fixed merely by evolving the language."''

    That was a nice assertion, especially given the conflict inherent in doing a new language and VM and thereby underinvesting in JS (which happened: the V8 team was rebooted in Munich). Too easy to make a self-fulfilling prophecy.

    But it's also nearly useless as a prophecy. All real languages have flaws. C certainly does and it is nowhere near to going away (C++ inherited these flaws by intentional backward compatible design, and added a few more on top). Dennis described some of C's flaws (which JS inherited) in typically humble style here:

    JS has too many gaffes and WTFs, but at this point, for most developers, they are (mostly) avoidable paper-cuts. All but:

    * the lack of exclusively-lexical scope due to the global object, and

    * all the "totally '90s" implicit conversion junk, e.g. (0 == "") === true,

    are fixed by "use strict" in ES5.

    ES6 modules, 'let', 'const', and 'class' help fix the global object problem by binding in an outermost lexical contour.

    To fix the implicit conversion badness will take some further evolution that keeps backward compatibility for == and !=, but adds opt-in ways of binding better operators. This is on the agenda for ES7, as noted (value objects/types, binary data, SIMD short-vector types). It should cover all types and (I think) be lexically scoped, so in the future you would "use explicit"; and be free of the junk.

    Anyone who hasn't seen it, please watch Guy Steele's "Growing a Language" talk from OOPSLA '98:

    Languages evolve or die. At the limit, evolution can remake a species or a language -- the bad old forms fade away through disuse. Llinters and "use strict" and modules kill the crazy. So the claim that JS "can't be fixed" by evolution reflects a choice, not a certainty.


    1. So if I see it correctly the disagreement is whether JS can evolve to a "good enough" point or not. This is certainly something I can't decide.. This might be a stupid question, but if JS does have historical baggage required by backwards compatibility that makes it hard (or not possible) to evolve it to a "good" state, wouldn't it be possible to introduce something similar to "use strict"; except that it would indicate a backwards incompatible new version of javascript causing that marked page's JS code to be executed by taking advantage of the new version?

    2. One could make such a version opt-in, but "that marked page" is hard to isolate from related pages loaded in windows it opens, iframes it embeds, etc. Conflicts are possible, but page-loading fails softly (usually; https: vs. http: is an evolving counterexample). Something like what you suggest at a coarse enough grain could be done, though.

      The bigger problem is that engine implementors *and* language users do not want runtime "modes". The costs multiply and refract through the semantics. You can end up with a big explosion of cases, extra bug habitat, user confusion, code that should port from old to new mode but doesn't for obscure reasons found only if test coverage is perfect, etc.

      Note how most of ES5 strict mode is compile-time error checking. This is good, it avoids requiring test coverage perfection. Like a mandatory linter, it keeps programs from reaching runtime and facing the bad case-combination implied by runtime modes. But "use strict" does change a few things at runtime, too (doubling the test burden, at the limit).

      To avoid further runtime explosion of cases, V8 folks asked for "no more modes" after ES5. Mozilla's Dave Herman later posted about what became known as "1JS" (more a slogan than a specific idea, apart from Dave's original proposal).

      1JS as a general slogan is about how new syntax is its own opt-in gesture. In Dave's original proposal, ES6 modules would opt their bodies into all new ES6 features. No need for "use version 6" or <script type="application/javascript;version=6">. Experience with opt-in has been bad to terrible in other languages. As Hixie (I think) said, "versioning is an anti-pattern on the Web."

      As Ecma TC39 has worked on ES6, the 1JS approach has progressed: most new syntax that has only "local" (to the expression, within the new form) effects is its own opt-in gesture. "Big" new syntactic forms in ES6 that have code bodies implicitly make those bodies use ES5 strict mode: module, class. Thus the amount of strict-mode code looks likely to rise over time.

      Strict mode itself won't be evolved, or we would end up with a semi-lattice of strict and non-strict modes for ES6, 7, ..., making for too many cases for implementors and users to keep straight.

      In no case will an onerous and likely forgotten or misspelled version opt-in incantation on top of the new syntax be required.

      The bottom line is that we have many tools to evolve toward a "better" state. There is no absolute "good" in any real language. All real languages have flaws. Evolving toward the "better" in a living language is more important than striving for false perfection.


    3. Thanks, this actually makes sense and I'm curious to see what the web will look like in a few years. Exciting times for sure.

  7. Slightly off-topic, but I have two concerns regarding asm.js:

    1. JavaScript developers, in particular the "jsPerf crowd" will manually write asm.js code in an attempt to squeeze a few extra cycles out of the VM. This may end up pushing JS usage patterns in the wrong direction.

    2. JS VM manufacturers will focus on improving asm.js performance rather than on JS in general. I know V8 already stated they will not do it, but they may be forced to once they start falling behind in performance comparisons.

    If both #1 and #2 happen it can create a vicious loop that feeds itself, to the detriment of JS.

  8. For me, the central issue with Javascript is simply that it's the only option we have. If I want to develop a desktop or server side application, I can use whichever technology is most appropriate for the task at hand. If I want to develop an application that runs in a browser, I have to use Javascript and there are no other options. Javascript is *NOT* the best language for every development task there is and yet in the web space that is the ONLY tool.

    That makes no sense from a software engineering best practice point of view and as a developer who values creativity and choice, I resent it bitterly.

    1. I totally agree, however as you can read about above, JS is not going away and other VMs are not coming any time soon. This means JS evolves to be a compiler target and multi-lingual VM. Including for Dart2JS. It is not an option.


    2. Hi Brendan - thanks for the response.

      An alternative option would be for Mozilla and Google to stop acting like silos and work together (with Microsoft and Apple?) to get us past the current impasse.

      See, the problem with your assertion about making JS a viable compiler target is that while it certainly has merit (I quite like the asm.js idea) it will fail to work (like alternative VMs) unless there is broad vendor support. No one party is going to be able to create a solution to this problem but none of them wants to work together. They all want to push their own solutions and meanwhile the web development environment suffers.

    3. As for bitter resentment, you may as well resent your mtDNA for lacking a cell-nuclear wall protecting it better from ionizing radiation. We do not get to choose our heritage. I certainlly did not! (


    4. Peter: no, that's not true. We briefed all fellow-browser-implementors on Ecma TC39 before GDC about asm.js, they were all positive to enthusiastic.

      It's just another optimization wave on top of N such waves in JS engines. It will pass and then you'll wonder how we ever did without it.


    5. re mtDNA: Well, if it were our power to re-engineer our mitochondria, then that would be a valid comparison, Brendan.

      re Cooperation: I hope you're right.

    6. "An alternative option would be for Mozilla and Google to stop acting like silos and work together (with Microsoft and Apple?) to get us past the current impasse."

      This is a wonderful sentiment, but the problem is that there is a very real cost to consensus. It's one of the reasons Javascript has appeared to evolve slowly. Even assuming that nobody is playing political games the fact remains that everyone has different needs. Apple wants Javascript features that compliment their iOS strategy. Microsoft cares about features that blend well with Surface and Windows 8 (like the Pointer API), Mozilla has been working on a lot of APIs that enable the Firefox OS phone to be a fully featured device. Google does the same for Chromebooks. All of these produce different, very legitimate priorities and can bog down discussions. Everyone wants to standardize on a single way of doing things, but everyone wants that way to play well with their own systems, and as a result things naturally slow down. Brenden linked to a great article about the search for the "perfect VM bytecode" above that's worth repeating, as covers a variation of this concept extremely well:

      In that light there's actually some real benefit to be had if everyone comes up with their own answer, with some caveats. If there are many different proposals developers can vote for their preference through use (see: MVC frameworks). Optimally the market will whittle itself down to a manageable number of popular standards through natural selection. If you get two or three standards that become well supported they drive innovation in each other through competition. (see: iOS/Android, Mac/Windows, Nvidia/AMD, Playstation/Xbox, Browsers in general...) In fact, in most markets having a single dominant player is a bad thing that squashes innovation. (see: Internet Explorer).

      Javascript is funny in that there are many different implementations that compete with each other, so although it's the only language choice it still has good forward momentum. Nevertheless, it could still benefit from having real external competition. Any language that wants to compete, however, has a long and extremely hard struggle ahead before it can legitimately be seen as an viable alternative. It's expected that most attempts will fall flat, but that's not to say that nobody should try! Eventually something will catch on and the ecosystem will be better for it, and in the meantime Javascript will continue to improve itself anyway. Given the nature of the market it's likely that an alternative language won't come out of some grand union of browser vendors but from everyone trying something different and seeing what sticks. This, in my opinion, is where Dart and asm.js sit at the moment.

    7. The "let a thousand flowers bloom" argument has some prima facie appeal, but I think the idea that market forces will deliver us a good solution in the browser development context is a flawed argument.

      You correctly point out that the competing actors (MS, Apple, Google, Mozilla) have their own valid interests in the future of the web as a platform. You suggest that innovation may be driven along if some competing 'standards' become popular. The sense I get of your argument is that one or a few of these standards will become successful and become the bigger brighter better development platforms of the future through some kind of natural selection.

      That will not happen. You will not get rational market behaviour out of the browser market because it is NOT A FREE MARKET. When people keen on market forces talk about "Free Markets" the "Free" they talk about is freedom of market entry and exit. Clearly, as you and Brendan have both indicated, the web development space is very very far from free to enter. All of the actors in this market have control over market entry - a web tech that is not supported in all browsers is a tech that most developers cannot use. If I were madly in love with Google's NaCl (I'm not) I still wouldn't be able to use it for a web product. What business can afford to ignore the majority of the market who do not run Chrome? Likewise asm.js - Brendan thinks that cooperation isn't important to get asm.js established but the truth of the matter is that if only Mozilla optimise the asm.js path, its appeal over bog-standard Javascript is near nil for most developers.

      When you have a market where fitness for purpose is not the driver of success, but rather the whim of self-interested parties who have lots to gain by 'winning' this competition and plenty of power to prevent the success of alternatives, then this is NOT the kind of market that we should expect to provide solutions that meet the needs of us mere developers. In fact, the very idea that markets will deliver the best solutions is a curious idea. Actual markets usually deliver what is cheap, ubiquitous often the minimal viable solution - like McDonalds in the context of food. Much like Javascript in the browser.

      As I said to Brendan, I hope you're right - I hope this "competition" actually produces some good contenders for future web development. But the cynic in me thinks that this mexican standoff of self interested parties is not likely to produce anything that can gain market share - especially when the status quo suits the JS faction: JS has market dominance and refusing to support any alternatives makes maintaining that dominance trivial.

      I'm discouraged by the fact that all parties seem to believe that cooperation is not possible because you have your own interests. OpenGL manages famously under exactly the same circumstances.

    8. Peter:

      Google and Mozilla are cooperating on a lot. You seem to ignore that cooperation, but never mind. We cannot cooperate past certain hard inherent problems, such as the cost of inter-heap cycle collection GC barriers. See Filip's webkit-dev post linked above, read the paper he cites.

      The alternative of a single GC and VM for multiple languages designed from a "clean slate" is also risky and costly, compared to evolving JS VMs to become that single GC/VM system. We have to evolve JS VMs anyway to keep our browsers competitive, and we're adapting to selection pressure for better cross-compiled code performance already (not just asm.js -- GWT and others).

      On your reply to my genetic trope, proposing engineering: We do not get to re-engineer our mtDNA _in situ_ now that it has spread throughout 7B people. Making alife with new mtDNA would be interesting (and dangerous). Unless you make a virus that rewrites 7B humans' mtDNA, you have to deal with "backward compatibility".

      Backward compatibility is what binds us most. It is deeply engrained in the Web, and in the Internet (see Postel's Law and my corollary). If someone could get past it and spin up a new Web, they would soon enough face the same problems we face, perhaps with a bit better up-front design helping them get a bit farther toward one idea of "perfection".

      But the evolutionary system doesn't care about "perfect", it cares only about "better and backward-compatible enough to hop to".

      Given these constraints, I have chosen to work on "better" in reachable hops.

      Dart designers seemed to want a much bigger hop -- not feasible for competing browsers to make based on DartVM code -- and a "replacement" strategy, but they seem to be ending up (via Dart2JS) needing the smaller hops. That validates my thesis.


  9. This conversation feels incomplete without mentioning Decaf ( which tries to put Ruby in the browser.
    A humble beginning by a single developer but still...

    1. Why modify webkit when you can just compile to JS?

      This is the future for alternate languages in the browser(at least the immediate one). Compiling to JS.

  10. I too love Dart, and would love to see it and it's VM adopted broadly. It's an uphill battle, but I really hope it makes it. It's extremely intuitive to write (for anyone with a JS or Java background), very performant, and batteries-included. It gives you Java performance without all the complexity associated with Java for web development.

    And sure, maybe JS will "get there" eventually. But come on, ES7? The ES6 standard hasn't even been released and isn't expected to release until December of this year. And then how long until wide adoption by even the current "stable" versions of each browser? Another year? Then how long till proposal freeze on ES7? And then until release? And then until implementation? The point is that sometimes a huge standards body like TC39 moves so slowly that they can't evolve the language fast enough to meet the needs of a market. And I suppose this very reality is what makes other alternatives viable. If TC39 moved faster and JS advanced faster (fixing its warts and improving) then there would be no need for alternatives like Coffeescript and Dart.

    In any case, Dart is awesome and I hope it takes off.

  11. Abe: who needs a "But come on" here? Dart is many years away from standardization even on Google's own terms (a la OOXML, a corrupt/captive standard), and strictly behind the uplift needed in ECMA-262 for Dart2JS to be usable.

    Taken together, these two points strongly suggest in the far future if there's a "DartVM", it is very like the same VM as the one running JS (and other languages).

    Standards take time, especially starting from zero in 2010 (or whenever Dart started) and going public/open later.

    While standards take a while, you make a common mistake: the ES6 standard will be finalized long after it is usable in evergreen browsers covering most of the web browser market as seen by top servers, same as ES5 (strict mode took till IE10), same as all the many new standards emerging under the HTML5 umbrella.

    Standards finalization *follows* implementation and adoption, it does not precede it, in the modern era (done right, knock on wood, etc.).

    Yes, of course (especially on desktop, and on Android 2.3) there are downrev browsers, which require compilers and other things (and are not easily worked around at the limit -- Gingerbread WebKit has so many bad bugs that PhoneGap cannot patch around them all). Hold vendors to account (MS of course, and they are improving; Google also, for GB).

    This brings us full circle: any non-conforming (whether downrev or dissenting) browsers in a period where Dart runs as if "natively" on an appropriate VM will require Dart2JS, which will (if those downrev browsers are being updated to track JS evolution) require JS uplift. Which is in general much, much easier than standardizing and re-implementing/dual-implementing/reverse-engineering DartVM.

    If we go through an 80% market power period (one browser on top), this changes. If old browsers are not maintained so they don't see JS uplift, then an alternative approach would be required. I proposed one in ES4 days: Screaming Monkey (add an Active Scripting ES4 interface to Flash so IE gets ES4 support via Tamarin, whether MS wants it or not).

    There are always options, but just saying "get there" and "eventually" won't cut it. You have to wait, or else wish for a market-dominating or even monopoly condition. I've had enough of those, both in the '90s and more recently on "mobile".


  12. A couple of quick followup points. I wrote:

    1. "Hold vendors to account" and later wrote about "market-dominating or even monopoly condition". These are in conflict. The best way to hold vendors to account, the reason MS is doing better now, is competition among vendors.

    2. "You have to wait" -- of course, I meant we all do, since standards take time. But some of us are working to uplift JS, not just waiting around. And that makes all the difference in what is likely to happen next.


  13. Aking Web Tech a leading IT company & Provides web services :- website Development in just 1,999 Rs/-, software development like {Billing software, School Management Software, Inventory Software, ERP, CRM}, Domain & Hosting , SEO
    Software companies in indore

  14. Thanks to share this well informative blog with us.Keep sharing.I will keep share in future.Web design company

  15. I was just thinking...
    basically the way to optimize js on v8 works in the same way asm.js does.
    Look here : 'v8 works better if your function has less overload'
    and here : 'asm.js translates llvm byte code to javascript from previously compiled c++ code'
    isn't it similar the way to gain more performance is to have more strict type and logic (which is a good idea from es6) that we can compile it later more closer to the real assembly language,v8 and asm.ja is just about top down or down top approach. I think what we really need is to 'statify' javascript. I mean we need to make a switch on javascript to tell the browser like 'hey, at this part of code I need more performance so I write it in static manner please compile it once and dynamically link it, and please tell me if I use it in a wrong way.' Such library as physic and graphic don't need to be dynamic right? Maybe giving a <script type='text-c++' language='c-c++> which later the parameter can be bind similar to bind uniform at webgl is a good option to fix js flaws. Let's call it dual standard system which can cover each other weakness while still keep a backward compatible. How bout it?#inexperienced programmer

  16. I am happy that I found your post while searching for informative posts.