Why we added Typescript and Jest to our tech stack

Technologies and languages used in software development are constantly evolving. It seems like every month there is a new language, library or framework taking the software development world by storm. The abundance of options out there can make it hard to select the best technologies for your project. It can be tricky trying to figure out if a new technology is right for your specific needs. Deciding whether or not to add a new language to your tech stack usually takes a combination of reading documentation, Googling around, reading a fair number of articles, getting advice from other developers in the field and having a play and creating MVPs. More often than not, it can be a case of taking a back seat and waiting to see which technologies stick around. If it sticks around and continues to grow in popularity, you know the language is solid and you now only need to figure out if it fulfils your project needs.

Our approach to new technologies

Here at Inktrap we’re often trialling new technologies to improve the overall quality of our digital products. That’s the reason new languages and frameworks are created, and why as developers we’re always on the lookout for the next best thing to make our lives easier and our products better.

Both Typescript and Jest have been making a lot of noise over the past few years so after some initial viability testing, we decided to progressively add them into our new and existing projects.

What are Typescript and Jest

Before we go into our experiences working with them, let’s nail down what actually they are and what they try to achieve.

Typescript is a programming language built on top of Javascript to help scale large Javascript based projects. All Javascript code is valid within Typescript. This point makes introducing Typescript into your stack much easier to do. The file names .ts and .tsx replace .js and .jsx. Because Typescript is a superset of Javascript, you can write your Javascript exactly as you did before but within the .ts and .tsx files and it works exactly the same as before. On top of this you can add your Typescript specific type checking as much or as little as you like.

Jest is a testing framework for testing Javascript applications, whether that’s solely Javascript, or React, Typescript, Vue, Angular, Node, Babel projects too. Its purpose is to catch bugs and improve the overall quality of your codebase, especially as the project scales. It can be very time consuming to retest the whole site manually when new features are added and so having Jest tests running on every pull request can be a big time saver in finding and fixing bugs.

Why we stuck with them

As a development team we are always seeking ways to reduce bugs and increase our test coverage. We’ve found that spending a little more time working on these 2 aspects reduces the total development time overall as we spend much less time in QA and UAT. And this is exactly the reason we trialled and added Typescript and Jest to our tech stack. Having significantly less back and forth around bugs and changes between us and our clients has resulted in a higher quality product created faster than before. This consequently creates a better agency-client relationship, and with everyone saving money by getting the product out quicker and to a higher quality. Everyone having more confidence in the quality of the product has led to many happy relationships!

Our stack differs depending on the requirements of the project, but we mostly have used React, Tailwind and Laravel previously. The hardest part of adding new technologies to a tech stack is the differing knowledge of the new language within the dev team. What made introducing these technologies into our stack so manageable is the ability to ease them into a project if needed, we didn’t have to do a full 100% adoption if the knowledge wasn’t there. We can pick and choose when, where and to what extent to use them. For anyone not as experienced in the technologies, using them in a more basic way still leads to accessing a majority of the benefits. And over time as experience and knowledge increases, all of the advanced benefits can be achieved also.

By default we strive for every Typescript file to be using types, and to have its own Jest test. This approach gives us the most confidence in terms of quality and is the best approach for getting large test coverage. This is especially important when working with a large codebase that is going to evolve with new features over time.

Our findings

Since being introduced, as a dev team we’ve really noticed the differences in our projects compared to before. Even more so than before, we are really thinking about a feature and planning ahead before writing any code. Writing the types and a test before doing anything else gives us such a strong starting point. By this point we already know exactly what the component requires as input and what it needs to output. When developers are feeling a little lazy, it often feels easier to start writing code rather than plan out how it’ll work. This, however, can lead to the developer having to start again or significantly backtrack after not fully taking into account what is needed. By being strict and always implementing types and tests before anything else, we’ve really cut down on having to rewrite code due to not fully understanding the requirements for the component.

We’ve also had instances where we’ve inadvertently broken a different feature by creating a new feature. Previously the developer might have missed this and it only gets caught within browser testing at a later stage. We’re now catching these bugs much faster with the Jest tests. Catching these bugs early has been beneficial in reducing the amount of time it takes to fix the bug, and also reduces the time the product spends in internal and client testing. Reducing this time has really given everyone involved more confidence in the product before launch.

The whole dev team has been very pleased with the introduction of Typescript and Jest into our tech stack. We’ve really noticed the difference in spotting bugs early, and spotting fewer bugs overall. It’s always an uncertainty adding new technologies into a tech stack and there are benefits and drawbacks to them, but thankfully this time the team is all on board and are very happy with the constant improvements we’ve been making to our digital products.