7 ms·

Have you used TypeScript? Try it out for a month or two on a real project. It's the best thing that has happened to web development in recent years - it improv

Have you used TypeScript? Try it out for a month or two on a real project. It's the best thing that has happened to web development in recent years - it improves Javascript in a completely compatible and future proof way. The most amazing thing is that Microsoft created it. It's the polar opposite of Old Microsoft - standards are being followed (not subverted), it's simple pragmatic and has no lock-in.

awjr 11y ago
I cannot vote this up enough. It really is such a different experience to developing in "plain" JavaScript.
- echelon 11y ago
  It's so much more pleasant to write and maintain than wild, un(type)safe javascript.
  - acjohnson55 11y ago
    Only problem is that it's not sound. That means that while it may provide static checking that your program is validly linked together, it can't fully prevent run-time type errors. And kind of like you can't be "a little pregnant", you can't be "a little typesafe".
    - JoeAltmaier 11y ago
      Of course you can. Can't catch all the bugs; but can catch some of them. Which saves time and money. It doesn't actually have to be perfect to be useful and helpful.
      - acjohnson55 11y ago
        I'm not saying it doesn't help. I'm saying you can't count on it the same way you can if you're working in a truly end-to-end statically typed environment. Even Scala's type system has its leaks, due to nulls.
Hurtak 11y ago
Is TypeScript really future proof? I mean unless types, exactly implemented as they are in TypeScript, will become part of the spec, we can't really call it future proof. Also how is it compatible with anything, JavaScript is compatible with TypeScript, since TypeScript is superset of JS, but it is not compatible the other way around.
- nothrabannosir 11y ago
  Yes, it is. Compiling TS just removes type annotations; the compilation output (.js) is as readable as your original .ts. It has the same structure, same indentation, same variable names, same whitespace, same comments, same everything. This also makes debugging the code in the browser very easy. TS does not add any semantic features, it only adds type annotations. Which it checks at compile time, and then removes. That's it. Want to switch away from TS? Compile all your .ts files, save the .js, check that into your repo and continue from there. (As other commenters sort-of pointed out: you will need to keep Babel in your pipeline.)
  - agumonkey 11y ago
    Interesting, I never 'considered' that. It's basically a thin typechecker linguistic layer. A variant of gradual typing.
  - Roboprog 11y ago
    Thanks for the concrete description. Can I still use dynamic constructs such as string subscripts to associative arrays and code generation via eval()?
    - nothrabannosir 11y ago
      You mean in TS? Yes. ∀ x: I can do x in JS → I can do x in TS But, let's assume for a second that you couldn't: this thread is about TS being future-proof. I.e.: ∃ x: I can do x in TS & I cannot do x in JS? No, false. This implies TS = JS. And that's the point: semantically, TS = JS.
im_down_w_otp 11y ago
If Elm didn't also exist, I'd almost agree with you.
- tommyd 11y ago
  In an ideal world I'm sure a lot of us would love to work with Elm, but the reality in a commercial situation is often that the choice of language is driven by factors like: how widely used/well known it is, what the availability of libraries for it is like, how easy it is to hire developers with experience for. This unfortunately makes languages like Elm and Clojurescript unlikely to be chosen in a lot of situations (e.g. as I understand it, the JS interop story with Elm isn't amazing, so you can't just use JS libraries with it). Typescript is close enough to plain Javascript to not scare people off (I'd be willing to bet any JS developer could pick it up in a few hours) and can almost be considered in the same light as vanilla JS in such a decision, yet brings with it the advantages of a fairly decent type system. As I've said elsewhere, it's definitely not perfect, but for developers in a position where other, more "esoteric" compile-to-JS languages aren't likely to be accepted, Typescript probably represents the best choice of bringing a decent amount of sanity and predictability to codebases. (This isn't meant to be having a go at the parent BTW, it's just something I've been thinking about a bit and the comment jogged my memory!)
  - rtfeldman 11y ago
    You can totally use JS libraries with Elm. Source: we do it all the time at NoRedInk, and we've been using Elm in production for our millions of users (as our go-to for all front-end work at the company, not just as a side thing) for the better part of a year now. :) Details about our experience with Elm in production: https://www.youtube.com/watch?v=R2FtMbb-nLs https://www.youtube.com/watch?v=R2FtMbb-nLs
    - tommyd 11y ago
      That's interesting to know! Thanks
    - pka 11y ago
lcfcjs 11y ago
Oh yeah? Just like coffeescript was a couple years ago? Give me a break.
bpicolo 11y ago
Have you used ClojureScript? Try it out for a month or two on a real project. We can do this all day ;)
- hnbroseph 11y ago
  not sure what you're trying to say.
  - bpicolo 11y ago
    There are a lot of good JavaScript alternatives out there. This article sort of misses the point in what's good about alternatives existing - you can use any of them and expect decent interop with javascipt. A library in one is more exclusionary for all the other interests out there.
    - deleted 11y ago
      [deleted]
- untog 11y ago
  You've basically ignored the OPs point entirely. Typescript is backwards compatible to JavaScript, ClojureScript most definitely is not. Not that I'm agreeing with the post in question, but ClojureScript and TypeScript are very different beasts.
tkinom 11y ago
I have not used TypeScript personally, just read and try some demo of it. But for me JS -> TS feels like C -> C++ evolution/Transition. For most of Unix utillies or even as complex as Linux Kernel, Apache, Nginx, C is good enough. In the hands of developers who master it, there are no C++ equivalent. For after look at the v8's C++ code, I can't imagine anyone would write that with C. But when a new language's ego system is not mature enough, the development work flow can be a nightmare. I remember trying to use GWT to compile Java into JS. The demo works and looks cool. But more often or not, I end up debug "The JAVA code" AND "The machine generated Javascript" AND "how that JS interact with different browsers" for something that is extremely trivial to do with one line of JS/JQuery code. * Writing code is easy. * Debugging code is harder. * Make sure that code works on all the browsers are much harder. * Debugging system with multiple languages (JS, TS, React, Angular, polymer, etc) + machine generated code is not easy. * Integrated them all together to fixed all issues and make sure the final program will work on all browsers are > N^2, N^3, N^4 times harder? I am old enough to admit, that is not a job for me. :-)
- klodolph 11y ago
  That's not my experience with TypeScript. To me, TypeScript feels like JavaScript, with a few bits that make it feel more like writing ES6 even though you're really writing something closer to ES5. The differences between C and C++ are much larger. You're never debugging TypeScript separately from JavaScript.
  - tkinom 11y ago
    I see the following code in https://github.com/Microsoft/TypeScriptSamples/blob/master/todomvc/js/todos.ts https://github.com/Microsoft/TypeScriptSamples/blob/master/t... , For me, it is definitively not the JS I know. declare var _: { each<T, U>(arr: T[], f: (elem: T) => U): U[]; delay(f: Function, wait: number, ...arguments: any[]): number; template(template: string): (model: any) => string; bindAll(object: any, ...methodNames: string[]): void; }; declare var Store: any; If there is bug in this code, I won't know how to debug it. I have no clue on what the JS generated by it looks like. If I have to ask some JS programmer with no TS experience to integrate this "ts library" into their app and make sure the integrated app works on all browsers. I would have no clue on the complexity of the task just as I have no clue on how complex it was to make the GWT generated JS app to work on all browsers. If it is just a JQuery / JS app, I can have 80-90% confident on schedule and quality of the app delivery. But that's me, like I said, I am too old... :-)
novaleaf 11y ago
I love Typescript, I do all my javascript coding via it. However, Though I wish it were, Typescript is NOT currently suitable for defining modules for external consumption. The problem comes down to no effective means of publishing the typings of your project and your project's dependencies. For example, if your project uses Promises, you might choose to include a definition of those promises, or (worse) reference a Promise typing you found on DefinitelyTyped. This will work fine for you, the publisher. But any consumer of your project will be rudely greeted with typing collisions: Things like "The interface 'Promise' already exists in es6.d.ts" There needs to be a solution to this module publishing problem before people can seriously publish modules (using NPM) using Typescript. Unfortunately, I have been tracking this issue and there is no timeline for resolving it, mostly due to too many different module systems, and handling module publishing being outside the design-scope of Typescript.
- lloyd-christmas 11y ago
  typings[1] does exactly that as long as people start publishing their definitions (which is kind of the point of them). Relying on un-versioned ambient declarations is what breaks things, not having dependencies. [1] https://github.com/typings/typings/blob/master/docs/registry.md https://github.com/typings/typings/blob/master/docs/registry...
  - novaleaf 11y ago
    thanks for the link. I'm partially aware of typings, but too into my own implementation right now to consider switching fro definitely typed. I'll give it a try and pray it actually can let me ship an OSS project!
    - lloyd-christmas 11y ago
      For a quick and small example to see it in action: npm init && typings init npm install debug ms --save typings install debug ms --save debug is dependent on ms, so in node_modules you have: |-ms |-debug | |-ms typings/main/definitions will have |-debug | |-index.d.ts |-ms | |-index.d.ts It makes up for this file structure by declaring modules named in a file-like structure so the entire dependency tree is self contained in one file, while only exposing it's own typings through the final export declarations "debug" and "ms". No stepping on toes. Best to see for yourself, it would take a bit to write down. As a point of info, it only works when people start adding versioning to the typings registry itself. debug and ms are both versioned in the registry, which is the only reason their dependencies are correctly managed. DefinitelyTyped ambient declarations will still break things. Until those are gone and everything is versioned, you'll still need some hacking depending on your dependencies. That being said, I've seen the issues start to fade rather quickly given the short time period I've been using it.

awjr 11y ago

I cannot vote this up enough. It really is such a different experience to developing in "plain" JavaScript.

echelon 11y ago
It's so much more pleasant to write and maintain than wild, un(type)safe javascript.
- acjohnson55 11y ago
  Only problem is that it's not sound. That means that while it may provide static checking that your program is validly linked together, it can't fully prevent run-time type errors. And kind of like you can't be "a little pregnant", you can't be "a little typesafe".
  - JoeAltmaier 11y ago
    Of course you can. Can't catch all the bugs; but can catch some of them. Which saves time and money. It doesn't actually have to be perfect to be useful and helpful.
    - acjohnson55 11y ago
      I'm not saying it doesn't help. I'm saying you can't count on it the same way you can if you're working in a truly end-to-end statically typed environment. Even Scala's type system has its leaks, due to nulls.

Hurtak 11y ago

Is TypeScript really future proof? I mean unless types, exactly implemented as they are in TypeScript, will become part of the spec, we can't really call it future proof. Also how is it compatible with anything, JavaScript is compatible with TypeScript, since TypeScript is superset of JS, but it is not compatible the other way around.

nothrabannosir 11y ago
Yes, it is. Compiling TS just removes type annotations; the compilation output (.js) is as readable as your original .ts. It has the same structure, same indentation, same variable names, same whitespace, same comments, same everything. This also makes debugging the code in the browser very easy. TS does not add any semantic features, it only adds type annotations. Which it checks at compile time, and then removes. That's it. Want to switch away from TS? Compile all your .ts files, save the .js, check that into your repo and continue from there. (As other commenters sort-of pointed out: you will need to keep Babel in your pipeline.)
- agumonkey 11y ago
  Interesting, I never 'considered' that. It's basically a thin typechecker linguistic layer. A variant of gradual typing.
- Roboprog 11y ago
  Thanks for the concrete description. Can I still use dynamic constructs such as string subscripts to associative arrays and code generation via eval()?
  - nothrabannosir 11y ago
    You mean in TS? Yes. ∀ x: I can do x in JS → I can do x in TS But, let's assume for a second that you couldn't: this thread is about TS being future-proof. I.e.: ∃ x: I can do x in TS & I cannot do x in JS? No, false. This implies TS = JS. And that's the point: semantically, TS = JS.

im_down_w_otp 11y ago

If Elm didn't also exist, I'd almost agree with you.

tommyd 11y ago
In an ideal world I'm sure a lot of us would love to work with Elm, but the reality in a commercial situation is often that the choice of language is driven by factors like: how widely used/well known it is, what the availability of libraries for it is like, how easy it is to hire developers with experience for. This unfortunately makes languages like Elm and Clojurescript unlikely to be chosen in a lot of situations (e.g. as I understand it, the JS interop story with Elm isn't amazing, so you can't just use JS libraries with it). Typescript is close enough to plain Javascript to not scare people off (I'd be willing to bet any JS developer could pick it up in a few hours) and can almost be considered in the same light as vanilla JS in such a decision, yet brings with it the advantages of a fairly decent type system. As I've said elsewhere, it's definitely not perfect, but for developers in a position where other, more "esoteric" compile-to-JS languages aren't likely to be accepted, Typescript probably represents the best choice of bringing a decent amount of sanity and predictability to codebases. (This isn't meant to be having a go at the parent BTW, it's just something I've been thinking about a bit and the comment jogged my memory!)
- rtfeldman 11y ago
  You can totally use JS libraries with Elm. Source: we do it all the time at NoRedInk, and we've been using Elm in production for our millions of users (as our go-to for all front-end work at the company, not just as a side thing) for the better part of a year now. :) Details about our experience with Elm in production: https://www.youtube.com/watch?v=R2FtMbb-nLs https://www.youtube.com/watch?v=R2FtMbb-nLs
  - tommyd 11y ago
    That's interesting to know! Thanks
  - pka 11y ago

lcfcjs 11y ago

Oh yeah? Just like coffeescript was a couple years ago? Give me a break.

bpicolo 11y ago

Have you used ClojureScript? Try it out for a month or two on a real project. We can do this all day ;)

hnbroseph 11y ago
not sure what you're trying to say.
- bpicolo 11y ago
  There are a lot of good JavaScript alternatives out there. This article sort of misses the point in what's good about alternatives existing - you can use any of them and expect decent interop with javascipt. A library in one is more exclusionary for all the other interests out there.
  - deleted 11y ago
    [deleted]
untog 11y ago
You've basically ignored the OPs point entirely. Typescript is backwards compatible to JavaScript, ClojureScript most definitely is not. Not that I'm agreeing with the post in question, but ClojureScript and TypeScript are very different beasts.

tkinom 11y ago

I have not used TypeScript personally, just read and try some demo of it. But for me JS -> TS feels like C -> C++ evolution/Transition. For most of Unix utillies or even as complex as Linux Kernel, Apache, Nginx, C is good enough. In the hands of developers who master it, there are no C++ equivalent. For after look at the v8's C++ code, I can't imagine anyone would write that with C. But when a new language's ego system is not mature enough, the development work flow can be a nightmare. I remember trying to use GWT to compile Java into JS. The demo works and looks cool. But more often or not, I end up debug "The JAVA code" AND "The machine generated Javascript" AND "how that JS interact with different browsers" for something that is extremely trivial to do with one line of JS/JQuery code. * Writing code is easy. * Debugging code is harder. * Make sure that code works on all the browsers are much harder. * Debugging system with multiple languages (JS, TS, React, Angular, polymer, etc) + machine generated code is not easy. * Integrated them all together to fixed all issues and make sure the final program will work on all browsers are > N^2, N^3, N^4 times harder? I am old enough to admit, that is not a job for me. :-)

klodolph 11y ago
That's not my experience with TypeScript. To me, TypeScript feels like JavaScript, with a few bits that make it feel more like writing ES6 even though you're really writing something closer to ES5. The differences between C and C++ are much larger. You're never debugging TypeScript separately from JavaScript.
- tkinom 11y ago
  I see the following code in https://github.com/Microsoft/TypeScriptSamples/blob/master/todomvc/js/todos.ts https://github.com/Microsoft/TypeScriptSamples/blob/master/t... , For me, it is definitively not the JS I know. declare var _: { each<T, U>(arr: T[], f: (elem: T) => U): U[]; delay(f: Function, wait: number, ...arguments: any[]): number; template(template: string): (model: any) => string; bindAll(object: any, ...methodNames: string[]): void; }; declare var Store: any; If there is bug in this code, I won't know how to debug it. I have no clue on what the JS generated by it looks like. If I have to ask some JS programmer with no TS experience to integrate this "ts library" into their app and make sure the integrated app works on all browsers. I would have no clue on the complexity of the task just as I have no clue on how complex it was to make the GWT generated JS app to work on all browsers. If it is just a JQuery / JS app, I can have 80-90% confident on schedule and quality of the app delivery. But that's me, like I said, I am too old... :-)

novaleaf 11y ago

I love Typescript, I do all my javascript coding via it. However, Though I wish it were, Typescript is NOT currently suitable for defining modules for external consumption. The problem comes down to no effective means of publishing the typings of your project and your project's dependencies. For example, if your project uses Promises, you might choose to include a definition of those promises, or (worse) reference a Promise typing you found on DefinitelyTyped. This will work fine for you, the publisher. But any consumer of your project will be rudely greeted with typing collisions: Things like "The interface 'Promise' already exists in es6.d.ts" There needs to be a solution to this module publishing problem before people can seriously publish modules (using NPM) using Typescript. Unfortunately, I have been tracking this issue and there is no timeline for resolving it, mostly due to too many different module systems, and handling module publishing being outside the design-scope of Typescript.

lloyd-christmas 11y ago
typings[1] does exactly that as long as people start publishing their definitions (which is kind of the point of them). Relying on un-versioned ambient declarations is what breaks things, not having dependencies. [1] https://github.com/typings/typings/blob/master/docs/registry.md https://github.com/typings/typings/blob/master/docs/registry...
- novaleaf 11y ago
  thanks for the link. I'm partially aware of typings, but too into my own implementation right now to consider switching fro definitely typed. I'll give it a try and pray it actually can let me ship an OSS project!
  - lloyd-christmas 11y ago
    For a quick and small example to see it in action: npm init && typings init npm install debug ms --save typings install debug ms --save debug is dependent on ms, so in node_modules you have: |-ms |-debug | |-ms typings/main/definitions will have |-debug | |-index.d.ts |-ms | |-index.d.ts It makes up for this file structure by declaring modules named in a file-like structure so the entire dependency tree is self contained in one file, while only exposing it's own typings through the final export declarations "debug" and "ms". No stepping on toes. Best to see for yourself, it would take a bit to write down. As a point of info, it only works when people start adding versioning to the typings registry itself. debug and ms are both versioned in the registry, which is the only reason their dependencies are correctly managed. DefinitelyTyped ambient declarations will still break things. Until those are gone and everything is versioned, you'll still need some hacking depending on your dependencies. That being said, I've seen the issues start to fade rather quickly given the short time period I've been using it.