Forgot your password?
Programming News

TypeScript: Microsoft's Replacement For JavaScript 488

Posted by samzenpus
from the no-code-on-the-block dept.
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).
This discussion has been archived. No new comments can be posted.

TypeScript: Microsoft's Replacement For JavaScript

Comments Filter:
  • by turgid (580780) on Monday October 01, 2012 @05:36PM (#41518539) Journal

    JavaScript programs are TypeScript programs.

    'Nuff said.

    and it isn't good for C# developers who now have confirmation that Ander Hejlsberg is looking elsewhere for his future.

    It's C++ all the way down!

  • by Bill, Shooter of Bul (629286) on Monday October 01, 2012 @05:38PM (#41518565) Journal

    Dart, obviously. But what is the other one? Anyone know what the article writer was talking about?

  • by superflit (1193931) on Monday October 01, 2012 @05:41PM (#41518599) Homepage

    I am still busy with silverlight...

    Oooppss. that did not work....

  • by thetoadwarrior (1268702) on Monday October 01, 2012 @05:42PM (#41518613) Homepage
    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.
  • by RightSaidFred99 (874576) on Monday October 01, 2012 @05:43PM (#41518621)

    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.

    Lol, how cute. You're trying to create FUD.

    • by aztracker1 (702135) on Monday October 01, 2012 @07:04PM (#41519459) Homepage
      What's funny, is that was my first thought as well. It's not like Linus doesn't do anything beyond kernel dev... I mean, we have things Git.. oh noes.. Linus is looking elsewhere, Linux is teh d00med now!

      I do think CoffeeScript is pretty compelling, though I'm not sure how much I like it... a lot of what's in TypeScript is based on efforts with EcmaScript in the past/future, so it lines up a little better. I think there's room for CoffeeScript, Haxe and TypeScript. TS will probably get a bit more traction than Dart, given the tools integration. I do find it very interesting, and refreshing, that the system runs with/under Node.js for the compiler.
  • by catbutt (469582) on Monday October 01, 2012 @05:55PM (#41518745)
    ...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.
  • by logicassasin (318009) on Monday October 01, 2012 @06:02PM (#41518867)

    I'm going to leave this here as a placeholder for the inevitable...

  • by ilsaloving (1534307) on Monday October 01, 2012 @06:03PM (#41518877)

    We already have, what, a couple *hundred* languages to choose from at this point? []

    Can we knock it off with the new effing languages already? Don't these people have anything more useful to do?

  • by Anonymous Coward on Monday October 01, 2012 @06:05PM (#41518901)

    It doesn't replace anything. Its simply a higher level language that compiles to cross-compatible JS. And its open standard to boot.
    Not seeing any negatives about it. JS is a mess and MS is attempting to clean it up.

  • by _8553454222834292266 (2576047) on Monday October 01, 2012 @06:08PM (#41518955)

    to compile my C# algorithms to Javascript. See []. It's by a Microsoft guy so hopefully it gets official support some day.

  • by Nyder (754090) on Monday October 01, 2012 @06:11PM (#41518969) Journal

    Sticking with C.

    How many computer languages do we need? Really?

    It's bad enough that you don't trust javascript from webpages, now i have a new type not to trust?

    Microsoft, i don't trust you, never have. fuck typescript, fuck Windows 8, and well, fuck you.

  • by QX-Mat (460729) on Monday October 01, 2012 @06:52PM (#41519347)

    As a cocoa programmer tasked with implementing yet another embedded htmlfucking5 project thanks to Adobe Edge, I wish Javascript would die.

    After looking at the myriad of patterns for my current project - a Javascript client REST API - I came to the swift conclusion that most of them are silly, namespace polluting, self initializing mindfucks. I gave up looking at patterns, found a preloader (lab.js - although require.js is looking good) and wrote my own module pattern objects to satisfy the clarity, structure and ease of maintenance requirements of a good API. Being verbose is not a sin in enterprise Javascript.

    I have a lot of little helpers like this:

    MyCompany.fetchSomething(function (things) { // actually gives you things

    Plus some event handlers

    MyCompany.addEventHandler('scope', function (data) { // handler

    But by far the largest section of my code is the model fetching stuff - you know the really boring bits where copy by value doesn't cut it, I need functions and and objects.

    My last trail by fire was a paginated e-book reader with support for embedded video and audio. That wasn't a lot of fun, but at least the CSS3 spec was helpful and the DOM readable. The Javascript in that project was limited to around 200 lines.

    I recently discovered that REST libraries are pretty long winded - after 200 or so lines, Javascript becomes a horrible implementation specific mess of spaghettied anonymous function chains. I opted for the Module pattern and ran into lots of fun:

    1. I have to write all my getters and setters, as properties/getters/setters
    2. Variable lifting/elevating results in seriously ugly var blocks at the top of my functions and causes copy by value in some rather obvious block scopes
    3. Fast enumeration (for x in a) doesn't work
    4. Itterating through ordered keys is painful with associated hashes - you have to create a key enumerator (with pushes! ) each time you want order. jQuery doesn't particularly help.
    5. Everything runs on the same thread.
    6. Post increments don't work in for loops, for (i = 0; i
    7. Prototypical inheritance is pointless key bashing - it pollutes your vision with the use of 'self' everywhere god forbid you miss a one.
    8. Inheritance is a dirty word unless you've already written things in a special way (prototype extension is just a dirty hack!)
    9. Given a lack of compile stage, writing code is error prone and debugging a tiresome line by line experience
    10. Chained async callbacks are inflexible, hard to read and painful to edit. Expanding ajax piped promises to a colleague made him cry and take a week off sick.
    11. Everything has to be a fucking DOM element before jQuery/the DOM will play nice
    12. Preloading code, initializing it and handing off to that code is painful/ugly with self initializing modules.

    So with MS actually targeting 5 or more of the annoying problems I face, I find this library really useful. But naturally I'll get modded down because, a) I develop Apple software and b) I don't pick sides, I program (I like Windows 7 as my desktop, XCode as my IDE, and Slackware on my shell - go fish!).

    Oh well, I can only dream of this being adopted!

  • by John Bokma (834313) on Monday October 01, 2012 @06:59PM (#41519411) Homepage
    Playground doesn't work :-( Tested in Firefox and Chrome.
  • by devent (1627873) on Monday October 01, 2012 @08:49PM (#41520413) Homepage

    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.

"But this one goes to eleven." -- Nigel Tufnel