Năm 2019, một startup fintech ở Hà Nội tuyển tôi vào dự án có 200 file JavaScript. Sau 3 tháng, họ quyết định migrate sang TypeScript. Tôi lúc bấy giờ không hiểu tại sao, vì "JavaScript vẫn chạy được mà". Nhưng rồi khi implement xong, tôi mới nhận ra: đó là lúc codebase dừng lại những tiếng thét giữa đêm kém.
Câu chuyện thực tế từ các dự án lớn
Theo một cuộc khảo sát của Stack Overflow năm 2024, 38% các dự án enterprise sử dụng TypeScript, và mức tăng trưởng này liên tục leo thang. Nhưng con số thứ 2 mới quan trọng: 68% lỗi production trong JavaScript có thể tránh được bằng static typing.
Khi bạn làm việc với 50+ developers, một người viết fetchUser(id) trả về object, nhưng người khác kỳ vọng nó trả về Promise. Một người gán null vào property, người khác không kiểm tra. Trong dự án nhỏ, mọi người nhớ rules. Trong dự án lớn? Chaos is the natural state.
TypeScript không phải là "ngôn ngữ mới", nó là hệ thống chi phí
Điểm mà ai cũng nói nhưng ít người hiểu đúng: TypeScript không thực sự "bảo vệ runtime". Nó là một lớp chi phí chuyên dịch trước deployment, giống như linting nhưng mạnh mẽ hơn 1000 lần.
Khi quy mô dự án đạt 100k+ dòng code, bạn cần điều gì? Không phải speed trong viết code lúc ban đầu. Bạn cần certainty - chắc chắn rằng thay đổi code của bạn không phá vỡ những thứ khác.
Năm 2021, một startup Việt (tôi sẽ không nói tên) merge một PR đơn giản: đổi parameter object từ { name: string, age?: number } thành { fullName: string }. Trong JavaScript, không có warning. Trong 5 chỗ khác nhau, họ vẫn truyền . Cái PR đó phá hỏng feature người dùng yêu cầu 2 tuần trước. Với TypeScript? Compiler sẽ đốt màu đỏ lên mặt developer.
Chia sẻ bài viết
Bài viết liên quan
Bạn cần tư vấn về công nghệ?
Đội ngũ Idflow luôn sẵn sàng hỗ trợ bạn trong hành trình chuyển đổi số.
Dự án càng lớn, refactoring càng khó. Trong JavaScript, đổi tên function từ getUserById thành fetchUserById, bạn phải:
1Tìm tất cả nơi gọi function
2Cầu nguyện bạn không miss chỗ nào
3Chạy toàn bộ test suite (nếu có)
4Deploy và cầu nguyện tiếp
Với TypeScript + IDE tốt (VS Code, WebStorm), bạn chỉ cần:
1Rename symbol (F2 trong VS Code)
2Xong. Compiler tự find & replace + kiểm tra tính hợp lệ.
Một công ty sử dụng TypeScript có thể refactor 500 dòng code trong 30 phút. Một công ty dùng JavaScript dùng 2 ngày để test. Với 50+ developers mỗi ngày refactor 5-10 lần, bạn tiết kiệm 400+ giờ/năm (hoặc $12k-20k nếu tính lương).
Type system là documentation
Hôm qua tôi mở một file utils/api.ts trong dự án. Header của hàm là:
Tôi không cần đọc implementation. Tôi đã biết:
- Function này async
- userId phải là string (UUID?)
- Email và name là optional
- Nó trả về User + ChangeLog
- Có option để include audit log
Với JavaScript, comment tốt có thể giúp, nhưng:
- Comment lỗi thời
- Comment không được kiểm tra
- Comment dễ bị ignore
Type không bao giờ bị ignore vì compiler sẽ đập mặt bạn.
Insight ít ai nói: TypeScript thực sự tiết kiệm code
Mọi người nghĩ TypeScript viết nhiều hơn JavaScript vì phải khai báo type. Thực tế? Đối với dự án lớn, TypeScript viết ít hơn 15-20% vì:
Bạn viết ít defensive coding hơn (kiểm tra null/undefined)
Bạn không cần so many unit tests cho type-checking logic
IDE autocomplete tốt hơn, ít typo hơn
Refactoring tự động lớn hơn, ít boilerplate hơn
Trade-off thực sự
TypeScript có giá:
- Setup phức tạp hơn: webpack config, tsconfig, type definitions
- Developer ramp-up chậm hơn: junior mất 2-3 tuần để comfortable
- Build time dài hơn: thêm 2-5 giây compile time
Nhưng khi dự án có 30+ developers và 5+ năm lifetime, những chi phí này coi như không có gì so với cost of bugs and refactoring hell.
Khi nào bạn thực sự cần TypeScript?
>50k dòng code: Single dev có thể dùng JavaScript, team thì không
>10 developers: Miscommunication về type tăng exponential
>6 tháng codebase lifetime: Technical debt tích tụ, cần safety net
API/backend product: Thay đổi contract API dễ break frontend
Dự án NextJS 5k dòng của 1 người? JavaScript ok. Enterprise backend serving 10 services? TypeScript là must-have.
---
TypeScript không phải là magic bullet, nhưng trong dự án lớn, nó là sự khác biệt giữa "code that runs" và "code you can confidently change". Ở Idflow Technology, chúng tôi thấy rõ điều này qua từng dự án scale-up.
