So there have been a lot of contenders to replace JavaScript, and it hasn't budged from it's market seat at all. Here's why:
You can do almost anything in JavaScript these days. The down side? You can do almost ~anything~ in JS these days. Including lots of stupid things.
Since JS works extremely well for user interaction, and is "good enough" for simple object-oriented programs, it will likely never go away in the foreseeable future in these realms. What I think things like SoundScript are for, is 1) for people who are used to strongly-typed programming languages to feel more comfortable on the web (which is actually pretty important), and 2) for larger OO or enterprise-style systems that really shouldn't have been written in JS in the first place (I'm looking at you Angular).
I wonder if it will end up like Go, though. An interesting language which never gets more than a niche market.
I'm not sure you read the article. "Soundscript" is just a fancy name for "notifying the Javascript interpreter that you promise never to do certain things, thus the interpreter can stop checking for them on every access and the optimizer is allowed to make stronger assumptions". It's not a new language so much as slightly different 100%-backwards-compatible dialect.
It is a way of deliberately putting down some of the often-silly dynamism Javascript provides.
Whether it takes off or not, I can't call it a "contender to replace Javascript" when it is Javascript.
Google are trying to find a direction for web programming. The browsers have made plugins obsolete, but the plugins did bring something that the standard web technologies may have been missing.
What is hard is to change JavaScript from the outside. They may have found that impossible to do. The direction started with asm.js shows that JavaScript needs to change from the inside. JavaScript can be changed and remain largely compatible, but it will not be without the drawbacks. The path started with transpiling and polyfills may help to keep some backward compatibility, for example. :-)
Not all problems can be solved with just 1 technology. It will continue to look more like a mash-up. The challenge is to make it cross-platform. Google have to run ads on those things for it to help with the bottom line.
In my opinion Javascript is on its path to marginalization. Just glancing the recent tooling options for ClojureScript and TypeScript, I'm pretty sure now is the time to start putting your alt-js experience ahead of Javascript on the resume. The syntactical checks are great (typescript ides) or instant feedback (clojurescript figwheel) but for me the killer is the performance optimization over 'raw' Javascript due to compilation optimizations.
Better tooling, better performance, why would I want to go back?
The language of the future includes a Javascript compilation target.
Before you start talking about what to put on your resume, I'd look at what job descriptions are asking for. I haven't seen many asking for ClojureScript or TypeScript yet.
TypeScript (and to a lesser extent CoffeeScript) seem fine to me, but ClojureScript looks very different to JS. I'd always advise someone to learn JS first, then your compiled language of choice.
Which is why I said marginalization. Knowing Javascript is important, but I believe a savvy team will jump on one these languages to turbo charge their productivity.
Possibly, but you can argue the opposite. I've seen a bit of commercial TypeScript and it's been horrific and to me just matched the anything but Web/JS approach I was expecting.
I'd also worry that the TS community itself would risk marginalization, end up as a small niche ghetto, with most of the interesting stuff going on in ES7+.
Hard to be sure but I wouldn't write off JS just yet, people have been doing it for years as new/better (flash/silverlight/compile to JS) technologies have promised to make it seem soooo 90s.
Brendan Eich made the following comment here recently:
" Indeed we had structural types in ES4
toward the end, and almost bluffed
MS into folding (I'm told by a reliable
source). But ES4 was trying for too
much too soon.
At this point we really need to see
ES6/7 and TypeScript + Flow "gene-
culture co-evolution". As I said at the
last TC39 meeting on the topic, big
de-facto standard wins trump rushed
de-jure standards any day.
/be"
and also:
" Type system implementors
and the JS stewards must
communicate well for this to
win. It's looking good so far,
on Ecma TC39: JQuery,
Facebook, Netflix, PayPal
(Ebay originally, and again),
Twitter all represented along
with Apple, Google,
Microsoft, and Mozilla. Also
academic researchers from
various universities, all of
whom love type systems and
theory :-)."
You can do almost anything in JavaScript these days. The down side? You can do almost ~anything~ in JS these days. Including lots of stupid things.
Since JS works extremely well for user interaction, and is "good enough" for simple object-oriented programs, it will likely never go away in the foreseeable future in these realms. What I think things like SoundScript are for, is 1) for people who are used to strongly-typed programming languages to feel more comfortable on the web (which is actually pretty important), and 2) for larger OO or enterprise-style systems that really shouldn't have been written in JS in the first place (I'm looking at you Angular).
I wonder if it will end up like Go, though. An interesting language which never gets more than a niche market.