I think Typescript solves a lot of these problems. The type system is amazing, conversions are explicit. Syntax is slightly improved, built-in class system.
The others I don't really mind: I like writing event-loop code over threads, and have never once run into Object.prototype problems in the wild.
I hadn't heard of Typescript, but I think we'll be seeing a lot more efforts along these lines. Despite the pain and inelegance of compiling something to Javascript, I see two inexorable forces that will lead a lot of smart engineers in that direction.
First, running the same UI code on the front-end and back-end will enable the best performing apps across platforms. Imagine being able to run a rich client on a powerful PC that just talks to an API and does all the rendering as a single page app, while simultaneously being able to serve up pure HTML/CSS to mobile devices and search engines. Being able to run code on the server or client as needed solves too many problems to ignore.
But on the other hand, javascript flexibility and lack of type system will inevitably cause problems as the codebase grows unless you have a good lead developer to define standards and an iron-fisted approach to code reviews.
Personally I think coding standards are a stretch with a language as wild as javascript, and a higher level language to enforce certain things is the best way to reconcile these two problems. I can even imagine supplementing with something like (for instance) a Haskell library that lets you generate JS code for interfacing with the back-end in a provably correct fashion, and plugging that into the UI code.
Where have you been hiding? There's been a virtual explosion in the number of languages that compile down to JS[1] in just the past 1-2 years, and TypeScript is probably the youngest of them all. CoffeeScript[2] is another big one, I believe it's much more Ruby-like. There's even 7 projects involving Haskell.
I've been using TypeScript for experimenting with Node.js and while it's a great solution there's a few difficulties some might face with it:
-TypeScript definitions for many libraries, such as express are out of date and require modding to use.
-Visual Studio has no built in support for TypeScript with Node for debugging, but it has been mentioned as likely to be added by the TypeScript team eventually.
-There are third party plugins for Node in Visual Studio for debugging, but none support TypeScript yet.
I've found the best solution thus far is Intellij IDEA or WebStorm, as it has support for both Node and TypeScript.
Almost no one realizes this, but the main purpose of TypeScript is to negate one of JavaScript's greatest advantages which is the lack of typing. This is an advantage because it makes code easier to write and read.
The problem that TypeScript solves is that the web platform is in direct conflict with Microsoft's monopolies in PC gaming and business productivity software (Office). Confusing developers into thinking that JavaScript needs types leads them down the path of statically typed languages, i.e. C# and Microsoft's proprietary and closed .NET Framework and software ecosystem.
I think optional typing is better than no typing. It's useful for allowing APIs to be self documenting. It seems as if optional typing is going to get more and more popular. For example, see Google's optional typing in dart, where they actually recommend to not use types for local variables:
They can. But both tend to get out of date as a codebase develops. It's very useful to have an automated tool that ensures the documentation lines up with the actual code - i.e. a type checker.
The "Open Web" is closed to one single language choice that was made for you by someone else. TypeScript is being developed, because Microsoft adapts to where the world is moving and they are just trying to avert the disaster that will happen when enterprises will actually start trying developing whole applications in JS. And Google is developing a higher-order version language as well. Nobody developed a language to run on top of Java, C#, C++, but there is a plenty of choice for JS: Dart, TypeScript, CoffeeScript etc.
> Nobody developed a language to run on top of Java, C#, C++
Because instead of developing languages to run on top of them, people just designed languages to run on the same platform. The browser environment is a special case where the only common feature of the platform that is available to target is JS, there's no common VM underlying it, so replacements target JS.
Though its worth noting that while it may be true that no one developed a language to run on top of C++, C++ was originally implemented as a language that was preprocessed into C and then fed to a C compiler, much the way that many JS alternatives are compiled to JS and then fed to a JS interpreter.
The primary mechanism for running Dart on the client is by compilation to JS. There is a DartVM that runs Dart directly, but its not bundled into any browsers except for a special version of Chromium ("Dartium") bundled with the Dart SDK so that the development cycle can proceed without a dart2js run at each iteration, but its not intended for general use that way.
the two best features of Typescript's type system IMHO are:
- structural typing for interfaces (which means that classes implicitly implement an interface if the definitions match)
- gradual typing (mainly the ability to convert between 'any' and other types implicitly, which makes it much easier to interact with JS libraries/port JS code to Typescript.)
More generally speaking, Typescript aims to solve the problem of maintaining large codebases by giving you the additional security of static typing. The idea is that many simple errors can often be caught by a compiler, but would be much more time-consuming to find otherwise.
The others I don't really mind: I like writing event-loop code over threads, and have never once run into Object.prototype problems in the wild.