[sytelus]

Having spent quite a bit of my dev life with typed languages and now coding a LOT in pure JavaScript, I'm actually not at all thrilled by TypeScript. Yes, pure JS is bit hard to maintain and it does occasionally pisses me off but at the same time it is liberating.

Not having to constantly keep adding types all over, not having to constantly refactor things because I now accept object instead of an int etc is refreshing. And best of all, not having compile at all is fast and simple. I'm only using JS frameworks that doesn't force me do build before testing the page and retains purity of JavaScript (that means no simulations of traditional OOP). Yes, sometime I do make bad mistakes and spend some time chasing down bugs that would have been caught in typed languages. However overall I find cost of adding types all over and maintaining them over the evolution of code is actually higher. It would have been really great if they had produced cool algorithms that could have inferred types as much as possible and added it as static analysis tool instead of JS extension.

Just because JS doesn't have type checking I'm now set in to mindset of doing quick tests of small changes, write more elaborate tests and so on. Even in moderately large project I think pure JavaScript is not only maintainable but also joy to work with compared to typed languages.

[klibertp]

I don't know very much about TypeScript, yet, but I'm doing some research and I'm going to advocate it on my next project. From what I already know:

> Not having to constantly keep adding types all over,

TypeScript is gradually typed (which means it's happy with as little or as much type declarations as you want to give to it) and uses type inference, which reduces amount of needless type declarations even more. Actually, coming from C and later C++ to Python and JavaScript I thought the same as you, that type systems are a complete PITA. I then learned OCaml and I changed my mind: bad, archaic type systems are PITA, but modern and powerful ones are a huge help and incur little cost.

> and retains purity of JavaScript

That's like saying that you're not using any Scheme library which implements convenient exception handling and you use bare call/cc instead.

Prototypal inheritance in JavaScript is strictly more powerful than most of the class based systems, but it is less convenient to express some common idioms using just what's built-in. This is why you're going to implement some kind of object and meta-object protocols on top of prototypes sooner or later. It makes sense to agree on a standard way to do it, otherwise you're just going to add yet another slightly incompatible object system. I agree that there are many cases where prototypal inheritance is enough, though, and you shouldn't use classes by default in JavaScript.

> adding types all over and maintaining them over the evolution of code is actually higher

I have vastly different experience here. Types tend to make refactoring rather easier than harder. It's because when you change a return value or expected argument of some function you don't need to grep for all its calls in the codebase - the compiler will tell you. With sufficiently good type system, the compiler will tell you if the new type is compatible with the old one, which makes writing adapters easier. And it all happens on compile time, which means you don't need to run your app to test it. I read that TypeScript compilation is slow - that may be, but I bet it's comparable to running all the unit tests for a project, for example.

> It would have been really great if they had produced cool algorithms that could have inferred types as much as possible and added it as static analysis tool instead of JS extension.

Yeah, I agree, I'd like it too. I remember there being a very cool project from some distinguished JS developer which did just that; it was an editor and a supporting library for checking and validating JS code. I can't remember what it was, exactly, though... Help, anyone?

> Just because JS doesn't have type checking

As I said, it's not either-or situation. Gradual typing is one thing, contracts are the other. You can have the best of both worlds. After a few years I'm still amazed with Racket and Typed Racket combo - it's exactly the right mixture of compile-time and run-time support for ensuring program correctness and I would like to have something very similar in JS one day. In the meantime, TypeScript is a step in the right direction. I only hope it will continue to evolve after 1.0 release.

[shaneofalltrad]

I have performed QA tasks on both, and find that either JS developers are better or going pure vanilla makes a much stabler product. The TypeScript projects I have seen had some major flaws and requests (vs bugs) always turned into low priority because of the inability to perform the task.

[klibertp]

I think it's easy to explain: TypeScript is a new technology and programmers will have very little experience in using it. It's completely impossible to find "TypeScript programmer with 5 years of experience" for example. On the other hand, JS is stable and much older and you can easily assemble a team of highly experienced people.

Relative strengths and weaknesses of TypeScript will be only visible after it's around long enough to get its own best practices and experienced programmers. I see the same process with CoffeeScript - in the beginning average CS code was much worse than average JS, but now they are comparable and the advantages of CS are starting to be visible.

That's of course on average. It's still possible to get a few people with enough knowledge to be able to use TS effectively, but I think it's hard enough to make it very rare. It's unfortunate, but technologies - and especially languages - take very long time to mature. In short, your impression is probably correct, but it's not because of TypeScript features; we need to wait a few years before we can compare TS and JS products success rates.

[pjmlp]

> Even in moderately large project I think pure JavaScript is not only maintainable but also joy to work with compared to typed languages.

You will see that joy quickly fade away in enterprise projects.

[anton-107]

But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't?

I've seen multiple examples of "enterpisey" web apps, and there was no joy, just because developers didn't know how to build a good application with JavaScript and even more - they didn't care at all.

With a "don't touch anything that works" mindset that lots of enterprise developers have - you write write-only JavaScript code and when it becomes too large - of course, there is no joy in touching this kind of codebase.

Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine: the joy won't fade away.

[pjmlp]

> But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't?

No, it is because:

- Unit tests have zero value over new features

- Project development tends to be outsourced to teams with high attrition rates

- Most of the time cheaper developers are what matter

- No one cares about quality, because there are no options to get the software from somewhere else

> Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine

Oh, the dream enterprise, where can I get a job?

[mattcole]

If you're willing to live in sunny SE QLD, Australia, and good at C# as well as JS, get in touch.

[pjmlp]

Thanks for the invite, it is a bit far from Germany and Portugal. :)

[pingec]

>Not having to constantly keep adding types all over

You don't have to if you don't want to.

>not having to constantly refactor things because I now accept object instead of an int etc is refreshing

Again this is your choice, you can omit types if you want

TS gives you the option to add typing if you want it. And that is huge in my book, try refactoring a large enterprise app written in JS vs. written in TS.

[nmjohn]

Okay so if you don't use types, wouldn't you would just be writing vanilla javascript and would have no reason to use typescript in the first place though?

[lmm]

It has a somewhat nicer syntax for functions and better scoping rules, but you could certainly get that from a more lightweight js extension like coffeescript yeah.

[klibertp]

Not exactly, there is still type inference mechanism at work which, combined with DefinitelyTyped (https://github.com/borisyankov/DefinitelyTyped) declarations will get you quite a lot type safety even if you won't write any type declaration by yourself.

[CmonDev]

"cool algorithms that could have inferred types as much as possible" - like Hindley-Milner type system? Like OCAML/Haskell/F#? There is only one reason JS could be chosen. Because it's everywhere. Almost any other modern language is realistically better. But unfortunately Web is Closed to JS/HTML/CSS.

[aquadrop]

TypeScript is the future of JavaScript, since all TS does is trying to introduce ES6 features right now.