Why does TypeScript have be the answer to anything?

http://www.hanselman.com/blog/WhyDoesTypeScriptHaveBeTheAnswerToAnything.aspx

by andrijac • 14 years ago

94 80 14 years ago

The way I see it:

1. TypeScript is an answer to the poor state of JavaScript development today and an attempt to get more structure into it. There are other answers as well, and it can be discussed on properties of each of them, but they are competing in the same domain.

2. Since state of JavaScript is as it is, it is obvious that there is a lot of potential benefit in being a leader of the technology in that domain. Regarding that, it is kind of answer to forces that are trying to ensure domination in that domain for the future.

dreamdu5t• 14 years ago

Poor state of JavaScript development? By what measure?

I've been doing "application-scale" development using JavaScript for 5 years... Not once did I think "gee my development process would be better if I had rigid typing." The notion is laughable.

The lack of rigid typing and classes is by design. This is a feature not a bug. I honestly wonder about a programmer's understanding of JavaScript if they say things like "JS lacks classes!" - I'm not sure they understand JavaScript.

ajanuary• 14 years ago

The type system in TypeScript isn't 'rigid'. It's both optional and structural. These combine to make it a heck of a lot more lightweight than something like C++ or Java.

The classes in TypeScript are a formalisation of a very common design pattern in Javascript, so obviously people do think it's useful. TypeScript takes the common practice and makes it more succinct. (Other than inheritance, which does seem a little un-JSy)

oinksoft6• 14 years ago

Types are not classes! Why do people feel the need to constantly drag out this scarecrow? Having tools to perform static analysis is nothing but a good thing, and you need type data to do a great deal of this. Perhaps your project requirements are such that you never require type checking for your JS, but I can say that it's saved my ass a number of times when working on very large code-bases, and definitely has sped up my development cycle when working on hairy code.

This is a type, not a class, taken from a Closure Compiler docs annotation example:

  /**
   * Enum for tri-state values.
   * @enum {number}
   */
  project.TriState = {
    TRUE: 1,
    FALSE: -1,
    MAYBE: 0
  };

Now I can require this type in my code with standard JSDoc, which is what the compiler uses anyway for type-checking. It makes my code self-documenting (the Closure Linter, should you use it, will complain if you omit descriptions and the like too, if you find yourself getting lazy):

  /**
   * Do something...
   * 
   * @param state {project.TriState} The state ...
   */
  function doSomething(state) {

If you are documenting your code, you already do this. And now you have static analysis out-of-the-box ... not bad!

winteriscomming3• 14 years ago

You are entitled to your opinion but many developers disagree and want some more structure in the programming model. The very fact that many people are trying so hard to come up with some solution to JS means that there are significant problems worth fixing. If you don't see these problems or have them then that's great for you.

nxn• 14 years ago

To preface, let's say that "application-scale" means something like the following: your server outputs a single html file that only contains references to js files and css (i.e., the minimum to get the app to work right), from then on all data operations are ajax calls to a server side API, while the entire state of the app, all UI/markup components included, is maintained via JS.

I've worked on a couple of these applications, they almost always end up having some fake-class system that provides mechanisms for encapsulation, code sharing, and namespacing. There's often almost a hundred of these fake classes defined with thousands of instances living in memory. I grant you that you can use things like the module pattern to accomplish those requirements -- in fact, if you couldn't, then I wouldn't be here talking about it because I'd be writing Java applets instead. But the lack of having static typing to catch simple errors and enabling basic refactoring tools (like renaming something without having to use a regular expression which took 2 hours to "perfect", or simply switching argument orders, etc) was the absolute worst. I've spent countless hours debugging problems that occurred because something like a string was accidentally passed when an array was expected, and only having the actual runtime error occur 50 function calls later because something like "cat"[0] was working fine up to that point. Static typing would have caught that before I even ran the app.

Anyway, these types of apps perhaps aren't as common as websites, but they exist and therefore there is a need for statically typed languages for the browser.

path4112• 14 years ago

I don't think of lack of strong typing or OO features as a bug either. I think Typescript's approach of optional features added to javascript provides even more flexibility. You can choose specifically if you want strong typing or not, or you can choose to use classes if you think it's the best approach for the current project. I don't think typescript is trying to remove the options that javascript already has, otherwise they would have gone the way of coffeescript or dart. Typescript, to use the common metaphor, simply extends your toolbelt to let you pick what you want for what you need.

petegrif• 14 years ago

1. Well said.

rmrfrmrf• 14 years ago

To me, TypeScript is the answer to 1) the perceived quirkiness of JavaScript to those who are unfamiliar with it and 2) an increasing number of developers coming out of college with heavy Java backgrounds. I see TypeScript taking off mainly because of the latter point--strict typing and well-defined OO practices will act as a decent safety net for new developers.

giulianob2• 14 years ago

Actually just about every popular library out there for JS creates some sort of fake OO layer on top of JS (e.g. Backbone, jQuery, Prototype, YUI, etc..). If you are just throwing a couple of scripts together then JS is fine but if you are trying to make an actual application, you need libraries to make it more OO.

I've worked on large code bases in several languages and JS has to got to be one of the worst when it comes to code quality due to the flexibility. It's always an awful experience trying to refactor a large portion of JS since it's difficult to even find where objects are being used. I'd take AS3 over JS anytime of the day since it allows me to specify types (though optional) and if I do the tooling is able to do a lot of the static analysis that is important in large projects. TypeScript still gives you plain old JS while allowing you to specify some extra information in order to facilitate development. It's actually new developers that aren't aware of these things and love JS from what I've seen. They haven't worked on large code bases and love the flexibility of JS. When you actually are trying to create proper abstractions in order to architect your code, you need visibility modifiers, you need interfaces, and you need types.

WayneDB• 14 years ago

Javascript is quirky. It's a great language, but c'mon...please. That horse has been beaten to death and the long discussion on this topic alone is proof of it's quirkiness and it's numerous pitfalls.

The idea that (optional) strict typing and (optional) well-defined OO practices would only work to act as a "safety net" for new developers is, quite frankly, ludicrous. Static typing is the bedrock of static analysis and if you can't see the value in static analysis, take a read here - http://www.altdevblogaday.com/2011/12/24/static-code-analysi...

You're welcome to keep doing things the hard way. You will certainly be enabled to do so since Javascript is not going anywhere. But easy-to-use Javascript-compatible languages with powerful, precise and accessible features are the future, IMO. I don't think I'm alone in that sentiment given the recently budding interest in this arena.

MatthewPhillips4• 14 years ago

I agree with this. If it's nothing more than a forward-compatible superset of JavaScript, with optional static typing, it has a place in the world of JS target languages.

grayrest• 14 years ago

I'm not sold on forward compat. I'm only an interested observer of TC39 but to my knowledge only arrow lambdas and modules (the cross file ones) are near consensus. The rest of the features added have either been going around for a long time or haven't really gotten a lot of discussion.

devgutt• 14 years ago

This is a ingenious move. A much smaller subset than CoffeeScript and still a sensitive and important one that probably will be incorporate at ECMAScript 6. If not, you still have your vanilla JS. I'm not sure with TypeScript will succeed, but I'm sure that this is the way to fix JS's problems.

nahname• 14 years ago

I have to build my entire project every time I want to update my client side code? That is an enormous tax to charge the developer just to add static typing to your client side code. I can't see this doing anything but slowing a team down.

Me10002• 14 years ago

Anyone building large projects do this anyway, using minifiers to reduce the download size. Sometimes the code has inline documentation which gets built too.

A build step is already a reality for many people writing JS today.

asher_• 14 years ago

This isn't really a fair comparison. You can use unminified, commented javascript in development for testing without a build step, and just build for production.

Even so, a build step can be a single keypress, so its no big deal.

taude• 14 years ago

Pretty sure this will be addressed (likely sooner than later) in much the same way Mindscapes Web Workbench plug-in compiles SCSS & less files when you save the file...

Edit: I'm currently using Chirpy to compress and unify all my JavaScript, anyway. So this isn't even really a concern.

oinksoft6• 14 years ago

I agree 100%. You won't see type-check warnings/errors from the Closure Compiler (which I noted yesterday supports far more detailed type-checking than TypeScript) until you re-compile, but this doesn't prevent you from running your code in a development context at all, as it's just plain JavaScript and `base.js' can handle goog.require() calls at runtime. The same things of course apply to unit testing via the Closure test runner or any other test framework.

And you can use plovr to recompile on every reload (takes 5-10s) if you need these warnings in your workflow at every step.

mullr• 14 years ago

Not an issue in practice with coffescript, due to various server- and client- side tooling. My current setup will actually recompile and refresh the browser for me whenever I save. Typescript should be just the same, workflow-wise.

MartinCron• 14 years ago

I have to build my entire project

With good tools (IDE and build automation) coupled with continuous integration/deployment, this doesn't have to feel like a tax.

mistercow• 14 years ago

>Dart interops with JavaScript...but it's not JS. It doesn't even use the JavaScript number type for example.

What is meant by this? As far as I know, the only way that you can use Dart in any browser currently is by compiling it to JS, and when you do that it most certainly does use native JS numbers. In fact, the type check function it creates for numbers contains this line:

      if (!(typeof value === 'number')) {

apendleton• 14 years ago

The native Dart VM distinguishes between integers and floats for performance reasons, and (I think) lets you explicitly cast back and forth between them, and if, at some point, Chrome ships a Dart interpreter, developers will be able to take advantage of that. I assume this all gets turned into noops when it's translated to JS, so to some extent it's academic, but I think they were just trying to illustrate that Dart's innate notions of built-in types are different than JS's, and are kludged into JS types at compile time, whereas TS sits much closer to current JS environments.

scott_s2• 14 years ago

He means that the semantics of Dart - including the data types provided by Dart - are different from JavaScript. This is in opposition to TypeScript, which is a superset of JavaScript, which means that it necessarily shares JavaScrips semantics.

If your example bothers you, consider that JavaScript just happens to be a target language for the Dart compiler. That is, it takes a program with Dart's semantics, and figures out how to map those to JavaScript semantics. That there is a mapping is not all that interesting, as such a mapping will exist from any Turing complete language to any other.

lindenr• 14 years ago

Really? Wow, that's cool. Can I have a reference?

jzelinskie• 14 years ago

There is an experimental build of Chromium called Dartium that contains a Dart VM. It isn't practical for daily use, but it's a taste of things to come.

benatkin• 14 years ago

The author ignores the fact that TypeScript is being heavily promoted by Microsoft. TypeScript isn't an experiment, but something Microsoft is trying to sell, along with their IDE. He starts it with a quote from a colleague rather than citing examples of people attacking TypeScript, as if it's a forgone conclusion that people have gone overboard on attacking it. I hate to see an argument for a programming language start with the author's persecution complex.

TazeTSchnitzel3• 14 years ago

>Microsoft is trying to sell

Do you mean sell as in for money? Or sell as in get people to adopt? Under an Apache license, I doubt it's the former. Although they could sell the Visual Studio tooling.

seanmcdirmid3• 14 years ago

Use the tooling to sell the platform? It might be in Microsoft's interest to have some mindshare I this space; JavaScript is a significant part of the windows 8 story from what I can tell.

ryanzec2• 14 years ago

> Microsoft is trying to sell, along with their IDE

I highly doubt that they created TypeScript to try to sell more copies of Visual Studio. I mean TypeScript is under the Apache 2.0 License so I don't see what would stop other IDEs (like JetBrain's WebStorm/PHPStorm/RubyMine/etc...) from integrating TypeScript into them (and I really hope they do soon).

rbellio• 14 years ago

I've been testing it out and I like it so far. I personally don't enjoy writing JavaScript in text editors and the tools like PHPStorm, while being decent don't really give me the slick development environments that I've come to enjoy.

Since I do a lot of Windows and .NET web app development for my day job, I really enjoy the fact that Microsoft is putting a concerted effort into not only adding more support for JavaScript, but also for looking at the state of JavaScript and looking to improve the experience for people like me.

In Anders introduction to TypeScript, he mentions the gap between .NET development and JavaScript and hints that this is just the beginning of bridging that gap.

Rather than being a language that hides the underlying structure (a la ASP and ASP.NET) it is much closer to native JavaScript development. I'm really excited to see where this might go and have my fingers crossed that it only improves the state of JavaScript development.

bascule• 14 years ago

"What I like about TypeScript - so far - is that TypeScript’s static typing could enable better tooling with warning squiggles, easy statement completion, plus smart refactoring. You also get easy navigation around code, as well as find references, rename, and more."

RubyMine (by IntelliJ) can do all of that. Don't get me wrong, the refactoring support for statically typed languages is a lot better (e.g changing method signatures) but none of the examples he listed require one.

krohrbaugh2• 14 years ago

First of all, I'm glad Microsoft is getting involved in this space. They have a deep talent pool when it comes to language design and tooling and it'll be interesting to see where TypeScript goes.

Unfortunately, the arguments trying to draw some kind of monumental distinction between TypeScript, Dart and CoffeeScript are silly. They are all a response to the state of client-side development and are all applying essentially the same strategy (i.e., some syntax changes and a pre-compiler). It's great that TypeScript is a superset, which is what makes it pretty interesting to me, but it's still more similar to the other two than not.

Plus, what's so bad about being Microsoft's "answer" to something else? Windows was the response to Mac OS, Xbox was a response to PlayStation, .NET was the response to Java, ASP.NET AJAX was the response to Prototype (later abandoned for jQuery), ASP.NET MVC was the response to Rails, Entity Framework was the response to Hibernate/Active Record, NuGet was the response to Rubygems/npm. Each of these moved MSFT forward and several of them moved the industry forward. The ASP.NET team (of which Mr. Hanselman is a member) is doing a lot of great stuff inside MSFT, but a lot of is derivative. That's okay. It's largely the strategy MSFT has always followed, so why waste energy defending what has worked well in the past?

I agree with one point, however: It is disappointing when smart people display a profound ignorance of computing history.

TazeTSchnitzel3• 14 years ago

> essentially the same strategy (i.e., some syntax changes and a pre-compiler)

TypeScript and CoffeeScript, yes. Dart's a brand new C-like web language that is quite different, and has its own VM. Although, of course, you can still compile to JS. But unlike TypeScript and CoffeeScript, it isn't really an alternative syntax for JS, or annotations removed at compile-time.

krohrbaugh2• 14 years ago

Yes, I know and you are correct.

At a high-level, though, and in the case where browsers are the target platform, those aspects are largely implementation details.

saraid216• 14 years ago

> I agree with one point, however: It is disappointing when smart people display a profound ignorance of computing history.

Yeah, this was kind of an odd non sequitur that didn't go anywhere. I half-expected the article to actually give an illustration from computing history.

jmmcd7• 14 years ago

This isn't exactly the right place, but I don't know where else to ask this.

When people argue for static types (whether optional as in TypeScript or mandatory), one of the main reasons is "tooling". Why?

I know that writing a "go to definition" function for your IDE is impossible to do 100% correctly, when types are dynamic. But I would've thought it'd be pretty easy to do a 99% implementation, which rarely fails if you don't deliberately write code to fool it. Right?

winteriscomming3• 14 years ago

Go to function definition, refacor/rename, find references, view object / class hierarchy, and so on. Why not have all this work 100% of the time?

Tooling makes your life so much easier. I don't understand why people would resist optional typing.

jmmcd7• 14 years ago

I'm not saying that tooling isn't nice. On the contrary. I'm asking why can't we have tooling even with dynamic types.

jes5199• 14 years ago

Yeah, I think it might be a programming-language cultural thing. Most refactoring tools are written for Java and C#, so the people with experience writing refactoring tools have worked out how to solve the problems when they have certain assurances. But it really should be possible to write usable refactoring tools for ruby and python and javascript - you'll have to do a little more work to figure out name collisions between variables and methods and there's going to be ambiguous metaprogramming stuff like using strings to lookup instance variables, but having good tooling in the cases where you weren't using metaprogramming might encourage programmers to use a more concrete coding style, and that's probably a good thing. (Java has the same problems when you use a lot of reflection. So people don't use much reflection!)

jmmcd7• 14 years ago

YES! And I bet that a little bit of heuristics, a little bit of machine learning, and/or a little bit of user feedback (say, a button that tells the tool it went to the wrong function definition) would help such a tool cover a few more of the difficult cases.

This ought to be a classic case of "worse is better", which is why I'm surprised to see that people seem to shy away from it.

JackC2• 14 years ago

I came to ask a similar question -- how much better is IDE support for statically typed languages than, for example, JetBrains' IDE support for Python, Javascript, CoffeeScript, etc? They offer code-completion, live error highlighting, go-to-declaration, refactoring (with a confirmation step if it's ambiguous), all that good stuff.[1] The interface asks for clarification when it's not sure what something refers to. It seems to work pretty well. I don't really use typed languages, though, so I don't know how much I'm missing. Can anyone comment based on experience with both?

(I actually also came to say, damn, y'all, IDE support is awesome, and it's here for dynamic languages. Go-to-declaration alone is lifechanging, since it's usually faster to jump into a library call with ctrl-B than to check the docs. Live error highlighting alone is worth it. Just give JetBrains whatever they ask for.)

[1] http://www.jetbrains.com/pycharm/features/index.html

giulianob2• 14 years ago

If you've ever used Resharper then it's difficult to work in any other environment. I doubt most of Resharper's features would be possible in a non statically typed language. It's a Jetbrains product as well:

http://www.jetbrains.com/resharper/

dodyg• 14 years ago

Try the TypeScript playground http://www.typescriptlang.org/Playground/ . You can do rename, intellisense, find reference, etc directly from your browser.

TypeScript language service is developed in TypeScript. This is how they can host these type of function on the browser. It's all just JavaScript

Check out this screenshot from the playground http://i.imgur.com/H2rqD.png

jmmcd7• 14 years ago

Typescript has static type annotations. All those things are already easy in that context.

jconley• 14 years ago

The Typescript syntax looks shockingly like Adobe's ActionScript. Next up, Adobe releases an ActionScript to Javascript cross compiler?

aaronblohowiak• 14 years ago

Do you know the history of ES4? http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Ed...

Zecc• 14 years ago

This guy agrees with you (and so do I btw): http://blog.blakebarrett.net/2012/10/typescript-vs-actionscr...

And yes, they're all variants of ECMAScript. It's a mess!

eranation2• 14 years ago

I think google missed big time on Dart, and something like TypeScript is what they should have done. I really find it hard to come up with bad things to say about Microsoft's move, it's a mental cognitive dissonance, but I have to admit, they are doing something very right.

1) it's just JavaScript - winning some CoffeeScript fans

2) regular JavaScript is valid, (just like SCSS vs SASS)

3) it has day 1 interop with vanila JS (Dart just started, and until it has it, it's just a play-with language)

4) TypeScript support for most popular editors (Dart has mostly Eclipse I think, TypeScript has support for everything but eclipse, but an eclipse plugin is just a matter of time probably)

5) TypeScript has a bit more chance becoming a standard, (future ECMASCript 6?)

Well played Microsoft, didn't see it coming...

VS 2012 is actually nice, still I would probably wait for an Eclipse plugin (I'm sure someone out there is already working on it) but this is for me a big reason not to start learning Dart

cmccabe3• 14 years ago

I think you answered your own question. Google wanted a fundamentally different language, not just JS with some extra features thrown in. As to what will win out in the end-- I have no idea.

eranation2• 14 years ago

Google seem to like inventing things, they have people who create languages for a living (some of the creators of Java, that some of them are probably behind Dart) and they did some pretty amazing things, Go is a great language, I'm sure Dart will have a fan base, and who knows, it might catch up (in 2004 no one thought Ruby will be that popular, right?) Google went for their vision, Microsoft went for the practical.

ahrjay• 14 years ago

Don't forget source map support, that is a huge plus to have from day one.

cmccabe3• 14 years ago

Seems like a troll article to me.

Of course people are comparing TypeScript to Dart. They do the same freaking thing-- provide you with a different way to write code to run in the browser.

Then he presents the metaphysical distinction between "building on JS" (good) versus "interop with JS" (bad). What's the difference? Neither language is JS. If something breaks, you're still going to be debugging code that isn't the code you wrote-- it's generated code.

I feel no better informed after reading this article than before. Will someone please do a straightforward comparison between Dart, TypeScript, and CoffeeScript? It might be kind of hard because as far as I can see, TypeScript does not build on Linux.

P.S. Is "it doesn't even use the JS numeric type" supposed to be a put-down of Dart? I always thought the JS numeric type was a big mistake. Who would want to be forced to use floats for everything? Inaccurate and slow-- two great tastes that taste great together.

Garoof• 14 years ago

> What's the difference?

One lets you take existing JS-code and make use of new language features there. The other "just" lets you call existing JS-code.

I'd guess one is clearly better than the other when it comes to dealing with existing JS-code* . (While the other is clearly preferable to the one when it comes to making the language you want to make.)

* It still obviously depends a lot on the language. Like, how well TS-code works together with plain JS-code (how much do you get out of adding some type annotations here and there while leaving most of the JS-code untouched, etc.).

cmccabe3• 14 years ago

OK. So there is a path to converting JS to typescript without rewriting the whole thing. Thanks for the additional information.

Why does TypeScript have be the answer to anything?

Related Stories