All the way back in 2010 Google realized that JavaScript is a dead end programming language.

Here is what was posted on the com.googlegroups.google-caja-discuss list

Javascript has fundamental flaws that cannot be fixed merely by evolving the

language. We’ll adopt a two-pronged strategy for the future of Javascript:

– Harmony (low risk/low reward): continue working in conjunction with

TC39 (the EcmaScript standards body) to evolve Javascript

– Dash (high risk/high reward): Develop a new language (called Dash) that

aims to maintain the dynamic nature of Javascript but have a better

performance profile and be amenable to tooling for large projects. Push for

Dash to become an open standard and be adopted by other browsers. Developers

using Dash tooling will be able to use a cross-compiler to target Javascript

for browsers that do not support Dash natively.

A new language will be announced at the goto conference named Dart, the keynote will be: Opening Keynote: Dart, a new programming language for structured web programming

Assuming that Dash is now called Dart, here is what it is supposed to do, again according to the posting on the com.googlegroups.google-caja-discuss list

Dash is the leapfrog effort that is designed to be a clean break from

Javascript. It will seek to keep the parts that have made the Internet so

successful, but fill in holes everyone agrees it has.

Dash is designed with three perspectives in mind:

– Performance — Dash is designed with performance characteristics in

mind, so that it is possible to create VMs that do not have the performance

problems that all EcmaScript VMs must have.

– Developer Usability — Dash is designed to keep the dynamic,

easy-to-get-started, no-compile nature of Javascript that has made the web

platform the clear winner for hobbyist developers.

– Ability to be Tooled — Dash is designed to be more easily tooled (e.g.

with optional types) for large-scale projects that require

code-comprehension features such as refactoring and finding callsites.

Dash, however, does not require tooling to be effective–small-scale

developers may still be satisfied with a text editor.

Dash is also designed to be securable, where that ability does not seriously

conflict with the three main goals.

Dash will be designed to be consumed in a number of locations:

– Browser VM — Our aspiration is that Dash will ultimately be a viable

substitute for Javascript as the native client-side language of choice

across all browsers.

– Front-end Server — Dash will be designed as a language that can be

used server-side for things up to the size of Google-scale Front Ends. This

will allow large scale applications to unify on a single language for client

and front end code.

– Dash Cross Compiler — Dash will be designed so that a large subset of

it can be compiled to target legacy Javascript platforms so teams that

commit to using Dash do not have to seriously limit their reach. Platforms

that have a Dash VM can operate on the original Dash code without

translation and take advantage of the increased performance. One of the

ways we will evolve Harmony is to be a better target for such compiled Dash

code.

So far we don’t know much about this new language except for what they say about Dash, we can assume that it will address some of the points that were posted in the list which I shared in this post earlier

Even if this new language is better than JavaScript will all the other browser vendors be on board? Remember that Google launched the Go language last year, what happened to that?

I am skeptical about all of this but of course I could be dead wrong

Time will tell………