By Craig Buckler

Why Google Dart Will Miss Its Target

By Craig Buckler

Dart is Google’s new programming language designed for creating structured web applications. You’ll be able to run it on the server but it’ll also run on the client. In a browser.

Depending on what you read, Google has both admitted and denied that Dart is a replacement for JavaScript. However, Chrome will shortly be able to use either language and, given the choice, I’m sure Google would prefer developers used a solution they control.

I was initially skeptical about Dart but reserved judgment until more information was available. I can now categorically state that it’s almost certain to fail in the same way VBScript did in Internet Explorer.

Dart’s Goals

Dart is an open source project with the following design goals:

1. Create a structured yet flexible programming language for the web.
Great. But what’s wrong with all the other structured and flexible languages? One of the web’s greatest benefits is you can use any server-side language you like: PHP, C#, VB, Perl, Java, Ruby, Python, etc.

There’s always room for improvement but we’re spoiled for choice. Dart doesn’t offer something different — just an alternative.

2. Make Dart feel familiar and natural to programmers and thus easy to learn
Syntactically, Dart is very similar to Java, C++ and C#. So why didn’t Google simply adopt one of those languages? That would have made it even easier to learn.

3. Make Dart appropriate for the full range of devices.
Google has stated that they’re “up against fragmented mobile platforms”. Wouldn’t another language fragment it further?

It’s possible Google will create a native Dart runtime for Android. Perhaps they’ll even create a version for Windows phones. What about Apple — the most successful smartphone vendor? Not a chance.

4. Provide tools that make Dart run fast across all major modern browsers.
Will Microsoft, Mozilla, Apple or Opera add native Dart clients to their browsers? It’s unlikely.

Google could create plugins for those platforms but web developers won’t write Dart code until the plugin has a wide installation base. Unfortunately, users won’t install the plugin until compelling applications have been developed using Dart. Catch-22.

JavaScript Compilation

Google doesn’t actually need to a Dart plugin since they’ve created a compiler which translates Dart code to native JavaScript.

Before you get too excited, take a look at a compiled Dart “Hello World” program. Nine lines of Dart code is successfully compiled to … 17,259 lines of JavaScript.

I’m sure that situation will improve. Even today, it could be run through Google’s Closure Compiler to make the code more efficient. But the fact remains that native JavaScript written by a half-decent JavaScript developer will always beat compiled Dart code.

Even if you do develop in Dart, you’ll probably want to drop into JavaScript at certain points to improve efficiency. But if you can already write good quality JavaScript, why would you develop in Dart? Catch-22-2.


Show JavaScript Some Love

It’s clear from Google’s documentation that Dart is aimed at developers who dislike JavaScript.

Despite being the world’s most-used programming language, JavaScript is the most misunderstood. The name doesn’t help — it’s neither Java or script — but the biggest cause of bad press comes from professional programmers.

Initially, JavaScript looks a little like C++ or Java. Developers with knowledge of those languages hunt through the manuals for the class syntax only to find it doesn’t exist. They conclude JavaScript is awful or attempt to force classical inheritance techniques into their code.

I implore you to persevere. JavaScript is flexible and allows you to write code in a number of ways. Once you understand concepts such as prototypal inheritance, JavaScript will earn your respect. It may not be perfect but class-based languages soon begin to feel clunky.

Don’t expect it to happen overnight. It took more than a decade for developers to rediscover the beauty of JavaScript. Fortunately, there are many fabulous resources on the web and JavaScript is recognized as a first-class language.

Because You Can’t Fight it

The major problem for Dart is that JavaScript is everywhere; from humble mobile phones, to Apple iPads, to modern desktop browsers. Microsoft is even making HTML5 and JavaScript key technologies for application development in Windows 8.

Even if Chrome reached 50% market share, would you develop in a language which was supported everywhere or on just half of all devices? Perhaps it would have stood a chance if it was released a decade ago, JavaScript was utterly terrible or Dart was revolutionary. None are true.

I’m glad Google continues to innovate but Dart feels like a backward step. You may dislike JavaScript, detest HTML and despise CSS — but, to be a web developer, you can’t avoid them.

  • John

    “Even if Chrome reached 50% market share, would you develop in a language which was supported everywhere or on just half of all devices? “

    Well what if Google Chrome drops support for JavaScript, like they did with H.264? ;)

    • Peter

      Well, if google drop support for javascript, their chrome browser will become useless to surf the web (thankfully the web != google), so their users will have to choose another browser (perhaps internet explorer?)

    • Is that likely to happen?

      Dropping H.264 had a fairly minimal impact. It wasn’t much fun if you had adopted that as your format of choice but only your videos would have been affected and it was relatively easy to fix.

      Dropping JavaScript would strip interactive functionality from all websites and break many others. Would you accept that or would you switch to another browser?

  • As much as I agree that Dart feels like one of Google’s less well thought through endeavours, this article feels overly biased; as though you had already written off Dart before giving it a chance.

    • Ryan Holdren


      In my opinion, the specification unveils Dart to be a more robust language than JavaScript and undeniably better suited for large-scale development.

      While I wouldn’t put any money on Google being able to pull it off, I wouldn’t hesitate to switch to Dart if it were adopted by all the major browsers.

      • Why do you consider Dart to be more robust? JavaScript has been around for a 15 years. Dart has been in development for a few months. Time scales aren’t everything but no one’s had a chance to find problems in Dart yet.

        If Google really wanted a robust system, why didn’t they adopt an existing language rather than starting from scratch. Again. Besides, what ever happened to “Go” – their other language for the web?

    • I wanted to wait until the syntax and further details were revealed before writing a Dart article. I admit that I was skeptical when Dart was announced but, after going through the latest documentation and JS compiler output, the whole idea seems even more ridiculous.

      Perhaps I’ll be proved wrong. Does anyone intend adopting Dart for client-side development?

  • Well, you know ruby started out as a weird, unloved sidebar language with some nifty, forward thinking features. Now look where we are . . .

    • Ruby wasn’t trying to position itself as a replacement for another language. You’re free to use Ruby for one project and drop it for the next.

      There’s no reason why Dart can’t become a viable server-side development language. That said, it’s so similar to C# or Java, there are few compelling reasons why those developers would want to switch. It’s early days, though.

  • Prasad

    Well, the way i look at it is, Dart is an attempt to save the web. If anyone has noticed, the coolest apps are not web based any more but are on iOS platform, running exclusively on iPad. If we let the web takes its own evolutionary course, where Javascript will eventually catch up with either iOS or android, well, It aint gonna happen. Its better late than never. The wisdom lies in joining hands and help create new standards, (if revisions to older ones just dont cut it). No point in sitting and complaining. All it needs is a couple of major companies like Google and Microsoft push the standards. Apple or for that matter anyone else will have to follow or die. Closed platforms are not the future !

    • You’re confusing JavaScript with browser APIs.

      Dart (and JavaScript) don’t offer anything over any other language – it’s just a programming syntax. What you’re really saying is that native OS (desktop) apps are quicker and offer better system integration than web apps. That’s always been the case and is likely to remain so for some time to come.

      • Prasad

        Well, javascript has fundamental flaws which even Javascript gurus accept. Thats why there are books like “Javascript : the good parts”. Every Tom Dick and Harry has written a js library, where half the library has nothing to do with the DOM (which is another screw up, but i wouldnt go there). For a list of what Dart’s goals are, (which IMHO Javascript can never reach) please read this memo :

        My initial observations, Dart is definitely better than javascript, but success depends on browser vendors and i hope these guys get serious about building a better web. There is a lot to fix and Dart is just another step and an important one !

      • JavaScript is not perfect, but neither is any other language. Douglas Crockford’s “JavaScript The Good Parts” highlights just how good JavaScript is and went a long way to rectifying the misunderstandings.

        Again, though, your main complaint is not about JavaScript but the APIs. The primary reason JavaScript libraries exist is to fix inconsistencies between browsers. DOM handling is a large part of that, but event handling and Ajax are the other main parts of all library cores.

        Dart still requires a large library and who knows how complete or efficient that will be. The only difference is that, unsurprisingly, there’s only one at this time.

  • “Because you can’t fight it” is not a good reason to stop innovating (although I’m not so sure that Dart is much of an innovation).

    You may be interested in knowing that not everyone who dislikes Javascript does so because of prototypical inheritance. Perhaps it’s because its relaxed attitude towards errors, the lack of tools, the lack of a standardized module system, the almost complete absence of a standard library, etc.

    • But aren’t reasons such as relaxed error handling and flexible modules a benefit too?

      A few years ago I’d have agreed that we lacked tools, but every browser now offers a great set of debugging facilities. Personally, I don’t want a standard library — they often have too much overhead for client-side code. But, if you want one, jQuery is about as good as it gets.

      • I’m not a fan of relaxed error handling. I want to notice errors so I can fix them. I don’t want them to be ignored and hidden.

        Regarding modules, since Javascript doesn’t have any built-in support for modules, so everyone invents their own scheme. Luckily things are getting standardized with node.js, require.js etc. There still is no way to load modules in browser-based JS without polluting the global namespace and the DOM.

      • Oh, and the whole *point* of a good standard library would be that it would not have to be downloaded for every page that uses it. JQuery from a CDN gets us closer to that, but it’s pretty far from the richness of the libraries of e.g. Python or Java.

        That, and that a standard library provides a standard way of doing things, which simplifies code library interoperability. We don’t want a situation like in C++ where every code library invents its own string class!

  • Niels Krijger

    When I first met JavaScript and the whole world was using IE it wasn’t a big deal; javascript was used for some nifty visual and usability effects, and we had yet to discover IE had actually implemented AJAX before everyone called it that.

    Now with it’s huge popularity I have yet to come across the first large javascript codebase (say over 20000 LoC) which I consider “intuitive”. Perhaps it’s a question of bad architecture, fine. But you can go so many ways with JavaScript and the strength of a language is not necessarily in what it can do, but what you can’t do. It should be a tool to aid you in you in a purpose and excel in that purpose. We still use Perl for IRC bots for example. JavaScript is moving from a domain-specific language to a general purpose one; and I for one consider that a bad thing.

    I’ve built plugins in both Chrome and Firefox using javascript and let me tell you, I adore it for those type of purposes. In the mobile app business, it’s fantastic. In those domains they are provided with domain-speific libraries that get the job done easily without a lot of code. For big web applications with lots of custom javascript; I loathe it. And I would consider using DART if it is supported natively. It is much more familiar for anyone from an OOP background.

    • Dart is certainly more familiar to anyone from a traditional OOP background. Personally, it took me many years to understand JavaScript concepts — partially because I thought OOP techniques were impossible (they’re not), the documentation was fairly poor, and techniques such as modules and closures were largely unknown. Now, I really miss JavaScript techniques when programming in other languages.

      I’m sure JavaScript could be used for large-scale apps — I’ve used far worse. However, it’s primarily used within a browser and downloaded on the fly with a single page. Server-side page refreshes are far from redundant, so JavaScript (and client-side Dart) apps need to remain relatively small and nimble.

    • Thanks Craig for the article. I’ve been finding your posts stimulating – thank you! :-)

      +1 for Niels comment:

      Love JavaScript for smaller work.

      For larger work, I want good code structure. Well structured code makes for faster programmer ramp-up, simpler maintenance & extension, easier collaboration, less bugs. And less pain.

      While great structure is possible in JavaScript, it is not an intrinsic strength of JavaScript.

      For web apps with complex front-ends, I will consider GWT (and in future Dart) versus JavaScript-with-well-planned-structure.

      I’d love to see some articles on achieving great structure in JavaScript.

  • Devon

    You said:

    “Great. But what’s wrong with all the other structured and flexible languages? One of the web’s greatest benefits is you can use any server-side language you like: PHP, C#, VB, Perl, Java, Ruby, Python, etc.”

    That’s only half the story, though. Currently, client-side scripting is almost entirely Javascript. Even though developers have a choice for their server-side language, they’re more or less stuck with Javascript on the client-side. The interest in Node.js indicates that developers are at least interested in working with the same language for both the client and server.

    • One of Google’s goals was to create a robust web language. So why didn’t they create a client-side implementation of Java, Ruby, C++ etc? What does Dart offer which those languages don’t?

      On the client, JavaScript is your main choice (although let’s not forget VBScript, ActionScript and the various Silverlight languages). It’s in all browsers and will remain there for some time. Perhaps a better solution will eventually appear but I don’t think Dart is it and, even if it were, it would take years to have any impact whatsoever.

      Let’s face it, client-side development is far from perfect. You’re free to create alternatives to HTML, CSS and JavaScript but they’d need to be considerably better before anyone took notice.

      • Anonymous

        Why would they need to make a client side version? All they need to do is port it. If Microsoft or Novell wants C# on the clients browser, they can just port it, and by themselves. Same goes with Oracle and Java. C++ is way to big for a client-side scripting language. They could make a much simplified that removes all the unnecessary features and add the (oh wait, they did, Its called Dart.). They idea of Dart is to make a scripting language that is better for large projects, and has more optimization opportunities than JavaScript. In the future (if Dart catches on) it will be able to run faster than the fastest possible JS engine. But if JS would be replaces with an existing language, I vote for Lua (fastest interpreted language), especially if Dart can’t exceed LuaJIT2’s speed.

  • Richard Cook

    First off, I would like to point out that I am not going to be switching to Dart, at least not at the moment. However, I would like to point out some things that are very misleading in this article.

    1) 17,000 lines of hello world: While this is technically true, it is horribly misleading. Dart’s hello world contains its entire language definition in javascript. As such it is always going to much larger than expected. For example, JQuery’s “hello world” is 9,000+ lines of code. Ext’s “hello world” is over 90,000 lines. So please don’t posit that as evidence of it’s inefficiency.

    2) All of the C class of languages (C, C#, Java, javascript) all look extremely similar to each other as far as syntax goes. The only thing that makes Dart look more like a traditional C style language is the strong typing it provides. With that being said, the strong typing is optional, leaving the syntax much closer to javascript itself, but still accessible to classical programmers.

    3) If google can make Dart run much faster as native Dart interpreteres than javascript can run, and still maintain good performance in its compiled javascript code, then there is no reason not to covert to Dart if you’re looking for high performance. Also, google has a pattern of making its technologies open source, thus others could easily pick it up and adopt it to run natively.

    As I stated previously, I am not going to be switching to Dart. The lack of documentation on closure and lambdas is enough to deter me. There are some real down sides to using Dart at the moment, especially with many new programmers learning to leverage the power of function programming. However, instead of focusing on the real problems with Dart, you decided to rail on how its syntax is “too much like C”, and how its “compiled hello world is 17,000 lines”. That’s just bad journalism, and frankly has nothing to do with Dart’s chances of success.

    Anyone that has looked at Dart can easily see its benefits, and anyone that knows how to code real javascript can easily see its downfalls.

    • 1. My main point is that native JavaScript will always be more efficient than a pre-compiler (or using a library such as jQuery). Besides, why would you need jQuery for a “hello world” application?

      2. If Google really wanted Dart to be accessible to classical programmers, why didn’t they pick an existing language? Why start again? And what’s the benefit of switching from JavaScript to Dart because it can be written in a similar way?

      3. The main bottleneck for any JavaScript application is the browser API. Modern JavaScript engines are extremely fast – Chrome has a great one – it’s the browser rendering which slows things down. Preprocessed Dart code will have the same problem and it’ll never run as fast as a native JavaScript.

      And why would a native Dart plug-in fare any better? If Google can make Dart run quickly, they can make JavaScript run quickly. JavaScript’s not slow because of its syntax – it’s slow because it’s interpreted within a browser. Like Dart.

      • Alex

        #3 is incorrect. There are still plenty of instances where JS slows things down. A typed language which can be given advantages such as parallel processing directives can have huge advantages in speed over JS. A plug-in “Dart Player” could also manage using browser and platform-specific APIs much like Flash currently does. Dart could conceivably standardize access to the GPU (which Flash does for us now).

  • Harry

    Using GWT for more than 3 years in large and mid-range enterprise projects I am SURE that Google is not missing its target. And belief me, at the end of the day you will never ever have to think about improving efficiency using javascript. With the compiler it is assured that you can target all browser platforms. GWT does all that really well today and Dart will do it tomorrow. How ever I’m not really sure why they need a “new” language for this …

    • I can’t comment too much about GWT because I’ve not used it. However, Google seem intent on providing solutions which allow developers to avoid JavaScript coding. In the same way, someone can use Dreamweaver to avoid HTML and CSS coding.

      If you don’t want to develop using those technologies, that’s your prerogative. But why would anyone who’s interested in web development want to avoid the tools and techniques which make it possible?

      • boen_robot

        “If you don’t want to develop using those technologies, that’s your prerogative. But why would anyone who’s interested in web development want to avoid the tools and techniques which make it possible?”
        That’s an easy one… because we’re “naturally wired” (so to speak) to quickly desire the shiny results without getting our hands too dirty. If there was a way to create a new [insert your favorite web app]… but make it look completely different… with a different UI… in less than an hour… without using actual [insert app kind] packages, people would go nuts for it.

      • I know what you’re saying but, personally, I want to get under the hood and start tinkering. That’s why most of us started software development. If you need HTML, CSS or JavaScript coded for you, you’re not a web developer.

      • Remon

        Craig, the reason you want to use a higher level language for the web is the same reason you probably ought to code in Java/C#, etc. instead of assembly language. I’m old enough to remember assembler programmers using the same arguments you do to pooh-pooh the first high(er) level languages.

        You should try GWT. All concerns about whether your code will run correctly on all versions of all browsers go away (at least that has been my experience). You can concentrate on the business problem you are solving rather than than being distracted by the idiosyncrasies of all the platforms your code has to run on.

        Finally I think that encapsulation is more easily accomplished in java than in javascript. Have you ever seen two javascript libraries conflict with each other? It happens all the time, and can be absolutely maddening. I can’t think of a single case where that happened with the third-party java libraries I’ve used over the years. Is that because java programmers are smarter than javascript programmers? Of course not The problem is the language.

      • Harry

        Using high level languages like GWT or Dart does not mean that you don’t have to care about HTML and CSS anymore (this is a precondition IMO). You don’ t have to care about Javascript and it’s different browser implementations.

        However, Dart does not try to shield you from Javascript. It gives you a language that can be used instead of Javascript. The Dart-to-Javascript compiler is only a vehicle for running your Dart implementations on any browser, regardless if it supports the native Dart VM. The real benefit of GWT and Dart is that they perfectly scale in developer productivity for big projects. Javascript itself seems to have its problem in this area, otherwise Google would not introduce a new language (and I think they have the experience to deal with really big JS projects).

        PS: Javascript developers are not the only Web developers.

      • @Remon JavaScript is hardly low-level. It’s an interpreted script running in the browser. The chances of it being replaced by Dart are nil in the short terms and highly unprobable in the long term.

  • Once there was a functionnal language called caml which is very similar to javascript though entirely different in its syntax… Progammers should make an effort to learn these functionnal languages and refuse procedurals programming as java and now dart ! …
    We should learn new way of programming, leave away those hugly nested foreach/ for…

  • Won’t Be Fooled Again

    While I agree with a great of that stated, I do find it hard to fully grasp the degree to which you feel compelled to declare yourself a JavaScript apologist who so easily sidesteps the possibility (or outright certainty) that the vast number of developers who despise JavaScript are entirely correct in stating, from experience, that it does, in fact, suck to no end.

    Count me among those that have grown forever weary of the excessive inefficiencies and outright primitive results associated with traditional web-based development, who understand that once onslaught of HTML5/JavaScript hype has run its course, as it most certainly will, those creating the most incredibly immersive user experiences on the web will still be doing so via Flash and/or Silverlight…

    • Why, exactly, do you despise JavaScript so much? Please give some examples of excessive inefficiencies and outright primitive results.

      I used to think JS was crap too – but finally realized my previous experience with C-like languages led to many misunderstandings. After all, what can any other language do which JavaScript can’t?

  • David A. Powers

    In my experience 90% of all JavaScript I have ever seen is horribly written. It is difficult to debug and maintain, and it lacks modularity. I say this, as someone who has written C, Java, ActionScript 3, Ruby, and Python.

    Whether Dart succeeds or fails, any “serious” application developer should be able to see where JavaScript is seriously flawed, at least as it is typically used. I’m sure one could use a framework to improve it, but much as I love jQuery, jQuery is NOT that framework. jQuery plugins and scripts are part of that 90% of horrible code.

    Also, I totally disagree that “relaxed error handling” is good. I have built complex applications in Flash/Flex (think JellyVision / choose-your-own-adventure) that should be possible in JavaScript, but I am quite confident that it would take 4-5x longer to debug and create anything so complex in JavaScript. So clearly, if Dart can allow one to create these type of robust applications on both client and server-side, it is fulfilling a real and valid need in the community.

    • While there’s a lot of horrible JavaScript in the wild, I’m not convinced that’s a fault of the language. I’ve seen horrible code in all languages … and written my fair share.

      Part of the “problem” is that JavaScript is very accessible to novice coders – hence the shoddy code. But, ultimately, that accessibility is a good thing.

  • Same thoughts I had Craig. I have to say it, but you always seem to hit the nail on the head.
    Google should focus on making javascript better (like they did with GWT indirectly) rather than creating a whole new language and risking inconsitent implementations across browsers.

    First Google+, now this. I love google, but I hope Dart fails. It’s time google learnt to focus their efforts on doing what they do best.

    • Thanks Stefan.

      What’s wrong with Google+ though? I like it!

  • Nick

    Javascript slept with my girlfriend, I will kill Javascript with my bare hands. I am not a ninja though.

  • Soulcyon

    @your response to Dart’s goals:
    1 and 2) Server-side languages are irrelevant, since we’re talking about client-side programming. Improving/replacing Javascript would mean creating a competing Interpreted language, not using one of those “mainstream” languages which have to be compiled. Regardless there are many existing interpreted languages, but why didn’t Google use those? You should probably read up on the history of the web – why didn’t Netscape and Microsoft create languages for their own browsers? They both agreed with Netscape’s proposal for Javascript – later revisions of ECMAScript came to fruition.

    3 and 4) Are you seeing the current trends with WebGL? WebM? WebP? If Google can provide a viable solution for replacing Javascript, it could probably be caught in the storm of updates. I’m pretty sure Javascript won’t die off anytime soon, even if Dart is natively supported on all the browsers, and it doesn’t seem to unreal to support both Javascript (legacy) and Dart at the same time, in the same browser.

    As for “what can’t JS do?”, here are a couple examples:
    – 0.1 + 0.2 != 0.3
    – NaN != NaN

    These are just a couple trivial flaws, I won’t even go into the language’s fundamental flaws. Also a few points: Dart is meant to be fundamentally strong, speed can always be improved upon in interpretation of the language. Dart would be really strong as a server-side language, I would presume, however the language is still in its infancy so we’ll have to see where Google takes it.

    Google Go was a whole new language that was competing with C and C++. You could use Go to create web applications, but those only ran on Google App Engine. We do have to be clear though, any language can become a “web language” in your sense Craig, however, there is only 1 programming language that will run on a browser – Javascript, and soon to be Dart. Java and Flash are compiled, and Silverlight was a good attempt at shaking up Javascript, but the marketing really sucked, so it ended up being another plugin.

  • I definitely wouldn’t trade my best friend for a new friend that only works in Chrome. JavaScript is a great language in many many ways. I wouldn’t have started my blog at if I believed it to be junk. JS might be different than most languages, but it sure isn’t junk and now that JavaScript can run nicely on the server with Node.js, I’ll definitely be sticking to my guns.

  • walterbyrd

    > But what’s wrong with all the other structured and flexible languages?

    As you, yourself, stated; Dart is meant to be run on the server, or the browser.

    > Syntactically, Dart is very similar to Java, C++ and C#. So why didn’t Google simply adopt one of those languages?

    Maybe because Microsoft, and Oracle, and completely insane about suing anybody (but especially Google) who uses IP that supposedly comes from Oracle or MS? Do you think Java is a FOSS language? Then why is Oracle suing Google for using Java?

    > Will Microsoft, Mozilla, Apple or Opera add native Dart clients to their browsers? It’s unlikely.

    By that reasoning, there is no way that Microsoft would allow JavaScript in IE; since JavaScript would compete with VBScript.

    If Dart were to catch on, do you think MS would risk losing IE market share to Chrome?

    • > As you, yourself, stated; Dart is meant to be run on the server, or the browser.

      How does that answer the question?

      > Maybe because Microsoft, and Oracle, and completely insane about suing anybody…

      Oracle are suing Google because they adapted Java so it’s no longer the same language. Oracle’s case is based on Google taking their original code, changing it, and releasing a competing system. But there are many open standards. Microsoft’s C# is one option – that’s why Mono exists.

      > By that reasoning, there is no way that Microsoft would allow JavaScript in IE…

      Are you serious? Microsoft reverse-engineered JavaScript to create JScript which they made available on the client and server. That was in the very early days of the web when Netscape had the most popular browser. Had they not implemented JScript, IE may have failed.

      That’s not the case for Dart. It’s very late to the game, isn’t a W3C standard, and pre-processes to JavaScript anyway. There’s little incentive for Microsoft, Apple, Mozilla or Opera to implement it — especially when it’s only an alternative to a language which has already proved itself.

  • saty

    Hi, 100% agree.. Too bad that Google keeps on trying to come up with things like Go, Dart, etc, just because they can. Today’s Javascript is an awesome language, Google needs to support it instead of reinventing the wheel.


  • Anonymous

    Javascript is a monopoly needing to be displaced.

    • JavaScript (or more specifically, ECMAScript) is a standard. Like HTML and CSS. You’re welcome to suggest alternative options.

  • Joe Knight

    I don’t know if Dart will fail but one thing i’m sure : Javascript is a complete failure. The fact that it’s been around for 15 years says nothing of it’s robustness. Your article is completely biased. Accept that Javascript will fail , must fail. But of course you love JS and you can’t accept and analyse the facts. I really hope Google or anyone comes up with a JS replacement as soon as possible. Yes i’m a JS hater, and with reason.

    • …and those reasons/facts would be?

      You state JavaScript has failed. How? It’s been around for 15 years and is the world’s most-used programming language. If that’s a failure, we might as well give up on IT altogether.

      I think JavaScript’s a great language. That’s my opinion — or “bias” if you prefer. You may not agree, but that’s your own opinion/bias. It’s just a shame you don’t offer any rationale for it.

      No technology is ever perfect, but I’m yet to see a better alternative. Can Dart succeed when it’s a non-standard language developed behind closed doors by a single vendor? I wouldn’t bet on it.

  • Anonymous

    I like the Dart initiative. I have hated JavaScript ever since I started working in it. I have complained about it to my colleagues but have never gotten anywhere because in the end, it is just my opinion vs others; and I am only one humble developer. However, to see Google come out and point out the same flaws in JavaScript is a big deal. They have the most experience when it comes to rich web applications; not websites, but real applications. So, I am sure that they have truly felt the pain of trying to build rich powerful web applications using JavaScript, and finally they came to the conclusion that JS has some major flaws that can only be really fixed by re-doing everything. As long as Dart/Dart Compiler/IDE can covert Dart code to efficient JavaScript I am all in! It is the best of both worlds in my opinion.

Get the latest in JavaScript, once a week, for free.