Thank you TypeScript
I will be posting a series of Thank you <techstack-component> posts to thank some of the important technologies used in building SQL Frames starting with this one about TypeScript.
Building a major framework with the goal to make it easy to use, by as many as possible and to solve as many use cases as possible, the choice of the programming language can potentially make a huge difference. SQL Frames gladly embraced TypeScript. As this was done mid-way after several thousands of lines of code, it was not a trivial effort. However, it did pay off well.
Early on it was decided that it should be possible for SQL Frames to be executed within the browser. That limited the choices to JavaScript. Though Web Assembly could be another choice, it was decided to stick to a mature technology for the time being.
The initial ideation and prototyping using JavaScript turned out to be successful. However, as the SQL Frames framework was shaping up, it became clear that to build something that can last for years to come, the work had to move to something else. Something else that provides type guarantees, something that makes it easy to refactor code without worrying about introducing runtime errors. Since the goal is to provide an enterprise grade data analytics solution, the code base has to be written in a language that can provide type safety, avoid runtime errors and make the code maintainable for the long term.
Having been a big fan of Haskell I am familiar with PureScript that allows writing code in Haskell like language and transpile it to Javascript. But being not fluent enough in Haskell also made me rethink if I wanted to go down the PureScript path even though it relaxes some strict constraints imposed by Haskell and makes it lot more easy to work with several monads all at once.
Luckily, there is another option and that is TypeScript. TypeScript provides static type checking eliminating a class of errors. TypeScript is and will always be a language that has JavaScript language as a subset. The great thing about this is that it's possible to gradually transition the JavaScript code base to TypeScript.
The process of moving a large JavaScript code base to TypeScript had been surprisingly pleasant. This was done in two steps. First step was to move all the code to be TypeScript compatible with plenty of anys and almost no unknowns to gradually getting rid of most anys with some unknowns. The second step was to start organizing the code more structured as separate packages, classes and interface. Some of this is possible in JavaScript as well and it's just a matter of discipline. But there is a great deal of things that's not possible to express in JavaScript such as interfaces and parametric polymorphism.
In spite of lots of manual testing and some test automation there have been some bugs that were easily surfaced due to type checking errors. All of these have been fixed and that's part of the reason to move away from any and if necessary towards unknown.
Another reason to move towards TypeScript was the fact that there is a way to use TYPE DOC to auto generate documentation for the API.
While there are several benefits of moving to TypeScript the single most drawback is the build time. What used to take few seconds using rollup.js ended up being several seconds. This killed the productivity for a while but that has been solved and will be discussed in another post.