This post is mainly directed at @Leftmost_Cat, @mr_monkey, @arthelon2 and @shivamt, all of whom I think have written some code for BookBrainz over the past year (but others are welcome to join in!)
I’d like us to decide whether to continue using Flow for type checking, or whether we should switch to TypeScript. Initially, when choosing a type checking system for BookBrainz, it seemed that Flow was the least intrusive of the two, and that we could gradually migrate our code to use it, while TypeScript seemed to be the better choice for new projects.
Because of this Flow was picked and integrated into a few of our repositories (mainly the site). I’d estimate that about 30 files have some meaningful type annotation with Flow.
However, over the past few months, I’ve become increasingly disappointed with Flow. When running it consumes a huge amount of system memory, and seems to have some memory leak which result in certain code structures forcing me to terminate the processes. It’s also quite slow, and lacks good integration with IDEs. In contrast, TypeScript is extremely well integrated into VSCode, faster and supports a variety of features (autocomplete and automatic refactoring) that Flow doesn’t. For more info, see:
I think there are two important questions to answer at this juncture:
Will this increase velocity?
If we don’t take this path, how hard will it be to come back to it in future?
I can’t answer 2, as I’m not familiar enough with the difficulties it could present. As for 1, though, I have strong doubts that it will. Using TypeScript might give us a bit of a boost, but at the cost of additional churn and time spent on yak shaving. Ultimately, it may be a good idea, but if we can put it off, I’d much rather do so.
Just as a disclaimer, I’ve worked on one large JavaScript project where we eventually switched to using TypeScript.
To answer the second point from @Leftmost_Cat, TypeScript is something that can be gradually introduced into the codebase so I don’t think there’s an immediate need to convert. The TypeScript compiler is interoperable with JavaScript files and can even performs some basic error checks.
Having used both Flow and TypeScript before, TypeScript editor integrations are a lot more powerful and the compiler seems to be able to catch more errors and provide better completions. That said, the benefits of TypeScript can only really shine once a decent portion of the codebase is converted and there is some maintenance cost in creating/updating types and dealing with the “strictness” of the compiler.
Like @Leftmost_Cat pointed out, I’m also not sure if the complexity of the codebase is at the point where using TypeScript would significantly speed up development. Better error-checking is nice to have though.
Worth keeping in mind that MBS uses Flow, if we want to try to keep a standard of some sorts among the two projects. Not that it’s necessary either, I guess, but IMO whatever makes it easier for people to contribute to both should be a good thing.
@Leftmost_Cat - you’re right that this won’t lead to a direct increase in velocity. But it also won’t cost much time to switch over - maybe 3-6 hours. I think it makes sense to do this sooner rather than later when we have more Flow-annotated code.
@reosarevok - good point. However, if we were to share code, we’d probably split it into a separate JS package, and it’s possible to create a TypeScript side-file alongside a Flow side-file to provide type information for both systems. But I’d like to hear what @bitmap has to say first.
@LordSputnik Well, I was first looking into adding types to MB sometime in 2016. From what I remember, both TS and Flow had major issues, but Flow had much better type inference (you barely had to add any types and still got good checking), and TS didn’t have what is now strictNullChecks yet, which was kind of a dealbreaker; null and undefined dereference errors were probably one of the most common bugs we’d see.
Flow was easier to integrate. Our build system was already set up and working well using Babel. TS has its own transpiler, and I didn’t want to go through all our Babel plugins and figure out what would break.
I imagine there were other small reasons which I don’t remember.
I’ve kept up with TS development out of interest and it’s certainly moved at a much faster pace than Flow and is better in some ways. You wouldn’t be wrong to go with TS. Flow is steadily improving too, though, and I don’t think it’s a good use of MB development time to switch right now. I also know for a fact that for every issue I currently have with Flow, I’ll find a different one in TS. Nominal types are one example of a feature I’d hate to lose.
I’ve only extensively used TS so I can’t compare properly. The article you posted helps.
In my opinion, unless you’ve identified a specific blocker that would require the change or that Flow is stopping users from participating, I’d rather see development efforts be directed towards the functionality of the website in priority.
Resurrecting this two years on… Flow type annotation coverage is still quite low on BB, and adding more type information to improve the quality of the codebase is something I’m interested in doing, and feels like something helpful.
It also doesn’t seem like a huge amount of effort to flip over to TypeScript - in fact I’ve already manually converted all of the flow-annotated JS in my local copy of the server code to TypeScript in less than an hour.
I think that’s a great idea, but to be honest I just thought it would be quite an endeavor and not the best use of time (considering nothing was broken).
But by all means, if you’re interested in doing the conversion, and even more so if it turns out to be a straightforward task to do and to merge, please do !
My main concern was that we would land in an in-between with flow deactivated but only part of the codebase switched to typescript (if we needed to do multiple PRs), but the work you did locally suggest that won’t be a problem.
Totally up for it on a personal level. I think that’s the right direction to go.
Happy to help if there’s anything you need help with!
Nominal types are one example of a feature I’d hate to lose.