Pernah gak sih kamu ngalamin hal kayak gini. Kode udah di-deploy ke production, semua kelihatan aman-aman aja pas development, terus tiba-tiba muncul error kayak gini di console:

PLAINTEXT Snippetplaintext

TypeError: Cannot read properties of undefined (reading 'name')

1 baris•63 chars

UTF-8•Spaces: 4

Kamu buka kodenya, cari baris yang error, dan ternyata masalahnya sepele banget. Ada objek yang kamu kira selalu punya properti

PLAINTEXT Snippetplaintext

name

1 baris•4 chars

UTF-8•Spaces: 4

, eh ternyata di salah satu kondisi objeknya

PLAINTEXT Snippetplaintext

undefined

1 baris•9 chars

UTF-8•Spaces: 4

. Kalau ini kejadian pas kamu masih ngoprek di local, paling cuma buang waktu lima menit. Tapi kalau ini kejadian di production, pas user lagi transaksi, ceritanya jadi lain.

Yang jadi pertanyaan, kenapa sih bug sesimpel ini bisa lolos sampai ke production, padahal kodenya udah "jalan" pas kamu testing manual berkali-kali?

Jawabannya ada di sifat dasar JavaScript itu sendiri.

JavaScript Emang Dibikin Fleksibel, Bukan Aman

JavaScript itu bahasa dengan dynamic typing. Artinya, tipe data sebuah variabel baru ketahuan pas kode dijalankan, bukan pas kode ditulis. Ini yang bikin JavaScript kerasa fleksibel banget dan enak buat prototyping cepat. Kamu bisa nulis kode kayak gini tanpa ada yang protes:

index.jsjavascript

function getDiscount(user) {

  if (user.isMember) {

    return user.membershipLevel * 0.1;

}

  return 0;

}

6 baris•108 chars

UTF-8•Spaces: 4

Kelihatan aman-aman aja kan? Tapi coba pikirin, apa yang terjadi kalau suatu hari fungsi ini dipanggil kayak gini:

index.jsjavascript

getDiscount(null);

1 baris•18 chars

UTF-8•Spaces: 4

atau kayak gini:

index.jsjavascript

getDiscount({ isMember: true }); // membershipLevel-nya lupa diisi

1 baris•66 chars

UTF-8•Spaces: 4

JavaScript gak bakal ngasih peringatan sama sekali sampai kode ini beneran dijalankan. Errornya baru muncul pas runtime, biasanya pas user lagi make aplikasi kamu. Ini yang sering disebut "fail at runtime", dan ini salah satu sumber bug paling umum di aplikasi JavaScript yang udah gede.

Sekarang bandingin sama versi TypeScript dari fungsi yang sama:

index.tstypescript

interface User {

  isMember: boolean;

  membershipLevel: number;

}

function getDiscount(user: User): number {

  if (user.isMember) {

    return user.membershipLevel * 0.1;

}

  return 0;

}

11 baris•190 chars

UTF-8•Spaces: 4

Begitu kamu coba manggil

PLAINTEXT Snippetplaintext

getDiscount(null)

1 baris•17 chars

UTF-8•Spaces: 4

atau

PLAINTEXT Snippetplaintext

getDiscount({ isMember: true })

1 baris•31 chars

UTF-8•Spaces: 4

tanpa

PLAINTEXT Snippetplaintext

membershipLevel

1 baris•15 chars

UTF-8•Spaces: 4

, editor kamu langsung ngasih garis merah dan pesan error, bahkan sebelum kamu pencet tombol run. Bug yang tadinya baru ketahuan pas user komplain, sekarang ketahuan pas kamu masih ngetik kodenya.

Nah, ini dia inti dari value TypeScript sebenarnya. Bukan sekadar nambahin tipe data ke JavaScript, tapi mindahin momen ketahuan bug, dari "pas production" jadi "pas development".

TypeScript Itu Superset, Bukan Bahasa Baru dari Nol

Penting dipahami dari awal, TypeScript itu bukan bahasa pemrograman yang beneran terpisah dari JavaScript. TypeScript itu superset dari JavaScript. Artinya, semua kode JavaScript yang valid, otomatis valid juga sebagai kode TypeScript. Kamu gak perlu belajar sintaks yang benar-benar baru dari nol.

Yang TypeScript tambahin cuma satu lapisan ekstra, yaitu sistem tipe statis, yang jalan pas proses compile. Pas kode TypeScript dikompilasi, semua anotasi tipe bakal dihapus, dan hasil akhirnya cuma kode JavaScript biasa yang bisa dijalankan di browser atau Node.js kayak biasa.

Jadi kalau kamu udah nyaman sama JavaScript, kamu udah punya delapan puluh persen bekal buat belajar TypeScript. Sisanya tinggal belajar cara mikir pakai tipe.

Tiga Manfaat yang Sering Diremehin Pemula

Banyak orang mikir TypeScript itu cuma soal "biar gak salah tipe data". Padahal manfaat aslinya jauh lebih dalam dari itu. Berikut tiga manfaat yang biasanya baru kerasa setelah kamu pakai TypeScript di proyek yang udah cukup besar.

1. Nangkep Bug Sebelum Kode Sempat Dijalankan

Ini manfaat yang paling gampang dirasain. Typo di nama properti, salah jumlah parameter fungsi, atau lupa nangani kasus

PLAINTEXT Snippetplaintext

null

1 baris•4 chars

UTF-8•Spaces: 4

dan

PLAINTEXT Snippetplaintext

undefined

1 baris•9 chars

UTF-8•Spaces: 4

, semuanya bisa ketahuan langsung di editor. Kamu gak perlu nunggu proses build, apalagi nunggu user lapor bug.

Contoh sederhana, typo di nama properti:

index.tstypescript

interface Product {

  price: number;

  quantity: number;

}

function getTotal(product: Product) {

  return product.pric * product.quantity; // Property 'pric' does not exist

}

8 baris•175 chars

UTF-8•Spaces: 4

Di JavaScript biasa, kode kayak gini tetep "jalan" tapi hasilnya

PLAINTEXT Snippetplaintext

NaN

1 baris•3 chars

UTF-8•Spaces: 4

yang bikin bingung pas mau didebug. Di TypeScript, error ini langsung ketahuan sebelum kode sempat dijalankan sama sekali.

2. Refactoring Jadi Jauh Lebih Santai

Bayangin kamu punya fungsi yang dipakai di dua puluh tempat berbeda di codebase, terus kamu perlu ubah struktur objek yang jadi parameternya, misalnya ganti nama properti

PLAINTEXT Snippetplaintext

userName

1 baris•8 chars

UTF-8•Spaces: 4

jadi

PLAINTEXT Snippetplaintext

fullName

1 baris•8 chars

UTF-8•Spaces: 4

. Di JavaScript biasa, kamu harus cari manual satu-satu, atau berharap tools pencarian teks kamu nangkep semuanya dengan bener. Risiko human error-nya gede banget.

Di TypeScript, begitu kamu ubah definisi tipe, editor langsung nandain semua tempat yang masih pakai nama properti lama sebagai error. Kamu gak perlu nebak-nebak, tinggal ikutin daftar error yang muncul, benerin satu-satu, dan kamu tahu persis kapan refactoring udah kelar seratus persen. Ini yang bikin developer berani ngelakuin perubahan besar tanpa takut ada bagian yang kelewat.

3. Tipe Data Jadi Dokumentasi yang Gak Pernah Basi

Dokumentasi manual, kayak komentar atau file README, punya masalah klasik, gampang basi. Kode berubah, tapi dokumentasinya lupa diupdate. Akhirnya dokumentasinya malah nyesatin.

Tipe data di TypeScript gak punya masalah kayak gitu, karena tipe itu bagian dari kode itu sendiri. Kalau tipenya gak sesuai sama kode, compiler bakal langsung protes. Ini yang bikin tipe data berfungsi sebagai dokumentasi yang otomatis selalu sinkron.

Coba lihat bedanya. Fungsi JavaScript ini butuh komentar biar dimengerti:

index.jsjavascript

// user adalah object dengan id (number), email (string), roles (array of string)

function canAccessAdmin(user) {

  return user.roles.includes('admin');

}

4 baris•154 chars

UTF-8•Spaces: 4

Sementara fungsi TypeScript ini udah jelasin dirinya sendiri:

index.tstypescript

interface User {

  id: number;

  email: string;

  roles: string[];

}

function canAccessAdmin(user: User): boolean {

  return user.roles.includes('admin');

}

9 baris•157 chars

UTF-8•Spaces: 4

Developer lain yang buka fungsi ini, termasuk kamu sendiri enam bulan kemudian, langsung tahu persis bentuk data yang diharapkan, tanpa perlu baca kode implementasi lain atau nanya ke tim.

Tapi Bukan Berarti TypeScript Gak Ada Kekurangannya

Biar artikel ini jujur dan berimbang, penting juga ngebahas sisi yang sering gak disebutin pas orang lagi promosiin TypeScript.

Learning curve di awal beneran kerasa. Konsep kayak generics, union types, atau utility types butuh waktu buat dipahami, apalagi kalau kamu sebelumnya cuma terbiasa sama JavaScript yang fleksibel tanpa aturan.

Ada proses compile tambahan. TypeScript perlu dikompilasi jadi JavaScript dulu sebelum bisa dijalankan. Ini nambah satu langkah di workflow yang sebelumnya gak ada di JavaScript biasa, meskipun di kebanyakan setup modern proses ini udah otomatis dan cepat.

Kode bisa kerasa lebih panjang. Terutama pas awal belajar, sebelum kamu terbiasa manfaatin type inference dengan baik, kamu mungkin bakal nulis anotasi tipe di tempat yang sebenarnya gak perlu, jadi kode kelihatan lebih panjang dari yang seharusnya.

Buat proyek yang kecil banget, kadang kerasa berlebihan. Kalau kamu lagi nulis script sekali pakai yang cuma lima puluh baris dan gak bakal dipelihara jangka panjang, effort setup TypeScript kadang gak sebanding sama manfaatnya.

Poin terakhir ini penting. TypeScript bukan solusi buat semua situasi. Tapi begitu proyek kamu mulai punya lebih dari satu developer, bakal hidup lebih dari beberapa bulan, atau punya struktur data yang rumit, manfaat TypeScript mulai kerasa jauh lebih besar dibanding biayanya.

Jadi, Kapan Sebaiknya Pakai TypeScript?

Sebagai patokan kasar, TypeScript layak banget dipertimbangkan kalau salah satu dari kondisi ini kejadian:

Proyeknya dikerjain lebih dari satu orang, di mana komunikasi lewat tipe jauh lebih efisien dibanding komunikasi lewat chat atau dokumentasi terpisah
Codebase-nya diperkirakan bakal hidup dan berkembang lebih dari beberapa bulan
Aplikasinya berhubungan sama data yang rumit, kayak response API dengan banyak nested object
Kamu pengen bisa ngelakuin refactoring besar dengan lebih percaya diri di masa depan

Sebaliknya, kalau kamu lagi bikin proof of concept singkat, script otomatisasi sekali pakai, atau eksperimen kecil yang bakal dibuang setelah beberapa jam, JavaScript biasa masih sangat masuk akal.

Penutup

TypeScript bukan soal nambahin tipe data biar kelihatan lebih "profesional". TypeScript itu soal mindahin titik deteksi bug sedini mungkin, bikin refactoring jadi berani dilakuin, dan bikin kode ngejelasin sendiri bentuk data yang dia harapkan. Kekurangannya emang nyata, tapi buat kebanyakan proyek yang serius, manfaatnya jauh lebih gede dibanding biayanya.

Di artikel berikutnya, kita bakal masuk ke konsep yang sering bikin pemula bingung sejak awal belajar TypeScript, yaitu bedanya

PLAINTEXT Snippetplaintext

any

1 baris•3 chars

UTF-8•Spaces: 4

PLAINTEXT Snippetplaintext

unknown

1 baris•7 chars

UTF-8•Spaces: 4

, sama

PLAINTEXT Snippetplaintext

never

1 baris•5 chars

UTF-8•Spaces: 4

. Tiga tipe ini kelihatan mirip tapi punya filosofi yang beneran beda, dan salah milih di antara ketiganya bisa diam-diam buka celah bug yang justru pengen dihindarin TypeScript sejak awal.

TypeScript Bukan Cuma JavaScript yang Dikasih Tipe Data

TypeScript Fundamentals

JavaScript Emang Dibikin Fleksibel, Bukan Aman

TypeScript Itu Superset, Bukan Bahasa Baru dari Nol

Tiga Manfaat yang Sering Diremehin Pemula

1. Nangkep Bug Sebelum Kode Sempat Dijalankan

2. Refactoring Jadi Jauh Lebih Santai

3. Tipe Data Jadi Dokumentasi yang Gak Pernah Basi

Tapi Bukan Berarti TypeScript Gak Ada Kekurangannya

Jadi, Kapan Sebaiknya Pakai TypeScript?

Penutup

Timur Dian Radha Sejati

Punya Masalah Arsitektur atau Ingin Membangun Sistem yang Benar?

Artikel Rekayasa Terkait

Utility Types yang Wajib Diketahui Setiap Developer TypeScript

Generics, dari Dasar sampai Constraint

Union, Intersection, dan Discriminated Union, Cara Memodelkan Data yang Punya Banyak Kemungkinan Bentuk