Image by Author
# Introduction
You’ve been coding in Python for a while, absolutely love it, and can probably write decorators in your sleep. But there’s this nagging voice in your head saying you should learn TypeScript. Maybe it’s for that full-stack role, or perhaps you’re tired of explaining why Python is “totally fine” for large codebases.
Here’s the thing: TypeScript isn’t just “JavaScript with types.” It’s what JavaScript should have been from the start. And if you’re coming from Python, you already understand more than you think.
# Going from Python to TypeScript
Python gives you duck typing and dynamic flexibility. TypeScript gives you the same flexibility with a safety net. Think of it as Python’s mypy if mypy actually worked everywhere.
In Python, you can call any method on any object and “hope” it works. TypeScript tells you at compile time whether it will work, saving you from those "AttributeError: 'NoneType' object has no attribute 'name'" moments.
# Python: You hope this works
def process_user(user):
return user.name.upper()
// TypeScript: You know this works
function processUser(user: User): string {
return user.name.toUpperCase();
}
If user doesn’t have a name property, TypeScript catches it before your code ever runs. So you don’t need defensive if hasattr(obj, 'attribute') checks everywhere.
# TypeScript Basics
Let’s start with the basics of TypeScript.
// Variables and Basic Types
Python’s type hints are optional suggestions. TypeScript’s types are more like enforced contracts. The good news? TypeScript can infer most types automatically, so you don’t need to annotate everything.
# Python
name = "Alice"
age = 30
is_active = True
scores = [95, 87, 92]
user = {"name": "Bob", "age": 25}
// TypeScript
const name = "Alice"; // string (inferred)
const age = 30; // number (inferred)
const isActive = true; // boolean (inferred)
const scores = [95, 87, 92]; // number[] (inferred)
const user = { name: "Bob", age: 25 }; // object (inferred)
// Or be explicit
const name: string = "Alice";
const scores: number[] = [95, 87, 92];
You only need explicit annotations when the inference isn’t obvious or when you want to be extra clear about your intentions.
// Functions
Function syntax maps almost directly, but TypeScript’s approach to default parameters is cleaner than Python’s mutable default argument gotchas.
# Python
def greet(name: str, excited: bool = False) -> str:
suffix = "!" if excited else "."
return f"Hello, {name}{suffix}"
// TypeScript
function greet(name: string, excited = false): string {
const suffix = excited ? "!" : ".";
return `Hello, ${name}${suffix}`;
}
// Or arrow function (Python lambda equivalent)
const greet = (name: string, excited = false): string =>
`Hello, ${name}${excited ? "!" : "."}`;
The arrow function syntax is similar to Python’s lambda, but more powerful. You can write full function bodies or concise one-liners. Template literals (those backticks) work just like Python’s f-strings.
// Classes
TypeScript classes feel more streamlined than Python classes. No more self everywhere, and constructor parameters can automatically become properties.
# Python
class User:
def __init__(self, name: str, email: str):
self.name = name
self.email = email
def greet(self) -> str:
return f"Hi, I'm {self.name}"
// TypeScript
class User {
constructor(public name: string, public email: string) {}
greet(): string {
return `Hi, I'm ${this.name}`;
}
}
That public keyword in the constructor is TypeScript’s shorthand for “create this property automatically and assign the parameter value to it.” So you don’t have to use the self.name = name boilerplate. You can also use private or protected for encapsulation.
# Where TypeScript Gets Interesting
This is where TypeScript starts to feel interesting as you move beyond the basics.
// Union Types (Python’s Union but better)
Python’s Union types from the typing module work, but they’re sometimes verbose. TypeScript’s union types are built into the language.
# Python
from typing import Union
def process_id(user_id: Union[str, int]) -> str:
return str(user_id)
// TypeScript
function processId(userId: string | number): string {
return userId.toString();
}
The | syntax is cleaner than Union[str, int], and TypeScript’s compiler can perform more sophisticated type checking. It knows which methods are available based on the specific type at runtime.
// Literal Types
Python’s Literal types are relatively new but helpful. TypeScript, however, has much more effective literal types.
# Python
from typing import Literal
Status = Literal["pending", "approved", "rejected"]
def update_status(status: Status) -> None:
print(f"Status: {status}")
// TypeScript
type Status = "pending" | "approved" | "rejected";
function updateStatus(status: Status): void {
console.log(`Status: ${status}`);
}
Try to pass an invalid string like “maybe” to updateStatus, and TypeScript will refuse to compile. Your editor will even provide autocomplete for the valid options. It’s like having an enum that’s actually useful.
// Interfaces
Python’s dataclasses are great for creating structured data:
# Python
from dataclasses import dataclass
@dataclass
class User:
name: str
email: str
age: int
But interfaces in TypeScript are more flexible. They describe the data without creating a specific class implementation.
// TypeScript
interface User {
name: string;
email: string;
age: number;
}
// Use it anywhere
const user: User = { name: "Alice", email: "alice@example.com", age: 30 };
Any object that has the right properties automatically satisfies the interface. No inheritance required, no explicit class instantiation needed. It’s duck typing with compile-time verification.
# Learning More TypeScript Features
Now let’s learn a few more useful features of TypeScript.
// Generics (Like Python’s TypeVar)
Python’s generic typing works, but it’s clunky. TypeScript generics feel natural and powerful right out of the box.
# Python
from typing import TypeVar, List
T = TypeVar('T')
def first(items: List[T]) -> T:
return items[0]
// TypeScript
function first(items: T[]): T {
return items[0];
}
// Works with anything
const firstNumber = first([1, 2, 3]); // number
const firstString = first(["a", "b", "c"]); // string
TypeScript automatically infers the generic type from usage. Call first with numbers, and it returns a number. Call it with strings, and it returns a string. No explicit type parameters needed, but you can provide them when the inference isn’t clear.
// Type Guards
Type guards let you write runtime checks that the compiler understands and uses to narrow types in subsequent code.
function isString(value: unknown): value is string {
return typeof value === "string";
}
function processValue(value: string | number) {
if (isString(value)) {
return value.toUpperCase();
}
return value.toFixed(2);
}
The value is string syntax tells TypeScript that if this function returns true, the parameter is definitely a string. Inside the if block, you get full string methods and properties. No casting, no assertions, just smart type narrowing based on your runtime checks.
// Mapped Types (List Comprehensions for Types)
Think of mapped types as list comprehensions, but for type transformations. They let you create new types by transforming existing ones.
type User = {
name: string;
email: string;
age: number;
};
// Make all properties optional
type PartialUser = Partial;
// Make all properties readonly
type ReadonlyUser = Readonly;
// Pick specific properties
type UserContact = Pick;
These utility types ship with TypeScript and solve common patterns. If you need a type that’s like User but with optional fields for updates, you can use Partial<User>. And if you need to ensure no modifications after creation, use Readonly<User>.
# Error Handling in TypeScript
Python developers love try/except blocks, but they can get verbose. TypeScript uses a different approach using result types and union types for error handling that make errors explicit in your function signatures:
// Result type pattern (inspired by Rust)
type Result = { success: true; data: T } | { success: false; error: E };
// Make this file a module
export {};
// Assuming you have a User type and parseUser function
interface User {
name: string;
// ... other properties
}
function parseUser(data: unknown): User {
// Your parsing logic here
// This should throw an error if parsing fails
if (!data || typeof data !== 'object') {
throw new Error('Invalid user data');
}
const user = data as any;
if (!user.name || typeof user.name !== 'string') {
throw new Error('User name is required and must be a string');
}
return { name: user.name };
}
async function safeParseUser(data: unknown): Promise> {
try {
const user = parseUser(data);
return { success: true, data: user };
} catch (error) {
// Fix: Handle the case where error might not have a message property
const errorMessage = error instanceof Error ? error.message : String(error);
return { success: false, error: errorMessage };
}
}
You can use it like so:
// Usage (wrapped in an async function or use at top level in a module)
async function example() {
const rawData = { name: "John Doe" }; // Example data
const result = await safeParseUser(rawData);
if (result.success) {
console.log(result.data.name); // TypeScript knows this is User
} else {
console.error(result.error); // TypeScript knows this is string
}
}
// Call the example function
example();
This pattern makes errors explicit in the type system. Instead of exceptions flying around invisibly, errors become part of the return type. The Result<T, E> type forces you to handle both success and failure cases. TypeScript’s discriminated unions make this pattern simple: the success property tells which branch of the union you’re in, so it knows whether data or error is available.
# Conclusion
TypeScript is becoming super popular in web development, large-scale applications, and anywhere you need robust APIs.
The transition isn’t about learning a new language. It’s more about applying everything you know about good software design in a different ecosystem. Your Python intuition for clean code, readable APIs, and thoughtful abstractions translates directly.
So open VS Code, create a .ts file, and start coding. The worst thing that happens? You learn something new. The best thing? You might just find your new favorite language. Happy coding!
Bala Priya C is a developer and technical writer from India. She likes working at the intersection of math, programming, data science, and content creation. Her areas of interest and expertise include DevOps, data science, and natural language processing. She enjoys reading, writing, coding, and coffee! Currently, she’s working on learning and sharing her knowledge with the developer community by authoring tutorials, how-to guides, opinion pieces, and more. Bala also creates engaging resource overviews and coding tutorials.