TypeScript jako kolejny krok po JavaScript

Jeśli znasz już JavaScript na tyle, że pytanie "co dalej?" zaczyna się robić aktualne, odpowiedź coraz częściej wygląda tak samo: TypeScript. Nie jest to przypadek — stoją za tym konkretne dane, nie tylko moda.

TypeScript właśnie wyprzedził JavaScript na GitHubie

W 2025 roku TypeScript wyprzedził JavaScript i Pythona i stał się najpopularniejszym językiem na GitHubie — to największy skok w rankingu języków od ponad dekady. Liczba kontrybutorów piszących w TypeScript wzrosła o 66% rok do roku (ponad milion nowych osób), docierając do około 2,6 miliona deweloperów łącznie. To nie jest powolny, organiczny wzrost — to wyraźny zwrot, który GitHub wiąże bezpośrednio z rozwojem narzędzi AI.

Statyczne typowanie uczy myślenia o programowaniu

W czystym JavaScript zmienna może być dziś liczbą, a za chwilę stringiem — i nic Cię o tym nie ostrzeże, dopóki kod nie wybuchnie w runtime. TypeScript zmusza Cię do podjęcia decyzji o typie danych zanim napiszesz resztę logiki, co w praktyce uczy porządniejszego planowania funkcji i struktur danych — umiejętność, która przenosi się później na każdy inny język ze statycznym typowaniem (Java, C#, Kotlin).

// JavaScript: błąd wykryjesz dopiero w runtime
function getTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

// TypeScript: błąd wykryjesz w edytorze, zanim odpalisz kod
interface CartItem {
  price: number;
}

function getTotal(items: CartItem[]): number {
  return items.reduce((sum, item) => sum + item.price, 0);
}

TypeScript daje programowaniu obiektowemu to, czego JavaScript nie ma

JavaScript ma klasy, ale nie ma prawdziwych interfejsów, modyfikatorów dostępu (protected) czy sprawdzania w czasie kompilacji, czy klasa faktycznie implementuje to, co obiecuje. Zobaczmy to na przykładach odwołujących się do 4 filarów programowania obiektowego — enkapsulacji, dziedziczenia, polimorfizmu i abstrakcji — które w czystym JavaScript trzeba wymuszać konwencją, a w TypeScript wymusza sam kompilator.

Enkapsulacja — private i protected sprawdzane w czasie kompilacji

class BankAccount {
  private balance: number = 0;

  deposit(amount: number): void {
    this.balance += amount;
  }
}

const account = new BankAccount();
account.balance = 1000; // ❌ Property 'balance' is private

W JavaScript ukrycie balance wymaga konwencji (podkreślnik, closure) albo nowszej składni #balance — żadna z nich nie ostrzeże Cię w edytorze, zanim kod się wykona. TypeScript zgłasza błąd kompilacji w momencie, gdy ktoś spróbuje złamać enkapsulację.

Dziedziczenie i interfejsy — kontrakt, który kompilator wymusza

interface Mentor {
  name: string;
  teach(topic: string): void;
}

class FrontendMentor implements Mentor {
  constructor(public name: string) {}

  teach(topic: string): void {
    console.log(`${this.name} uczy: ${topic}`);
  }
}

Jeśli FrontendMentor zapomni zaimplementować metodę teach, TypeScript zgłosi błąd przed uruchomieniem kodu — w czystym JavaScript dowiedziałbyś się o tym tylko w sytuacji, gdy ktoś faktycznie wywoła tę metodę.

Polimorfizm — ten sam interfejs, różne implementacje, bez zgadywania

class PythonMentor implements Mentor {
  constructor(public name: string) {}
  teach(topic: string): void {
    console.log(`${this.name} uczy Pythona: ${topic}`);
  }
}

function runLesson(mentor: Mentor, topic: string): void {
  mentor.teach(topic); // działa dla każdego Mentor, niezależnie od konkretnej klasy
}

runLesson(new FrontendMentor("Mateusz"), "React");
runLesson(new PythonMentor("Anna"), "Django");

runLesson nie musi wiedzieć, z jaką konkretną klasą pracuje — wystarczy, że obiekt spełnia kontrakt Mentor. To samo da się napisać w JavaScript, ale tylko TypeScript sprawdzi za Ciebie, czy przekazany obiekt rzeczywiście ma metodę teach o właściwej sygnaturze, zamiast wywalić się w runtime.

Abstrakcja — abstract class, czego JavaScript w ogóle nie ma

abstract class Shape {
  abstract area(): number;

  describe(): string {
    return `Pole powierzchni: ${this.area()}`;
  }
}

class Circle extends Shape {
  constructor(private radius: number) {
    super();
  }
  area(): number {
    return Math.PI * this.radius ** 2;
  }
}

new Shape(); // ❌ Cannot create an instance of an abstract class

JavaScript nie ma odpowiednika abstract class — klasę bazową bez pełnej implementacji trzeba symulować konwencją (np. rzucaniem błędu w metodzie, która "powinna" być nadpisana). TypeScript robi to deklaratywnie i sprawdza na etapie kompilacji, a nie dopiero wtedy, gdy ktoś spróbuje tę klasę bezpośrednio stworzyć.

Dlaczego to ma znaczenie właśnie teraz, w erze kodu pisanego przez AI

Tu dochodzimy do najważniejszego, najbardziej aktualnego powodu. Coraz więcej kodu — Twojego i Twoich przyszłych współpracowników — powstaje z pomocą asystentów AI (Copilot, Claude, ChatGPT). Problem w tym, że modele językowe mylą się w specyficzny sposób: według danych GitHuba aż 94% błędów kompilacji w kodzie wygenerowanym przez LLM to błędy związane z typami.

To właśnie te błędy TypeScript wychwytuje automatycznie, w edytorze, zanim kod trafi do review czy na produkcję. Innymi słowy: im więcej kodu w Twoim projekcie pochodzi od AI, tym ważniejsze jest, żeby ten kod był otypowany — a żeby skutecznie czytać, poprawiać i kontrolować to, co AI napisało, musisz znać TypeScript przynajmniej na poziomie pozwalającym zrozumieć, co dany typ gwarantuje, a czego nie.

Nowy projekt w TypeScript czy migracja istniejącego kodu JS?

Jeśli pracujesz już przy jakimś projekcie w czystym JavaScript, nie musisz przepisywać wszystkiego na raz. TypeScript jest zaprojektowany pod migrację krok po kroku — to dokładnie ten scenariusz, o który najczęściej pytają programiści zaczynający z TypeScript (jedno z pytań o migrację create-react-app z JS na TS ma na Stack Overflow 33 tysiące wyświetleń).

Krok 1: dodaj TypeScript bez wymuszania niczego

npm install --save-dev typescript
npx tsc --init

W świeżo wygenerowanym tsconfig.json ustaw dwie opcje, które pozwalają JS i TS żyć razem w jednym projekcie:

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": false,
    "strict": false
  }
}

allowJs mówi kompilatorowi, żeby nie ignorował plików .js — reszta projektu dalej się buduje, nawet jeśli nic jeszcze nie przepisałeś.

Krok 2: zacznij sprawdzać typy w plikach .js, zanim je przepiszesz

Zanim zmienisz choć jedno rozszerzenie pliku, możesz dodać // @ts-check na górze pliku .js i opisać typy w komentarzach JSDoc — TypeScript zacznie zgłaszać błędy już w edytorze, bez żadnej migracji:

// @ts-check

/**
 * @param {number} price
 * @returns {number}
 */
function addVAT(price) {
  return price * 1.23;
}

addVAT("20"); // ❌ TypeScript już to złapie, mimo że to wciąż plik .js

Krok 3: zmieniaj rozszerzenia od plików bez zależności

Zacznij od plików, które nic nie importują z innych Twoich modułów (helpery, funkcje czysto matematyczne, formatery) — tam kompilator nie musi jeszcze znać typów reszty projektu. Zmień .js na .ts (albo .jsx na .tsx), napraw błędy, które się pojawią, i przechodź do plików, które zależą od już przepisanych.

Krok 4: włącz strict na koniec, nie na początku

Włączenie strict: true od razu na całym, niewielkim jeszcze otypowanym projekcie zwykle generuje dziesiątki błędów naraz i zniechęca. Zostaw strict: false do momentu, aż większość plików ma już rozszerzenie .ts, a potem włącz strict i idź błąd po błędzie — to ten sam mechanizm, który stoi za błędem implicitly has an 'any' type, tylko zastosowany świadomie, na końcu procesu, a nie jako niespodzianka na starcie.

Co dalej

Jeśli te argumenty Cię przekonują, to nie znaczy, że TypeScript trzeba poznawać zaraz po pierwszych liniach JavaScriptu. W programie mentoringu frontendowego na devmentor.pl kolejność jest inna — i nieprzypadkowa: najpierw JavaScript, potem React, a dopiero później TypeScript razem z Next.js.

Powód jest prosty: React daje szybkie, widoczne efekty — po kilku tygodniach masz działającą aplikację, nie tylko ćwiczenia na konsoli, co na wczesnym etapie nauki jest kluczowe dla motywacji. Dopiero gdy umiesz już budować interfejsy w Reakcie, TypeScript przestaje być kolejną przeszkodą do przeskoczenia, a staje się tym, czym naprawdę jest: sposobem na robienie tego, co już umiesz, bezpieczniej i bardziej przewidywalnie. Stąd kolejność js → react → ts → next w programie, a nie odwrotnie.