As a front end developer who has not used the Ruby programming language, I must admit that before this year I did not know who DHH was. My first exposure to him was at a Ruby on Rails meetup where two out of the three speakers offhandedly referenced their distaste for him and his political views. Since neither talk was directly about DHH this piqued my curiosity and in the coming weeks I made an effort to learn about him and why he is such a contentious figure and not your typical startup CEO.
DHH is the creator of the Ruby on Rails framework, has been very involved in the open-source community, and is the co-founder of Basecamp, an author, and a race car driver. He posts regularly on his blog where he candidly expresses his opinions on everything from tech to business. He has been involved in many controversies over the years and while I appreciate his candor I am not surprised that he is not universally popular. I won't go over his full history in this post (he has been in the industry for 20 years) rather I will mostly focus on one recent event that I referenced in my previous post.
DHH removes TypeScript from Turbo-8
For those who were not paying attention to these events a few weeks ago. Turbo-8 is an open-source library initially built by DHH and his team that is proposed for the hotwire technique 1. As outlined on the repo the goal of the Turbo system is to do as much work as possible on the server before sending it back to the client code when the state changes. Like any open source code, anyone can pull it onto their machine, make changes, and then raise a pull request for said changes while following their guide. The code is written almost exclusively in JavaScript/TypeScript and is frequently contributed to by members of the open-source community.
Recently and seemingly out of the blue DHH announced on his blog that Turbo-8 is dropping TypeScript with a link to the PR on the framework. This decision was met with backlash for multiple reasons, as stated Turbo-8 is an open-source library which means it is not just 37signal employees that contribute to it, the decision seemingly came out of the blue with little to no warning. Many people in the community swear by TypeScript over JavaScript and to top all of this off DHH's reputation amongst many community members isn't positive. While many of the responses were in the form of memes and dry, sarcastic humor (which was often funny but not overly mature or helpful) the top comments were objective and well-reasoned:
It's been a few weeks, many active reddit posts were dedicated to it, many a YouTube video was made and many a complaint was had. So in what way can we add discourse to this event in a productive manner? What can we learn from this going forward?
Let's start by separating the art from the artist
A lesson I have learned as an adult is that the words that we say, our actions, and the art we create take on an existence that is separate from us as human beings. This can be a difficult thing to do due to our inherited bias and the halo effect, or in this case the reverse halo effect.
The fact is that humans are complex, malleable, imperfect, and likely to change over time. This is why I propose that the ability to separate the art from the artist, the words from the speaker or the ideas from the person is a very important life skill that will also benefit you as a software engineer. When you separate the art from the artist it opens space for more objectivity, it allows you to question, reaffirm or even change your own beliefs, it can create a productive dialogue and in some cases, it can come full circle and allow you to understand where the creator of the art or idea is coming from 2. So let's get specific...
How can separating the art from the artist can be applied to this situation
As an exercise let's forget everything we know about DHH, whether our opinions of him are positive or negative. Let's be real programmers and break down the problem itself into smaller parts. From what I can see it boils down to two main questions:
"Why is removing TypeScript from any given code base an ill-advised thing to do? What are the arguments for and against it in this particular instance?"
and a question that I beleive gets to the heart of a lot of the criticisms directed at DHH/basecamp:
"Is it justifiable for a company to make sudden, dramatic changes to its open source code that relies on community support for it to thrive?"
Let's start by addressing question 1...
TypeScript or !TypeScript?
TypeScript was developed by Microsoft in 2010 and set out to solve the problem of type errors in JavaScript. For those of you wanting context on its inception then I'd recommend checking out OfferZen origins documentary. TypeScript is a compile-time type checker that subsequently compiles vanilla JavaScript for execution in the browser or server. It also offers developer benefits of enforcing strict use of types through the IDE, let's look at a quick example before moving on. Suppose we have a function that takes in a numeric value and does any amount of arithmetic before returning another numeric value:
Nothing in the ide or language is stopping us from passing parameters of any type to this very simple function and it isn't until run time that we are given errors, often said errors are not the easiest to understand. But looking at the same code in TypeScript:
Suddenly as a developer and in the ide itself, we have red underlines and very readable error messages. Obviously, this is an extremely simple example but when we consider how important consistency is with data types and how strong types like this are self-documenting it's easy to see what the benefits of Strong types are. As our codebases grow TypeScript funnels developers towards being constantly vigilant about the types that they use and will let you know when you step out of line.
The argument against static typing is that it takes longer to write and as a developer, you might spend more time trying to satisfy the compiler than writing the code itself. If you're working with a library like React or NextJS suddenly more types are introduced and when async calls come into play there is even more type complexity introduced.
Furthermore, TypeScript is a compile-time checker that can give a nonvigilant developer the illusion of type safety. As a developer you might satisfy TypeScript, have the code compiled into JavaScript and then during runtime a response might deliver an object in a shape you did not account for when you wrote your code. Of course, a very valid argument against this is that a good developer will account for run-time type checking as well but the point stands that TypeScript is not a cure-all solution.
This has been a very brief description of the pros and cons of TypeScript and I have missed a lot however this leads me to my next point...
The unintended benefits of DHH's decision
The removal of TypeScript from Turbo-8 has had some unintended positive side effects: it's made a lot of developers articulate their opinions on why we use TypeScript and what its strengths and weaknesses are. It has given us a chance to examine our opinions on TypeScript, static vs dynamic typing and why any of us have certain preferences. It created an opportunity to express and even reconsider strongly held opinions and very importantly to educate newer community members on why certain preferences exist.
For anyone newer to programming (myself included) watching these discussions play out is invaluable. TypeScript has been an industry standard for years and while it is easy to explain its benefits and see why it's so widely used its use is not something that is always interrogated vigorously.
Suddenly the reason TypeScript is used and the problems that it solved when it was introduced more than 10 years ago are now a part of an active and feiry discussion. Suddenly there are intelligent, senior developers really deep diving into its benefits and the "why" behind TypeScript 3.
So now that we have seen the arguments for TypeScript and removed the Halo effect let's continue with objectivity and exercise..
Seeing the argument from both sides
DHH made an argument in a podcast (worth a listen) after the fact that the extra code involved with writing types was creating a bad developer experience for him and his team. He likened dynamically typed languages to being more "free" with less code overhead, coming from a company that very much favors Ruby many of the employees were not crazy about the strong typed way of thinking. Let's examine the following statement in a vacuum:
We as a company collectively decided we don't enjoy the developer experience of TypeScript so we opted to remove it.
On the face of it, this is not an unreasonable statement and it is not surprising that a company of people who most likely predominantly come from a dynamic language background might feel this way.
Under what circumstance is it unacceptable for personal preference to inform the languages you use, your system architecture, and how you write your code? At a certain point, bad practices cost money or become very inefficient so the answer is: "Yes, but this is very irresponsible and short-sighted". For a team that prefers dynamic to static typing removing TypeScript does not quite fall under this category.
Some very good arguments have been made for the TypeScript compiler (I certainly found them compelling) but the decision to remove it isn't inevitably going to break the code or make it unmaintainable. If it does boil down to a matter of preference, then it is understandable why TypeScript was dropped by this particular company.
Now let's address the other more pressing question...
What are the ethics of an abrupt change to an open-source codebase?
I am a tourist in the open source community and unsurprisingly many of its members are very loud and passionate. The thing that I don't think DHH accounts for when he talks about the blowback he received is that contributing to open-source code is a labor of love. Anyone outside of his company dedicating their time to contributing is doing so because they care and they want to give back.
But as ever we need to remain unbiased and think about where DHH and 37signals are coming from with the decision. It is clear as day that DHH prioritizes himself and his company first and foremost with his decision-making with the community outside of the company being a distant 2nd place. But he argues that the open-source code that is released is something that they have shared with the community for free. Based on this how much does he objectively owe the people who choose to give up their time to contribute to their code? The hard truth is that, while good relations are always favorable, he owes you nothing. His choice to prioritize himself and his company above the open-source community, while making him unpopular, is a defendable position.
An idea that I always come back to is that if you are someone who thinks for yourself and expresses your opinions in a free and candid way then you will inevitably polarize people. Whether you're a fan of DHH or not you have to concede that he is a free thinker, he speaks his mind and he acts whether his decisions will be popular or not.
Wrapping up
So after looking at the situation objectively it isn't so hard to see where people on both sides of the argument are coming from. Productive conversations can come out of disagreement and at the end of the day it is important to try to see things from other people's points of view.
One question I will leave with: is there a way to bridge the divide? In this instance, it seems like both sides of the argument are left with the impression that the other side is hostile and unreasonable. DHH wrote a follow-up blog to his initial post Open source hooliganism and the TypeScript meltdown and there was a line in there that stood out to me:
"I'm always happy to have technical discussions in good faith with such individuals, and they're certainly entitled to their opinion on a move like this without getting tarred by association with the hooligans who showed up spoiling for a fight."
If I had to guess I'd say that he is sincere in this offer. So here is a throwdown to the open source and Ruby on Rails community: take him up on it. Compile (lol) a list of your grievances, try to empathize with his point of view and meet him in the middle. Remember that it's very important to handle yourself respectably and patiently while also making an effort to understand where the other side is coming from. If you take anything from this post it's that civil and respectful public discussions about opposing ideas are always beneficial to anyone listening
For my money, if this can be a result of DHH's decision then something very productive will have been achieved.
-
For a breakdown of the library and what it does check out this article by Bhumi on dev.to. ↩
-
One thing I would like to make clear is that I am not advocating for separating the art from the artist in every case (that would be exhausting), nor am I suggesting that you should give someone the time of day regardless of how reprehensible you find them. If you find something someone has said or done offensive to the point where you don't want to listen to what they have to say or you wish to boycott their work then it is absolutely your right to do so. ↩
-
This article provided a good breakdown of the more technical discussions involved: https://tomaszs2.medium.com/contributors-angry-after-turbo-8-suddenly-drops-typescript-4ffd4e0be7cd ↩
Top comments (0)