Sự ra đời và cái chết của JavaScript (2014)
(destroyallsoftware.com)- Theo dõi lịch sử của JavaScript và lập trình từ năm 1995 đến 2035 theo phong cách khoa học viễn tưởng·hài kịch·bài giảng nghiêm túc
- Phạm vi không chỉ giới hạn ở JavaScript mà còn mở rộng tới lịch sử của toàn bộ ngành lập trình
- Giữ góc nhìn trung lập, không đứng hẳn về phía ủng hộ hay phản đối JavaScript
- Thẳng thắn đề cập đến các khiếm khuyết của ngôn ngữ, nhưng vẫn đánh giá rất tích cực tác động cuối cùng của nó đối với ngành công nghiệp
- Thông điệp cốt lõi là dù có khiếm khuyết, JavaScript vẫn để lại ảnh hưởng tích cực lớn đối với ngành công nghiệp lập trình
Tổng quan bài giảng
- Trình bày theo dạng theo dõi lịch sử của JavaScript và lập trình nói chung từ năm 1995 đến 2035
- Tính chất của bài giảng là sự pha trộn giữa khoa học viễn tưởng, hài kịch và một bài giảng hoàn toàn nghiêm túc
- Đây không phải là bài giảng ủng hộ hay phản đối JavaScript, và không quy về một lập trường duy nhất
- Các khiếm khuyết của JavaScript được đề cập thẳng thắn, nhưng tác động cuối cùng của nó đối với ngành công nghiệp được đánh giá là rất tích cực
1 bình luận
Ý kiến trên Hacker News
Dự đoán khá chính xác rằng sẽ có một thảm họa toàn cầu vào giai đoạn 2020~2025, chỉ là đoán sai loại thảm họa thôi, thật là hay(?)
Rất ra dáng JavaScript
Thật ngạc nhiên là vẫn chưa ai nhắc rằng chính người này đã để lại cho chúng ta kiệt tác này
Nếu chưa xem thì nên dừng mọi thứ lại và xem ngay. Bảo đảm đây sẽ là 5 phút đáng giá nhất trong ngày của bạn
https://www.destroyallsoftware.com/talks/wat
Boundaries là video sâu sắc nhất về kiến trúc phần mềm mà tôi từng xem, và đến giờ tôi vẫn nhớ đến những bài học trong đó mỗi khi thiết kế ứng dụng phức tạp
Đây cũng là tài liệu nhập môn rất tốt để học cách suy nghĩ như một lập trình viên hàm đối với những ai đã quen với lối tư duy mệnh lệnh, nơi trạng thái bị phân tán khắp nơi
https://www.destroyallsoftware.com/talks/boundaries
Sau khi gọi
Array(16), ông ấy nói có 16 dấu phân cách, nhưng thực ra chỉ có 15 nên câu đùa về Batman bị hụt đi một chútNgoài ra, ông ấy dùng
{}+[]rồi giải thích là đang cộng một object với một list, sau đó chế giễu rằng kết quả khác với[]+{}cho ra[object Object], nhưng thực ra nếu viết({}+[])thì cũng ra[object Object]Vì sao
{}+[]lại khác thì xin để lại như một câu đố. Gợi ý:Gurer vf ab bowrpg gurer.Thực tế JavaScript đã trở thành đích biên dịch, trong video khi đó là asm.js, còn giờ thì đã có WebAssembly
Nhìn vào việc nó đã được triển khai thực tế và chạy gần với native thì có thể nói dự đoán này khá đúng
Tôi chủ yếu dùng TypeScript, và nhờ Electron mà công nghệ web được đóng gói thành ứng dụng desktop, khiến cú pháp web cũng đi vào trong các chương trình thông thường
Dù Electron thường bị chê là nặng và không hay, nó vẫn là cách nhanh nhất để hỗ trợ đồng thời Mac, Windows và Linux
“Cái chết” được nói ở đây là trạng thái JavaScript không còn được viết trực tiếp nữa mà trở thành lớp nền tảng hiện diện khắp nơi, và tôi nghĩ thực tế đúng là như vậy
Tôi cũng thấy tốc độ phát triển với nó khá nhanh
Tuy vậy, tôi không rõ nó so sánh về hiệu năng với Electron hay ứng dụng native như thế nào
Với các đội nhỏ, tập trung vào thực sự phát hành sản phẩm thường tốt hơn nhiều so với tối ưu hiệu năng
Theo định nghĩa, compiler chuyển mã mà con người có thể đọc được thành mã máy
Điểm mạnh của JavaScript là Google đã đẩy V8 đến giới hạn, NodeJS tạo ra một môi trường hấp dẫn ở backend, rồi nó trở nên phổ biến khắp nơi như PDF, viết một lần là dùng được ở mọi nơi
Lý do nó vẫn có ưu thế trước WebAssembly đến nay cũng nằm ở tính đa dụng đó, còn WebAssembly thì chưa được cài sẵn rộng rãi như JavaScript
Ngày nay JavaScript gần như đã đồng nghĩa với TypeScript, và đó là một bước nhảy vọt rất lớn. Theo tôi, người hùng thầm lặng ở đây là Angular 2
Angular ngay từ đầu đã chọn TypeScript, dù cũng cung cấp phiên bản JavaScript thuần, nhưng nói thật là bản đó gần như không dùng được và thời đó bị chỉ trích dữ dội
Thú vị là nơi trú ẩn cuối cùng không đưa TypeScript lên làm lựa chọn mặc định là React, nhưng trong bối cảnh các dự án lớn như NextJS mặc định phụ thuộc vào TypeScript thì ReactJS cuối cùng cũng sẽ phải nhượng bộ
Đây không phải lần đầu tiên đổi mới xuất hiện trước ở dự án khác rồi ReactJS mới đi theo, và ở trường hợp này tôi cho rằng Angular đang dẫn trước
Nếu chọn JavaScript và Python thì hiếm khi sai quá nhiều
Mọi người vẫn đang trực tiếp viết một lượng JS khổng lồ, và WebAssembly vẫn chưa thống trị môi trường thực thi phổ biến của các ứng dụng web
Có thể tìm thấy các công ty xây dựng thứ gì đó trên WebAssembly, nhưng không nên nhầm điều đó với kiểu chuyển dịch lớn mà Gary nói đến
Điều đó hoàn toàn không xảy ra
Không cần phải chạy nhiều trình duyệt web chỉ vì chuyện đó
Cứ vài năm người ta lại phát minh ra một JavaScript tốt hơn, rồi lại transpile sang JavaScript
Bản thân việc biên dịch sang JavaScript không có gì sai về mặt bản chất, và các ngôn ngữ cấp cao có thể hiện thực nhiều đảm bảo mà JavaScript thuần không trực tiếp cung cấp
Gần như mọi đảm bảo ngôn ngữ mà chúng ta đã dùng từ trước đến nay đều có thể bị phá vỡ ở cấp assembly nguyên thủy
Vấn đề là tốc độ phát triển của Wasm không nhanh như những gì được dự đoán ở đây
Vì không có thao tác DOM nên vẫn phải dùng JS làm mã keo nối, hoặc nếu không thì phải bỏ hẳn HTML và CSS rồi render mọi thứ lên canvas như Flutter hay một số GUI bằng Rust
Nhưng đánh mất tập tính năng của web thì vẫn là điều đáng tiếc
DOM API được thiết kế trên giả định là sẽ được truy cập bằng JS, và thiết kế của JS cùng một số đặc điểm “kỳ lạ” của nó cũng phần nào xuất phát từ việc nó được tạo ra để dùng cùng DOM
Có thể debug ngay tại chỗ, có thể ném vào LLM thử, và cũng không cần wrapper nên việc chạm vào, thử nghiệm và làm việc với nó dễ hơn hẳn
Năm 2014, tôi đã xem Gary Bernhardt trình bày trực tiếp bài nói này tại Canadian Undergraduate Software Engineering Conference (CUSEC)
PNaCl vừa ra mắt vào năm trước đó, và Google đang dùng nó để biên dịch chéo, thực thi và sandbox OpenSSH cùng client RDP bên trong Chrome và ChromeOS, trong khi phía Mozilla/Firefox đã đề xuất asm.js để đáp lại điều đó
Khi đó chỉ thấy buồn cười, nhưng giờ nhìn lại mới thấy khá nhiều phần trong ý tưởng đó đã tồn tại, thật đáng ngạc nhiên
Lightning talk Wat của Gary Bernhardt là bài thuyết trình tôi thích nhất
Nó chỉ sớm hơn bài nói được nhắc trong tiêu đề bài viết này đúng 2 năm
[1]: https://www.destroyallsoftware.com/talks/wat
Gần như mọi thứ đã diễn ra đúng như kịch bản
Giờ chỉ cần chờ thêm một hệ điều hành khác hoàn toàn dựa trên công nghệ trình duyệt, hay WASM OS
webOS và Firefox OS ít nhất đã đi trước thời đại 20 năm
WASM không xác nhận luận điểm đó mà bác bỏ nó
Luận điểm đó nói rằng mã nguồn tương thích JavaScript sẽ trở thành nền tảng của tương lai, và rằng các engine JavaScript được tối ưu hóa cao để diễn giải hiệu quả những tập con tương thích, dù JavaScript thông thường là một nền tảng tồi, có thể trở thành nền tảng đa dụng của tương lai
WASM về cơ bản đã từ chối điều này bằng cách tạo ra một nền tảng mới không tương thích với JavaScript, được thiết kế để làm đích ở mức thấp
Nói rằng WASM xác nhận luận điểm đó cũng kỳ quặc chẳng khác gì nói một tương lai nơi ai cũng có trình thông dịch Rust trong trình duyệt là xác nhận luận điểm ấy
Nếu lập luận như vậy thì rốt cuộc chỉ đang nói rằng trình duyệt web sẽ chạy một dạng mã nào đó bằng bất kỳ ngôn ngữ nào, mà điều đó thì nó đã làm từ lâu rồi
Video rõ ràng bàn về những khả năng “đáng kinh ngạc”, nên thật vô lý nếu cho rằng nó cũng phù hợp theo nghĩa đen với mọi tương lai có thể xảy ra vốn chẳng có gì khác thường
Tôi hỏi hoàn toàn vì tò mò thôi
Và những ảnh chụp màn hình webOS mà tôi từng thấy khiến tôi muốn nó được hồi sinh, không chỉ trên smart TV mà cả ở những nơi khác nữa
Chúng ta đã đi qua một nửa mốc thời gian 2035 của Bernhardt rồi
JavaScript vẫn chưa chết, nhưng có vẻ như nó đang tự viết điếu văn cho chính mình bên trong WebAssembly
Trừ khi xảy ra chiến tranh hạt nhân toàn cầu, tôi sẽ cược rằng JS sống lâu hơn phần lớn loài người
Nó sẽ không bao giờ chết, giống như PHP vậy
JavaScript là ngôn ngữ lập trình vĩ đại nhất mọi thời đại