9 ms·

TypeScript: New Compiler and Moving to GitHub

212 points by hekul 12y ago

untog 12y ago
The move to Github is interesting. I'm wondering if this is harbinger of Codeplex's doom very soon.
- lbotos 12y ago
  The flip-side to that could be trying to bring the food to the fish so to speak. Github users are in their (perceived) target market.
- kyriakos 12y ago
  This is part of the new face of Microsoft. They realised that they are losing their followers in the developer community by sticking to their old ways. They've been 'listening' to the public opinion a lot lately.
  - BigChiefSmokem 12y ago
    I just got off the phone with a recruiter who offered me a chance at a Ruby job based on my ASP.NET experience because, quote "they have a lot of old C# guys there and they're willing to train anyone willing to cross over". This means I can make a lateral (stack) move without having to revert back to "junior" status. Hey, I love me some C# and .NET but the offers from the open-source community are just too tempting. I booked an interview.
    - cobalt 12y ago
      why not get them to move to asp.net maybe or at least something more like it
      - untog 12y ago
        Why not turn up at a Ruby shop and try to get them to convert to ASP.NET? As a former .NET dev... why would you even want to do that?
    - _random_ 12y ago
      Isn't Ruby considered a passing technology nowadays?
      - chc 12y ago
        Isn't just about everything? Hypothesis: For any language X, there exist articles claiming either "X is too immature for real-world use" or "X is no longer a good choice for new development".
        julien_c 12y ago
        Not an exclusive OR though :)
        Pacabel 12y ago
        Ruby on Rails is somewhat of a special case, though. Early web technologies like CGI, PHP, JSP, ColdFusion, ASP and ASP.NET arose due to real-world needs. Ruby on Rails, on the other hand, arose mainly due to hype. From a technological perspective, there really wasn't anything special about Ruby on Rails. Many of us who had been doing web development for some time had already built or used proprietary/in-house frameworks that offered the same functionality, but were written in Perl, Python or Tcl instead. If it weren't for strong and very loud personalities within the Ruby on Rails community, combined with some very lucky timing with respect to the rise of the so-called "Web 2.0", it likely wouldn't have been seen as "special", and wouldn't have garnered the hype that it did. Technologies that come out of an environment of hype, rather than solving real problems, tend not to stick around as long. Systems built using technologies that solve real problems continue to be used and maintained. Systems built using technology chosen purely because some manager or executive saw a webcast full of nice-sounding buzzwords tend not to survive very long.
        chc 12y ago
        The idea that Rails' popularity came from managers hearing buzzwords doesn't match my recollection of history. Rails' early support came from backend web developers who hated working in enterprise Java frameworks. Ruby on Rails offered them a pleasant and easy-to-jump-into alternative to that environment. I remember Pythonistas at the time raised similar complaints about how Python already had all this stuff — but the thing is, Rails did a nice job of packaging it up in a way that was easy for disaffected Java jockeys to get into and start having fun, while the Python approach at the time was more along the lines of "take this thing and that thing — or maybe one of these five other things, we can't decide — then make this other piece yourself and stick them together with chewing gum." Rails did come to prominence largely through social channels rather than technical superiority, but it wasn't a marketing-driven hype train targeted at nontechnical managers — it appealed to hackers who wanted to have fun but did not already have a homebrew Perl stack at the ready. That's how I remember it, anyway.
    - MichaelGG 12y ago
      Shouldn't this be expected? Hire people based on intelligence and capability, not necessarily for knowing a particular language or APIs.
    - UK-AL 12y ago
      "This means I can make a lateral (stack) move without having to revert back to "junior" status. " - Good. Because developers would reset or be unemployed every 5 years otherwise. I've made several stack switches without issue. Usually it involves switching languages at your current company, then using your current salary as leverage to get the next. The main barrier is HR, which you can get around using this method.
  - shurcooL 12y ago
    Yeah, this is awesome and it's making me jealous. I'm still dreaming of a world where one day Google will announce that golang source code is moving to git and GitHub.
- felixrieseberg 12y ago
  Truth be told, CodePlex is fairly popular in the .NET world. TypeScript simply is a JavaScript project, plays well with Node, NPM and Jake - I think it makes sense for it to be on GitHub. It's not the first MSFT source base hosted on GitHub, probably won't be the last. Heck, I work at MSFT and keep all my open source code on GitHub. I wouldn't read too much into that though - huge company, a bunch of projects and different audiences. CodePlex has an audience - there's a bunch of cool projects on there, too.
  - yellowapple 12y ago
    > It's not the first MSFT source base hosted on GitHub It is, however, the only repo under the "Microsoft" GitHub user AFAICT (https://github.com/Microsoft https://github.com/Microsoft).
    - felixrieseberg 12y ago
      True - but remember, there's a bunch of teams building stuff. Most of Open Tech's and Azure's open code bases are on GitHub. TypeScript isn't the biggest MS project on GitHub and I just want to make sure that nobody is using this as a "CodePlex is dead!" data point. https://github.com/MSOpenTech https://github.com/MSOpenTech https://github.com/Azure/ https://github.com/Azure/
      - rl3 12y ago
        Not to mention ASP.NET vNext and related projects: https://github.com/aspnet/ https://github.com/aspnet/
        spankyj 12y ago
        And WinJS https://github.com/winjs/winjs https://github.com/winjs/winjs
        mattpodwysocki 12y ago
        And the Reactive Extensions for all languages: https://github.com/Reactive-Extensions/ https://github.com/Reactive-Extensions/
kyriakos 12y ago
This is great news. Typescript compiler's slowness negatively affected my work flow. Hopefully 5x is fast enough.
- ashcairo 12y ago
  I haven't used Typescript yet, but I'm very keen on it. How fast is the compiler currently for you? (eg. seconds or minutes?, and how big is your codebase? (eg. 10k or 100k?)
  - cogware 12y ago
    On a 7kloc codebase it was around 3 seconds before the new compiler, seems to be about 1 second after.
    - Arnavion 12y ago
      I haven't tried the new compiler yet, but note that a lot of the compiler's slowdown comes from parsing lib.d.ts each time it's invoked. So the time taken for compiling X lines of code doesn't scale in a linear fashion - a helloworld will probably take a long time for you to compile too, but remove the dependency on lib.d.ts and the same helloworld will compile very much faster.
  - elpool2 12y ago
    I have a Typescript project with over 200k loc and over 200 ts files. The current compiler takes a while to build the whole project, but still under 10 seconds. However, you can also set it up to compile when you save a single ts file, which is much faster. So in practice its not any slower than what I was doing with Javascript, which was hit ctrl-S to save my changes then quickly hit refresh in Chrome to test and debug.
mkozlows 12y ago
The negative/cynical take: They're rearranging their internal deck chairs and spending time and effort on making their code pretty, rather than changing TypeScript (maligned, little-used, and little-loved) to be more relevant somehow. I have no doubt that the slowness is a major complaint they get from TypeScript users, but at their current level of success/failure, they probably should be listening more to TypeScript non-users than users.
- cpeterso 12y ago
  A project having enough time to schedule big rewrites (instead of new features) is often a bad sign.
  - mkehrt 12y ago
    I'm not sure that makes sense for typescript. It's aiming to be a very conservative extension of JS. Adding new features moves away from that goal.
- nimish 12y ago
  TypeScript is heavily used inside Microsoft. The Azure preview portal is mostly typescript. I suspect they had this in the works for a while and couldn't make build.
nawitus 12y ago
Good news. Compiler performance is pretty horrible at scale. I hope that they implement in-memory compilation, so that the compiler can work properly with Gulp (which would also increase build times). I also hope that they'll support automatic generation of ambient external declaration files. TypeScript doesn't work well with npm modules just yet because of that.
- benjaminjackman 12y ago
  The really slow compiler performance was quite surprising. I switched back to coffeescript (then eventually switched to ScalaJs where they are much faster) because they were so long.
  - frowaway001 12y ago
    Having tried using JavaScript and TypeScript, I settled with Scala.js, too. Stuff just worked better on all accounts: Language, tooling, fast compilation, good error messages, not having to touch JavaScript-related mess, etc.
- SanderMak 12y ago
  About TypeScript+Gulp: I was using gulp-tsc, but switched to gulp-type (https://www.npmjs.org/package/gulp-type https://www.npmjs.org/package/gulp-type). It offers incremental compilation and you can disable chasing through all references in the sourcefiles (since with Gulp you already provide all sources in the stream). This sped up our re-compilation times three-fold.
- Arnavion 12y ago
  >I hope that they implement in-memory compilation, so that the compiler can work properly with Gulp In-memory compilation already exists. I wrote a Gulp wrapper for TS for my own project [0] that supports both normal compilation and incremental compilation (i.e., watch functionality). The real issue with TS is that it doesn't export a programmable compiler API by default, necessitating either a process.exec to the shell script or adding an export statement using the vm module. I gather that was a low priority for the devs because they wanted to get the compiler API in shape first. [0] https://github.com/Arnavion/libjass/blob/master/gulplib/typescript.js https://github.com/Arnavion/libjass/blob/master/gulplib/type...
lennel 12y ago
The closure compiler is also pretty slow, a way around it is to keep a warm jvm and compile that way (70% performance increase over time). I assume a similar strategy is not possible for typescript, which is a pity. Typescript seems pretty cool, lack of dead code analysis and the inability to write my own compiler passes (I have looked for this, but it does not seem to be an option - would love to stand corrected) puts me off it.
phase_9 12y ago
Slightly off topic, but can anyone share a link to a large, well designed (open-source) codebase written in TypeScript? Github incorrectly/mistakenly tags C projects at TypeScript thanks to the `.ts` files present (thanks for picking a unique TLA Microsoft ;) [0] https://github.com/trending?l=typescript https://github.com/trending?l=typescript
- cpeterso 12y ago
  Mozilla's Shumway replacement for Flash uses TypeScript. Shumway's TypeScript translates ActionScript to JS. The Shumway team chose TypeScript for a few reasons. TypeScript's syntax is pretty close to ActionScript's, which simplifies the mapping from ActionScript to Shumway's implementation of Adobe's Flash APIs. Using three languages (AS, JS, and TS) also helps enforce modularity between the content (AS), compiler, runtime, and JITted (JS) code. https://github.com/mozilla/shumway/ https://github.com/mozilla/shumway/
- cogware 12y ago
  Check out Plottable (https://github.com/palantir/plottable/ https://github.com/palantir/plottable/). It's an open source library for data viz / charting, written as a layer on D3, and it's developed in Typescript. They have a mostly incomplete Github page here (http://palantir.github.io/plottable/ http://palantir.github.io/plottable/) with a tutorial (http://palantir.github.io/plottable/tutorials/ http://palantir.github.io/plottable/tutorials/)
- tlarkworthy 12y ago
  This beta product for a firebase security compiler is written in typescript (by me) for node.js https://github.com/firebase/blaze_compiler https://github.com/firebase/blaze_compiler Typescript has been a joy to develop in. The codebase is a mix of typescript and plain JS for some of the parsing. There are a few interesting architectures patterns like a work around for no subclassing of Error by wrapping an error with a backwards chained decorator https://github.com/firebase/blaze_compiler/blob/master/src/error.ts https://github.com/firebase/blaze_compiler/blob/master/src/e... (thanks to mindplay for that idea here https://typescript.codeplex.com/discussions/465345 https://typescript.codeplex.com/discussions/465345) That product is still in it's infancy so gradually being refactored towards full modularisation, so its still a work in progress. FYI: I use pycharm with the node.js plugin, and typescript compiles in the background without intervention, and I can step debug the program, and the line at the top off all the files transparent changes the stack traces back into TS.
cogware 12y ago
I'm excited by this. I think that moving to Github will help the image problem Typescript has and make it a little more accessible, and it's actually a very useful + powerful technology. Compiler errors on refactors are great :)
mixonic 12y ago
And while they move, they are filing issue bankruptcy. 574 open issues exist for TypeScript on Codeplex. https://typescript.codeplex.com/workitem/list/basic https://typescript.codeplex.com/workitem/list/basic "Please note: since we’re moving to a new issue tracker and a new codebase, we are not copying all issues over. If you have issues in the current CodePlex issue tracker, please try them against the new codebase and file them in the GitHub issue tracker if they still repro." Github is back up to 117. Managing an open source community is something that the TypeScript leadership still have yet to learn. They weren't concerned about coordinating with TC39 on module syntax (they shipped 1.0 with an arbitrary snapshot), they were never very interested in accepting code, and they don't value the time users take to document bugs and edge cases. tl;dr the move to Github is lipstick on a pig. It is a distraction from the real changes they must make on order to collaborate well with others.
- skybrian 12y ago
  Many high-profile open source projects have far more bug reports than they know what to do with. Declaring issue bankruptcy and asking people to re-test with a new version is annoying from a customer service point of view, but looked at another way, it's a scalable way for the community to help. Cut and paste (or better yet, summarize the conversation) isn't so hard if it's still a real issue.
  - frowaway001 12y ago
    Or ... TypeScript developers could just have added test cases to their test suite and figure out automatically whether the new implementation fixed things or caused regressions.
    - hvs 12y ago
      "just adding test cases" is not a free act. It requires work on the developers part.
      - frowaway001 12y ago
shadowmint 12y ago
I know there's this 'dont host on github' ethic from some people, but it's undisputable that it lowers the barrier to entry for contributions. I cant speak for anyone else but on github I will now almost always submit a pull request for a fix instead of filing bugs. Great move for typescript~
rgawdzik 12y ago
Seeing Microsoft on Github feels like some weird parallel universe.
waitingkuo 12y ago
Moving to GitHub!!?? As a open source project, at least it's on the right track now!
Kiro 12y ago
How is TypeScript compiled? I only find .ts files in the repo.
- sanxiyn 12y ago
  TypeScript is bootstrapped. Precompiled version of TypeScript compiler is at bin/tc.js.
doczoidberg 12y ago
Great to see typescript evolving. It's a nice approach developing software for browsers. Now we need tools bringing the bits (angular, breezejs, typescript etc) together.
tkubacki 12y ago
I still think - Dart is a better response to JS issues: a) good SDK and package system (pub.dartlang.org) b) clean break from JS (what if future JS will be incompatible with current TS ?) c) perf - realted to b) you can't eg. add property on the fly accidently and will not get perf penalty for this d) proper IDE for ALL mainstream OSes (vs. best IDE on Windows and substandard on OSX/Linux => various plugins)
- nailer 12y ago
  Never heard anyone say Dart's package system is better than NPM. Latency makes Eclipse unusable on every machine I've tried, including a current Haswell MBA with 8GB RAM and a half terabyte SSD. Also: how many web developers do you know that use Eclipse?
  - tkubacki 12y ago
    >Never heard anyone say Dart's package system is better than NPM neither do I - just say Dart has good dedicated (npm is for JS AFAIK) package system >Latency makes Eclipse unusable on every machine I've tried It's not as good as lets say IntelliJ (best IDE I've ever seen) but it's "good enough" Besides - it seems long term goal for Dart team is chromedeveditor https://github.com/dart-lang/chromedeveditor https://github.com/dart-lang/chromedeveditor (another point for Dart it's open source) which will be pretty fast when DartVM will come to Chrome
    - nailer 12y ago
      Trying Chrome Dev Editor I'm impressed - but generally, I don't think new languages should require new editors - better plugins for existing popular ones. I use Sublime, it's configured how I like, they can add the Dart AST for autocomplete etc to provide tab completion, renames, method lookups etc. if they want to.
      - spankalee 12y ago
        We're working on exactly that - it involves making the Dart analysis engine run as a standalone server that that talk to different editors and provide code-completion, errors & warning, etc.
Aardwolf 12y ago
In the playground, the following: class Greeter { greeting: string; constructor(message: string) { this.greeting = message; } greet() { return "Hello, " + this.greeting; } } Compiled to the following: var Greeter = (function () { function Greeter(message) { this.greeting = message; } Greeter.prototype.greet = function () { return "Hello, " + this.greeting; }; return Greeter; })(); So I have a question about this: what is the reason why it doesn't become the following instead? function Greeter(message) { this.greeting = message; } Greeter.prototype.greet = function () { return "Hello, " + this.greeting; }; In other words, why is the extra function put around it? There must be a good reason... Thanks!
- coldtea 12y ago
  It's a closure, so stuff doesn't escape unless it's explicitly returned. It doesn't seem to be needed here, but their transpiler could use the same structure for more evolved classes/module too, where it would make sense.
- Too 12y ago
  Check the modules sample, there a module is passed as argument to the self executing function to which the newly created Greeter class is added, without leaking any temporary Greeter variables to the global namespace. I guess it's just designed to generate as similar code as possible for both the module and non-module cases.

212 points by hekul 12y ago

untog 12y ago

The move to Github is interesting. I'm wondering if this is harbinger of Codeplex's doom very soon.

lbotos 12y ago
The flip-side to that could be trying to bring the food to the fish so to speak. Github users are in their (perceived) target market.
kyriakos 12y ago
This is part of the new face of Microsoft. They realised that they are losing their followers in the developer community by sticking to their old ways. They've been 'listening' to the public opinion a lot lately.
- BigChiefSmokem 12y ago
  I just got off the phone with a recruiter who offered me a chance at a Ruby job based on my ASP.NET experience because, quote "they have a lot of old C# guys there and they're willing to train anyone willing to cross over". This means I can make a lateral (stack) move without having to revert back to "junior" status. Hey, I love me some C# and .NET but the offers from the open-source community are just too tempting. I booked an interview.
  - cobalt 12y ago
    why not get them to move to asp.net maybe or at least something more like it
    - untog 12y ago
      Why not turn up at a Ruby shop and try to get them to convert to ASP.NET? As a former .NET dev... why would you even want to do that?
  - _random_ 12y ago
    Isn't Ruby considered a passing technology nowadays?
    - chc 12y ago
      Isn't just about everything? Hypothesis: For any language X, there exist articles claiming either "X is too immature for real-world use" or "X is no longer a good choice for new development".
      - julien_c 12y ago
        Not an exclusive OR though :)
      - Pacabel 12y ago
        Ruby on Rails is somewhat of a special case, though. Early web technologies like CGI, PHP, JSP, ColdFusion, ASP and ASP.NET arose due to real-world needs. Ruby on Rails, on the other hand, arose mainly due to hype. From a technological perspective, there really wasn't anything special about Ruby on Rails. Many of us who had been doing web development for some time had already built or used proprietary/in-house frameworks that offered the same functionality, but were written in Perl, Python or Tcl instead. If it weren't for strong and very loud personalities within the Ruby on Rails community, combined with some very lucky timing with respect to the rise of the so-called "Web 2.0", it likely wouldn't have been seen as "special", and wouldn't have garnered the hype that it did. Technologies that come out of an environment of hype, rather than solving real problems, tend not to stick around as long. Systems built using technologies that solve real problems continue to be used and maintained. Systems built using technology chosen purely because some manager or executive saw a webcast full of nice-sounding buzzwords tend not to survive very long.
        chc 12y ago
        The idea that Rails' popularity came from managers hearing buzzwords doesn't match my recollection of history. Rails' early support came from backend web developers who hated working in enterprise Java frameworks. Ruby on Rails offered them a pleasant and easy-to-jump-into alternative to that environment. I remember Pythonistas at the time raised similar complaints about how Python already had all this stuff — but the thing is, Rails did a nice job of packaging it up in a way that was easy for disaffected Java jockeys to get into and start having fun, while the Python approach at the time was more along the lines of "take this thing and that thing — or maybe one of these five other things, we can't decide — then make this other piece yourself and stick them together with chewing gum." Rails did come to prominence largely through social channels rather than technical superiority, but it wasn't a marketing-driven hype train targeted at nontechnical managers — it appealed to hackers who wanted to have fun but did not already have a homebrew Perl stack at the ready. That's how I remember it, anyway.
  - MichaelGG 12y ago
    Shouldn't this be expected? Hire people based on intelligence and capability, not necessarily for knowing a particular language or APIs.
  - UK-AL 12y ago
    "This means I can make a lateral (stack) move without having to revert back to "junior" status. " - Good. Because developers would reset or be unemployed every 5 years otherwise. I've made several stack switches without issue. Usually it involves switching languages at your current company, then using your current salary as leverage to get the next. The main barrier is HR, which you can get around using this method.
- shurcooL 12y ago
  Yeah, this is awesome and it's making me jealous. I'm still dreaming of a world where one day Google will announce that golang source code is moving to git and GitHub.
felixrieseberg 12y ago
Truth be told, CodePlex is fairly popular in the .NET world. TypeScript simply is a JavaScript project, plays well with Node, NPM and Jake - I think it makes sense for it to be on GitHub. It's not the first MSFT source base hosted on GitHub, probably won't be the last. Heck, I work at MSFT and keep all my open source code on GitHub. I wouldn't read too much into that though - huge company, a bunch of projects and different audiences. CodePlex has an audience - there's a bunch of cool projects on there, too.
- yellowapple 12y ago
  > It's not the first MSFT source base hosted on GitHub It is, however, the only repo under the "Microsoft" GitHub user AFAICT (https://github.com/Microsoft https://github.com/Microsoft).
  - felixrieseberg 12y ago
    True - but remember, there's a bunch of teams building stuff. Most of Open Tech's and Azure's open code bases are on GitHub. TypeScript isn't the biggest MS project on GitHub and I just want to make sure that nobody is using this as a "CodePlex is dead!" data point. https://github.com/MSOpenTech https://github.com/MSOpenTech https://github.com/Azure/ https://github.com/Azure/
    - rl3 12y ago
      Not to mention ASP.NET vNext and related projects: https://github.com/aspnet/ https://github.com/aspnet/
      - spankyj 12y ago
        And WinJS https://github.com/winjs/winjs https://github.com/winjs/winjs
        mattpodwysocki 12y ago
        And the Reactive Extensions for all languages: https://github.com/Reactive-Extensions/ https://github.com/Reactive-Extensions/

kyriakos 12y ago

This is great news. Typescript compiler's slowness negatively affected my work flow. Hopefully 5x is fast enough.

ashcairo 12y ago
I haven't used Typescript yet, but I'm very keen on it. How fast is the compiler currently for you? (eg. seconds or minutes?, and how big is your codebase? (eg. 10k or 100k?)
- cogware 12y ago
  On a 7kloc codebase it was around 3 seconds before the new compiler, seems to be about 1 second after.
  - Arnavion 12y ago
    I haven't tried the new compiler yet, but note that a lot of the compiler's slowdown comes from parsing lib.d.ts each time it's invoked. So the time taken for compiling X lines of code doesn't scale in a linear fashion - a helloworld will probably take a long time for you to compile too, but remove the dependency on lib.d.ts and the same helloworld will compile very much faster.
- elpool2 12y ago
  I have a Typescript project with over 200k loc and over 200 ts files. The current compiler takes a while to build the whole project, but still under 10 seconds. However, you can also set it up to compile when you save a single ts file, which is much faster. So in practice its not any slower than what I was doing with Javascript, which was hit ctrl-S to save my changes then quickly hit refresh in Chrome to test and debug.

mkozlows 12y ago

The negative/cynical take: They're rearranging their internal deck chairs and spending time and effort on making their code pretty, rather than changing TypeScript (maligned, little-used, and little-loved) to be more relevant somehow. I have no doubt that the slowness is a major complaint they get from TypeScript users, but at their current level of success/failure, they probably should be listening more to TypeScript non-users than users.

cpeterso 12y ago
A project having enough time to schedule big rewrites (instead of new features) is often a bad sign.
- mkehrt 12y ago
  I'm not sure that makes sense for typescript. It's aiming to be a very conservative extension of JS. Adding new features moves away from that goal.
nimish 12y ago
TypeScript is heavily used inside Microsoft. The Azure preview portal is mostly typescript. I suspect they had this in the works for a while and couldn't make build.

nawitus 12y ago

Good news. Compiler performance is pretty horrible at scale. I hope that they implement in-memory compilation, so that the compiler can work properly with Gulp (which would also increase build times). I also hope that they'll support automatic generation of ambient external declaration files. TypeScript doesn't work well with npm modules just yet because of that.

benjaminjackman 12y ago
The really slow compiler performance was quite surprising. I switched back to coffeescript (then eventually switched to ScalaJs where they are much faster) because they were so long.
- frowaway001 12y ago
  Having tried using JavaScript and TypeScript, I settled with Scala.js, too. Stuff just worked better on all accounts: Language, tooling, fast compilation, good error messages, not having to touch JavaScript-related mess, etc.
SanderMak 12y ago
About TypeScript+Gulp: I was using gulp-tsc, but switched to gulp-type (https://www.npmjs.org/package/gulp-type https://www.npmjs.org/package/gulp-type). It offers incremental compilation and you can disable chasing through all references in the sourcefiles (since with Gulp you already provide all sources in the stream). This sped up our re-compilation times three-fold.
Arnavion 12y ago
>I hope that they implement in-memory compilation, so that the compiler can work properly with Gulp In-memory compilation already exists. I wrote a Gulp wrapper for TS for my own project [0] that supports both normal compilation and incremental compilation (i.e., watch functionality). The real issue with TS is that it doesn't export a programmable compiler API by default, necessitating either a process.exec to the shell script or adding an export statement using the vm module. I gather that was a low priority for the devs because they wanted to get the compiler API in shape first. [0] https://github.com/Arnavion/libjass/blob/master/gulplib/typescript.js https://github.com/Arnavion/libjass/blob/master/gulplib/type...

lennel 12y ago

The closure compiler is also pretty slow, a way around it is to keep a warm jvm and compile that way (70% performance increase over time). I assume a similar strategy is not possible for typescript, which is a pity. Typescript seems pretty cool, lack of dead code analysis and the inability to write my own compiler passes (I have looked for this, but it does not seem to be an option - would love to stand corrected) puts me off it.

phase_9 12y ago

Slightly off topic, but can anyone share a link to a large, well designed (open-source) codebase written in TypeScript? Github incorrectly/mistakenly tags C projects at TypeScript thanks to the `.ts` files present (thanks for picking a unique TLA Microsoft ;) [0] https://github.com/trending?l=typescript https://github.com/trending?l=typescript

cpeterso 12y ago
Mozilla's Shumway replacement for Flash uses TypeScript. Shumway's TypeScript translates ActionScript to JS. The Shumway team chose TypeScript for a few reasons. TypeScript's syntax is pretty close to ActionScript's, which simplifies the mapping from ActionScript to Shumway's implementation of Adobe's Flash APIs. Using three languages (AS, JS, and TS) also helps enforce modularity between the content (AS), compiler, runtime, and JITted (JS) code. https://github.com/mozilla/shumway/ https://github.com/mozilla/shumway/
cogware 12y ago
Check out Plottable (https://github.com/palantir/plottable/ https://github.com/palantir/plottable/). It's an open source library for data viz / charting, written as a layer on D3, and it's developed in Typescript. They have a mostly incomplete Github page here (http://palantir.github.io/plottable/ http://palantir.github.io/plottable/) with a tutorial (http://palantir.github.io/plottable/tutorials/ http://palantir.github.io/plottable/tutorials/)
tlarkworthy 12y ago
This beta product for a firebase security compiler is written in typescript (by me) for node.js https://github.com/firebase/blaze_compiler https://github.com/firebase/blaze_compiler Typescript has been a joy to develop in. The codebase is a mix of typescript and plain JS for some of the parsing. There are a few interesting architectures patterns like a work around for no subclassing of Error by wrapping an error with a backwards chained decorator https://github.com/firebase/blaze_compiler/blob/master/src/error.ts https://github.com/firebase/blaze_compiler/blob/master/src/e... (thanks to mindplay for that idea here https://typescript.codeplex.com/discussions/465345 https://typescript.codeplex.com/discussions/465345) That product is still in it's infancy so gradually being refactored towards full modularisation, so its still a work in progress. FYI: I use pycharm with the node.js plugin, and typescript compiles in the background without intervention, and I can step debug the program, and the line at the top off all the files transparent changes the stack traces back into TS.

cogware 12y ago

I'm excited by this. I think that moving to Github will help the image problem Typescript has and make it a little more accessible, and it's actually a very useful + powerful technology. Compiler errors on refactors are great :)

mixonic 12y ago

And while they move, they are filing issue bankruptcy. 574 open issues exist for TypeScript on Codeplex. https://typescript.codeplex.com/workitem/list/basic https://typescript.codeplex.com/workitem/list/basic "Please note: since we’re moving to a new issue tracker and a new codebase, we are not copying all issues over. If you have issues in the current CodePlex issue tracker, please try them against the new codebase and file them in the GitHub issue tracker if they still repro." Github is back up to 117. Managing an open source community is something that the TypeScript leadership still have yet to learn. They weren't concerned about coordinating with TC39 on module syntax (they shipped 1.0 with an arbitrary snapshot), they were never very interested in accepting code, and they don't value the time users take to document bugs and edge cases. tl;dr the move to Github is lipstick on a pig. It is a distraction from the real changes they must make on order to collaborate well with others.

skybrian 12y ago
Many high-profile open source projects have far more bug reports than they know what to do with. Declaring issue bankruptcy and asking people to re-test with a new version is annoying from a customer service point of view, but looked at another way, it's a scalable way for the community to help. Cut and paste (or better yet, summarize the conversation) isn't so hard if it's still a real issue.
- frowaway001 12y ago
  Or ... TypeScript developers could just have added test cases to their test suite and figure out automatically whether the new implementation fixed things or caused regressions.
  - hvs 12y ago
    "just adding test cases" is not a free act. It requires work on the developers part.
    - frowaway001 12y ago

shadowmint 12y ago

I know there's this 'dont host on github' ethic from some people, but it's undisputable that it lowers the barrier to entry for contributions. I cant speak for anyone else but on github I will now almost always submit a pull request for a fix instead of filing bugs. Great move for typescript~

rgawdzik 12y ago

Seeing Microsoft on Github feels like some weird parallel universe.

waitingkuo 12y ago

Moving to GitHub!!?? As a open source project, at least it's on the right track now!

Kiro 12y ago

How is TypeScript compiled? I only find .ts files in the repo.

sanxiyn 12y ago
TypeScript is bootstrapped. Precompiled version of TypeScript compiler is at bin/tc.js.

doczoidberg 12y ago

Great to see typescript evolving. It's a nice approach developing software for browsers. Now we need tools bringing the bits (angular, breezejs, typescript etc) together.

tkubacki 12y ago

I still think - Dart is a better response to JS issues: a) good SDK and package system (pub.dartlang.org) b) clean break from JS (what if future JS will be incompatible with current TS ?) c) perf - realted to b) you can't eg. add property on the fly accidently and will not get perf penalty for this d) proper IDE for ALL mainstream OSes (vs. best IDE on Windows and substandard on OSX/Linux => various plugins)

nailer 12y ago
Never heard anyone say Dart's package system is better than NPM. Latency makes Eclipse unusable on every machine I've tried, including a current Haswell MBA with 8GB RAM and a half terabyte SSD. Also: how many web developers do you know that use Eclipse?
- tkubacki 12y ago
  >Never heard anyone say Dart's package system is better than NPM neither do I - just say Dart has good dedicated (npm is for JS AFAIK) package system >Latency makes Eclipse unusable on every machine I've tried It's not as good as lets say IntelliJ (best IDE I've ever seen) but it's "good enough" Besides - it seems long term goal for Dart team is chromedeveditor https://github.com/dart-lang/chromedeveditor https://github.com/dart-lang/chromedeveditor (another point for Dart it's open source) which will be pretty fast when DartVM will come to Chrome
  - nailer 12y ago
    Trying Chrome Dev Editor I'm impressed - but generally, I don't think new languages should require new editors - better plugins for existing popular ones. I use Sublime, it's configured how I like, they can add the Dart AST for autocomplete etc to provide tab completion, renames, method lookups etc. if they want to.
    - spankalee 12y ago
      We're working on exactly that - it involves making the Dart analysis engine run as a standalone server that that talk to different editors and provide code-completion, errors & warning, etc.

Aardwolf 12y ago

In the playground, the following: class Greeter { greeting: string; constructor(message: string) { this.greeting = message; } greet() { return "Hello, " + this.greeting; } } Compiled to the following: var Greeter = (function () { function Greeter(message) { this.greeting = message; } Greeter.prototype.greet = function () { return "Hello, " + this.greeting; }; return Greeter; })(); So I have a question about this: what is the reason why it doesn't become the following instead? function Greeter(message) { this.greeting = message; } Greeter.prototype.greet = function () { return "Hello, " + this.greeting; }; In other words, why is the extra function put around it? There must be a good reason... Thanks!

coldtea 12y ago
It's a closure, so stuff doesn't escape unless it's explicitly returned. It doesn't seem to be needed here, but their transpiler could use the same structure for more evolved classes/module too, where it would make sense.
Too 12y ago
Check the modules sample, there a module is passed as argument to the self executing function to which the newly created Greeter class is added, without leaking any temporary Greeter variables to the global namespace. I guess it's just designed to generate as similar code as possible for both the module and non-module cases.