This is blog #2 in my series on how I'm teaching myself TypeScript. I cover things I've learned, provide links to resources I've found helpful, and share some personal best practices I've developed over the course of the past 3 months. The blogs make will make sense whether you read them in order or out of order, but if you're completely new to TypeScript, I suggest you start with Part I.
Intro
After playing around in the TypeScript Playground and docs, refactoring some of my old JavaScript code into TypeScript, and building my portfolio with TypeScript + jQuery, the next steps in my journey were to create some very basic apps with TypeScript + React and develop my first TypeScript APIs.
In this blog I cover things I've learned about:
- TypeScript's features
- Navigating the TypeScript ecosystem and configuring projects
- Developing personal best practices for working with TypeScript
- How I plan to continue furthering my TypeScript skills
TypeScript's Features
Being a superset JavaScript, TypeScript has a lot of additional features that can be overwhelming at first for JavaScript developers when first going through the TypeScript docs. For me, reading about things like Interfaces, Types, and Tuples lead to a lot of confusion about when I would use these features and why they are valuable.
h/t to this blog for the original image used as the base for this graphic
Two YouTubers that do a great job of showing real-world examples of when it makes sense to use various TypeScript features are Harry Wolff and Ben Awad. They both have multiple videos on specific TypeScript features where they walk through realistic code-snippets that show when it does and does not make sense to use certain features of the language.
That being said, watching a YouTube video or reading a code-snippet from documentation is not enough to fully grasp and internalize any given TypeScript feature and its utility. In order to really make the language work for you, it's important to experiment and build your own on projects, even if very simple. Projects will allow you to develop your own style, build confidence, and start to see firsthand the benefits of Typescript's extra features. That being said, it's not necessary to use all of a language's features in every project just because they exist. The only way to figure out which features make sense for the problem you're trying to solve is by building projects.
For example, TypeScript has a lot of features that make it a better OOP language than JavaScript, but it can also be used for Functional Programming. This video by Fireship helped me understand that just because TypeScript has great OOP tooling, doesn't mean I have to use OOP for every single TypeScript project if it doesn't make sense or if it will slow me down.
So far, I've found myself using Static Typing and Interfaces in every project, Declaration Files and Generics in some projects, and rarely Enums or Tuples.
I'm certain there are some things I'm missing right now, but that's OK. The important thing for me is that I'm seeing benefits from using TypeScript, especially in my Node projects. I'm also learning more about computer science concepts and writing cleaner code as a result of working in TypeScript. So far I've only developed small solo projects, so I look forward to learning more about TypeScript's features as I begin to work on larger projects with other developers.
Navigating the the TypeScript Ecosystem and Configuring TypeScript Projects
TypeScript is a compiled language, and can take some configuration before starting development on any given project. Depending on which packages you are trying to use in your project, you may need to set up Declaration Files or install pre-existing type declarations from npm. For example, if working with TypeScript and jQuery, you'll need to install @types/jquery, and choose a JavaScript compiler like parcel bundler, Webpack, etc.
Sometimes, you may also need to change your ts-config based on which packages and frameworks you're using. I suggest googling the name of the tech you want to use with "TypeScript + ts-config file" (e.g TypeScript and jQuery ts-config file) to find some settings that will work for your project rather than learning what each and every one of the options does when first getting started.
Though you can customize your ts-config file and install additional packages/compilers for your projects, there are also a lot of tools/frameworks that come with TypeScript support built in. If you're like me, you would rather spend your time writing code than configuring and customizing your project's setup, using solutions with great TypeScript support already built in is the way to go. I personally have found create-react-app and (for frontend projects) and Google Firebase (for building APIs) to be great solutions for simple TypeScript projects.
Developing Personal Best Practices
The most important thing I've learned so far while working with TypeScript, is that programming languages are just problem solving tools and that no one language or paradigm is inherently better than another. I have heard this point from more seasoned devs before, and have been able to see the strengths and weaknesses of different languages by building projects in JavaScript, Python, and Ruby, but working with TypeScript has really driven this point home for me because it is so similar to JavaScript. I personally like using TypeScript for backend development more than frontend development.
h/t Mark Pollman for this image
When building an API I want to make it as clean and foolproof as possible. When creating frontends, I like to have more room for creativity and the ability to iterate quickly. TypeScript is more deliberate than JavaScript, and often requires more keystrokes/steps to accomplish the same outcome. At the risk of sounding naive, I don't see much benefit in statically typing things like event handlers in my React code. It feels like an extra step to me that just slows me down. Statically typing function parameters for my API makes complete sense to me, however, because a user could easily input a number into a field that the database expects to be a string, which could cause problems.
In the spirit of making the language work for me, I've become more comfortable with using the any type at times as long as I use it sparingly and avoid using it for primitive types. Using the any everywhere in your TypeScript code kinda defeats the whole purpose of the language, but using it once in a while in the interest of getting your program to "just work" is not a cardinal sin in my opinion.
There's no such thing as perfect code, and as long as you aren't writing software that requires extreme precision for something like a self-driving car or a medical device, attempting to write the most perfect code possible all the time can cause more harm than good and stifle progress. Your future-self will thank you for writing the cleanest code possible, but your future self will also never exist if you spend the rest of your life trying to debug an error that could be solved just by declaring an any type.
Conclusion and What's Next
I've been enjoying using TypeScript so far, and I'm excited to continue working with it and improving my skills. So far, I've learned about a lot of its features and using some of them even feels second nature at this point. If you're just getting your toes wet with TypeScript, or feel intimidated by it at all (like I was at first), then I encourage you to keep going because it gets easier with time and ultimately will improve aspects of your code and programming experience dramatically.
My next steps are:
- Learn typeORM and build an API that takes advantage of TypeScript's OOP features
- Build a project with Next.js + TypeScript
If you're also learning TypeScript I hope you found reading about my experience helpful. If you have any questions, suggestions for how to improve this blog, or if you feel I have gotten anything wrong please do not hesitate to leave a comment below or reach out to me via Twitter DM!
Top comments (0)