Sự ra đời và cái chết của JavaScript
JavaScript chạy trong trình duyệt với đặc quyền thấp. Tuy nhiên, nó lại vận hành cả máy chủ, các công cụ build và các pipeline. Đây không phải là một kế hoạch định sẵn. Đó là một chuỗi các bản vá lỗi cho một quyết định từ năm 1995.
Hiểu được lý do tại sao điều này xảy ra sẽ thay đổi cách bạn thiết kế stack của mình ngày nay.
Bài diễn thuyết năm 2014 của Gary Bernhardt không phải là về sự hoài niệm. Đó là một sự chẩn đoán về những xung đột trong kiến trúc. Ông đã chỉ ra một vòng cung đầy mỉa mai: JavaScript vốn là một ngôn ngữ đồ chơi nhưng lại tồn tại được nhờ vào vị thế độc quyền trong trình duyệt. Chính sự độc quyền đó đã biến nó thành ngôn ngữ được sử dụng nhiều nhất trên thế giới.
Sự mâu thuẫn này rất đơn giản. Trình duyệt phải chạy mã một cách an toàn và nhanh chóng. Hai mục tiêu này xung đột với nhau.
Vào năm 2014, người ta từng đặt cược rằng WebAssembly sẽ thay thế JavaScript. Điều đó đã không xảy ra hoàn toàn. WebAssembly ổn định và hữu ích cho những thứ như Figma hay Google Earth. Nhưng nó không thay thế JavaScript với tư cách là một ngôn ngữ lập trình ứng dụng.
Thay vào đó, JavaScript đã biến đổi. TypeScript, các bundler và các runtime mới như Bun ra đời để khắc phục những xung đột mà Bernhardt đã chỉ ra.
Đừng dùng bài diễn thuyết này để né tránh việc học JavaScript. Đừng dùng nó để biện minh cho việc nhảy sang WebAssembly khi chưa gặp vấn đề về hiệu năng.
Hãy dùng nó như một danh sách kiểm tra cho stack của bạn:
- Tôi có đang dùng cái này vì nó là công cụ tốt nhất không?
- Hay vì nó là thứ duy nhất hoạt động được ở đây?
- Chi phí vận hành (overhead) của các công cụ đang giải quyết xung đột hay chỉ đang chuyển dịch nó?
- Nếu bắt đầu lại từ đầu vào hôm nay, tôi có chọn thứ này không?
- Ngưỡng hiệu năng tối đa (performance ceiling) có chấp nhận được cho trường hợp sử dụng của tôi không?
TypeScript giúp xử lý kiểu dữ liệu (types) tại thời điểm biên dịch (compile time). Nó không lấp đầy được khoảng cách giữa các kiểu dữ liệu của bạn và dữ liệu thực tế truyền qua mạng. Bạn vẫn cần phải xác thực tại thời điểm thực thi (runtime validation).
Bài học quan trọng nhất là: hãy biết liệu công nghệ bạn đang dùng tồn tại nhờ vào giá trị thực sự hay nhờ vào vị thế độc quyền.
Đừng thay đổi runtime của bạn dựa trên một dự đoán từ năm 2014. Hãy thay đổi khi bạn có dữ liệu đo lường thực tế cho thấy sự nghẽn cổ chai (bottleneck).
Nguồn: https://dev.to/jtorchia/the-birth-and-death-of-javascript-2014-what-still-holds-and-what-doesnt-2hae