Typescript Reigns Supreme
If you, my fellow web developer, haven’t heard yet, Typescript is under the magnifying glass again. A popular package recently got slaughtered in an effort to rid the codebase of all typescript and thus “simplify” it in the PR author’s words. Because of its popularity, and perhaps the heavy-handed, quick merge, developers across the chatting spaces have started to opine to one another about what morality of such a decision. So allow me to opine.
Javascript, if you recall, was a language cobbled together quickly in the very early days of the internet for the purpose of providing developers a simple runtime inside browsers. Of course, having had more than 20 years to develop, it has become one of the most used languages in computer programming. Similar to python, javascript is a high level language. It is meant for functional programming so that developers could play fast and loose as they quickly build small apps and widgets for their users. Things like audio players, and form automations, and image galleries come to mind. You do not get control of pointers to smartly manage memory, and seldom do you see classes and inheritance dictating your models and data flows. Just functions for days, and I-don’t-care-how data structures.
Think about how powerful that is though. You can set a junior developer down in front of an IDE and they’ll rapidly develop that custom menu your product manager made up on the spot, one that reflects permissions, what page their on, and what state the user is in at that time. Then your PM says make it save bookmarks! And the developer tacks on some more JSON, and bam, done before lunch. No POJOs, no pointers, just a big ol’ JSON blob to define all the things.
Hopefully I’ve irked a few developers by now. “But you should care about data structures, your arrays can be so much more memory efficient in lower level languages,” one might say. Or “that junior developer just made a mess of a JSON blob that no one will ever understand,” or better yet, “object oriented programming is far superior to functional programming.” Or the even more critical of you might say, but your title says typescript reigns supreme, so get on with it.
Valid points, all of them. My point is, however, that often our tasks are not very complicated at all, are they? Writing forms is such a tedious process, and it’s never more complicated than given these inputs, toggle the visibility, or given these outputs, validate the form. Classes and objects don’t fit nicely around these tasks, especially when it’s all reactive, like most HTML forms and react.js forms are. Since the majority of web development consists of simple tasks, we should keep things as high level as possible. So, when considering what language to use, javascript is remarkably well suited to the task.
Nevertheless, that junior developer is going to make a huge mess quickly unless they do some real thinking about what a model for the menu should look like. Should there be an array of bookmarks? What makes more sense, some flags to indicate certain permissions, or a resource url, and how do they change when the user changes roles? A clearly defined model to show their senior developers sure would be nice in this situation. Maybe some JSDoc annotations could help, but what about these objects not being passed between functions? Oh well, my senior devs will figure it out. Exit clean code, stage right. Enter spaghetti, stage left. Dim lights.
I know some of you already know how this story goes. The senior developer steps in and says, “look, typescript!” And typescript arrives on stage glistening with sequins (or something, I dunno, I’ve got a theater metaphor going right now) “Typescript will let you define a model for this menu object you keep passing around. Then you won’t get lost wondering what is in your object right now, and it will remind you for free if anything is undefined when you call it.” The play then proceeds with the junior developer falling in love with programming again, letting types guide them around their codebase and protect them from those optionally defined fields. For those of you who haven’t seen the play yet, the developer then runs into generics and other exotic typing, wrestling with the compiler as things get more complicated. Then the developer moves to other codebases, and the issues continue to compound: building with babel, compiling for jest, and stumbling through webpack to find the right build settings.
In the end this play ends up with two diametrically opposed families clashing head to head over which way of life is better, to be free with javascript, or to be powerful with typescript; all while the junior developer and his beloved codebase remain torn in the middle. I know, I said I’m team Typescript, but you can’t ignore the values that javascript originally brought to the table.
In my play, the crisis is averted with the magical, peace-giving, and singular suggestion of using the type any. any restores the freedom javascript granted us all. It no longer matters what extended type is passed into this generic function, trust the developer. any gives those anarchists a bit of space so you can tidy up your enums. any allows you to do what you tell your project managers all the time, punt it.
Sometimes typescript enables those persnickety developers to obsess over the remaining unclaimed soil of codebase without a pattern. Do we really need a pattern for what sequence HTML attributes go in? I’m sorry, there probably is one, and I’m not following it. Forgive me for I have sinned. Should there always be a pattern or should we pick a font and move on?
So, in conclusion, a developer should always use Typescript, and just use any whenever it makes sense. The less experienced will probably use it more, that’s fine, add some types for them in another PR. Typescript greatly improves readability and safety, which becomes more evident as your codebase grows. Make your typescript strictness your dial to control, and leave it low for simple projects, such as UIs or relay backends, and high for complex things like shared libraries and codebases with many contributors. And ultimately, yes, turn up the strictness as much as you can, every effort towards type safety goes a long, long way. Exit wise programmer, stage right.
