Enhancement: Flow support #500
Comments
|
I'm a long-time Flow user, but I'm kind of skeptical of the benefit of making Deno natively support both. Don't they have practically identical syntax and type system capabilities? The main differences seem to be tooling support and ecosystem proliferation, which Typescript seems to be winning on. Someone with an existing Flow-using codebase can always compile their code to plain Javascript with Babel first to be able to use it in Deno. (And possibly when Deno supports custom loaders, one could make a project that runs Babel on all imported files automatically.) The only benefit to making Flow be natively supported by Deno is reducing configuration, and introducing an on-ramp into Flow for new users (which is more a benefit to Flow than to Deno). I guess I'm worried that if Deno has multiple type system options, that 1) it will cause choice paralysis for users and cause some to pick neither (I can easily imagine Deno tutorials avoiding picking either in order to stay relevant to users who pick either), and 2) bifurcate the community to making libraries that work with one or the other. (Personally as a long-time Flow user, the only thing that disappoints me about Typescript is that the option "strictNullChecks" is not on by default. Strict null-checking is amazing for forcing people to stop being sloppy and start being explicit about where nulls are expected. I would love Deno forever if it set that option on by default or just forced it.) |
|
I think Deno is significant enough to enforce the proposed typescript config you propose. If Deno went with Flow instead of TS, Flow may over take TS in a couple years. I also think Deno is big enough to fork TS... Make it better, faster, stronger and call it TypedJS (TJ) |
|
@rayfoss outside of a preference, you seem to imply that Flow is better than TypeScript, or that forking TypeScript would be an advantage. Is there more behind that argument? As far as forking, TypeScript has about 10 people full time dedicated to maintaining TypeScript plus a community of several thousand contributors. Deno is not that big. Forking TypeScript, which will continue to be leveraged in all sorts of runtime environments including browsers, Node.js, etc and limiting that code to only run in Deno will likely benefit no-one. You seem to imply that there are things that could be improved in TypeScript by forking it. What did you have in mind? Why wouldn't it be beneficial to contribute those back to TypeScript instead of forking it? Deno just adopting Flow will not make Flow bigger than TypeScript. If the engineering powerhouse of Facebook can't achieve large adoption of Flow, Deno won't help, it will simply limit the usefulness of Deno. Some might argue that Facebook is even de-emphasise Flow, as ReasonML seems to be their big focus at the moment.
I am going to be suggesting that the internal TypeScript code of deno move to |
|
Flow has 17k stars vs typscripts 37k, both are actively developed and strongly supported. I agree with you on --strict. |
I am not sure what that means in practice. Deno has 24k stars and 0 users and not even a binary release. It is unwise to judge things by GitHub stars. Both V8 and SpiderMonkey are mirrors and only have 10k and 1k stars respectively. You asserted "If Deno went with Flow instead of TS, Flow may over take TS in a couple years." To what end? Why are you suggesting this course of action? |
|
Let's think about a time when TC39 will finally adopt types-proposal and both Typescript and Flow own typing syntax will lose it's JS-compliance. It will be not an issue in case of Typescript. Because it supports So, i see exactly zero reasons to support Flow. It has worse typing, worse tooling and clearly losing it's momentum. If we want to joke around with numbers, lets check npm: |
|
@garkin I was not aware of TC39. Flow isn't losing momentum, at the moment. It's just not gaining much either. I was suggesting this course because I'm following PayPal's lead and using it. I don't expect Flow projects to have a big problem with TC39, its usually configured in a way where just files go through Flow first so the extension is irrelevant. Flow would have let us use a pipeline more similar to what most developers use in the front end, which is typically Bable backed transpilation. As opposed to the monolithic approach of merging the typechecker and transpiler into one. https://medium.jonasbandi.net/here-is-why-you-might-not-want-to-use-typescript-part-1-alternatives-ec1248bb6dc P.S. this was like preaching buddhism to the catholic choir. |
While this is something that was discussed a bunch of times before - as far as I know the current consensus is for TC39 to not pursue adding static type checking as part of the core language and to cater for the needs of pluggable type systems (like TS and Flow). I think that the eventual plan might still be to have language level types (like ES4) but I don't see that happening any time in the next 2-3 years.
I don't think we do in Deno, I think the goal is to do what's right and useful and not what's popular necessarily. Though my mileage might vary. |
I don't think this is an issue for either of them, as the have both continued to adapt to syntax changes. For example Private Instance Fields is going to "conflict" with the Another example is "protocols". TC39 is fully aware that TypeScript uses the keyword I don't think either project will lose JavaScript compliance.
Not that this is relevant for deno, but the TypeScript team and Babel worked together to allow Babel to transpile TypeScript, in exactly the same fashion as Flow does.
Not that I want to start an argument, but you weren't preaching. You simply threw it out there like it was an abject fact without any support. Your first factual argument for Flow was that it has half as many GitHub stars. Eventually you stated "well PayPal uses it" and "I get to use Babel" as your main arguments. The first one is totally subjective and hopefully we agree popularity contests are not a good gauge of technical appropriateness. The second one is as stated above irrelevant in general and very specifically irrelevant for discussion of deno. I am not a TypeScript fanboy because someone uses it, I was entirely resistant to using TypeScript four years ago when it was first muted by some team I was working with. My first biggest objection was "it was Microsoft, are you serious?" My second was "I don't compile code, I hit refresh in my browser!" From there I actually started using it, and because of what it help me achieve, and helped others who used the software I helped create with it achieve, I started to really appreciate it. I then became active in contributing to the direction of the language, in a wider community way and have met the core team on a couple of occasions. I have a good understanding of how the language works and what the core team's design objectives are. I also have a pretty good understanding of where JavaScript is at a language and where it is headed. So when someone rocks up and says "Flow should be supported", yeah, maybe it triggers me a little, but I want to understand if that is just a random throw away comment, or if there is real substance there. So feel free to preach, but if you are going to preach, understand your religion.
There have been on and off discussions, but you are right, there is nothing serious. There have been several statements that if something were to be adopted, it would be minimal, and follow the type annotation semantics of |
|
The ocaml choice is a major problem for flow adoption. In any case deno is a very new project and can't afford to go in so many directions. We're heavily tied to TS and will remain so. That is, I won't add flow support. In the limit that may change, but not in the foreseeable future. |
I was wrong, since 2018 Flow realy got some traction:
|
|
This is essentially a duplicate of #1739 |
https://github.com/facebook/flow
Many of us prefer Flow syntax over Typescript
The text was updated successfully, but these errors were encountered: