12 ms·

Love for TypeScript

220 points by svieira 10y ago

saosebastiao 10y ago
I cant believe how much more accessible typescript is than javascript. Type signatures are helpful. Refactoring is so much less stressful. Even things as simple as catching misspelled imports have saved me tons of time. At one point in time, a 'this' bug ate up half of my day. Ever since moving to typescript, I haven't had a single 'this' bug make it past the compiler. I still don't fucking understand 'this'...all I know is that Typescript knows what it is and can tell me to fix something before I send it off to the browser. Typescript will never be my favorite language...not even close. But since we can't actually get rid of javascript, I'm pretty happy we have typescript around to make it not suck so much.
- ridiculous_fish 10y ago
  TypeScript catches a lot, but "this" bugs are still one of the most common things it misses. For example, when factoring a method into a free function, I'll often miss a this: function hypot(x:number, y:number) { return Math.sqrt(this.x * this.x + this.y * this.y) } TypeScript does not warn about this case.
  - farnsworth 10y ago
    Check out the option "noImplicitThis" in TS2, for this exact case. It will ban using `this` when it's implicitly `any`. I agree that it was much needed!
    - ridiculous_fish 10y ago
      Great addition! Thanks for pointing it out.
  - hkjgkjy 10y ago
    A very happy way to live as a Javascript coder is to avoid the `this` keyword, in my experience. You really don't need it. Instead write this function as (x, y) => Math.sqrt(x*x + y*y) That can never have any state bugs, because it's a pure function (just like you can never have type errors with a sufficiently good type system). And you might be interested in the native JS function (since ES6) called Math.hypot. Happy hacking :-)
- BinaryIdiot 10y ago
  > I cant believe how much more accessible typescript is than javascript. Can you elaborate on your meaning? A language that requires transpiling by definition can't be more accessible than the language it transpiles into. > At one point in time, a 'this' bug ate up half of my day. Ever since moving to typescript, I haven't had a single 'this' bug make it past the compiler. I still don't fucking understand 'this'. 'this' can be a little complicated but it's really not that bad. I like the dry way the MDN explains 'this' [1] if you find it helpful. Even if you're using TypeScript I still think it's important to understand (TypeScript does compile into JavaScript after-all; debugging the transpiled output without chrome maps can be necessary at times). [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - regularfry 10y ago
    > A language that requires transpiling by definition can't be more accessible than the language it transpiles into. It's a funny definition of "accessible" that counts C as less accessible than assembler.
    - spriggan3 10y ago
      C doesn't transpile to assembler.
      - clappski 10y ago
        That's a rather arbitrary statement; C _compiles_ to machine code that maps pretty directly to an assembly language, which is normally not far off of the abstraction level offered by C. Taking the definition of transpile being translating to a language with a similar abstraction level, you're just picking hairs.
- jensvdh 10y ago
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... This is the best guide to "This".
SomeCallMeTim 10y ago
TypeScript is, in fact, awesome. 2.0 adds still more awesomeness, and 2.1 has async/await compiled down to ES3/ES5, which I will be very happy to see. The only thing that I don't understand is why TypeScript isn't just considered a required client (or Node) Best Practice at this point. There are other languages that I prefer for specific domains, of course. But if you're writing code that needs to run on a web client and/or that needs to run in Node, TypeScript is the only way to go.
- michaelchisari 10y ago
  For me, I've simply decided to just focus on javascript. I have to use it, and while I had quite a bit of enthusiasm for Coffeescript, the move towards ES6 has made me realize that I need to just buckle in. Maybe it's a little bit of fatigue setting in, but at this point, my next foray into a new language will be something properly compiled like Rust or Swift, not a transpiled language. This is not to detract from Typescript or Purescript or anything else like it. There's some amazing work going on, but for now, I'd rather learn the ins and outs of javascript instead, warts and all.
  - eloisant 10y ago
    It is good indeed to have a deep understanding of Javascript before using other tools. I've never really cared for Coffeescript (because I felt like it brought very little at the cost of a very different syntax) but Typescript really improves my productivity.
    - michaelchisari 10y ago
      I do miss meaningful whitespace. It's my favorite thing about Python. Although I recognize it's not for everyone, and it's purely a matter of aesthetics and preference.
      - gmac 10y ago
        Yeah, I have been all-in on CoffeeScript until recently, and significant whitespace is one of its best features for me. It's a DRY issue.
awalGarg 10y ago
This would be a little offtopic for this thread, but anyone knows if there is an example of using TypeScript with Node only as a typechecker (like flow)? Recently it was in news that TypeScript can understand JSDoc annotations - so I was wondering if I could use TypeScript as a typechecker for my code which is all 100% pure JS with JSDoc style type annotations. I tried flow, but flow's comment syntax for type annotations is not compatible with JSDoc, and flow really needs a lot of work still. I am hopeful it will improve, but I feel presently it isn't ready for primetime for large codebases on the server side. (I guess it works great for React though). Pretty new to TS but I like TS a lot as well!
- wwwigham 10y ago
  The TS compiler is usually configured to disregard most type errors in JS (even if it does infer a bunch types from JSDoc comments); if this would be super super useful for you, you should consider making an issue or upvoting an existing issue for it on the TS repo!
- alxlu 10y ago
  I've found https://www.npmjs.com/package/documentation https://www.npmjs.com/package/documentation to handle JSDoc + Flow annotations reasonably well.
johnfn 10y ago
TypeScript is straight up one of the best technologies I work with, rivaled only possibly by giants like Postgres. It takes one of the worst parts of my day - refactoring Javascript code - and makes it straightforward and enjoyable. TypeScript 2.0 goes beyond that and begins to push the envelope on what type systems can do. Recently I've been loving the combination of discriminated union types and nullable types. It means that you can have code like this: function myFunction(x: number | null) { if (x === null) { return; } console.log(x + 1); // x is now a number } The argument to the function is x, which is either number or null (that's what number | null means). But the if statement ensures it's not null by exiting the function, so by the time you get to the log TypeScript has (correctly) set the type of x to be just number! The types match up exactly with how you'd write the Javascript code. It's awesome and it just works.
- gprasanth 10y ago
  What happens when x is 0?
  - deleted 10y ago
    [deleted]
  - johnfn 10y ago
    Good question - edited my code to be correct.
  - ww520 10y ago
    I think it's just the sample code needs to be x === null. Nothing to do with TypeScript. The sample is a good example to illustrate the union type.
    - noselasd 10y ago
      On that note, are there any documentation that explains the == and === operators in Typescript ? The language spec is only briefly acknowledges the existence of those operators.
einrealist 10y ago
We introduced Typescript into our architecture. We start to love it, too. One thing though: the engineers started to write classes for everything. I had to catch that and forced them to stay as functional as possible. Does that happen to other teams, too? And I really like to see WebAssembly to become part of our browsers and Typescript generating it instantly.
- randomvariable 10y ago
  I've written a lot of Angular code with Typescript and although you're right in saying functional code is preferrable I've found that a little bit OO when used correctly makes your code DRYer. For example, if you have a lot of paginated lists you can write an abstract class that handles all the "get the results", "put them on a list", "display pagination", "on click display the next/previous page" trivia and then inherit from that to add the UI/presentation and any specific logic. It's absolutely possible in plain javascript but I shudder at the thought of writing something like that and even worse, refactor it. Typescript with OO and generics simplifies the task considerably. As in everything in life: "dogma is bad", "παν μέτρον άριστον", "use the best tool for the job" etc. Words to live by.
  - einrealist 10y ago
    Of course, I don't forbid to use OO. Its just adds more boilerplate if ES5 is generated and increases the size of the code. And the ES5 code we migrate is already mostly functional. For cross cutting concerns like pagination, we already have functions that enhance the pagination controls.
- joobus 10y ago
  I'm hoping WebAssembly opens up lots of other languages to browser development. Any language could compile to WebAssembly: rust, haskell, go, swift, etc. I think it will really open up the browser.
- kevingadd 10y ago
  TypeScript will never generate WebAssembly for you. WA is used for hosting your own sandboxed native code environments, it doesn't offer any of the tooling you'd need to run TypeScript-based libraries/applications.
isoos 10y ago
It is interesting for me to follow how the community mindset develops around TypeScript/JS/... over the years. Many in the JavaScript community frowned upon GWT, Closure Compiler, Dart and other typed compile-to-JS tools, most of which predate TypeScript, and provided state-of-the-art tooling at the time. "Types are overrated, everything that is non-JS must go away" was a common mentality. Now some of these people started to see some value in tool-based refactoring, and suddenly realize that types are not always bad. TypeScript undeniably improves the situation over JavaScript, with the caveat that it won't stop you shooting in the foot with the bad parts of JS. So now, types are good, nevertheless JS must stay. I wonder how many years it will take for people to lobby for a clear break of JS backwards-compatibility, to use something that is not ad-hoc, has good tooling and a great base API, etc. Something where sorting number doesn't need additional extra care. These usually start to matter when the team size is beyond 10 person working on the same part of the codebase. It will be interesting to see how this spans over the years. I bet the earliest "clear break of bad JS" will happen around 2019, with mostly linters and data flow analysis improving but hitting the eventual limits. Uninteresting times, in a certain sense. I'm glad we have other tools to compete with.
- yulaow 10y ago
  I think at this point we just have to wait for a good support for webassembly on all main browsers and then everyone can have its own ""isomorphic"" stack and we can finally stop these wars about how to modify javascript and what features to introduce because we all will finally have other alternatives to choose.
  - thaumasiotes 10y ago
    What do you see as the difference between a language that compiles to javascript and a language that compiles to webassembly?
    - mafribe 10y ago
      Javascript currently doesn't provide viable concurrency which makes translating languages that do a problem. Parsing Javascript can also be a performance bottleneck for some applications as Javascript parsing is somewhat expensive in comparison with Webassembly.
scotty79 10y ago
Wait? Same guy built Turbo Pascal, Delphi, C# and now Type Script? First three is the list of languages that make me feel at home when I'm doing desktop development. Yet another reason to seriosly try TypeScript with default tooling if it's comming from this guy. His work is beacon of sanity in tangled world of software development.
- mercer 10y ago
  Yeah, for me one reason to give TypeScript a serious go was that I grew up on Turbo Pascal and Delphi, and a bit of C# experience. Haven't been disappointed.
Retozi 10y ago
TypeScript is the one technology I would discard last of the entire web stack. Using TypeScript instead of JavaScript is such a productivity boost for a team developing a sizeable single page application, any other technical decision (which Framework, tooling decisions) is almost irrelevant relative to this major improvement. TypeScript has ALL the properties that should make adoption a no-brainer: 1) Increases developer productivity, especially over long term maintenance timeframes. (My non-scientific, ymmv estimate is at least 30%) 2) Reduces production exception rate significantly 3) Can be adopted gradually 4) Full JavaScript ecosystem still at disposal People seem to massively underestimate the benefit of a typed language in a frontend codebase. At gunpoint, I would rather have the backend in a dynamically typed language and keep TypeScript for the frontend. Chances are that the distance between your database and the API is not far, so static typing is not that useful. However, if you have decided for a client side rendered application, your app is stateful, dynamic and probably quite big. Static typing really helps to avoid mistakes and increases the ability to refactor quickly and correctly by order of magnitude. There are too many hardly ever visited code branches, and tests are very costly to write for an application where users can click a lot of things.
- rubber_duck 10y ago
  It's not even the fact that JS is dynamically typed it's that it's the worst of dynamic typing - magic strings, monkey-patching, retarded scoping rules coupled with callback pyramids all over the place, no proper modules - you just get no meaningful help from tooling as soon as your code base grows to even medium complexity. ES6 helps but TS brings all that + more. Python IDEs like PyCharm offer far superior tooling even without static typing, and Clojure is so nice I don't usually even need the tools.
  - r2dnb 10y ago
    I get your point, but while I am a big advocate of typescript, I think that the topology of the javascript language is perfectly suited for front-end development. There are a lot of impedance mismatches to deal with in the front end, (javascript to DOM, json to javascript, diversity of execution environments etc...), and I feel that when correctly used, dynamism the way javascript does it is a god-send. All my core developments are in typescript, but in many situations it feels so magic to just do : myprop.undeclared = value and encapsulate the stuff in a knockout component written in typescript, while the situation would have caused a drama / major redesign in a back-end static language (C#, Java etc...). There are many valid scenarios (not resulting from a wrong OOP design) where this is very useful. I'm actually amazed that people who designed Javascript got it so right. Static languages are great in the backend, typescript is great for the front-end and solved a real maintenance and Q&A issue by providing a level of typing and popularizing OOP in the front-end, but javacript is great for the web browser in general. Typescript is the piece that was missing, but this doesn't mean that javascript is broken, the elasticity of the language is a very powerful and elegant solution for the problems specific to the front-end.
bricss 10y ago
Maybe it could be better to just learn JavaScript?
- themihai 10y ago
  TS was developed to avoid replacement of JS(i.e by something like Dart) so I doubt better JS training could help it.
- d357r0y3r 10y ago
  TypeScript doesn't let you avoid learning JavaScript fundamentals. The same basic rules still apply. The difference is having a compiler and a type system that tells you when you've broken things. Most people that have actually used TypeScript for any length of time understand the type system to be invaluable.
  - bricss 10y ago
    FYI -> https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3#.sh9gk2gsf https://medium.com/javascript-scene/the-shocking-secret-abou...
    - d357r0y3r 10y ago
      Not a strong argument. Static typing prevents a certain class of bugs. There are a ton of bugs that it does nothing for, which is why tests are still useful.
    - sotojuan 10y ago
      Using Eric Elliott articles as a source is never a good idea. The guy is way too dogmatic and even crazy/harmful.
a-saleh 10y ago
Did any of you have good experience using typescript on node.js project? I remember trying out typescript with few tutorials, but so far mostly on the browser side (i.e angular 2 is in typescript) and when I poked around I couldn't really figure out how to hook up to the npm ecosystem. Was that just a lack of decent google-fu that particular day?
- pingec 10y ago
  Sure, there are a few steps to make a hello world work but then you soon realise they make sense and it's smooth sailing. I would suggest this link: https://code.visualstudio.com/docs/runtimes/nodejs https://code.visualstudio.com/docs/runtimes/nodejs
- d357r0y3r 10y ago
  Yes, wouldn't even consider using node without TypeScript, personally. Really, the main pieces that could seems a little mysterious are type definitions and compiler options. tsconfig.json exists in the root of the project for compiler options. Type definitions can be managed by a library called 'typings', or for TypeScript 2.0, type definitions can be managed with npm.
  - mercer 10y ago
    The biggest problems I had with TypeScript involved type definitions, combined with the module system. Now, the latter is not TS' fault and a bit clusterfuck at the moment for everyone, but it's a bit more complicated if you add TS to the mix. It's improved immensely though in the past months/year.
mark_l_watson 10y ago
I like TypeScript for what is probably a different reason than most people. I have started using TypeScript as a great languge for book examples. The language is so easy to read and understand, and it is so quick to install the compiler and runtime. Right now I am using it for many of the examples for a book Introduction to Cognitive Science that I am writing. TypeScript is a great universal language for thinking about code and algorithms.
- Noseshine 10y ago
  Ahem... TypeScript is 100% Javascript, they only add optional type annotations. The "to-ES5" compilation serves a different issue - that's just a different version of Javascript.
  - mark_l_watson 10y ago
    But I use the surface TypeScript syntax for the book examples. It is a clear and concise notation, which is why I like it for this use case.
    - Noseshine 10y ago
      I have no idea what you mean by > surface TypeScript syntax TypeScript syntax is... Javascript (ES 2015 or above) - plus the optional type annotations and some few minor additions like "enum" or decorators. Things like "interface" don't compile to actual code, they only serve the compile-time type checks.
q1t 10y ago
How is Dart doing comparing to TypeScript? I mean what are significant differences?
deevus 10y ago
I too, love TypeScript. The client side JS where I work was becoming a bit of a horrible beast so I started using TypeScript here and there when I worked on new things. It has really helped rein in some un-maintainable messes. It's got to the point now where TypeScript is my default go-to language because it's so powerful. Someone mentioned how great it is for strongly typing API's and libraries, and I have to second this. When there aren't typings available it forces me to RTFM instead of just prodding around in intellisense, so in some cases it actually helps me learn libraries better. Just today I created a boilerplate project for webpack/typescript 2 [0]. It's not finished yet, but it's usable if you wanted to jump right into TypeScript with no run-time dependencies. As a bonus I modified the same boilerplate but for HTML [1] [0]: https://github.com/deevus/webpack-typescript2-boilerplate https://github.com/deevus/webpack-typescript2-boilerplate [1]: https://github.com/deevus/webpack-typescript2-html-boilerplate https://github.com/deevus/webpack-typescript2-html-boilerpla...
qwertyuiop924 10y ago
Wow. I feel like the only person who doesn't especially like static typing, traditional OO, and typescript.
- GFischer 10y ago
  Many people like myself like static typing and don't particularly care for "traditional OO". I wouldn't put them all in the same bag. Heljsberg himself (the creator of TypeScript) likes functional programming a lot and brings the best features to his languages. I haven't tried TypeScript yet, but I look forward to it :) http://www.itwriting.com/blog/2443-anders-hejlsberg-on-functional-programming-programming-futures.html http://www.itwriting.com/blog/2443-anders-hejlsberg-on-funct...
  - qwertyuiop924 10y ago
    I put it in because TS added 'class' to the language
gaoshan 10y ago
I will say that I'm my experience developers with a background in C# seem to love Typescript while developers with a background in Javascript seem to be slower to warm up (a lot slower). In our office it seems like the JS folks are sensing that they should "get on board" with the clear enthusiasm from the C# folks but there is resistance (mostly muttered quietly to each other to avoid looking like they don't get something that seems so obvious to others).
agentgt 10y ago
Did anyone else chuckle at the bug labels (I often find weird things funny)?
andrewclunn 10y ago
Sorry, but unless browsers srart interpreting typescript directly, I won't be using it. I'm done with flavor of the month preprocessors. I'll code in the base language and focus on developing my skills there.
- pmoleri 10y ago
  I totally get your point and I would think the same if all browsers supported ES6. But right now I would transpile just to use ES6, and TS adds a lot of goodies on top of that. Also, TS is pretty stable and proved its value, it isn't a flavor of the month transpiler.
zumu 10y ago
What are some reasons to switch from flow to ts? I see a lot if ts hype, but flow has been getting the job done for me. When non-nullable types come to ts via 2.0, I could see myself switching if there are viable reasons.
- shados 10y ago
  basically, on paper flow is better. However, lack of Windows support and poor tooling, plus the fact that it was second to market, slowed down its adoption. Now you have the issue where TypeScript has thousands of type definition for a lot of libraries, and Flow only has a few. Facebook keeps underestimating Windows (eg: there was a survey out for a while asking people if they should just stop working on Windows support for Jest and depend on Windows 10's linux userland support instead). That, coupled with Flow being harder to get up and running, makes TypeScript much more popular for the average developers. I still prefer Flow though :(

220 points by svieira 10y ago

I cant believe how much more accessible typescript is than javascript. Type signatures are helpful. Refactoring is so much less stressful. Even things as simple as catching misspelled imports have saved me tons of time. At one point in time, a 'this' bug ate up half of my day. Ever since moving to typescript, I haven't had a single 'this' bug make it past the compiler. I still don't fucking understand 'this'...all I know is that Typescript knows what it is and can tell me to fix something before I send it off to the browser. Typescript will never be my favorite language...not even close. But since we can't actually get rid of javascript, I'm pretty happy we have typescript around to make it not suck so much.

ridiculous_fish 10y ago
TypeScript catches a lot, but "this" bugs are still one of the most common things it misses. For example, when factoring a method into a free function, I'll often miss a this: function hypot(x:number, y:number) { return Math.sqrt(this.x * this.x + this.y * this.y) } TypeScript does not warn about this case.
- farnsworth 10y ago
  Check out the option "noImplicitThis" in TS2, for this exact case. It will ban using `this` when it's implicitly `any`. I agree that it was much needed!
  - ridiculous_fish 10y ago
    Great addition! Thanks for pointing it out.
- hkjgkjy 10y ago
  A very happy way to live as a Javascript coder is to avoid the `this` keyword, in my experience. You really don't need it. Instead write this function as (x, y) => Math.sqrt(x*x + y*y) That can never have any state bugs, because it's a pure function (just like you can never have type errors with a sufficiently good type system). And you might be interested in the native JS function (since ES6) called Math.hypot. Happy hacking :-)
BinaryIdiot 10y ago
> I cant believe how much more accessible typescript is than javascript. Can you elaborate on your meaning? A language that requires transpiling by definition can't be more accessible than the language it transpiles into. > At one point in time, a 'this' bug ate up half of my day. Ever since moving to typescript, I haven't had a single 'this' bug make it past the compiler. I still don't fucking understand 'this'. 'this' can be a little complicated but it's really not that bad. I like the dry way the MDN explains 'this' [1] if you find it helpful. Even if you're using TypeScript I still think it's important to understand (TypeScript does compile into JavaScript after-all; debugging the transpiled output without chrome maps can be necessary at times). [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- regularfry 10y ago
  > A language that requires transpiling by definition can't be more accessible than the language it transpiles into. It's a funny definition of "accessible" that counts C as less accessible than assembler.
  - spriggan3 10y ago
    C doesn't transpile to assembler.
    - clappski 10y ago
      That's a rather arbitrary statement; C _compiles_ to machine code that maps pretty directly to an assembly language, which is normally not far off of the abstraction level offered by C. Taking the definition of transpile being translating to a language with a similar abstraction level, you're just picking hairs.
jensvdh 10y ago
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... This is the best guide to "This".

SomeCallMeTim 10y ago

TypeScript is, in fact, awesome. 2.0 adds still more awesomeness, and 2.1 has async/await compiled down to ES3/ES5, which I will be very happy to see. The only thing that I don't understand is why TypeScript isn't just considered a required client (or Node) Best Practice at this point. There are other languages that I prefer for specific domains, of course. But if you're writing code that needs to run on a web client and/or that needs to run in Node, TypeScript is the only way to go.

michaelchisari 10y ago
For me, I've simply decided to just focus on javascript. I have to use it, and while I had quite a bit of enthusiasm for Coffeescript, the move towards ES6 has made me realize that I need to just buckle in. Maybe it's a little bit of fatigue setting in, but at this point, my next foray into a new language will be something properly compiled like Rust or Swift, not a transpiled language. This is not to detract from Typescript or Purescript or anything else like it. There's some amazing work going on, but for now, I'd rather learn the ins and outs of javascript instead, warts and all.
- eloisant 10y ago
  It is good indeed to have a deep understanding of Javascript before using other tools. I've never really cared for Coffeescript (because I felt like it brought very little at the cost of a very different syntax) but Typescript really improves my productivity.
  - michaelchisari 10y ago
    I do miss meaningful whitespace. It's my favorite thing about Python. Although I recognize it's not for everyone, and it's purely a matter of aesthetics and preference.
    - gmac 10y ago
      Yeah, I have been all-in on CoffeeScript until recently, and significant whitespace is one of its best features for me. It's a DRY issue.

awalGarg 10y ago

This would be a little offtopic for this thread, but anyone knows if there is an example of using TypeScript with Node only as a typechecker (like flow)? Recently it was in news that TypeScript can understand JSDoc annotations - so I was wondering if I could use TypeScript as a typechecker for my code which is all 100% pure JS with JSDoc style type annotations. I tried flow, but flow's comment syntax for type annotations is not compatible with JSDoc, and flow really needs a lot of work still. I am hopeful it will improve, but I feel presently it isn't ready for primetime for large codebases on the server side. (I guess it works great for React though). Pretty new to TS but I like TS a lot as well!

wwwigham 10y ago
The TS compiler is usually configured to disregard most type errors in JS (even if it does infer a bunch types from JSDoc comments); if this would be super super useful for you, you should consider making an issue or upvoting an existing issue for it on the TS repo!
alxlu 10y ago
I've found https://www.npmjs.com/package/documentation https://www.npmjs.com/package/documentation to handle JSDoc + Flow annotations reasonably well.

johnfn 10y ago

TypeScript is straight up one of the best technologies I work with, rivaled only possibly by giants like Postgres. It takes one of the worst parts of my day - refactoring Javascript code - and makes it straightforward and enjoyable. TypeScript 2.0 goes beyond that and begins to push the envelope on what type systems can do. Recently I've been loving the combination of discriminated union types and nullable types. It means that you can have code like this: function myFunction(x: number | null) { if (x === null) { return; } console.log(x + 1); // x is now a number } The argument to the function is x, which is either number or null (that's what number | null means). But the if statement ensures it's not null by exiting the function, so by the time you get to the log TypeScript has (correctly) set the type of x to be just number! The types match up exactly with how you'd write the Javascript code. It's awesome and it just works.

gprasanth 10y ago
What happens when x is 0?
- deleted 10y ago
  [deleted]
- johnfn 10y ago
  Good question - edited my code to be correct.
- ww520 10y ago
  I think it's just the sample code needs to be x === null. Nothing to do with TypeScript. The sample is a good example to illustrate the union type.
  - noselasd 10y ago
    On that note, are there any documentation that explains the == and === operators in Typescript ? The language spec is only briefly acknowledges the existence of those operators.

einrealist 10y ago

We introduced Typescript into our architecture. We start to love it, too. One thing though: the engineers started to write classes for everything. I had to catch that and forced them to stay as functional as possible. Does that happen to other teams, too? And I really like to see WebAssembly to become part of our browsers and Typescript generating it instantly.

randomvariable 10y ago
I've written a lot of Angular code with Typescript and although you're right in saying functional code is preferrable I've found that a little bit OO when used correctly makes your code DRYer. For example, if you have a lot of paginated lists you can write an abstract class that handles all the "get the results", "put them on a list", "display pagination", "on click display the next/previous page" trivia and then inherit from that to add the UI/presentation and any specific logic. It's absolutely possible in plain javascript but I shudder at the thought of writing something like that and even worse, refactor it. Typescript with OO and generics simplifies the task considerably. As in everything in life: "dogma is bad", "παν μέτρον άριστον", "use the best tool for the job" etc. Words to live by.
- einrealist 10y ago
  Of course, I don't forbid to use OO. Its just adds more boilerplate if ES5 is generated and increases the size of the code. And the ES5 code we migrate is already mostly functional. For cross cutting concerns like pagination, we already have functions that enhance the pagination controls.
joobus 10y ago
I'm hoping WebAssembly opens up lots of other languages to browser development. Any language could compile to WebAssembly: rust, haskell, go, swift, etc. I think it will really open up the browser.
kevingadd 10y ago
TypeScript will never generate WebAssembly for you. WA is used for hosting your own sandboxed native code environments, it doesn't offer any of the tooling you'd need to run TypeScript-based libraries/applications.

isoos 10y ago

It is interesting for me to follow how the community mindset develops around TypeScript/JS/... over the years. Many in the JavaScript community frowned upon GWT, Closure Compiler, Dart and other typed compile-to-JS tools, most of which predate TypeScript, and provided state-of-the-art tooling at the time. "Types are overrated, everything that is non-JS must go away" was a common mentality. Now some of these people started to see some value in tool-based refactoring, and suddenly realize that types are not always bad. TypeScript undeniably improves the situation over JavaScript, with the caveat that it won't stop you shooting in the foot with the bad parts of JS. So now, types are good, nevertheless JS must stay. I wonder how many years it will take for people to lobby for a clear break of JS backwards-compatibility, to use something that is not ad-hoc, has good tooling and a great base API, etc. Something where sorting number doesn't need additional extra care. These usually start to matter when the team size is beyond 10 person working on the same part of the codebase. It will be interesting to see how this spans over the years. I bet the earliest "clear break of bad JS" will happen around 2019, with mostly linters and data flow analysis improving but hitting the eventual limits. Uninteresting times, in a certain sense. I'm glad we have other tools to compete with.

yulaow 10y ago
I think at this point we just have to wait for a good support for webassembly on all main browsers and then everyone can have its own ""isomorphic"" stack and we can finally stop these wars about how to modify javascript and what features to introduce because we all will finally have other alternatives to choose.
- thaumasiotes 10y ago
  What do you see as the difference between a language that compiles to javascript and a language that compiles to webassembly?
  - mafribe 10y ago
    Javascript currently doesn't provide viable concurrency which makes translating languages that do a problem. Parsing Javascript can also be a performance bottleneck for some applications as Javascript parsing is somewhat expensive in comparison with Webassembly.

scotty79 10y ago

Wait? Same guy built Turbo Pascal, Delphi, C# and now Type Script? First three is the list of languages that make me feel at home when I'm doing desktop development. Yet another reason to seriosly try TypeScript with default tooling if it's comming from this guy. His work is beacon of sanity in tangled world of software development.

mercer 10y ago
Yeah, for me one reason to give TypeScript a serious go was that I grew up on Turbo Pascal and Delphi, and a bit of C# experience. Haven't been disappointed.

Retozi 10y ago

TypeScript is the one technology I would discard last of the entire web stack. Using TypeScript instead of JavaScript is such a productivity boost for a team developing a sizeable single page application, any other technical decision (which Framework, tooling decisions) is almost irrelevant relative to this major improvement. TypeScript has ALL the properties that should make adoption a no-brainer: 1) Increases developer productivity, especially over long term maintenance timeframes. (My non-scientific, ymmv estimate is at least 30%) 2) Reduces production exception rate significantly 3) Can be adopted gradually 4) Full JavaScript ecosystem still at disposal People seem to massively underestimate the benefit of a typed language in a frontend codebase. At gunpoint, I would rather have the backend in a dynamically typed language and keep TypeScript for the frontend. Chances are that the distance between your database and the API is not far, so static typing is not that useful. However, if you have decided for a client side rendered application, your app is stateful, dynamic and probably quite big. Static typing really helps to avoid mistakes and increases the ability to refactor quickly and correctly by order of magnitude. There are too many hardly ever visited code branches, and tests are very costly to write for an application where users can click a lot of things.

rubber_duck 10y ago
It's not even the fact that JS is dynamically typed it's that it's the worst of dynamic typing - magic strings, monkey-patching, retarded scoping rules coupled with callback pyramids all over the place, no proper modules - you just get no meaningful help from tooling as soon as your code base grows to even medium complexity. ES6 helps but TS brings all that + more. Python IDEs like PyCharm offer far superior tooling even without static typing, and Clojure is so nice I don't usually even need the tools.
- r2dnb 10y ago
  I get your point, but while I am a big advocate of typescript, I think that the topology of the javascript language is perfectly suited for front-end development. There are a lot of impedance mismatches to deal with in the front end, (javascript to DOM, json to javascript, diversity of execution environments etc...), and I feel that when correctly used, dynamism the way javascript does it is a god-send. All my core developments are in typescript, but in many situations it feels so magic to just do : myprop.undeclared = value and encapsulate the stuff in a knockout component written in typescript, while the situation would have caused a drama / major redesign in a back-end static language (C#, Java etc...). There are many valid scenarios (not resulting from a wrong OOP design) where this is very useful. I'm actually amazed that people who designed Javascript got it so right. Static languages are great in the backend, typescript is great for the front-end and solved a real maintenance and Q&A issue by providing a level of typing and popularizing OOP in the front-end, but javacript is great for the web browser in general. Typescript is the piece that was missing, but this doesn't mean that javascript is broken, the elasticity of the language is a very powerful and elegant solution for the problems specific to the front-end.

bricss 10y ago

Maybe it could be better to just learn JavaScript?

themihai 10y ago
TS was developed to avoid replacement of JS(i.e by something like Dart) so I doubt better JS training could help it.
d357r0y3r 10y ago
TypeScript doesn't let you avoid learning JavaScript fundamentals. The same basic rules still apply. The difference is having a compiler and a type system that tells you when you've broken things. Most people that have actually used TypeScript for any length of time understand the type system to be invaluable.
- bricss 10y ago
  FYI -> https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3#.sh9gk2gsf https://medium.com/javascript-scene/the-shocking-secret-abou...
  - d357r0y3r 10y ago
    Not a strong argument. Static typing prevents a certain class of bugs. There are a ton of bugs that it does nothing for, which is why tests are still useful.
  - sotojuan 10y ago
    Using Eric Elliott articles as a source is never a good idea. The guy is way too dogmatic and even crazy/harmful.

a-saleh 10y ago

Did any of you have good experience using typescript on node.js project? I remember trying out typescript with few tutorials, but so far mostly on the browser side (i.e angular 2 is in typescript) and when I poked around I couldn't really figure out how to hook up to the npm ecosystem. Was that just a lack of decent google-fu that particular day?

pingec 10y ago
Sure, there are a few steps to make a hello world work but then you soon realise they make sense and it's smooth sailing. I would suggest this link: https://code.visualstudio.com/docs/runtimes/nodejs https://code.visualstudio.com/docs/runtimes/nodejs
d357r0y3r 10y ago
Yes, wouldn't even consider using node without TypeScript, personally. Really, the main pieces that could seems a little mysterious are type definitions and compiler options. tsconfig.json exists in the root of the project for compiler options. Type definitions can be managed by a library called 'typings', or for TypeScript 2.0, type definitions can be managed with npm.
- mercer 10y ago
  The biggest problems I had with TypeScript involved type definitions, combined with the module system. Now, the latter is not TS' fault and a bit clusterfuck at the moment for everyone, but it's a bit more complicated if you add TS to the mix. It's improved immensely though in the past months/year.

mark_l_watson 10y ago

I like TypeScript for what is probably a different reason than most people. I have started using TypeScript as a great languge for book examples. The language is so easy to read and understand, and it is so quick to install the compiler and runtime. Right now I am using it for many of the examples for a book Introduction to Cognitive Science that I am writing. TypeScript is a great universal language for thinking about code and algorithms.

Noseshine 10y ago
Ahem... TypeScript is 100% Javascript, they only add optional type annotations. The "to-ES5" compilation serves a different issue - that's just a different version of Javascript.
- mark_l_watson 10y ago
  But I use the surface TypeScript syntax for the book examples. It is a clear and concise notation, which is why I like it for this use case.
  - Noseshine 10y ago
    I have no idea what you mean by > surface TypeScript syntax TypeScript syntax is... Javascript (ES 2015 or above) - plus the optional type annotations and some few minor additions like "enum" or decorators. Things like "interface" don't compile to actual code, they only serve the compile-time type checks.

q1t 10y ago

How is Dart doing comparing to TypeScript? I mean what are significant differences?

deevus 10y ago

I too, love TypeScript. The client side JS where I work was becoming a bit of a horrible beast so I started using TypeScript here and there when I worked on new things. It has really helped rein in some un-maintainable messes. It's got to the point now where TypeScript is my default go-to language because it's so powerful. Someone mentioned how great it is for strongly typing API's and libraries, and I have to second this. When there aren't typings available it forces me to RTFM instead of just prodding around in intellisense, so in some cases it actually helps me learn libraries better. Just today I created a boilerplate project for webpack/typescript 2 [0]. It's not finished yet, but it's usable if you wanted to jump right into TypeScript with no run-time dependencies. As a bonus I modified the same boilerplate but for HTML [1] [0]: https://github.com/deevus/webpack-typescript2-boilerplate https://github.com/deevus/webpack-typescript2-boilerplate [1]: https://github.com/deevus/webpack-typescript2-html-boilerplate https://github.com/deevus/webpack-typescript2-html-boilerpla...

qwertyuiop924 10y ago

Wow. I feel like the only person who doesn't especially like static typing, traditional OO, and typescript.

GFischer 10y ago
Many people like myself like static typing and don't particularly care for "traditional OO". I wouldn't put them all in the same bag. Heljsberg himself (the creator of TypeScript) likes functional programming a lot and brings the best features to his languages. I haven't tried TypeScript yet, but I look forward to it :) http://www.itwriting.com/blog/2443-anders-hejlsberg-on-functional-programming-programming-futures.html http://www.itwriting.com/blog/2443-anders-hejlsberg-on-funct...
- qwertyuiop924 10y ago
  I put it in because TS added 'class' to the language

gaoshan 10y ago

I will say that I'm my experience developers with a background in C# seem to love Typescript while developers with a background in Javascript seem to be slower to warm up (a lot slower). In our office it seems like the JS folks are sensing that they should "get on board" with the clear enthusiasm from the C# folks but there is resistance (mostly muttered quietly to each other to avoid looking like they don't get something that seems so obvious to others).

agentgt 10y ago

Did anyone else chuckle at the bug labels (I often find weird things funny)?

andrewclunn 10y ago

Sorry, but unless browsers srart interpreting typescript directly, I won't be using it. I'm done with flavor of the month preprocessors. I'll code in the base language and focus on developing my skills there.

pmoleri 10y ago
I totally get your point and I would think the same if all browsers supported ES6. But right now I would transpile just to use ES6, and TS adds a lot of goodies on top of that. Also, TS is pretty stable and proved its value, it isn't a flavor of the month transpiler.

zumu 10y ago

What are some reasons to switch from flow to ts? I see a lot if ts hype, but flow has been getting the job done for me. When non-nullable types come to ts via 2.0, I could see myself switching if there are viable reasons.

shados 10y ago
basically, on paper flow is better. However, lack of Windows support and poor tooling, plus the fact that it was second to market, slowed down its adoption. Now you have the issue where TypeScript has thousands of type definition for a lot of libraries, and Flow only has a few. Facebook keeps underestimating Windows (eg: there was a survey out for a while asking people if they should just stop working on Windows support for Jest and depend on Windows 10's linux userland support instead). That, coupled with Flow being harder to get up and running, makes TypeScript much more popular for the average developers. I still prefer Flow though :(