Hacker News Reader

Comment by radicalbyte | Hacker News Reader

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.

View on HN

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.

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...

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!

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.

TypeScript has support for namespaces, and `import` gives you a lot of flexibility. If these aren't sufficient to handle the problem you describe, can you explain how? Can you post a link to the issue you are watching so we can see a better description of the problem you're running into?

Here's a scenario: You write a library that uses Promises, and use bluebird.d.ts for that definition.

For someone to use your library, they will have to download bluebird.d.ts manually and include it. if you (the lib dev) include it yourself, then any other definition of Promise (including if the user has their own bluebird.d.ts definition included) will cause typing collisions.

As someone mentioned, the Typings project might solve this, but there isn't very good communication on this project and the problems it's supposed to solve.

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.

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.)

Interesting, I never 'considered' that. It's basically a thin typechecker linguistic layer. A variant of gradual typing.

Thanks for the concrete description. Can I still use dynamic constructs such as string subscripts to associative arrays and code generation via eval()?

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.

OK, that's a good start. Is there a tool analogous to JSDoc for TypeScript that gathers the same docs without repeating the type info already in the code?

http://typedoc.io/ might be what you're looking for.

Thanks. Also, some informative samples of what TypeScript itself looks like.

https://github.com/sebastian-lenz/typedoc/blob/master/src/li...

It is, you just need to define a d.ts file. I was able to use plain jquery with typescript. Check out DefinitelyTyped. It's a project that makes it easy.

Sort of. I don't recall the details from the top of my head and can't easily seem to find details, but I think we're seeing some divergence between Typescript's classes and es6 classes, though I think it's mostly syntactic.

Your code will keep working, but it may diverge a bit from standard JS; however everything will keep working, and I'm sure the expectation would be to move over the es6's syntax unless there were semantic reasons not to.

The Typescript authors are involved in the ECMAScript process, so I'm pretty sure that there won't be any surprising huge rifts at least.

I don't know why you're being downvoted. You're exactly right - there are a few tiny divergences between ES6 and TypeScript. In particular, try compiling some classes with Babel's strict compatibility mode and compare the output to TypeScript's output. There are several small semantic differences.

Also, there a few constructs in TypeScript that generate JavaScript code, like enum and module.

THAT SAID, TypeScript is basically ES6 + type annotations, and can certainly be used as such.

I'm hoping that Typescript will be willing to break backward compatibility when necessary to maintain its core advantage of being an assisted version of the standard rather than just another non-standard language. If Typescript gets out ahead of the ES standard and adopts a feature that is presumably coming in ES, but ES changes course and doesn't follow, TS will no longer be annotated, standard ES.

In this case, I'm hoping TS will just make the breaking change and go back to being pure, standard ES plus optional type annotations. Developers who use it would just accept that from time to time, this could happen, but it could probably be made a non-issue if MS just wrote another transpiler: oldTS -> newTS, for people whose choice of Typescript meant they had committed from the start to a system that would ALWAYS require transpiling.

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. :-)

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.

I see the following code in 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... :-)

Just wanted to point out that that isn't the JS you know because that's just typing information -- it isn't generating any code at all, it's telling TS what the types look like for Underscore's external methods. This would be stripped out completely in the compiled code. The actual code that results in JS just below that is much more typical.

This is only a typescript definition. It only shows you the types that were already there - even before typescript was introduced. And if the JS developer was not aware that these are the accepted types for the functions then he obviously wouldn't also be able to use or debug it in pure JS.

Right, for the human there are still the English API docs to figure out the arguments and return values. These are the type annotations that TypeScript uses to let you know when you've misinterpreted the API docs, which is an incredible time saver.

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

It's so much more pleasant to write and maintain than wild, un(type)safe javascript.

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".

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.

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.

Have you used ClojureScript? Try it out for a month or two on a real project.

We can do this all day ;)

not sure what you're trying to say.

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.

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.

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

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!)

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

That's interesting to know! Thanks

Just for the obligatory record: Purescript is basically "Elm evolved". Everything Elm does, Purescript does better (FFI for example is such a chore in Elm). Drawback: the learning curve is basically as steep as Haskell's.

My experience with Purescript/pulp was rather negative. Basic commands were throwing errors (pulp init IIRC) so I decided to not even consider it for anything serious.

The tooling is not perfect, that's absolutely true. I have to say though that any imperfections (which are going to get fixed anyway) are well worth it if you want a pure strongly typed language for the web. There's simply nothing better (except the full-blown Haskell-to-js compilers, like GHCJS and Haste of course).

I recommend you try again and file a bug or look for help in irc if something breaks again (although I've never seen pulp init throw an error).

My memory could be off (on which command failed). I think I still have the repo on my home machine, so I could re-visit and file a bug report. At the time I kept pursuing elm instead. Reports of better FFI with JS is why I had explored PureScript.

Update: The bug is with pulp server https://github.com/bodil/pulp/issues/133

Cool, does it work for you now?

Being backed by Microsoft is another strong point of TS for some.

Reply on news.ycombinator.com