Horizon: Switch to TypeScript

[niieani]

I understand this is an entirely opinionated decision, but given that you are heavily leveraging RxJS, which itself is written in TypeScript, it would make sense to also use TypeScript for Horizon.
The added benefit is that there's no need for the huge babel polyfill, which would solve https://github.com/rethinkdb/horizon/issues/141

I don't see any reason why the current JS-Babel codebase shouldn't compile with TypeScript, as type annotations are optional in Typescript; these would however greatly help people developing with TS without the need for hand-written typings. On the other hand JavaScript people don't miss out on anything, as the transpilation step is already there anyway, and the code itself probably won't require any changes, aside from the optional type annotations.

It's worth noting that other modern JS projects, such as CycleJS, are also working on switching their codebase to TypeScript.

If you'd decide to switch, I'd be happy to send a pull request with the added typings.

[deontologician]

Typescript is neat, but it doesn't seem like the right time to be switching to another language. We've had several large refactors already, and it we need to reduce churn for the time being (trying to get 1.0 out)

[niieani]

@deontologician The thing is I don't think it would be a large refactor, or even a small one - it might just work by changing the filenames from .js to .ts and adding type annotations - that's all. If that's something you'd be interested in, I could try tomorrow if it works and let you know whether any additional changes are needed or not.

[deontologician]

It's no so much that the code will have to change, but we'll also need to create/understand/debug type annotations that we don't have to at the moment. It's not the end of the world, but it is a slow-down since we'd have to read up on typescript (none of us are proficient in it)

[coffeemug]

I think it'd be reasonable to investigate a migration to TypeScript post v1.

[segphault]

:+1: I've been really impressed with Typescript personally. Even if it's not practical to migrate the codebase, I still think it'd be useful to generate and publish a .d.ts for the Horizon client library.

[niieani]

As I had thought, switching to TypeScript is trivial.

I've had two tries with the Horizon Client:

1. There are no changes necessary for TypeScript to build the current JavaScript files into ES5 modules (as is done currently with Babel). This means you could use TypeScript as the transpiler in place of Babel, even without using any of the TypeScript-specific stuff. Then you would be able to make the switch to TS gradually, by converting the code on on per-file basis.
2. Only a few changes are necessary for a successful TypeScript build after renaming the files to .ts, and I've done them here:
   https://github.com/niieani/horizon/commit/15d0d2f2e445e76ac2881c6d2f716738877bf978
   It's mostly replacing the require() calls with ES6 import and switching from the manual module.exports object definition to the ES6 export syntax. (btw. you could be using that syntax already with Babel anyway!)

To compile .js in place of Babel, all that you need is a config file and optionally typings (which provide autocompletion): https://github.com/niieani/horizon/commit/4fd34642c7a7f196fe0ce5c6e06d3880bf1209fd

[niieani]

I've converted the @horizon/client to TypeScript in my fork and generated typings that should work with the official JS version, available here: https://github.com/niieani/typed-horizon-client

[d3viant0ne]

@niieani - Everything I do workwise is in TypeScript, so Typings are going to be a must for me.

It would be great to get the client / server typings out in an official capacity as a vast majority of the Angular2 projects are going to be built using TypeScript.

If you want any help in the realm of TypeScript / Typings and so on, just @ me here or on twitter.

[niieani]

Well the maintainers have stated that there's will to migrate to TS eventually. My experimental TypeScript fork was quite easy to make - aside from adding type-annotations, it didn't require any changes to the codebase whatsoever. Since Horizon is developing rapidly, those typings would probably need to be updated by now (they're 2 months old now).

I think we should hold off till the APIs are stable before we make the Typings official. Maintaining them with every update would get really annoying.

Alternatively, if the Horizon team doesn't want to switch to TS before v1.0, how about adding type annotations and stripping them with a babel plugin for automatic Typings generation? This is how Aurelia framework (example) currently maintains their codebase synced with their definitions.

This would mean that there's nothing new to learn for those of you who don't know types/TypeScript (you wouldn't need to add them to the parts of code you create), while contributors that care about typings could help by sending pull requests with the new code type-annotated. This way, once the code is mature, and you are ready to invest in learning TypeScript, the only thing left to do would be to change the file extensions from .js to .ts. You'd basically be outsourcing the typing to those who already know about it.

Does that make sense?

[d3viant0ne]

From a consumer perspective, if I'm working on an Angular2 client that I want to tie into Horizon I'm going to want Typings. As I am sure you know, creating manual typings for packages is exhausting :(

While I would never suggest converting the project to TypeScript now or in the near future ( though it does make sense ) I would think delivering a 1.0 with client side typings could only help adoption in the realm of Angular2.

I agree with using babel to strip type annotations as a logical first step. The impact to the codebase would be benign and the impact to the build would be minimal while aiding in the automatic generation of typings. It's also a good way for those that aren't familiar with TypeScript to get their feet wet without taking a velocity hit pre-release.

In the short term, a few of us TypeScript folks would have to actively monitor changes and PR updates to type annotations. While that is less than optimal from a process perspective, it wouldn't be terribly difficult. Post 1.0 updating typings could be made part of the release process to keep everything in sync.

To refine what @niieani is proposing, generate typings for the client side lib in the manner suggested and move this from "Subsequent" to "Release 1.0 polish" as it can be done with minimal impact to current development while providing value to a large portion of the Angular2 community.

[deontologician]

I agree. Previously it looked as if we would not get much time for client side rework before the release, but that's not the case currently. If you guys want to create a PR for typings, we can check it out. I still don't think we want to change the code itself to typescript quite yet, especially since it isn't compatible with the function bind operator we use.

[DanielRosenwasser]

Hey @deontologician, could you fill me in more on the issues you're running into with bind? I'm assuming you mean Function.prototype.bind, right?

[segphault]

@DanielRosenwasser he's referring to the :: operator, syntactic sugar for bind that will likely be proposed for inclusion in ES7. It's still too speculative for TypeScript to implement. You can see the TypeScript discussion about it here: https://github.com/Microsoft/TypeScript/issues/3508

(Edit: haha, I just noticed your comments on the linked TypeScript issue. Sorry for adding noise)

[littleli]

Just for a completeness. If you use bind in TypeScript you are going to lose type information anyway. Function interface provide such signature: bind(thisArg: any, ...argArray: any[]): any; It means that after bind return type is always any :( Some people recommend to avoid bind completely and use closure for proper scoping.

Having public api covered by type definitions would be great of course no matter if you have codebase in ES6 or TypeScript.

[deontologician]

Moving to Release 1.1 milestone

[niieani]

Please let me know when you'll be ready to receive a PR that generates d.ts typings using a Babel transform on the code (without switching to TypeScript at this time, as agreed above). It'll be easier for me to do it as I can use my outdated Horizon fork as a template.

[deontologician]

Will do @niieani

[jonathan-casarrubias]

Great to see that will be addressed in 1.1, I was trying to create a NativeScript App and I'm being unable to use Horizon on it, also all the examples import in the index.html the client here we do not have any index.html.. so, looking forward for a solution

[d3viant0ne]

@niieani One thing in regards to the d.ts files being generated. I propose they be maintained in https://github.com/orgs/typed-typings and we should really generate them per the Typings guidelines ( they have a project template for typings )

This group is really pushing to standardize the generation and maintenance of Type definitions to make TypeScript easier for everyone to use.

Also worth noting, I'm sure @blakeembrey would be happy to add you to the org to simplify the ongoing maintenance of type definitions for Horizon. I am already in the process of creating a properly versioned, Typings compliant project for RethinkDB which will also be moved into the TypedTypings Org.

[DanielRosenwasser]

I would actually recommend that if there's a commitment to keeping official and up-to-date .d.ts files, that you keep them in the package itself - especially if you eventually start generating them directly from source.

Check out our guidelines on Typings for NPM Packages for more details.

[blakeembrey]

👍 to @DanielRosenwasser's comment. If you're writing type definitions, they should be maintained in the library. See https://github.com/typings/typings/issues/322 for more information. Of course, if you ever need a hand you can ping anyone from @typings for help. I've helped a few packages transition to inline typings.

Edit: I'll also add collaborators to @typed-typings if someone wants to maintain a definition in the collection :smile:

[kushwahashiv]

+1

[darrylryan]

+1 :)

Typescript is definitely the way forward. I think the public tsd repos are more for providing third-party typings for libraries where the original authors are not interested in Typescript. Where it is possible, it makes a lot more sense to make the typings part of the library distribution and keep them up to date as you go along.

[kennetpostigo]

You should look at flow as well.

[kennetpostigo]

Flow will be easier to transition to because it can happen incrementally easier.

[niieani]

@kennetpostigo Incorrect. Transitioning to TypeScript-annotated JS is exactly the same as transitioning to Flow. Yet Flow adoption is much lower and the community traction is definitely with TypeScript. For Flow support, please encourage the Flow team to implement support for TypeScript definitions.

[kennetpostigo]

I don't think I'm necessarily incorrect, its easier to just add types to existing files and add babel plugin than to change all files, go to VSCode, etc. Especially if Horizon is not certain about the move. If they are looking to incrementally type their files overtime without wanting to learn nuances of typescripts build steps and take advantage of all of babels features give flow a shot.

[d3viant0ne]

One of the main points is Horizons deep ties to RxJS which is written typescript.

Considering Flow has none of the benefits above nor the backing of a Corp entity to ensure a reasonable life span, I see no reason to consider it as a viable option.

[niieani]

@kennetpostigo That's my point, I still believe your statement was incorrect. Because you can add types to existing files just as easily with TypeScript and a babel plugin to generate typings, without going full-on TypeScript. There's literally no benefit to Flow over TypeScript.

[kennetpostigo]

Considering Flow has none of the benefits above nor the backing of a Corp entity to ensure a reasonable life span, I see no reason to consider it as a viable option.

@d3viant0ne is backed by Facebook, and they use it heavily in opensource projects. I would say it's lifespan is secure.

There's literally no benefit to Flow over TypeScript.

@niieani I would suggest you research flow before calling it useless. Flow provides several benefits over typescript: http://www.2ality.com/2014/10/typed-javascript.html

I'm don't try to favor one over the other I just think Flow would be a more pragmatic solution for Horizon to test the waters of seeing how they benefit from typed javascript.

[niieani]

@kennetpostigo I understand you're very passionate about Flow, but I have done my research and I'm following news on Flow regularly. The article you cite is from 2014. One of the main advantages of Flow, non-nullable types, is coming to TS 2.0 in June, and they're already available in the nightlies. The speed of development of TS is much higher, the roadmap clear and very comprehensive. At this point there are almost no benefits to Flow vs TS, aside from very few quirks which are also already on TS' roadmap.

[kennetpostigo]

@niieani I'm not really passionate about flow, I just dislike when developers say that a library that many engineers have worked on is called "useless". Not a very great way to make a point. As it stands those using typescript lack access to future ecmascript features that many use today in browsers as typescript has in the past been bit in the ass by adding features not in spec (when they implemented their own module system and had to scrap it). Babel on the other hand lets you use all future features starting at stage 1 as opposed to TS only submitting features at Stage 3.

The article you cite is from 2014.

Yea and its 2016 still no null types till June

Both Flow and Typescript are great projects, They make writing libraries and applications that grow overtime easier. I brought flow into the issue to try to add a different perspective from the onesided typescript conversation.

[blakeembrey]

@kennetpostigo Can developers re-use the types from Flow if this project uses Flow? The thing that's important about this conversation is not just the benefits for Horizon, but also the benefits every developer using the library would gain - TypeScript would automatically be consuming the types.

I may not be up to date, but last I checked Flow didn't have a type re-use story for dependencies. Although Horizon could be written in Flow, it's not very useful to developers if the types can't be re-used. Please feel free to correct me if the type re-use if no longer an issue (I'd love a link).

[niieani]

@kennetpostigo you keep bringing up Babel as a pro of Flow, while ignoring the fact that you can declare TypeScript typings together with Babel in the exact same say as Flow typings, using the plugin I linked to earlier (in fact, combined with the flux-strip plugin, just because TS and Flux typings are so similar). You mention it's possible to use Flux with all the new features that Babel allows, yet time and again Flux had it own issues of supporting new features, like the decorators, which are still not supported officially in Flux.
At this point I feel we're just flooding the topic with pointless flame, so I'm not going to go further on the Flux vs Typescript debate.

[shlomiassaf]

The scale of this project and the fact it's OSS is probably the best candidate for TypeScript.

Having TypeScript in you'r project makes it an open book.
No effect on runtime, more readability and navigation for new comers.

TypeScript = Inference + Type annotation
Flow = Inference, less annotations.

not to mention tooling, lang service etc...

TypeScript's inference is miles ahead of Flow but that's not important, if you have type annotations you easily understand the code, navigate, refactor and what not...

So self document Horizion with typescript, let user's jump in quickly.

IMO, Flow's approach will not hold. They favour inference over type annotations but in reality annotations are mandatory for a type system to work properly. They will add more types as they evolve. In the end it's just wanting to be TypeScript.

Sometimes I get the feeling it's facebook VS the rest.

[deontologician]

Not to single out anyone's comments, but for future commenters, let's not fill up this issue with discussion about flow vs. typescript. It's a big flamewar topic, which you can feel free to discuss on our horizon slack channel :)

[lgleim]

Is this still on the roadmap? I would be really interested in seeing this happen soon, especially now that everything about this project is changing anyway. I can tell you as a developer used to typescript code and just going through all the details of the current codebase, having type annotations (especially for options) and inline documentation would make this code sooo much more accessible...