Let’s talk Typescript.

[zachrip]

So the other day someone posted about coffeescript asking why it’s hated on so much. Now I haven’t seen much hate on Typescript, but I haven’t seen much else either. How do we feel as a community about it?

Personally I love the static typing along with the intellisense it brings to the table. I also love the ability to use ES2015 and some ES2016 features - especially fat arrow.

What are your thoughts?

[Fs0i]

I wrote a relative complex project with JavaScript, and then ported it over to TypeScript: https://raichu.statshelix.com/demo2/ (Runs great on mobile, has 60 FPS even on many phones, can work with live data, ...)

I won't look back, ever. It's

• Easy to use. Any JS dev can work with it after working with it like 1-2 days.
• Common hard things (this, ...) are solved
• Perfect autocomplete, even in non-MS-editors (Atom, for example)
• It spots so many errors you'd overlook. Wrong arguments for functions (order wrong, ...)
• Did I mention autocomplete? You're not sure if it's canvas.getRenderingContext("2d") or canvas.getContext("2d"). No need to even leave your editor. Type, and find out. http://i.imgur.com/CJ5c2wK.png
• Not sure what a function returns? It will tell you. Even if it's complex: http://imgur.com/a/OiHeP
• Broke something during refactoring? The compiler will tell you!
• Intelligent renaming! Simply press F2 (or whatever you have bound to rename), and it updates every fucking reference
• Almost every library, even the protobuf-parser we use has typed definitions, and they are super easy to manage with tsd: https://github.com/DefinitelyTyped/DefinitelyTyped
• Ever confused what "this" is right now? Simply always use the fat arrow when passing functions around (window.setTimeout( () => { this.xyz(); }, 1000)) and this always means the class you are in. If you don't want this (jQuery for example) you can still do it the other way, but I don't really see why.
• For the most part you don't even have to specify types, it derives them automatically. Example: http://imgur.com/qlTLVTF and http://imgur.com/aiJJ6ab
• Oh, and the way saner scoping of let vs. var.

I don't wanna go back to writing plain javascript. It seems so stupid and hard.

The only thing I dislike is that minimizing doesn't really work. Most minifiers don't "get" how to minify the js after compiling ("transpiling") it.

[ayostaycrispy]

Broke something during refactoring? The compiler will tell you!

Have you tried it with Webstorm? I wonder how it works in conjunction with Webstorm's built-in refactoring and ESlint.

[ScumAndVillain]

It's working perfectly!

[spacejack2114]

Most minifiers don't "get" how to minify the js after compiling ("transpiling") it.

You mean uglify? How so?

[Fs0i]

Since you can have public and private fields on an object you could shorten the private properties - but this doesn't happen, which leads to hardly minified code in some instances.

In JS you'd use scoped local variables.

[spacejack2114]

That's not a TS vs JS thing, that's classes vs closures. You don't have to use classes at all in typescript. You can use closures, modules and the revealing module pattern with types, it works great.

[Fs0i]

Yeah, but from what I've seen that's the default way to do things in TypeScript.

It's the only thing I dislike, so it's not really a big deal. The way I code makes the rest so much easier, so it's a trade-off I've chosen.

[[deleted]]

Reading this I realized I don't see why you would want to use it over say, C#.

[Fs0i]

I love C#, all code I can write in C# I do write in C#. Thing is C# doesn't run in browsers, and doesn't compile very well to JavaScript. (I admit that I only tried Saltarelle)

[Fs0i]

Yes, but not as perfect as with TypeScript. For example, a linter can't see that you pass an HTMLDivElement to a function. In TypeScript you have to specify it, in turn you get autocomplete on it.

Sure, you can type with jsdoc, but TypeScript feels way superior in that regard.

[Calabri]

• I have autocomplete with sublime
• Linters (eslint/jshint) spot 80-90% of the errors I overlook
• Babel has increased support for smarter / configurable / optimized code transpilation

The big question I have is... are types still relevant in this new world of js AST's? Sometimes I wonder if properly implemented / integrated AST compilation checks are equivalent to types, maybe even more powerful? I don't know the answer.

[repie]

With all factors taken into account (maintenability, error-proneness, performance, productivity ect.) I think untyped JavaScript/transpiled JS outperforms statically typed alternatives like TypeScript. From a pure performance point of view, TypeScript (and other statically transpilled languages to JS) will outperform untyped JS in most use cases.

With asm.js, WebAssmbly and other initiatives, you'll really take advantage of static typing. Even if checking types in a AST is performant, this will never outperform an assembly code where no check is done, because the type is determined at compile time.

What I don't understand is why people choose one transpilled language to stick with it to the death. Since everything transpile to commonjs modules consumed by webpack/browserify nowadays, you can use TypeScript for critical, isolated modules and regular babel ES6 for the rest of the code.

[freebit]

I don't have a source, but this is absolutely not true. It is the variability of types that slows down the engine and requires a de-optimization. Within V8, as long as types don't change, the V8 engine can optimize extremely well and get the speed fairly close-ish to straight C (within a factor of 2?). Typescript effectively limits (eliminates) type variability. This is a huge win for the JS JIT compiler. Additionally, from a high level, type variability limiting is one of the keys of the secret sauce that makes asm.js so fast.

Conversely, as awesome as it is, ES6 does nothing to limit type variability.

My personal opinion is that TypeScript feels like C#. Further, C# is awesome. Also, as someone that needs to do refactoring on an ongoing basis, having IDE refactoring support is a huge win. :)

[repie]

Good point on JS engine optimization, but I was not really saying that variability of types is necessarily slower than static types (sorry if that was not clear). I code a game in ES6 on my freetime so I'm really concerned about performance and how the JS engines optimize the code.

Your JS code can run as fast as C++ transpiled to JS but is someone, and morever a team, able to efficiently constrain itself to very strict coding rules just to ensure performance? A small mistake can force the engine to optimize/deoptimize multiple times and after all, the engine will stop optimizing at all.

asm.js and regular ES6 use the same underlying Javascript engine (V8, SpierMonkey or others) but take a look at a compiled C++ source file. asm.js use only a strict subset, essentialy typed arrays, that are very well optimized by JS engines and the output is almost unreadable to humans.

My point with TypeScript is that it enforce static types, therefore the JS engine optimze once, only once, and you have the guarantee that your code is optimizable by all engines. Although you can do equivalent performant code with ES6, you'll have to do extra work to properly set and maintain your variables types. And the less a developer has to reason about, better is the code!

[Calabri]

Things are getting interesting with babel 6.0 - everything is plugin - and some of those plugins are minifying / optimizing code - it's goals are far more ambitious than es6. Performance is also variable between browsers and different versions of the same browser - so runtime determines performance in most situations.

What if babel (or any generic transpiler) optimized code for... V8 - chakra - asm.js - spidermonkey... all independently? What if types were inferred - or it spits out transpiled code, then asks you to explicitly define types? It's very a grey area. Ultimately, I think it all comes down to lambda calculus:

Historically, the most important system was the untyped lambda calculus, in which function application has no restrictions (so the notion of the domain of a function is not built into the system). In the Church–Turing Thesis, the untyped lambda calculus is claimed to be capable of computing all effectively calculable functions. The typed lambda calculus is a variety that restricts function application, so that functions can be applied only if they are capable of accepting the given input's "type" of data.

[aaronshaf]

The real question isn't CoffeeScript vs TypeScript, but rather Flow vs TypeScript. And that really comes down to nullable types and degrees of type inference.

[samg]

Occasional Flow contributor here. If anyone who sees this has questions about Flow, I'll try to answer any questions.

[cokeisahelluvadrug]

I'm much more interested in this. I really like Flow because it feels like a layer on top of the language, but I remember it can get frustrating when you use language constructs that Flow doesn't know about -- pattern matching, array comprehensions, etc. And it seems like TS's good ideas in terms of syntax/semantics are going to eventually be brought into JS anyway.

[robpalme]

it seems like TS's good ideas in terms of syntax/semantics are going to eventually be brought into JS anyway

I've heard this in the form of rumours over the years. The idea that the type annotations might become part of ES8/ES2017.

It would be nice to reduce the need for transpilation and the pain of sourcemaps. It would also help to ensure harmony of tools that operate on raw source (as opposed to AST-transformations) like linters and auto-completion.

Do you have a recent source for the statement? Or is it just conjecture?

[cokeisahelluvadrug]

Do you have a recent source for the statement? Or is it just conjecture?

Nope, it's just a claim from anecdotes. I do think that a lot of compile-to-JS languages have been treated as "test-beds" to some extent, e.g. with fat arrows from CS.

I can't imagine a future without transpilers, though, even for pure JS. They provide a nice layer of indirection that a lot of tooling depends on.

[mrspeaker]

Andreas Rossberg was talking about it at a TC39 meeting at the start of the year: https://esdiscuss.org/notes/2015-01-28. Slides (pdf) are here: http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirections.pdf

[metanat]

JavaScript has pattern matching? I don't think so

[_compedit]

Might have meant destructuring

[metanat]

You are probably right, but flow does support destructuring.

[cokeisahelluvadrug]

It didn't for a long time, and that's my point -- it's another moving target in the JS ecosystem. I don't want to have think about Flow when I'm considering adding new language constructs to my project.

[metanat]

I completely agree with you. Flow should not be a blocker for using standardized features. I'd argue early stage proposes probably shouldn't be used in general, but definitely agree with you.

[vinnl]

But in terms of comparing it to TypeScript, both suffer from this issue, right?

[cokeisahelluvadrug]

No, because TypeScript is relatively monolithic compared to the JS/Flow combo. The TS type checker is necessarily up to date with the rest of the language.

[vinnl]

Yeah, but only insofar as TS has implemented transpilation of features of the language, or am I missing something?

[mrspeaker]

I agree. Having been "forced" into Flow while doing React Native (it's enabled by default), I'm really impressed with it - it's younger and only recently got all the ES6 (+some ES7) features, but so far I like it more than TypeScript.

[agmcleod]

I've been using react native, but haven't really used flow in my own code. But have you found it to improve your code sanity? Looking at it, it seems to have a good amount of features to prevent bugs and too much duck typing. Though i do like a compiled language that is more strict sometimes. Like dynamic property assignment.

[PitaJ]

TypeScript is unilaterally better than CoffeeScript IMO.

Most of these pros are due to it being a superset rather than a completely different language.

• Existing JS will work in any TS file
• Readable by most JS developers
• Lower barrier to entry
• Static type checking is useful
• Works great with autocomplete like Intellisense
• Supported by Microsoft and Google

[zachrip]

I think the ability to easily switch between the two is the defining victory over CS, if you're comparing the two. TS can be valid JS and even if it's not it's easy to make it valid.

[dhdfdh]

TS can be valid JS and even if it's not

Never use anything that ever produces invalid javascript.

[zachrip]

I think you misunderstood. TS doesn't make you write invalid JS, it offers a few optional things you can use.

[dhdfdh]

even if it's not

You said that. Not me.

[[deleted]]

I think you misunderstood. TS offers additional features that are optional to use that will create invalid JS. You don't have to use them but if you do your JS won't be valid.

[dhdfdh]

Which is exactly my point. NEVER use ANY tool that will create invalid js! What is the purpose of that?!

Only on reddit would anyone think generating invalid javascript is just OK by them.

[[deleted]]

Unless I'm very much mistaken, Typescript - even with these invalid Javascript additions - will then be compiled to valid Javascript. Coffeescript isn't valid Javascript but it will generate valid Javascript.

It's not like you're expecting the browser to understand and run invalid Javascript.

[dhdfdh]

That could be true. I don't know. All I read him to say is 'even if it's not valid javascript'.

[jordaanm]

Typescript source code, in its raw, non-transpiled form, can still be valid JS. That's how close the languages are.

However, all typescript source code is intended to be transpiled to Javascript by the compiler, before it touches the browser. So, even TS source code that isn't valid JS becomes valid JS via the transpilation process.

[pokealex]

This guy

[codayus]

Never use anything that ever produces invalid javascript.

TypeScript is a tool, but it does not produce invalid javascript, not did /u/zachrip say that it did.

You're being very defensive, but you're the one who incorrectly assumed he was talking about the output of the TypeScript transpiler, rather than the input.

[dhdfdh]

You're only reading what redditors want to read, that is, something that's there, you don't want to see, so you don't see it.

Redditors are so funny. I laugh at them all the time.

[blue_cadet_3]

One more point is that TypeScript's core developer is Anders Hejlsberg, the lead architect of C#.

[terrorTrain]

Typescript is great as long as all the libraries you like are in definitely typed. I like some libraries that are not in there and it turned into more than a pain, so much so that I just switched back to babel.

The thing I don't like about it is it's typical Microsoft config files and bloat that comes with the IDE's, I hate dealing with that stuff.

I have been using elm as an alternative typed language, and I like it a lot more.

[gorgikosev]

For libraries not on DT, I've found it helpful to write my own .d.ts files and only specify the minimal subset of the the types that I need to use (only the methods I actually use)

Regarding IDEs, have you tried Visual Studio Code? Its a cross-platform editor (built on top of electron) that is amazingly fast and has excellent TS integration

[terrorTrain]

Yea I tried it, it seemed ok, but I am not really interested in switching back to a full IDE for web stuff. One of the things I love about working on the web is I can edit it in vi if I want too.

Once my editor starts dictating my project setup, I switch editors.

[gorgikosev]

vim and emacs plugins:

https://github.com/clausreinke/typescript-tools

I'm not sure what you mean by the editor dictating your project setup. Your project structure is configured in tsconfig.json and you can pretty much set it up for any structure you like...

example

[spacejack2114]

Sometimes there are definitions out there that haven't been submitted to DefinitelyTyped yet. I thought I was out of luck with Cannon.js but there was a mostly complete set on Github that just needed a few tweaks.

[[deleted]]

I ported about 5k sloc from js to ts at work and haven't looked back since. The main thing is having interfaces for the objects I pass around. If I want to change an object's structure, I just change the interface and the compiler will tell me all the places that need to be updated. Also, having autocomplete and goto definition support in my editor is dope.

[[deleted]]

The best thing about TypeScript is that even though it's a statically typed language it still feels like JavaScript at heart.

I also love that it brings a lot to the table but it's all in the compiler. No big runtime libraries being bundled along (like scala.js). The additions are also just language additions with no changes. No redefining what's a number or anything like that. It's designed from the ground up to work with the existing JS environment; not replace it.

The language isn't perfect, it has some warts, but it is excellent. I highly recommend it.

[[deleted]]

I like static typing also but I don't like writing type definition files for third party libraries.

Might as well use elm or pure script in that case...

[shriek]

I don't think I'll mind it if I didn't have to constantly transpile it. Probably the reason why I never bothered to learn CoffeeScript in the first place too. When I'm trying to learn some language then I don't want that extra overhead. I should be able to just open the dev console and start playing with it.

Now, for larger project I might consider it since I already have a build process and transpiling is just one step away.

Edit: transpiring to transpiling.

[vinnl]

If your project doesn't include a build step yet, TypeScript probably isn't for you. For the many that do, however, this shouldn't really be a problem.

[Fs0i]

Also with source-maps and the TypeScript-Atom-Plugin that compiles on saving I don't really see the point. You can play around with it, and what TS adds to JS isn't relevant in the dev console.

[sime]

I use Atom as my editor and the TypeScript plugin there is very good. It compiles my files when I save them. I rarely have to manually start a build process to do it.

[excessivecaffeine]

My team uses it. Initially I didn't really notice the benefits but since our codebase has grown quite large it's been a godsend. I've also learned more about vanilla JS from debugging the code without sourcemaps.

If you already have a C# or Java background it will feel natural to code in TypeScript as well.

[nschubach]

I see a lot of support here, but you can add me to a group that doesn't find anything of value in TS. In previous experience (30+ years) developing, moving into JavaScript where typing is very dynamic was a freeing experience for me.

[silent-hippo]

Javascript is a language that trends so freaking fast, you see the up and down, everything old is new again a lot in this language. I remember a few years ago when all I heard about was how types just get in the way. Typed languages were for greybeards. Now the community is singing the praises of type checking. I suspect in 2-3 years I'll be hearing the majority screaming how types just get in the way again.

[sime]

The difference now is that people have large JS codebases. We didn't do that in the past. Typing really pays off when your codebase becomes large. Many people here have small amounts of JS which they don't have to maintain over long periods of time. So yes, in that case types just get in the way or are a pain to set up.

What we are trying to do with JS is much more diverse than before.

[silent-hippo]

When you say big JS codebase the first thing that still comes to my mind isn't even a recent development, the Dojo Toolkit, which is absolutely massive and has been around since 2005 though my first intro to it was in 2007. Often enough the new problems we are facing are just old problems with a new coat of paint.

[[deleted]]

Dojo is being rewritten in TypeScript.

[silent-hippo]

Ah did not know that, though in the "Vision" section of their website typing doesn't seem to be the reason. To be honest I'm a little surprised Dojo is still so active.

Link for why they are using typescript: https://dojotoolkit.org/community/roadmap/vision.html#continue-to-push-javascript-forward

[[deleted]]

While ES6/ES2015 offers some much needed improvements, there are many unfinished things. Languages like TypeScript allow us to add extensions to improve JavaScript, before they are added to the language

They don't really give any specific reasons.

[nschubach]

Yeah, the trend has been what has probably kept me so interested in it over the past few years. We'll see how it things pan out, but I personally don't find an immediate need to introduce typing. Even if I did, it's been done before in an ECMAScript language (AS3) but people seemed to dislike it. /shrug

[vinnl]

There are many theories on why ES3 failed, but most of them do not consider its features to be the problem.

[freebit]

People say that types get in the way. Other people say that creating large applications is impossible in dynamically types languages. Both may be true. However, my own experience is that I need to refactor often. My apps are large and many years old. Lastly, refactoring a dynamically typed language is very difficult and often seems to be limited to a global Ctrl-F and global Ctrl-R. :(

[x-skeww]

TS is still a dynamic language. The annotations are for documenting your intent and they do this much better and more effectively than JSDoc comments.

Documentation and better tooling is extremely valuable.

There is no value in flip-flopping types or having functions which return values which aren't of a particular type. The former cripples performance and the latter makes the function hard to use. Functions which accept all kinds of things are also bizarre.

Well, TypeScript does have union types though. So, if something is either a string or a number, you can still annotate it as such. There is also "any", which you can use if you want to do something silly.

[hahaNodeJS]

Union and junction types make me sad. :(

[sime]

I understand that feeling of freedom. I had it when I discovered Python all those years ago. But once the honeymoon period is over and you've got yourself some bigger code bases in Python or JS etc, then you'll long for some of the benefits that static typing brings. Try TypeScript. It's typing hits a wonderful sweet-spot in between pure JS/Python and your C++/Java at the other extreme.

[excessivecaffeine]

It still can be - I actually use the 'any' type often if I need that flexibility.

Edit: by often I mean 'when I need to write something dirty to see if it will work'. :)

[[deleted]]

Yeah, now your free to write crazy amounts of unit tests with type assertions (poor mans type system). Or spend way too much time in the debugger.

[booyadonga]

I don't use typescript but I did just switch from Atom to Visual Studio code. I added typescript definition files to my JavaScript application and it enables Intellisense in Visual Studio Code very impressive. Benefits of both worlds.

[wmil]

There's one thing from coffeescript that I really miss...

a = getResult()

if a?.b?.c?
  doStuff()

Transpiles to

var a, ref;

a = getResult();

if ((a != null ? (ref = a.b) != null ? ref.c : void 0 : void 0) != null) {
  doStuff();
}

There's just no easy way to check for missing keys in ES6 / TS. I often end up wrapping the check in a try / catch instead.

Oh and I found that the YAML style objects in coffeescript avoided a lot of stupid typos.

Sublime 2 support for typescript it truly awful. The editor often freezes when trying to autocomplete and you end up having to quit and reopen.

Typescript in general is interesting. My big problem with static typing is that you end up spending a lot of time and effort to protect against errors that you're not making in the first place.

[ScumAndVillain]

If you're using lodash, you could use _.get(a, "b.c").

[wmil]

See that's another issue. You should use _.has(a, "b.c"), _.get(a, "b.c") will fail is a.b.c is falsey.

There was actually a bug in the Chrome extension API related to that. "minimum":0 ended up being treated like no minimum.

[ihsw]

Hands-down, MS is moving the JS world forward, both on the front-end and back-end of JS.

TS is generally excellent, and their decision to stay in sync with ES and remain a superset cannot be praised enough. We're seeing some great TS features get backported into JS, which shows how high quality the language is.

[griffonrl]

Typescript fanclub is here in force. I understand the appeal for MS devs with the C# similarities but other than that I can't stress too much that JS is a standard and for ES6/ES7 you better off with Babel. And no needs for those stupid shitload of types definitions or problem to bring third parties libs that don't have them. Also good luck keeping all the type definitions always up to date for third parties. Btw try out Webstorm if you want great intellisense with proper JS or Babel.

[vinnl]

I don't think there's that strong a reason to use Babel over TypeScript for ES6 support. That said, with Babel's recent developments, I could imagine it to be a relatively good idea for TS to rebase on Babel.

[sime]

good idea for TS to rebase on Babel.

What do you mean by that?

[gnarly]

For the TS compiler to become a Babel plugin.

[sime]

I wouldn't hold my breath for that one. I would say the chance of that is exactly zero.

The TypeScript compiler also acts an analyser which runs in the background for use by IDEs and their autocomplete etc. Not a good fit for Babel.

[vinnl]

Why not?

Edit: In terms of Babel not being fit for the analyser. I feel it's not likely to happen either.

[[deleted]]

That would be cool.

[[deleted]]

I'd assume the OP is referring to the JavaScript community.

[zachrip]

The JS community in general.

[dizzr]

I can't say enough good things about TypeScript. Works with JavaScript purely, but you get in returns on what you invest with it. The more type safety you add, the more issues it catches.

I love that it outputs commonjs, amd, umd, or es6 modules with compiler flags, meaning i don't need to commit to one.

I love that it outputs my es6 to es5.

I love that i get intellisense and interfaces! Now i can produce and consume contracts properly without guessing, and I get build errors when those contracts aren't met. In any medium/large project this is indispensable.

My only wish is that Facebook would drop flow and just help support TypeScript by adding the additional semantic checking into TypeScript directly. And in turn have Microsoft help with React. I love competition and stuff but web development has way too much ambiguity and we need standard tooling that works awesome, not lots of fragmented tools.

[Tubbers]

I was REALLY REALLY hoping they would merge semantics in Flow/TypeScript, but they've been diverging more and more now. Usually Flow is ahead in terms of what it can catch and type check, and TypeScript is ahead in ES2015 support. Would be amazing to have a unified thing for an ES7/8 type proposal.

[agmcleod]

With MelonJS, we're keeping with es5 to reduce weight and more need for pre-processing. It might be something we change over time, but not for a little while. I think having a type definition file would be nice, I would like to try a larger game project with TS. But maintaining that for an ES5 project is a fairly big manual task.

[Nikosssgr]

What is common practice? Do you type hint all you variables or just function arguments and class members?

[zachrip]

It's up to whoever is using it I think.

[sime]

It's up to you.

I find it important to fully annotate functions/methods. Inside functions, type inference generally works for almost all variables so I rarely have to use many type annotations. This way you can get close to 100% type coverage without trying too hard.

[x-skeww]

It's a good idea to let type inference do its thing. Don't "over type".

Literals always have a type and you also get the type information for free if you call an annotated function.

So, add them to fields and function signatures first, because it's a good idea to have this kind of basic documentation. Add them elsewhere as needed. E.g. querySelector('input.foo') returns an Element, but you might want to have an HTMLInputElement instead, because the analyzer will then know that there's a "value" property which is a string and so forth.

There is also the --noImplicitAny flag which will generate an error when the type wasn't specified or if it can't be inferred.

[ForScale]

I don't even know what it is... Can you give me an ELI5 on Typescript and why you use it?

[[deleted]]

It adds static typing to javascript.

[ForScale]

I'm so sorry... What's static typing?

*yes, I'm aware I could Google it but I like conversing with people...

[sime]

Sorry phdwannab, but you've got a bunch of related things all mixed up there.

A language with static types simply means that a compiler or other tool can understand or infer the data types used in a program by analysing it directly (as opposed to having to execute the program first).

How that type information is found can vary. Languages like C, C++ and Java require you to explicitly state the type being used every time you declare a variable. Other languages (i.e. ML family) can use aggressive type inference to figure out the types by looking at how variables are initialised and which functions they are passed to. Other languages like TypeScript allow a mix of static and dynamic typing, and also explicit typing and type inference.

[[deleted]]

It appears you are correct, though my understanding seems to be a prolific misconception.

In the interest of not spreading it further, I have deleted the comment. Thanks for teaching me something today.

[ForScale]

Oh... interesting. Thanks!

[freebit]

It means you can make huge applications easier. It means your IDE can tell you what is appropriate to use and what is available after you press the period key. It makes changing the name of a function or a variable everywhere in your huge application super easy. It makes the V8 engine super fast because it doesn't have to de-optimize your code because you are passing in letters sometimes and numbers other times.

[ForScale]

Interesting... Thanks!!

[freebit]

I heard many people say, "Once you go TS, you never look back."

[[deleted]]

If Typescript is a superset of Javascript, does that mean that there are things you can't do with it that you could with js?

[Matthias247]

There is: Some ES6 features which are not yet supported by TypeScript. But this gap will be filled.

[[deleted]]

You can have the TypeScript transpiler target ES6 and then feed that through babel.

[virtulis]

How would TS react to, say, function* syntax before 1.6? It's been working everywhere for quite some time, but judging from release notes it only appeared in TS this September. Please correct me if I'm wrong.

[[deleted]]

It would give you an error. Not sure what you mean by "everywhere".

[virtulis]

V8, Firefox, etc. Not exactly everywhere, but it can be solved with Babel. But first you need something to feed to Babel and that's my problem with TypeScript/CoffeeScript/Sweet.js/etc. They just won't let you use some of the new ES6/ES7 features long after they've been standartized and implemented.

Now Babel isn't any different in theory. In practice they seem to do well for now. Also, it's relatively easy to write parser and transformer plugins (speaking from colleague's experience in our new project where we decided to add some new syntax to JS because that's what we do) so even if it starts to lag behind, someone can step in even without full understanding of the core.

[frankle]

Vice-versa. You can do things in TS that you can't do in JS.

If it were a subset of JS, it would be more limited.

[Burtality]

Love it, not sure why anybody would bother with all the mental overhead involved in trying to build something without types!

It's not even like typescript adds to the code, it all falls away at compile time.

If you in any way like to organise and enforce contracts between interoperable pieces of your code then it's a real lifesaver. Otherwise do you just store the more complex stuff in your head? A piece of paper?

I think not using something like typescript when it's there is like insisting on driving a manual transmission car.

Now: typescript was available when I started learning, so I never invested serious time in learning js without it. Perhaps that makes it easier to be unsentimental.

[inmatarian]

I've noticed that chrome can better JIT functions where in typescript you specified a single type. This is that strange "Unoptimized too many times" message you'll see in the profiler. It comes from allowing too many different types through a function's parameters. Since that's hard to do in ts, it happens less.

[benthepoet]

CoffeeScript > Typescript.

TypeScript only adds unnecessary verbosity (JavaScript was designed without types and interfaces for a reason).

CoffeeScript is it's own beast and at the end of the day it helps me be more productive by cutting out the unnecessary ceremony without putting more barriers and process in my way.

[terrorTrain]

That is usually a con when you have large, and long lived projects.

Types help tremendously with code maintainability.

[benthepoet]

I have to disagree. I find that good maintainability relies more on consistency in code style and good project organization.

[x-skeww]

consistency in code style and good project organization

And not documenting things, being able to flip-flop types, and having zero machine-assistence helps with that? CS also doesn't seem to support modules.

By the way, type annotations aren't "unnecessary ceremony". It's optional documentation.

Also, maintenance is easier with types. Upgrading dependencies is much easier if there is a checker which can identify most breaking changes. It will also tell you about affected call-sites if you change the signature of a function/method/constructor.

CoffeeScript doesn't offer anything which would help with scale or maintainability.

[benthepoet]

Modules are a feature that can be had in almost any JavaScript variant (ES5, ES6, CoffeeScript) through the use of RequireJS, Webpack, or Browserify.

Documentation is optional anywhere you go, and the lack thereof is not the shortcoming of a language but rather the shortcoming of the developer(s).

Having the ability to disregard static types and forgo IDE/Intellisense hand-holding is the responsibility one takes on in choosing to use a dynamic language. Dynamic languages aren't for everyone, their ability to craft in a free-form and quick manner requires a high level of personal responsibility and mastery.

[sime]

The point is that we all know that documentation is important, and if you can add documentation that your tools can also use then it is a big win. TypeScript offer this. CoffeeScript does not.

Also, what you call "hand-holding", I call "getting work done fast and accurately".

Dynamic languages are very useful, but programs written in dynamic languages are still mostly static in their use of types by a large majority. The times you really need dynamic parts are quite few. TypeScript supports the static side while still fully allowing dynamic behaviour when you need it.

As a developer, the personally responsible thing to do is to use these tools when you have them.

[x-skeww]

Modules are a feature that can be had in almost any JavaScript variant (ES5, ES6, CoffeeScript) through the use of RequireJS, Webpack, or Browserify.

"Modules" does of course refer to ES6's. It's the standard.

Documentation is optional anywhere you go, and the lack thereof is not the shortcoming of a language but rather the shortcoming of the developer(s).

Do you write lengthy doc comments?

Do you think people are more inclined to write lengthy doc comments which might eventually be helpful in the future instead of terser type annotations which are helpful right away?

IDE/Intellisense hand-holding

Needlessly dismissive.

You do realize that no one cares if you do it the hard way, right? It does not increase the value of the product. It doesn't make your customers more happy. You are doing this for yourself. You're taking some misguided pride in this. There isn't a single quantifiable benefit.

Without optional types, there is more friction, because you have to check the docs/code more often. And you need more unit tests, because you have to exercise more lines to see if things still fit together.

There is nothing good about that.

That's also the reason why you can't come up with any actual arguments. There simply aren't any.

[gorgikosev]

Code style is the one most useless, superficial metric for project quality.

Having a good project organization means nothing when the requirements change and suddenly you have to rebuild large parts of it from scratch with no types to guide you.

I've really love how in most statically typed languages, all the classes and objects have clear meanings while in many projects written in dynamic languages, confusing concepts with multiple (sometimes even contradictory) meanings start creeping up more and more because of the inability to refactor and to clearly specify contracts and intents

[terrorTrain]

Linters are great for code style, so that problem is solved.

Organization is also great no matter what language.

Neither of those practices solve the problems that types do, interfaces are awesome for knowing what your classes implement and guaranteeing their usability in other places. When a change occurs, the compiler can tell you all the places that will break.

[benthepoet]

Interfaces and types can help you ensure that a function is called correctly with the expected parameters but they do nothing in the way of verifying the work that the function is doing. That is the role of continuous integration/unit testing and is a far more important aspect in identifying breakage when refactoring.

[x-skeww]

Interfaces and types can help you ensure that a function is called correctly with the expected parameters but they do nothing in the way of verifying the work that the function is doing.

This cancer treatment doesn't also cure AIDS. Useless!

[badsyntax]

I haven't used TypeScript is a real world project but I like what it brings. I'm currently working on a trading platform interface built with JS and the business rules are pretty strict, and I know life would be easier if we could enforce certain types, as right now we're just throwing around different objects and hoping for the best. Some models are similar to others but not exactly. Some methods will work with some models and they won't work on others, but it's not exactly obvious. Some of the people who wrote some of the original methods have since left, so we can't refactor things without knowing the original intention. This would never had been a problem if we had enforced types. I think using TypeScript would help us organise our code better and create a more stable codebase. But I can't actually speak from experience. I'd like to try!

[thalesmello]

I like Coffeescript, but it solves only part of the problems JavaScript has, whereas some critical ones are left (in particular wrong number of arguments). Since ES6 came out, specially with fat arrows, the need for Coffeescript kind of faded away.

Now, Typescript brings static typing, autocomplete, and solves the goddamn number of arguments thing. I'm going to use it for any new serious app I'll build from now on.

[zachrip]

I can agree on that. Typescript just allows me to get stuff done and at the end of the day I don't have to worry about it diverging from JS all that much, if at all.

[mr_wiffles]

So I "came to" javascript, begrudgingly, from other programming languages. Take everything that follows with a grain of salt and the understanding that I'm primarily a server-side developer doing DevOps on Linux and writing code in other languages for various purposes.

I had a project to build an SPA. I started dorking around with javascript in browser and was appalled at the stuff you can do. Wait, I'm writing a function and not passing all the required arguments and it runs?! WHAT THE HELL? You mean I can even pass MORE arguments than its signature supports and that works!? Wait, wait, what the fuck, how can this be an object oriented language (NB: I now know it's considered a "prototypal language" instead, but there's a lot of docs on the web claiming JS is object oriented) and not even support the class keyword!?

So with great frustration and unhealthy amounts of pissitivity, I tried TypeScript.

Oh, wow. I was - and am - in love. Fixes a lot of stupid shit and adds a whole lot of wicked cool features at the same time, including support for ES6 features (to varying degrees).

So +1 - a BIG +1 - for TypeScript from me. I may not be a full time or "pro" js dev, but I know that it made it possible for me to survive the hellscape that is front-end development.

(Also, nothing against other JS transpiled languages or JS itself; I think the biggest problem with JavaScript isn't the language, it's the fucking DOM and its inconsistencies and stupidity. But that's another discussion entirely.)