1/3 From JavaScript to TypeScript: How We Enhanced Code Reliability in SAPUI5 Development

[PetrBecka]

In our development team, we’ve always emphasized the importance of quality code. On top of automated code checks we implemented the four-eye principle for pull request approval, ensuring that every piece of code was reviewed by at least two developers before being merged. Yet, despite these precautions, certain issues with JavaScript continued to slip through the cracks and make their way into production.

The Challenges We Faced with JavaScript

While JavaScript is an incredibly versatile language, its flexibility came with some serious challenges. Even with thorough reviews, it was nearly impossible to ensure that:

• All conditions were correct: Reviewers could miss subtle logical flaws in complex conditionals.
• Edge cases were handled properly: Unhandled edge cases often led to unexpected behavior in production, which only became apparent after users encountered them.
• Accessing undefined properties: JavaScript’s dynamic typing meant that developers sometimes accessed undefined or null properties, leading to runtime errors that weren’t caught until much later.

These challenges caused bugs and errors to creep into customer systems, leading to delays in issue resolution and frustration for both our team and clients. Even with strict code reviews, the lack of static typing in JavaScript made it difficult to guarantee that all possible cases were covered.

Source: https://i.sstatic.net/QmW6V.png

Enter TypeScript: A Game Changer for Code Quality

To address these issues, we decided to transition from JavaScript to TypeScript, and the results have been remarkable. TypeScript’s static typing system has completely changed the way we approach development, making our code more reliable, maintainable, and less prone to errors.

With TypeScript, even junior developers are empowered to write higher-quality code. The compiler provides instant feedback on potential issues, such as incorrect conditions or missing edge case handling. This leads to:

• Immediate detection of issues: Developers are notified of potential problems, such as accessing undefined properties or incorrect data types, during development instead of at runtime.
• Increased accountability: TypeScript forces developers to handle edge cases explicitly, ensuring that conditions and logic are sound before the code is even reviewed.

Cleaner, more maintainable code: The ability to define types, interfaces, and classes makes the codebase easier to understand and work with, even for team members who weren’t involved in its original development.

Source: https://i.sstatic.net/XXVvo.png

The Benefits We've Seen So Far

Since moving to TypeScript, we’ve seen a dramatic reduction in the number of bugs and errors that make it into production. The code we produce is now far more reliable, and issues that would have gone unnoticed in JavaScript are caught early, often before they even leave the developer's machine.

What’s more, junior developers are writing better, more robust code right from the start. The TypeScript compiler acts as a mentor, guiding them through potential issues and ensuring that all logical paths are accounted for.

OpenAI. (2024). A cartoon illustration of a software web developer sitting at a desk, coding on a computer and being controlled by TypeScript compiler [AI-generated image]. DALL-E

Conclusion: Why TypeScript is Our New Standard

While JavaScript has its place, TypeScript has proven itself as a much-needed improvement for our SAPUI5 applications. With its static typing, we can catch more issues during development, produce cleaner code, and deliver more reliable applications to our customers.

Moving forward, TypeScript will be the standard for all of our new projects, and we’re excited to see how this change continues to improve our development process.

In the following part, we dive deeper into how your team can adopt this technology and how to support developers in reaching the level required to produce SAPUI5 applications written in TypeScript.

[wridgeu]

Nice introduction to your blog post series. When you mentioned TS acting as mentor that helps with guidance, I immediately thought: are you also using linting like eslint (which is more likely) or (my preferred alternative nowadays) biome?

When it comes to biome especially, I thought that its CLI is really neat in helping one to improve or "question" the JS code you write. As always it could also lead to over-optimization when not (yet) necessary (in case of forEach usage) but each rule can be configured. In other cases like with CSS units for example it can be really helpful. I really like the embedded direct link to MDN for most of the rules in biome, trying to not only show squiggly red lines but help you why and improve it at the same time. Of course, reading the rules themselves for whatever linter you're using, also helps.

TS in combination with those tools (if you pass configuration hell, depending on project size/setup :P) is truly a new world. Even if it may be "limiting" to some, at times. 😉