Live data from Hacker News

Flow vs. Typescript

djcordhose.github.io

131–140 of 158 posts

Re: Flow vs. Typescript

#131

Earlier quoted context omitted.

> 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 P…

> Node works fantastically on Windows. I beg to differ 1. npm install gulp 2. try to delete the node_modules folder 3. waste time fighting windows' legacy stuff (260 max path length in almost everything: explorer, cmd, git bash, etc.) 4. come across rimraf eventually I wouldn't describe that flow as "fantastically" unless you mean "fantastically broken".

Wow, that one is new to me. I just deleted a 120 MB node_modules directory by pressing "shift+del" in explorer. It went away.

I wonder what went wrong in your case.

I do remember having trouble committing a node_modules to git because of the same MAX_PATH bullshit, but then we realized that you're not really supposed to do that anyway.

More generally, by the way, NPM 3 fixed the MAX_PATH problem for the majority of cases, when they moved away from super deeply nested file trees.

Re: Flow vs. Typescript

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

Not sure if this will do, but there's Contracts for Ruby: https://github.com/egonSchiele/contracts.ruby

Re: Flow vs. Typescript

#133

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…

Actually TypeScript powers a JS editing experience codenamed "Salsa" that uses JSDoc comments for types. You can try it out in VS Code where it should currently be enabled. Give that a shot if you're looking into that sort of workflow.

> uses JSDoc comments for types

oh god... shivers... ;)

No, that sounds neat but I loathe JSDoc/JavaDoc derived formats. Good idea for someone else though!

Re: Flow vs. Typescript

#134
post #8

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…

Can you explain the difference between Flow's approach and plain JSDoc 3?

JSDoc is verbose, not inline, not directly associated with the code and not very friendly to use, as well as having a large maintenance overhead..?

I mean... that all applies to JSDoc/JavaDoc syntax before I compare it to Flow anyhow.

Flow's comment system is inline - right next to the code you're writing. It's very clear exactly what it refers to and it's easy to use. Plus it's not TypeScript: it's JavaScript, just with comments.

TypeScript is great, but it is what it is and that is not JavaScript (a superset, sure, but C++ is a superset of C, so what?)

Re: Flow vs. Typescript

#135
post #19

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.

> it's really not a "different but similar" language.

Oh so I can just run it in a browser without transpiling? No? Ok then, not the same language: so it's.. different but similar.

Re: Flow vs. Typescript

#136
post #130

Earlier quoted context omitted.

> Node works fantastically on Windows. I beg to differ 1. npm install gulp 2. try to delete the node_modules folder 3. waste time fighting windows' legacy stuff (260 max path length in almost everything: explorer, cmd, git bash, etc.) 4. come across rimraf eventually I wouldn't describe that flow as "fantastically" unless you mean "fantastically broken".

Not that it helps today, but the upcoming w10 anniversary update is going to get rid of the 260 char path length limit. Microsoft is waking up to the fact that developers mostly aren't using microsoft dev tools anymore. Hence, docker on windows, ubuntu on windows, redesigned env vars dialog, no more path length limit, nicer command prompt, etc...

Cool! About time.

Re: Flow vs. Typescript

#137
post #28

Earlier quoted context omitted.

No. With flow you can do both: var x /*: string*/ = "" var x : string = "" With TS you can only do the latter. The first one has the advantage that it's legal Javascript, thus not requiring a compiler. Since typescript is set-up purely as a compiler anyway I'm not sure it would be a useful feature for them. A disadvantage could be that it's easier to make silent errors by making syntax errors in the comments. I don't…

That's not entirely accurate. TypeScript 1.8 added the ability to use type information from JSDoc-style comments. For example: /** * @param {string} a * @param {number} b * @returns {string} */ function foo(a, b){ return a + b; } Is functionally identical to: function foo(a: string, b: number): string { return a + b; } See: https://github.com/Microsoft/TypeScript/issues/4790

"functionally" identical to the type checker.

But not functionally identical when it involves my fingers typing (the function there being my ergonomics). Flow would just be inline comments at the code points required.

Re: Flow vs. Typescript

#138
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?

Tweet from npm ceo Isaac Schlueter in 11/2015:

> 42% of @nodejs users use Windows as their desktop env. More than any single *nix.

https://twitter.com/izs/status/661597221763203072

Re: Flow vs. Typescript

#139
post #50

Earlier quoted context omitted.

"then TS would remove that syntax." So there is no hard promise of TS backward compatibility ? Sorry but whole TS looks like another EEE - MS will/can argue on some further JS changes for/against based on existing TS codebase. I hope I'm wrong here though.

You want to have your cake and eat it, too. You've just argued for both viewpoints (TS is bad because it does X and because it doesn't do X). Just be honest and recognize that you dislike Typescript and/or Microsoft. Nothing to be ashamed of, many decisions in tech are based on feelings as much as on cold, calculated decisions.

What? I want TS to be different lang transpiled to JS or be annotation to JS but it is: Embrace and extend existing Standard (superset) and when everyone will write TS it will come to Extinguish step. (I like C# and don't like Windows my like not like to MS tech is 50%)

Re: Flow vs. Typescript

#140
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…

Next time you spend hours looking for a strange bug that turned out to be a honest-to-god misspelling, think about how you wouldn't have had that bug in the first place if you were using static typing.

I feel like people don't like admitting that this happens to them, but when you're at the end of a long day, it's so easy to read your typo as if it were correctly spelled.
Post reply on HN