Google Dart vs. JavaScript Debate

Dart vs. JS : Objective Reactions?

Google Invests in Dart to Improve Upon JavaScript.
Brendan Eich tries to Reason Why Dart is Not "Right" Approach

I was just reading Brandon Jones's blog entry titled "A Tale of two Web Technologies" today where Brandon put forth a nice call for discussion about Dart vs. JavaScript (JS).  I liked how Brandon summarized his position on this subject as follows:

"For my part I think they're both [Dart and asm.JS] 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."

I am with Brandon all the way on this — there is no comparison between the cleanliness of Dart code and the equivalent (current) JS code (or asm.JS-infused mess): Dart makes writing large-scale, object-oriented, performant applications for the web so simple compared to JS!  Sure, it is not "perfect" and has some areas that need attention (as I have blogged about recently: see areas that Dart needs to improve upon to further adoption).  But, Dart solves a LOT of the issues that exist with JavaScript.

As expected, I noticed that Brendan Eich  (of Mozilla CTO and JS-inventor fame) was quick to jump in to represent and defend the JS camp (by commenting on Brandon's posting), while a few others expressed a mix of opinions about JS and/or Dart.  But, as of right now when I am writing this, I really didn't see anyone aside from Brendan (who has a serious vested interest in being a proponent of JS over most any "competition") really making any substantial arguments for sticking with JavaScript over Dart.  I think that alone says something.

An utterly huge number of JS developers are out there, but I cannot help wondering how many are at least in some part annoyed by the promise of what "ES6" or "ES7" will bring when the wait for such things has seemed infinite.  I personally gave up on waiting (for EcmaScript to get to where I wanted it) when I saw the difficulties the ES parties had even try to agree on how to implement classes (objects) and inheritance, etc.  Ugghhhh.  Like there is anything to "invent"??  How many languages do we need as a reference for a decent object system (plenty exist)?  Well, thankfully Google decided NOT to wait forever and instead created a language (Dart) that included the modern constructs and features I expect in a development language.  And, coming from Delphi, C#, C++, and other programming, Dart felt as natural as anything could be... and now I can code for the web much like how I write desktop applications.

Dart is FREE! Dartium (browser) Exists Now. Why knock it?

Maybe I am just unusual in my thinking.   Personally,  I do not see any problem at all with requiring a variety of Browsers (that may have varied VMs within them — Dart, JS, whatever) in order to access content that relies on applications / scripts written in a variety of languages.  E.g., "Dartium" (Chromium with the Dart VM in it) exists currently and works fine for viewing both Dart-based web applications as well as JS-based pages. We have all seen the "best viewed with XYZ browser" on sites at one point or another, so would it be that big of deal to see "runs faster with Dart" indicators too perhaps? And, what do I care if I need multiple browsers on my system to interact with various sites/services or to have an optimal experience?

Customers (i.e., users) don't seem to mind installing tens (or hundreds) of "apps" on their devices, so why would users care if the "app" called "Dartium" (or FireFox, Safari, etc) is required in order to access some other functionality/content? What I am getting at is that I don't think users care one iota about how their various apps/content are built, etc., so long as all are relatively stable, responsive, and simple enough to use. The rendering-engines in the browsers are what should be important (to users), and that's about it. So long as a browser renders the content of a site/app correctly, I doubt if any user could care less if the underlying scripting language (that augments the HMTL/CSS layout engine and standards) is Dart, JS, Forth, Modula-2, or Assembler... it is irrelevant to me and to most users. As a developer, I can choose whatever works best for me so long as the user has a simple way to use my site/app.

I think that arguing for "backwards compatibility" with JS is also nearly a pointless endeavor.  Users will not care so long as they are appropriately prompted to access content with the required "app" (Dartium, etc) and provided with a way to get that app.   Think about all the websites of old that had links for downloading the Adobe Flash Player that was needed to view content: and, guess what... people did, and did so in a huge way!  Flash became ubiquitous on the web.  Flash provided people with an improved user experience (well, "improved" if you like all those animations that is).  So, if Dart (or some yet-to-be-known technology) offers such an improvement, trust me: people will download Dart, Dartium, whatever in order to experience it! Games certainly come to mind: give gamers a higher frame refresh-rate that is only available through native Dart apps, and a whole group of Dart-aficionados will emerge.  Gamers could give a crap about whether their web-UI or app is "backwards compatible" with JS.  And, do you really think business-applications will be much different?  The only substantial challenge I see is mainstream public-facing web sites, but so what... that will come later.

Is Dart the Future of Web Programming?

Maybe.  I personally think JavaScript is likely ALREADY DEAD (its fate sealed), though there will undoubtedly be many people that will argue til the end that it is not (even beyond Brendan E.), as efforts like asm.js try to keep it alive.  And, regarding asm.JS, I like the comment left by an "EricomGuy" on Brandon's blog, stating:

"[...] 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."

I think those are valid points, but moreover I think asm.js is a ridiculous attempt to decorate JS in such a way as to bring Dart's formal language features and benefits into JavaScript instead of simply admitting Dart is the correct way to truly "fix" JS.  I am amazed how long the JS language has held on, and it is starting to remind me of M (alternatively "MUMPS") or other such languages.  Like M, it is bound to hold on a long, long time, but I expect Dart, TypeScript, or some other languages/approaches to start whittling away JS's ubiquity, and soon.  In a way, I see asm.js as a JS version of Intersystems Cache's answer to the shortcomings of MUMPS (and, a way to extend the life of a language and technology that needed a major overhaul.  Don't analyze this comparison too deeply — I realize there are many differences — but, some similar history may come to pass.

Thinking a bit further ahead...

I suspect the Dart-vs-JS discussion is just a total myopic distraction that may obscure us from recognizing the emergence of much more substantial and possible paradigm-shifts (much more disruptive than Dart, asm.js, etc.) that could hit "browsers" and web-based apps in general.  Dart is a welcome nice natural step forward, and one that should have come much sooner.  But, as I contemplate the incredible growth in network bandwidth and processing power and then extrapolate what things may look like in perhaps a mere 10 years or less,... this Dart vs. JS language-choice discussion may look ridiculous in hindsight.  Some company is going to upend things in a way that a simple browser-language/VM change cannot.

I put forth part of a vision of things to come, as I saw it, in a 2006 blog of Software Prognostications (my upcoming sentences will perhaps be more meaningful after reading that), and part of what I foresaw then has come to be since, but things are not yet completely to where I envision them going.  I saw "apps" coming a long time ago.  And in a way, the modern browser(s) have become, to a lesser extent, the "virtualization" environments that I was expecting on the client — they offer at least some degree of sand-boxing and isolation for security (though hackers still find these too easy to break out of) — and, with the advent of the Dart-VM in a browser, or the V8-JS engine in a browser, or SpiderMonkey or any other language-processor in that browser-encapsulated-virtual-environment-for-rendering-HTML/CSS, things are getting closer to what I had hoped for.  I want the option to deploy my web apps using whatever tech-stack makes the most sense, and I want it to be super simple to do.

As I see it, the only thing the distributed client device needs is a hypervisor / hardware abstraction layer and the ability to interact with and "navigate" the web (i.e., find a URL to pull a VM from) and a way to very nicely isolate/sandbox this stuff.  Essentially, I am waiting for the day when end-users have the equivalent of a bare-bones VMware ESXi-like Web-Meta-OS on their devices and that each "site" or connected "app" is pushed down as a VM image immediately when someone navigates to it (perhaps persisted and used by multiple sites too, where it makes sense — as would a common "basic backwards-compatible JS/Dart web browser VM" would be for a while. heh),... and each VM may contain the "optimal software stack" (as determined by the creator/publisher) for its purpose, and that stack may be a minimalist-Linux with Dartium or Firefox or FutureFox or whatever, or perhaps a proprietary OS with custom apps written in god-knows-what.

Cloud-hosting may minimize what all "needs" to be downloaded to the client like this, and for applications that absolutely must run "on the client", my vision may well require a network backbone based on quantum entanglement and zero-latency-at-arbitrary distances, but I suspect that is coming too.  Fact is, Intel and other hardware makers are going to have to figure out some way to keep distributed computing-power a "must have" thing.   So, I have to bet on the further increase in computing power coupled with every-cheaper and ample storage too.

But, I can picture the day where particular to a website/app, the user gets a VM fully loaded and optimized for that site/app, be it browser-based (or maybe even an entire Windows 12 or OSX-15 application), ready-to-go, fully-isolated/secure, and so on.  If that VM is running a Delphi XE5 app on Windows 9, so be it.  If it is a browser-based app written in Dart that requires Dartium, great.   If it is asm.js or JS "classic", fine.  So long as users don't have to know anything the internals of the app, and so as a developer I can choose to write my sites/content/apps in whatever language/stack I choose, great!

In the mean time....

Bottom Line: Embrace Dart (or even TypeScript)

For now: Dart wins, hands down over JS!  TypeScript is a fine improvement too.  And, I'll be darned if I am going to waste time on asm.js — that just sounds nuts (my opinion).  I see asm.js as nothing but a workaround for embracing something like Dart and the DartVM in browsers in order to prop up the JS "side" of this debate.  But, maybe that asm.js code will be more easily and automatically converted to proper Dart-language or TypeScript code by automation tools down the road?  (perhaps there will be value in it after all).

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.