I’ve been having an ongoing convo with some of my colleagues (e.g.) at Infragistics about TypeScript as of late. Now by way of preface, I started my professional programming career in ASP, have done more than my fair share of ASP.NET, was an ASP/ASP.NET MVP for years, and an ASPInsider for even longer, so let’s just say I’ve had a ringside seat, as it were, to Microsoft DevDiv’s relationship with the Web over the years. That said, for the last few years, I’ve been more focused on UX and the broader Web community at large, and I’ve spent a lot more time coming at Web dev from the non-MS perspective. So my angle in the discussion is something of a friendly Devil’s advocate.
Let me start by saying that Microsoft wins the overall dev productivity competition hands down. Visual Studio is an absolutely top-notch, amazing IDE, and there really is nothing that can compete with it in the overall category. On top of that, Microsoft has produced some top shelf Web dev tooling over the years. There really is no doubt about that, but there is always room for improvement.
The Web, in particular, presents a very challenging, wild-west environment for tooling. The technologies in themselves don’t lend themselves well to that, and there are all sorts of hacks and workarounds to address the problem, including some produced by Microsoft. To be a guru in Web dev requires mastery of so many different moving pieces and nuances, multiple, not-very-well-defined languages, innumerable libraries and frameworks, and a vast number of potential runtime environments. It’s a hard egg to crack when it comes to productivity tools, not to mention just general dev productivity, defined as time spent actively producing value-adding software assets.
The Problems for TypeScript
In any case, these perceptions are compounded due to various other biases and prejudices against Microsoft, however well or ill founded those may be for any given individual. All that stacks up to a lot working against TypeScript, certainly more than basically any other individual or organization creating a similar solution would face. And then you have folks who:
- are just against any sort of preprocessor (WTF!?)
- really prefer dynamic over static (for whatever reasons)
- feel like this is just one more thing to learn
- are fans of one of the existing quasi-competing solutions
- are well invested in an alternative solution
- are worried about adopting a niche technology, when the whole point of the Web is openness and interoperability
Measuring adoption and market share is always challenging, especially with the Web. However, here are some indicators around TypeScript.
First off, looking at job listings is always interesting in this area. It can tell you what people currently are doing as well as what is in the immediate plans. Numbers were accurate when I wrote this down. 🙂
- TypeScript: (104)
- Angular: (1,684)
- Ember: (828)
- Backbone: (3,195)
- Marionette: (119)
- JQuery: (42,884)
- TypeScript (CodePlex): 1,296
- Angular (GitHub): 13,637
- Ember (GitHub): 7,901
- Backbone (GitHub): 15,507
- Marionette (GitHub): 3,620
- jQuery (GitHub): 23,058
Oh, and that’s another thing–CodePlex? Really? 😉
Language Popularity (GitHub)
I just ran across this today, TOP GITHUB LANGUAGES FOR 2013 (SO FAR). You have to scroll down to the Top 100 lists to see TypeScript. It’s pretty puny. Whether or not this is a “fair” comparison is debatable, but it is just one data point/indicator of current popularity.
This is impossible to reasonably quantify, but I do keep a good eye on Web dev stuff in general, and except for asking “is anyone using TypeScript,” pretty much the only time you see people talking about TypeScript is if they are Microsoft devs or Microsoft employees. Granted, it’s still very young/early, but it is a data point nonetheless.
Even though the solutions compared above are different (language vs framework vs library), the core problems of productivity, maintenance, large scale, and so on are the target for all. The fact is that real, large-scale Web apps have been built and are being built using these technologies as tools to enhance productivity and overall effectiveness. And this is the space that TypeScript competes in.
All this doesn’t paint a pretty picture for TypeScript, so…
What Does TypeScript Need to Be Widely Adopted?
Let’s face it, there are a percentage of Web devs out there who are more or less lost to Microsoft, those who are deeply and irrationally against any and everything that Microsoft does. In a word, haterz. There’s no point in focusing on them, but I honestly don’t think that’s the vast majority. Most devs at heart value technical merit, and most, however altruistic they may be, do have to answer for their productivity and/or simply want to be productive for their own satisfaction.
So that’s the key thing:
TypeScript needs to demonstrate that it makes you significantly more productive.
Forget making claims about it being for apps that are supposedly more complex or larger scale. Forget about inane, academic, ideological arguments about the value of static typing. They smack of arrogance. They inevitably lead to rabbit holes, and they stir up all sorts of irrational passions in otherwise intelligent people. Just stay focused on productivity.
And the thing is, I think the team behind it gets how valuable this is. I mean, Microsoft DevDiv is all about dev productivity. Consider this from Anders shortly after the launch:
Specifically, [Microsoft] wanted to make it possible to create world-class developer tools that would make building large web applications easier, without breaking compatibility with existing browsers and standards. (Source)
Okay then. Let’s see more of the world-class dev tooling built on top of TypeScript!
Oh and ideally, let’s see the great tooling on all of the major desktop OSes. This latter would help a lot to dispel the notion of borgishness and is, IMO, essential to the widespread adoption of Web technologies in general. From a Microsoft business perspective, it makes sense in numerous ways, not the least of which would be as a way to make Azure even more attractive to a broader audience. Of course, you can’t be pushy about that, either, but I’m talking about things like increasing awareness, increasing positive associations (through enhanced productivity), making using Azure that much easier, and so on.