Live data from Hacker News

Flow vs. Typescript

djcordhose.github.io

111–120 of 158 posts

Re: Flow vs. Typescript

#111
post #19

Earlier quoted context omitted.

> no messing around in a different but similar language TypeScript would be a disaster if it subtly changed the semantics of JavaScript. It doesn't, though. It's a superset, so it's really not a "different but similar" language. It's the same language with more features, and the compiler is a great guide to using those features.

what if further JS will intersect with TS syntax ? IMO Typescript is "no go". We need clean break with transpile step (eg. Dart) or annotations.

It's very likely that JS will adopt some things tried initially in TS. Both TS and Babel have implemented extensions to the class syntax, for example, which are being considered for JS-future.

Re: Flow vs. Typescript

#112
post #18
post #14

The main problem for me, is that Flow doesn't support Windows (yet?). I've been working solo on a frontend a couple of months now, and the team has just been extended with a new developer (yay). However, he uses Windows, and so all my type annotations are worthless. We're making the switch to TypeScript once 2.0 is released (easier to port with strictNullChecks).

Windows support is coming soon; the Flow team is actively working on it -- so hopefully you'll see something in a few weeks.

Off topic, but what's the current status of flow-replacing-PropTypes?

Re: Flow vs. Typescript

#113
post #30

Earlier quoted context omitted.

> - if people enter or leave your team frequently: yes Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one

The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project. I wish I had something similar for all the Ruby code I write.

You might want to check out rubocop[1]. It does static checking, and we're pretty happy with it.

1: https://github.com/bbatsov/rubocop

Re: Flow vs. Typescript

#114
One aspect to consider before jumping into TS or Flow. As is the nature of any type system they rule out some programs that are perfectly fine.

A workaround for this is to infer, or explicitly annotate, things to be dynamically typed. And/or helping the typer by casting to known types it failed to recognize. And it will work fine, after all this is precisely what you do with untyped ES (in your head).

This workaround was to strong of a code smell to just let things be like that though. So I've found myself spending time inventing ways to refactor code, or alter type definitions, to get proper typing instead. This can eat up time better spent implementing features.

Not everyone will have this problem, but if you're anything like me, do consider it before adopting these.

As a less intrusive option, consider using eslint with Babel and reference checking for modules. Not in any way a complete type-system, but might be just enough if you're allready comfortable with ES as it is.

Re: Flow vs. Typescript

#115

One aspect to consider before jumping into TS or Flow. As is the nature of any type system they rule out some programs that are perfectly fine. A workaround for this is to infer, or explicitly annotate, things to be dynamically typed. And/or helping the typer by casting to known types it failed to recognize. And it will work fine, after all this is precisely what you do with untyped ES (in your head). This workaround…

Do you have a specific (and simple, if possible) example at hand?

Re: Flow vs. Typescript

#116

Earlier quoted context omitted.

The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project. I wish I had something similar for all the Ruby code I write.

You might want to check out rubocop[1]. It does static checking, and we're pretty happy with it. 1: https://github.com/bbatsov/rubocop

Does it actually do static type checking? Because I don't see anything about types in the documentation. It looks like just a more sophisticated linter, which is very different from what TypeScript and Flow bring to the table.

Re: Flow vs. Typescript

#117
post #14

The main problem for me, is that Flow doesn't support Windows (yet?). I've been working solo on a frontend a couple of months now, and the team has just been extended with a new developer (yay). However, he uses Windows, and so all my type annotations are worthless. We're making the switch to TypeScript once 2.0 is released (easier to port with strictNullChecks).

Really wondering: who is developing Node/JS on Windows nowadays? Not that I don't like Windows (I like W10 + the new Ubuntu within efforts a lot), but the ecosystem around Node is so much tailored around Linux. Even with OSX where we have an excellent support, there's still some slight friction when deploying to Ubuntu. Or is Windows 10 a viable alternative for Node devs?

Count me in as a Node/JS developer on Windows 10. Current project is a Cordova app that needs to run on a dedicated Windows 10 tablet (the app is used in clinics to collect patient information).

Re: Flow vs. Typescript

#120
post #55

Earlier quoted context omitted.

Really wondering: who is developing Node/JS on Windows nowadays? Not that I don't like Windows (I like W10 + the new Ubuntu within efforts a lot), but the ecosystem around Node is so much tailored around Linux. Even with OSX where we have an excellent support, there's still some slight friction when deploying to Ubuntu. Or is Windows 10 a viable alternative for Node devs?

I develop on Windows and deploy to Linux regularly, zero problems. Most of the projects are purely js with no dependencies on binaries.

Last time I tried to do something with Node on Windows I ran into the maximum path length issue, but I guess npm 3 is supposed to help with that?
Post reply on HN