I recently had a conversation about why I insist that JavaScript (and especially TypeScript) developers should learn from Rescript, Elm, Go, Rust, and other languages. A person asked me: “Who cares? Users don’t care what language you use to build your product. Often the business doesn’t care either! There are plenty of companies with tons of spaghetti code, and they sell their products well! So why bother?”
Well, I couldn’t spontaneously say why I care. But I kept thinking about the chat and decided to write my answer in this post.
Let me start with an analogy. Imagine you want to build a house. The builders give you two options: use bricks ‘A’, which are 40% cheaper than bricks ‘B’, which have a better reputation. You might ask: how will this choice affect the house in the long run? The builders can’t say - it depends on how you use the house, the weather, further modifications, etc. The future is unknown. So it’s your money, your investment, the house, the future and therefore your choice.
The house was complete with bricks “A”. You live there (or rent it) happily for a few years. But the environment changes. After a few damp winters, the north wall has become mouldy. You have tried to clean it (patchwork) a few times. But the mould is there and keeps coming back. You ask the contractors to fix it and they say you need to rebuild the wall with better bricks and some additional support structures for other walls. Now the house has these new columns that eat into the interior space. It’s no big deal, but the layout is no longer as good. Then you wanted a new feature - a fireplace. The builders told you that adding a chimney is difficult with these bricks, and you need more support for the roof.
Well, you get the picture. The same goes for cars, shoes, electronics, clothes, appliances - everything - including software. When we buy something, we want to know how reliable it is. We want to be sure that it will still work if we don’t use it 100% as intended. The people who make a product should take that into account too. It’s all about balancing the trade-offs. For example, there are no blenders that are only good for crushing ice. When engineers decide to use certain materials or components, they try to find a compromise to help users get the job done without breaking the bank. You never know how users will end up using your product. So thinking long term and being prepared is your ace in the hole.
So why should we think differently about software? Why should we choose the materials that have proven to be bad for the job? Instead, why not learn new ways of thinking about making reliable software? For example, error handling in JavaScript is weak. The language, the runtime or the compiler don’t care how you handle errors. But the users and the person on call (which may be you) do care. Unless you learn to represent errors as data and adopt TypeScript in your JavaScript projects.
The architectural patterns we choose also play a role. But I’d argue that it’s mostly a business issue because it determines how slow the company gets over time. You see, people leave, taking important knowledge with them, and the documentation gets neglected. So one person may introduce event-driven architecture. The next person may modify it in some way. After a while, a third person will insist that it’s all wrong and start rewriting it (successfully?). All this while working against a delivery plan (or deadlines), introducing new features and a constantly evolving ecosystem. How often have you found yourself looking at the code you wrote and feeling lost?
But you know what, I can get back to my Elm project, which I haven’t touched for two years, and be productive. And I am not the only one who says this. We can learn a lot from Elm. In the Elm ecosystem, many decisions have already been made: code formatting, architecture, compiler, error handling, core libraries, 3rd party libraries, communication with the rest of the world, and more. You just need to focus on implementing the application. The icing on the cake is that there are no runtime exceptions in Elm programs. Why shouldn’t we learn from that? Besides, I’d argue that every senior+ (front-end) engineer needs to write one or two applications in Elm.
People are generally bad at writing code. All kinds of code, including tests. Also, different people will have different experiences and defend their points of view. Choosing a technology on which to base a product is an investment that will play a big role in the future of a company. Fast results in the first few weeks (or even years) don’t guarantee the same speed in the future. Changing technology is hard, but taking good ideas from other technologies is easier.
In the real world, every organisation has goals and constraints. Developers are hired and paid to deliver quality products on time and within budget. There is also no such thing as a stable product - it has to meet the ever-changing expectations of the market and user base. Features must be added and removed, product complexity must be reduced, complex pieces must be broken up, smaller pieces must be combined into a new product, and new distribution platforms must be considered. All this happens as developers come and go.
I understand the argument that companies can sell anything, whether made cheaply or not. The person I spoke to was right - users don’t care (as long as it works as expected). Business doesn’t care (as long as it can grow and maintenance costs are reasonable). But as is often the case, the materials and tools chosen for the job often allow for a fast start and a massive slowdown later. Some companies can afford this because they may have different revenue streams. But it’s certainly not the rule. Also, hiring expensive engineers to make cheap products sounds a bit wasteful. Of course, there are always ways to find cheaper labour elsewhere, but that’s a trade-off. Companies can employ more tools to help with all sorts of complexities. The question is whether this rabbit hole is worth it. Isn’t it better to look around, gain new perspectives and try bringing the good ideas in?
Links
Videos:
Articles: