TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Flow vs. Typescript

244 点作者 dmnd将近 9 年前

24 条评论

greenspot将近 9 年前
I like very much the last slide and the author&#x27;s recommendation. Helpful and better than the admonitory &#x27;yes you should use typed JS&#x27;:<p>- if your project does not live for long: no<p>- if your project is really simple: no<p>- if there is a chance you will need to refactor the thing: yes<p>- if your system is very important or even crucial for the success of your company: yes<p>- if people enter or leave your team frequently: yes
评论 #11845213 未加载
评论 #11845177 未加载
评论 #11852720 未加载
Skinney将近 9 年前
The main problem for me, is that Flow doesn&#x27;t support Windows (yet?). I&#x27;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&#x27;re making the switch to TypeScript once 2.0 is released (easier to port with strictNullChecks).
评论 #11845317 未加载
评论 #11844932 未加载
评论 #11844896 未加载
msoad将近 9 年前
Both differences in this presentation are addressed in TypeScript 2.0<p><a href="https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;TypeScript&#x2F;wiki&#x2F;Roadmap#20" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;TypeScript&#x2F;wiki&#x2F;Roadmap#20</a>
评论 #11845528 未加载
OmarIsmail将近 9 年前
No matter which one you go with if you&#x27;re project is going to live for any decent length of time please use one of these. Typed Javascript plugs many holes in the language and there is a qualitative positive difference in productivity.<p>Just go with one of them. Seriously.
abritinthebay将近 9 年前
The biggest win that flow has - and for me puts it over typescript - is that it has comment decorator syntax.<p>This means I can <i>just write JavaScript</i> and add comments for types. No transplier step, no messing around in a different but similar language, no additional complexity, just easy.<p>It&#x27;s inferred types are a much stronger system imo too - gets out of a developers way more.<p>Typescript is great, but I really do prefer Flow in every metric.
评论 #11844741 未加载
评论 #11844787 未加载
评论 #11844935 未加载
评论 #11848594 未加载
评论 #11844773 未加载
tinza123将近 9 年前
TypeScript 2.0 added control-flow based analysis, therefore cases like the one in slide 12 will be cached with the `strictNullChecks` flag.
chvid将近 9 年前
I am the only one who is happy to code without static typing? Enjoying fast compilation, small, fast editors, flexibility.<p>I don&#x27;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.<p>Take one of the examples in the slides:<p><pre><code> let obj: string; obj = &#x27;yo&#x27;; &#x2F;&#x2F; Error: Type &#x27;number&#x27; is not assignable to type &#x27;string&#x27;. obj = 10; </code></pre> I simply don&#x27;t write code like that. The crucial difference is that I would pick a variable name that made it obvious what goes in it:<p><pre><code> let text = &#x27;yo&#x27;; &#x2F;&#x2F; This line here - I would not in practice write as 10 obviously does not belong in text: text = 10; </code></pre> (similarly I would never use the variable name &#x27;what&#x27;)
评论 #11845633 未加载
评论 #11845340 未加载
评论 #11845318 未加载
评论 #11845330 未加载
评论 #11846180 未加载
评论 #11846652 未加载
评论 #11845915 未加载
评论 #11847095 未加载
评论 #11845507 未加载
评论 #11845329 未加载
评论 #11845391 未加载
runn1ng将近 9 年前
From my experience - Flow is still very &quot;unstable&quot; and in heavy development. I haven&#x27;t tried TypeScript at all, so I cannot compare that.<p>It&#x27;s absolutely true that Flow team is merging all pull good requests, fixing issues (the backlog is big - 500 issues - but TypeScript has 1000, so it&#x27;s not incomparable) and the system is made dramatically better every release.<p>But there are still rough edges, especially when working with ES6 modules and import&#x2F;requires&#x2F;etc.<p>Again, I don&#x27;t know how TypeScript compares, I learned Flow and am just using that.
评论 #11847083 未加载
gear54rus将近 9 年前
So today is typed JS day? <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;XAEeEFm.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;XAEeEFm.png</a><p>Guess it&#x27;s time for the question then... I haven&#x27;t dived into this whole types thing yet so could someone provide a TLDR about either Flow or TS being opinionated and their impact on an established toolchain?<p>I have no intention of changing half of my tooling just to be compatible with what fb thought would be a good idea, and even less so for ms. A build step is required, I take it, but that&#x27;s not a problem. Would I be able to use old libs and build tools? Are there properly working code formatters for both? What about editor support (Sublime)?<p>I also understood that TS is a superset of ES6, what is Flow&#x27;s relationship with ES6+?
评论 #11844925 未加载
评论 #11844840 未加载
评论 #11844826 未加载
评论 #11845016 未加载
评论 #11872717 未加载
cabalamat将近 9 年前
This would be a good deal less irritating if it was written as an essay and not a slideshow.
评论 #11848261 未加载
评论 #11848462 未加载
robinricard将近 9 年前
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&#x27;s tooling (Nuclide especially), you will end up with great tools (jump to def, integrated checking, ...). However if you just start the project and you use VSCode, TS seems to be a strongest choice. Depends on what you do, but both tools are great, whatever you choose, typechecking is worth in javascript if you need more reliability and maintainability.
评论 #11845264 未加载
solomatov将近 9 年前
The best things about flow which typescript doesn&#x27;t have is sound typesystem. I hope typescript will adopt it at some point in time.
评论 #11845294 未加载
Matthias247将近 9 年前
Regarding the first class definition with TS (sayer):<p>You can shorten the it by declaring the public variable within the constructor: constructor(public this.what: string) {}. Thereby you can eliminate the property declaration as well as the assignment inside the constructor.<p>And regarding the non-nullable example for Typescript: I think there is an non-implicit-returns option or something similar for the compiler which would have warned you that the function is incomplete. Of course it wouldn&#x27;t help if you manually return null&#x2F;undefined (which is valid).
whatever_dude将近 9 年前
Good presentation. But two caveats:<p>First, the slides about lack of non-nullable types in TypeScript are incorrect, if you count the beta (&quot;next&quot;) versions. It&#x27;s already part of 2.0 [1] which should be out soon [2]. He says &quot;there is hope&quot; but it&#x27;s more than hope, it&#x27;s a certainty. (the date of the presentation is not clear, but seems outdated to me)<p>Second, there&#x27;s a lot of other features that are left out. Union types, flexible interfaces, etc. They&#x27;re not on par between the two languages, but many of those are almost as helpful as types, just more specific, so they&#x27;re important if one is trying to draw a comparison.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;TypeScript&#x2F;wiki&#x2F;Roadmap#20" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;TypeScript&#x2F;wiki&#x2F;Roadmap#20</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;TypeScript&#x2F;milestones" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;TypeScript&#x2F;milestones</a>
michaelwww将近 9 年前
Slide 12 is incorrect. TypeScript does catch this with a &quot;not all control paths return a value&quot;
fridek将近 9 年前
I think the biggest loser in this comparison is Closure Compiler, which is around for years with all those features. It&#x27;s also still active with development on understanding and transpiling ES6 and even TypeScript from what I&#x27;ve heard [1]. There also made a good move recently, enabling ES6 modules packages instead of its own goog.provide&#x2F;goog.require.<p>Yet, the available toolchain for it is years behind others. If you wonder how you should have any live reload development with it, you can either rely on community plugins like grunt-closure-compiler [2] or hope plovr[3] is finally resurrected back to a state where it&#x27;s usable. This all sounds fine until you think about any unit testing. The only karma runner[4] for closure is simply broken and unmaintained. Even worse, most of npm packages you might want to compile with your code will output thousands of errors because there is no clear way to whitelist code as &quot;not my code leave it alone&quot;. I can just hope one day Google will publish a yeoman generator with all those things solved and get it back in the game.<p>[1] <a href="https:&#x2F;&#x2F;groups.google.com&#x2F;forum&#x2F;#!msg&#x2F;closure-compiler-discuss&#x2F;5EVAw6oO2BI&#x2F;LI9ptKLnCYoJ" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;forum&#x2F;#!msg&#x2F;closure-compiler-discu...</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;gmarty&#x2F;grunt-closure-compiler" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gmarty&#x2F;grunt-closure-compiler</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;bolinfest&#x2F;plovr" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bolinfest&#x2F;plovr</a><p>[4] <a href="https:&#x2F;&#x2F;github.com&#x2F;karma-runner&#x2F;karma-closure" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;karma-runner&#x2F;karma-closure</a>
CuriousSkeptic将近 9 年前
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.<p>A workaround for this is to infer, or explicitly annotate, things to be dynamically typed. And&#x2F;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).<p>This workaround was to strong of a code smell to just let things be like that though. So I&#x27;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.<p>Not everyone will have this problem, but if you&#x27;re anything like me, do consider it before adopting these.<p>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&#x27;re allready comfortable with ES as it is.
评论 #11847480 未加载
avodonosov将近 9 年前
Where I saw the same nullable &#x2F; non-nullable values: Kotlin.<p>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&#x27;s an Array - if you are not going to mutate it).
Hurtak将近 9 年前
I heard somewhere, that TS class syntax diverged somewhat from the spec. Can anybody who has insight into the TS tell me what the situation is?
DJCordhose将近 9 年前
What currently is in TypeScript: <a href="https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;TypeScript&#x2F;wiki&#x2F;What&#x27;s-new-in-TypeScript" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;TypeScript&#x2F;wiki&#x2F;What&#x27;s-new-in-T...</a>
karmakaze将近 9 年前
Flow is more strict than TypeScript as demonstrated by the slides. As such why not use it as a static checker for TypeScript? I don&#x27;t see it so much as a vs. situation. Unless you mean to use the unsafe area in what is valid TypeScript and invalid Flow.
DJCordhose将近 9 年前
What TypeScript 2.0 promises: <a href="https:&#x2F;&#x2F;www.infoq.com&#x2F;news&#x2F;2016&#x2F;04&#x2F;typescript-2-preview" rel="nofollow">https:&#x2F;&#x2F;www.infoq.com&#x2F;news&#x2F;2016&#x2F;04&#x2F;typescript-2-preview</a>
moomin将近 9 年前
If you really want good types with your JS, there&#x27;s always Purescript. (I&#x27;m half serious.)
bkad将近 9 年前
Love the use of Zenburn in the syntax highlighting :)