TypeScript: Microsoft's Replacement For JavaScript
mikejuk writes "Everyone seems to have a replacement for JavaScript — Google even has two. Now Microsoft has revealed that Anders Hejlsberg, the father of C# among other languages, has been working on a replacement and it has released a preview of TypeScript. The good news is that it is compatible with JavaScript — you can simply load JavaScript code and run it. JavaScript programs are TypeScript programs. To improve on JavaScript, TypeScript lets you include annotations that allow the compiler to understand what objects and functions support. The annotations are removed by the compiler, making it a zero overhead facility. It also adds a full class construct to make it more like traditional object oriented languages. Not every JavaScript programmer will be pleased about the shift in emphasis, but the way it compiles to a JavaScript constructor is fairly transparent. At this early stage it is difficult to see the development as good. It isn't particularly good for JavaScript developers who already have alternatives, and it isn't good for C# developers who now have confirmation that Ander Hejlsberg is looking elsewhere for his future."
Update: 10/01 20:34 GMT by U L : It's also freely available under under the Apache 2.0 license, and there's a language specification available. It looks pretty interesting: it even has ML-style type inference (including e.g. deducing the types of higher order functions).
Dart, obviously. But what is the other one? Anyone know what the article writer was talking about?
Well.. maybe. Or Maybe not. But Definitely not sort of.
Sorry..
I am still busy with silverlight...
Oooppss. that did not work....
We have JavaScript and that's shit because no one wants to agree on anything. So what do we get instead? a dozen implementations or something that is in theory nicer but compiles to JavaScript. This is not a solution. It's a mess.
Fix JavaScript or give us something like Python minus the dangerous bits in the browser.
...theirs seems like the right approach. It is certainly a better one than Dart. They've gone out of their way to be as compatible as possible, and really are making it practical for people to adopt the upcoming standards earlier. I really don't see what about this to get so up in arms about. Javascript does need improvements, and this is the best approach to that I've seen so far.
I'm going to leave this here as a placeholder for the inevitable...
Fifty watts per channel, baby cakes.
Rubbish. Not a good view of the technology. You might want to watch the channel 9 video and see how the language works before sounding the war horns. Essentially it's an overlay on javascript code that allows the developer to infer useful information about their code. The output from the "compiler" is bog standard javascript, no microsoft extensions at all.
So if the "carpet" ever got pulled out from under you, all you would do is go back to editing the standard .js directly.
Obligatory: http://xkcd.com/927/
Note: please do not mod this post up.
Note: please do mod this post up
coding is life
Embrace, Extend, Extinguish.
Microsoft freely admits it, and when everyone jumps on the TypeScript bandwagon, the carpet will be pulled out from under you.
How is this shit modded 'Insightful'? Karma whoring at its best, capitalizing on the nerd rage of geeks frothing at the mouth whenever Microsoft does anything. The fact is it is under an Apache 2.0 license, the spec is available and there are already 5 forks, so unless you have a fundamental misunderstanding of what EEE means you're just trolling.
c? to write client-side code run by the browser?
are you high?
I think you are missing the point. While it is good the output is 'bog standard' Javascript what really matters is that the source is not 'bog standard Javascript'. Once you start writing in TypeScript you are forever bound to Microsoft. Now there may be compatible implementations but you may get a situation like C# where Microsoft's implementation is not only the foremost, but also the only complete one.
They did a similar trick in years past with C++, where they had so many extensions that you pretty much needed for Windows development that once you started down their C++ path, forever would it dominate your project's destiny. These days their compiler will accept 'bog standard' C++, however to get real stuff done you still have to start using Windows constructs and interfaces (due to Microsoft producing APIs that look like like 'plain vanilla' C++; as many other APIs try to do).
As others have pointed out, "All the roads lead to Microsoft, but none lead out".
Now Microsofties could complain that the open source proponents are whining unfairly about this and it is resticting their, "Freedom to innovate". To that I say simply this, "How about you instead spend the effort on making your browser work like everyone else's?". The amount of workarounds and hacks required to compensate for the borked and agonizingly slow way that Internet Explorer handles (what should be) cross-platform Javascript is 'criminal'. The wastage in businesses and the entire IT industry caused by handling Internet Explorer's brokenness should make them blush. Sure, innovate and make the Javascript experience the best on Microsoft tools and platforms, but don't do it by creating more 'islands' than you have already.
As others have pointed out, TypeScript may be tech flavor-du-jour for Microsoft at the moment (since they're trying to push their mobile solutions), but just like all their other tech it will have a limited shelf-life. You are better choosing truly cross-platform and long lasting tech for building solutions on. Historical examples: C#.NET (still used widely but not getting the Microsoft focus it once did), Visual Basic, COM/DCOM, OLE, C/C++ Win32 etc etc Yes you can still develop with these, but once upon-a-time they were the shizzle promoted by Microsoft and now people have to spend their time maintaining them with old and outdated tools. Meanwhile solutions developed with Standard C/C++, Java, etc get better tools and there are code changes required to maintain them are far more minor.
Bet your solution on the long-lived tech stacks (and increase your long-term profits!).
Once you start writing in TypeScript you are forever bound to Microsoft.
I see you're unfamiliar with the concept of open source: git clone https://git01.codeplex.com/typescript
The probem isn't so much with C# the language/toolset. The problem is that in order for Microsoft to sell you new tools and tech it has to periodically change them just enough so you feel enough pain to shell out for new stuff. The other problem is that while C# is good for development it is clear that it is no longer an object of adoration in Microsoft's strategy. C# will always be around but it won't get the resources that the 'new hotness' team gets (eg. TypeScript). Meanwhile, those that use other tools (standard C++, Java etc) will keep plodding along, continuously evolving.
If you know Aesop's Tortoise versus the Hare fable then this is what is happening now. Those who always watch the speed of the hare miss the fact that a new hare is entered into the race every few years. Meanwhile, those not distracted by the hare are watching the tortoise and see how it is less flashy but progresses continuously. If you built your tech on the tortoise you still have good solutions. If you build your tech with the hare then every few years you either have to rebuild your tech for the new hare (expensive! this is what CTOs worry about and code-monkeys don't), drop your existing investment and start building again for the new hare (expensive and wasteful), or stay with old tech (painful, and now surpassed by the tortoise).
Just keep calling it "ECMA Script" until it sticks.
For some reason, "ECMA" always makes me think of "ACNE". Now it will for you, too ;-)
You're welcome.
When all you have is a hammer, every problem starts to look like a thumb.
Javascript works well for what it was intended to do: adding dynamic functionality to webpages. It only has problems when it's used for something it was not intended to do like building web-based applications or the Flash-like animations of HTML5. These are very different use cases, and I don't think one language to cover them all is a good idea. Developing new languages for the new web technologies is the way to go.
I know a little bit about compilers.
"Every number is a float" is one of them in JavaScript. "All objects are associative arrays" is another. "Object prototypes are mutable everywhere" is yet another.
Some, yes, but many also come from tracing the flow of data as the program runs to figure out which pessimizations inherent to the semantics of JavaScript it's safe to undo. That's why modern JavaScript JITs work so hard to perform side exits with their guard clauses to produce code that runs in as straight a line as possible. Ask Jim Blandy about it sometime.
Perl would have to do similar optimizations. So would Python. So would Ruby. (It's instructive to talk to the people behind Rubinius and Unladen Swallow, if not people who've spent years optimizing Smalltalk implementations.)
how to invest, a novice's guide
Is it just me or are the MS shills getting even more stupid?
When Apache 2.0-licensed, publicly available (on Git), already forked code is somehow getting you "locked in" and "manipulated to be incompatible" i think it's safe to say the stupidity lies with all the anti MS morons with their senseless EEE rhetoric. Although given you think pointing out that this is about as open as it can get which makes it the exact opposite of "locking people in" is being a "shill" you're probably not much different.
So can we finally have a specification that is not bound to a specific implementation? Why in all what is good and holy, do we need the limitation of JavaScript? Just make a byte-language specification, just like the CLR or Java Byte-Code for the DOM stuff.
Then everyone are free to use Python, Ruby, Java or what else as a language, the browser needs only to interpret the Byte-Code that the language-compiler is producing (just like with Java and javac, where you can use any language you like to produce the Java byte-code).
If you are really worried about open source, then answer me this: What is the difference between this and byte-code? There is none, because both are not human-readable. So why not just to agree to a byte-code that interfaces the DOM and html5 and then we can use any language we like to generate the byte-code?
Wouldn't it be nice to fire up your favorite IDE or editor and just write Python or Ruby (or insert here your favorite language) for your web-page? But no, we just have to use JavaScript until the end of the universe.
PS: most browsers are compiling JavaScript to a byte-language anyway nowadays, because then they can optimize the byte-code so JS will run faster.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
Python 3.3 didn't add a "yield" keyword, it added a "yield from" construct. Python has had "yield" since version 2.2. Python also has type annotations that "don't do anything": http://www.python.org/dev/peps/pep-3107/