Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flow vs. Typescript

djcordhose.github.io

Post reply on HN
Print view View original

91–100 of 158 posts

Re: Flow vs. Typescript

#91

Post by shados »

adamors wrote: post #45
chvid wrote: post #41

I am the only one who is happy to code without static typing? Enjoying fast compilation, small, fast editors, flexibility. I don't really make stuff like marry(a, b) and then call it with a banana and an apple by accident. Sure I make plenty of mistakes when I am coding but only very few could have been caught by a static type check. Take one of the examples in the slides: let obj: string; obj = 'yo'; // Error: Type…

How big are the projects you are working on though? For instance I work an a 2 year old Angular project and static typing is something we are trying to introduce because the codebase is large and challenging to work with, mostly because Javascript. There's only so much you can do with best practices and code organisation.

I've worked in multi-million lines mono-repo Javascript projects built with Backbone and old school ES3 (supporting IE6, etc).

Types would have helped, a little. But really, architectural soundness, proper unit tests, and frequent refactoring (using the tests) kept things under control fine.

The biggest trick is that 99% of the community has never seen/worked with a properly unit tested code base. Even though who think they did, often didn't (they have 80-95% test coverage with bad tests, overlapping tests, or integration tests...and that's blah if that's all you have).

The current JS type systems only take you so far, too: since typing is optional (for good reasons), and type definitions of 3rd party libs are often out of sync, or wrong, etc, a small error, or a missing definition, and your right click -> rename ends up breaking something subtle. It helps, but it's not enough to have full confidence in a large system. In a small app it's not really needed, and in a massive app you have the above issue, so it's mainly in the mid range people find the most benefits

For a type system to really save your butt in a large app, you need an advanced type system, like Elm/Haskell/Scala/whatever. Otherwise, the tool you actually need is proper unit tests. Types will help, a little. But they're not the panacea. Especially optional ones.

Re: Flow vs. Typescript

#92

Post by shados »

hoodunit wrote: post #38
robinricard wrote: post #35

Both systems are really great, however, when adding typechecking into an existing codebase, flow does offer more flexibility thanks to weak checking and annotation comments. You can really progressively add typechecking by just dropping the tool in the codebase. Also, if you subscribe to Facebook's tooling (Nuclide especially), you will end up with great tools (jump to def, integrated checking, ...). However if you j…

I actually found the opposite was true in our project - TypeScript was easier to add into the code than Flow. The biggest reason for this was that Flow demands null/undefined checking and null was used extensively throughout this code base. With TypeScript, on the other hand, the changes to make it work initially amounted to sprinkling a few "any" notations and making some explicit object interfaces at various points…

Flow supports nullable types just fine, and flow in weak mode doesn't mandate any annotation whatsoever.

Re: Flow vs. Typescript

#93

Post by avodonosov »

Where I saw the same nullable / non-nullable values: Kotlin.

Bidning animals = cats is problematic only if the collection is mutable. Forbidding that is too limiting when you work with immutable collections (even it that's an Array - if you are not going to mutate it).

Re: Flow vs. Typescript

#94

Post by shados »

smt88 wrote: post #19
abritinthebay wrote: post #3

The biggest win that flow has - and for me puts it over typescript - is that it has comment decorator syntax. This means I can just write JavaScript and add comments for types. No transplier step, no messing around in a different but similar language, no additional complexity, just easy. It's inferred types are a much stronger system imo too - gets out of a developers way more. Typescript is great, but I really do pr…

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

You mean like how it breaks ES6 classes semantics by making members enumberables? Whoops (I know, if you look at my comment history I used that example all the time...but it's just such an easy one).

When comes the time to pick between shinier output and correctness, TypeScript is perfectly happy to diverge from JavaScript, until it really has no choice (eg: when it moved to ES6 modules)

Re: Flow vs. Typescript

#95

Post by PDoyle »

chvid wrote: post #41

I am the only one who is happy to code without static typing? Enjoying fast compilation, small, fast editors, flexibility. I don't really make stuff like marry(a, b) and then call it with a banana and an apple by accident. Sure I make plenty of mistakes when I am coding but only very few could have been caught by a static type check. Take one of the examples in the slides: let obj: string; obj = 'yo'; // Error: Type…

You're not the only one. It's a common sentiment if you haven't really, fully used a type system before.

If there's an important property you want your program to have, and you can express it using the type system, then your compiler can prove it for you. For example, if you have an Employee record with a jobTitle field of type String, then it's hard to be certain you'll never get an invalid jobTitle. If you change that to a type hierarchy with subtypes like Manager, Developer, etc. then once the program compiles, you can be certain that particular error can't happen at run time. As type systems grow more sophisticated, more program properties can be represented as types.

If you want to experience it, perhaps try a language with a really top-notch type system like OCaml or Haskell. Maybe try implementing some kind of transpiler from json to json that uses the type system to describe the valid input. You'll have a collection of parsing functions that detect all the errors, and then the rest of the system can rest assured that the parsed representation is error-free, and you can be certain that you never forgot to handle one of the possible cases. (OCaml, in particular, is very good at this.)

If you try this, and you're human, I think you'll make a few mistakes that get caught by the type checker.

Re: Flow vs. Typescript

#96

Post by PDoyle »

huuu wrote: post #4
abritinthebay wrote: post #3

The biggest win that flow has - and for me puts it over typescript - is that it has comment decorator syntax. This means I can just write JavaScript and add comments for types. No transplier step, no messing around in a different but similar language, no additional complexity, just easy. It's inferred types are a much stronger system imo too - gets out of a developers way more. Typescript is great, but I really do pr…

But programming with comments is bad practice. Maybe in this case it doesn't matter very much but there are a lot of ways comments can get lost or messed up.

Not true when the comments are mechanically checked for correctness.

Re: Flow vs. Typescript

#97

Post by zxcvcxz »

greenspot wrote: post #42
Skinney wrote: 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?

I have to go through shit like this in Windows all the time:

http://stackoverflow.com/questions/34906807/error-building-n...

Upgrading bcrypt didn't work for me.... I ended up installing Linux on a VM and developing inside the VM because that's the only way bcrypt would install.

Of course, I can usually get it to work some how, but I don't have these issues on Linux. Basically node works "good enough" on Windows, especially if you don't value your time.

Re: Flow vs. Typescript

#98

Post by shados »

s_kilk wrote: post #84
Hurtak wrote: 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

> since introducing TS to you project means longer time train new employees Does it though? I mean, we're talking about intelligent beings who can drive cars and program computers, how hard can it be for them to spend an hour reading the typescript docs? I suppose it depends on ones definition of a long time.

Learning TS itself takes minutes. Probably -seconds- if you're familiar with Java/C#.

The real learning curve is in the edge cases, of which there are plenty. Fighting with a 3rd party lib with incorrect type defs, dealing with cases common to JS that are hard to properly type (such as certain functional constructs), dealing with things missing from the TS compiler that are present in ES6/babel, etc.

Those things are quickly going away and may eventually be a non-ssue, but as of today, they're very real. That's in contract with languages that have the type system baked in from the get go, where it wouldn't be an issue.

Re: Flow vs. Typescript

#99

Post by cageface »

RX14 wrote: post #71
cageface wrote: post #48

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.

It's not exactly what you want, but if you want a statically typed ruby-like you should check out crystal ( http://crystal-lang.org/ )

Crystal looks interesting but I can't really migrate to a new language. Something that compiles down to plain Ruby would be great though.

Re: Flow vs. Typescript

#100

Post by skrebbel »

greenspot wrote: post #42
Skinney wrote: 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?

> but the ecosystem around Node is so much tailored around Linux

I really don't understand why people keep saying this, it's simply not true. Node works fantastically on Windows. I've yet to come across a library that won't work on my Windows box (barring obviously platform specific stuff). Node-gyp works fine too, and many libraries with native code offer Windows versions.

Especially when comparing to e.g. Ruby or Python, it's a world of difference. With Ruby you can't even use bundler on Windows and then deploy on Linux.

It seems all the basic fundamental design choices of Node and NPM were made with portability in mind. I'm frankly quite impressed.

Source: been running teams doing frontend and node for almost 3 years now, every team had at least one Win dev and at least one OSX dev, every team deployed to Linux. 0 problems, ever.

Post reply on HN