Why I Decided to Migrate My JavaScript Project to TypeScript

-
I’ve been working on this project to support my health tracking and climbing training routine. It’s a project close to my heart. Not just a tool, but a companion for my family's long-term fitness journey. As I started planning its future, I realized that keeping it maintainable and scalable over the years would be a challenge with plain JavaScript. That’s when I decided to take the plunge and migrate my project to TypeScript. Here’s why I made that choice, focusing on one key reason: long-term maintenance.

The Project: A Long-Term Commitment

This isn’t a throwaway app or a quick side project. My goal is to build something I can rely on for years, tracking my nutrition, workout progress, and climbing goals. Over time, I’ll likely add features like data visualizations, goal-setting tools, or even integrations with wearables. With that kind of evolution in mind, I needed a foundation that wouldn’t crumble under the weight of future updates. JavaScript, while flexible and fast to work with, started feeling like a risky choice for a project I want to maintain and grow over the long haul.

Why TypeScript? Long-Term Maintenance

After some research (and a bit of hesitation), I settled on TypeScript for one standout reason: if the project will evolve over years, TS reduces future headaches. Let me break that down.

With JavaScript, it’s easy to write code that works today but turns into a mystery tomorrow. Ever accidentally passed a string to a function expecting a number? In JS, you might not notice until something breaks at runtime, sometimes months later. For a personal project like mine, where I might not touch the code for weeks at a time, that’s a recipe for frustration. TypeScript, with its static typing, catches those mistakes before the code even runs. For example, if I define a function like this:


function logClimbingGrade(grade: number) {
    console.log(`Today’s climb: Grade ${grade}`); 
}

TypeScript will yell at me if I accidentally call logClimbingGrade("V8") instead of logClimbingGrade(8). That’s one less bug to chase down when I revisit the code a year from now.

Beyond catching errors, TypeScript acts like built-in documentation. As my app grows (say, with a TrainingSession interface defining properties like date, duration, and intensity) I won’t have to guess what data I’m working with. The types tell the story:



When I come back to this code after a long break (or if I ever share it with someone else), it’s crystal clear what’s expected. That clarity is gold for long-term maintenance.

This migration is about more than just code. It’s about building something reliable for my future self, a tool I can trust as I push my climbing grades higher and fine-tune my health goals. TypeScript gives me confidence that, even as the project evolves, I won’t be buried under a pile of obscure bugs or forgotten logic. For a long-term companion like this app, that peace of mind is worth every minute spent learning and converting.

Comments

Post a Comment

Popular posts from this blog

HTTP Message Converters in Spring MVC

-
When building web applications with Spring MVC, there are times when you don’t want to generate HTML responses using view templates like Thymeleaf or JSP. Instead, you might need to work directly with JSON data in HTTP APIs, reading or writing it straight from the HTTP message body. This is where HTTP Message Converters come in handy. Let’s dive into how they work, starting with a quick recap of some fundamentals. The Role of @ResponseBody You might know the @ResponseBody annotation. Here’s how it works: When you annotate a controller method with @ResponseBody , Spring skips the usual view resolution process (handled by viewResolver ). Instead, it writes the return value directly into the HTTP response body. This is powered by HTTP Message Converters , which handle different types of data: String : Processed by StringHttpMessageConverter . Objects : Handled by MappingJackson2HttpMessageConverter (for JSON). Byte arrays : Managed by ByteArrayHttpMessageConverter , and so on....
Read more

The problem of Data class in using JPA Entity in Kotlin

-
Image
 When I wrote this test, I expected that " DataIntegrityViolationException " is thrown. Since I put @NaturalId in email, it seemed that there was no problem. When I debugged to find out what the problem was, the member objects were successfully saved even though they had same email value. I found out it was from me poorly understanding how it works when using data class with JPA entity . This is the link:  https://github.com/spring-guides/tut-spring-boot-kotlin#persistence-with-jpa Since data class creates automatically equals/hashCode , data class's equal compares all the filed. Therefore, id value was different so it recognized they were different entities even though they were same entity.
Read more

@ModelAttribute vs @RequestBody in Validation

-
Image
1. What is @ModelAttribute? What does it do? @ModelAttribute is primarily used to bind request data like HTML form data or query parameters (e.g., ?name=abc&price=100) to objects. In other words, it converts data entered by users in forms into objects that can be easily handled by controllers. How does it work? It maps HTTP request parameters (e.g., name, price) individually to object properties on a field-by-field basis. For example, if an ItemSaveForm object has name and price fields, request parameters name="book" and price=1000 would be set as itemSaveForm.setName("book"), itemSaveForm.setPrice(1000). Important characteristic : Even if there's a problem with one field (e.g., price has an invalid value like "abc" that can't be converted to a number), the other fields (e.g., name) are still bound normally. It has a structure that can partially succeed. Advantages: Flexibility: Since it processes on a field-by-field basis, even if certain fiel...
Read more