First of all: I’m not a native speaker.
If anything sounds offensive, I’m truly sorry for it.
This is in no way my intention.
There are fewer TypeScript developers than JavaScript developers, which may make growing the number of contributors harder
I think the weight of this argument is strongly dependent on which languages you compare.
If you chose something like JavaScript and Erlang, this would be a major issue.
But I’m not aware of two languages that are as close as TypeScript and JavaScript.
TypeScript is basically JavaScript + Types.
If you ignore the types, basically every JavaScript developer can read the code.
Even the types you use in JavaScript are the same.
TypeScript adds an additional compile step to our build process, which could harm developer productivity
On paper, this might be true, but in practice, there are far more time-consuming things than waiting on the compiler.
The compilation step is often only a fraction of the effort you have to put into a new feature.
Arguably other ways to improve the reliability of the code are to increase the test coverage of unit tests and integration tests, but there will always be some bugs that slip through the net which could have been caught by static typing.
I fully agree.
Barriers to Contribution
Migrating the code to TypeScript eliminates a lot of ambiguities and makes assumptions explicit.
This helps to understand big unknown code bases.
I would argue that this even lowers the barrier to contribution.
While looking at JavaScript might be more convenient, I don’t think that it can outweigh the insight it brings to an unknown codebase.
When the project first started we had live reloads of static resources on the front end and plain interpreted Node.js on the back end so the development cycle was extremely fast.
I agree that live reloads make a lot of sense in the frontend and can largely increase your productivity.
But the backend isn’t stateless like a CSS file or an HTML file.
If you change something, you need to reload the application.
Loading an adapter alone takes some time.
Compiling the TypeScript sources isn’t a big deal here.
How would we feel about converting the codebase into TypeScript, only to convert it back to JavaScript at a future point in time once it has grown even bigger?
Actually, pretty good.
The TypeScript migration alone increases the code quality a lot.
It forces you to think about things you normally wouldn’t think about because it just works in JavaScript.
Even if you go back to JavaScript, the effort isn’t wasted.
- Revert the whole code base back to JavaScript but increase test coverage to improve reliability
I think you would need to put a lot of effort into writing tests to achieve the same confidence level.
Which, in my opinion, reduces productivity and makes it harder for people to develop new features.
- Convert the whole code base to TypeScript but find a way to improve build times and developer productivity
I’m in favor of this proposal.
- Convert the back end to TypeScript , but leave the front end as plain JavaScript
My impression is that the webpack process is far heavier than the TypeScript compilation.
I don’t have numbers, but my feeling is that there is little to gain by removing TypeScript while still using webpack.
- Convert the whole back end to Rust instead
I also like this idea.
It would also be pretty cool to have a gateway that is just a single binary with a very low memory footprint.
Also, no amount of automated testing is ever going to catch all the bugs that static typing could, and vice-versa.
Exactly 