
TypeScript: New Compiler and Moving to GitHub - hekul
http://blogs.msdn.com/b/typescript/archive/2014/07/21/new-compiler-and-moving-to-github.aspx
======
mixonic
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.

~~~
greggman
all of that seems true for most repos on github. At least in my experience.
I've spent the last 2 months learning node, checking out npm modules, finding
bugs, seeing the projects abandoned, lots of issue filed, pull requests
ignored, etc.. Maybe I've just been unlucky but this hardly seems like an MS
specific thing?

~~~
Pacabel
I think this is partially due to the informality that many GitHub users tend
to have with respect to managing their projects.

It's rare to see a GitHub-hosted project that offers proper releases, proper
planning for those releases, proper documentation, and the organization and
project management efforts that enable such things.

The lack of such basic project management structure leads to projects that see
very erratic development, or outright abandonment. Many GitHub-hosted projects
are barely more than a hobby, rather than an ongoing concern. Their code may
be somewhat usable, but it's rarely comparable to what we see from more
organized projects.

~~~
watwut
Proper release planning for tiny one man fifteen users project is very little
planing.

Those projects do not get erratic development or get abandoned because they
lack "proper planing". That is reversing cause and effect. They lack heavy
planing because their development depends too much on free time of one or two
people, who have other life priorities. No amount of planning will change
that.

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

~~~
kyriakos
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
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.

~~~
_random_
Isn't Ruby considered a passing technology nowadays?

~~~
chc
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".

~~~
Pacabel
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
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.

------
phase_9
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)

~~~
tlarkworthy
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/e...](https://github.com/firebase/blaze_compiler/blob/master/src/error.ts)

(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.

------
nawitus
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
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
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.

------
tkubacki
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
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
>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
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
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.

------
cogware
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 :)

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

~~~
ashcairo
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
On a 7kloc codebase it was around 3 seconds before the new compiler, seems to
be about 1 second after.

~~~
Arnavion
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.

------
Aardwolf
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
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.

------
lennel
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.

------
doczoidberg
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.

------
shadowmint
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~

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

~~~
sanxiyn
TypeScript is bootstrapped. Precompiled version of TypeScript compiler is at
bin/tc.js.

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

------
rgawdzik
Seeing Microsoft on Github feels like some weird parallel universe.

------
mkozlows
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
A project having enough time to schedule big rewrites (instead of new
features) is often a bad sign.

~~~
mkehrt
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.

