Cảm giác học JavaScript vào năm 2016 như thế nào

khuôn khổ Không có JavaScript nào được tạo ra trong quá trình viết bài viết này. Nội dung sau đây được lấy cảm hứng từ bài viết “It's the future” của Circle CI. Bạn có thể đọc bản gốc tại đây . Bài viết này chỉ là ý kiến cá nhân, và giống như bất kỳ khuôn khổ JavaScript nào, bạn không nên quá coi trọng nó. Này, tôi có một dự án web mới, nhưng thành thật mà nói, tôi đã không viết nhiều mã web trong vài năm và tôi nghe nói bối cảnh đã thay đổi một chút. Bạn là nhà phát triển web mới nhất ở đây phải không? -Thuật ngữ thực tế là kỹ sư Front End, nhưng đúng rồi, tôi là người phù hợp. Tôi làm web vào năm 2016. Hình ảnh hóa, trình phát nhạc, máy bay không người lái chơi bóng đá, bạn cứ nói đi. Tôi vừa trở về từ JsConf và ReactConf, vì vậy tôi biết các công nghệ mới nhất để tạo ứng dụng web. Tuyệt. Tôi cần tạo một trang hiển thị hoạt động mới nhất từ người dùng, vì vậy tôi chỉ cần lấy dữ liệu từ điểm cuối REST và hiển thị nó trong một số loại bảng có thể lọc được, và cập nhật nó nếu có bất kỳ thay đổi nào trong máy chủ. Tôi đang nghĩ có thể sử dụng jQuery để lấy và hiển thị dữ liệu? -Ôi trời ơi không, không ai dùng jQuery nữa. Bạn nên thử học React đi, giờ là năm 2016 rồi. Ồ, được thôi. React là gì? - Đây là một thư viện cực hay do một số thành viên của Facebook tạo ra, nó thực sự mang lại khả năng kiểm soát và hiệu suất cho ứng dụng của bạn bằng cách cho phép bạn xử lý mọi thay đổi chế độ xem rất dễ dàng. Nghe có vẻ hay đấy. Tôi có thể sử dụng React để hiển thị dữ liệu từ máy chủ không? -Được thôi, nhưng trước tiên bạn cần thêm React và React DOM làm thư viện vào trang web của bạn. Đợi đã, tại sao lại có hai thư viện? -Vậy thì một là thư viện thực tế và cái thứ hai dùng để thao tác DOM, giờ bạn có thể mô tả trong JSX. JSX là gì? -JSX chỉ là một phần mở rộng cú pháp JavaScript trông khá giống XML. Đây là một cách khác để mô tả DOM, hãy nghĩ về nó như một HTML tốt hơn. Có vấn đề gì với HTML? - Bây giờ là năm 2016. Không ai có thể viết mã HTML trực tiếp nữa. Đúng rồi. Dù sao thì nếu tôi thêm hai thư viện này thì tôi có thể sử dụng React phải không? -Không hẳn vậy. Bạn cần thêm Babel, sau đó bạn mới có thể sử dụng React. Một thư viện khác? Babel là gì? -Ồ, Babel là một trình biên dịch cho phép bạn nhắm mục tiêu đến các phiên bản JavaScript cụ thể, trong khi bạn mã hóa trong bất kỳ phiên bản JavaScript nào. Bạn KHÔNG PHẢI bao gồm Babel để sử dụng ReactJS, nhưng trừ khi bạn làm vậy, bạn sẽ phải sử dụng ES5, và hãy thực tế đi, bây giờ là năm 2016, bạn nên mã hóa trong ES2016+ giống như những đứa trẻ tuyệt vời khác vẫn làm. ES5? ES2016+? Tôi bị lạc ở đây. ES5 và ES2016+ là gì? -ES5 là viết tắt của ECMAScript 5. Đây là phiên bản mà hầu hết mọi người hướng đến vì nó đã được hầu hết các trình duyệt hiện nay triển khai. ECMAScript là gì? -Vâng, bạn biết đấy, tiêu chuẩn kịch bản JavaScript dựa trên vào năm 1999 sau khi phát hành lần đầu vào năm 1995, khi đó JavaScript được gọi là Livescript và chỉ chạy trong Netscape Navigator. Lúc đó rất lộn xộn, nhưng may mắn thay, bây giờ mọi thứ rất rõ ràng và chúng tôi có, giống như, 7 phiên bản của triển khai này. 7 phiên bản. Thật đấy. Còn ES5 và ES2016+ thì sao? - Lần lượt là phiên bản thứ năm và thứ bảy. Đợi đã, chuyện gì đã xảy ra với số thứ sáu? - Ý bạn là ES6 à? Vâng, ý tôi là, mỗi phiên bản là siêu tập hợp của phiên bản trước, vì vậy nếu bạn đang sử dụng ES2016+, bạn đang sử dụng tất cả các tính năng của các phiên bản trước. Đúng rồi. Vậy tại sao lại sử dụng ES2016+ thay vì ES6? -Vâng, bạn CÓ THỂ sử dụng ES6, nhưng để sử dụng các tính năng thú vị như async và await, bạn cần sử dụng ES2016+. Nếu không, bạn sẽ bị mắc kẹt với các trình tạo ES6 với các coroutine để chặn các cuộc gọi không đồng bộ để có luồng điều khiển phù hợp. Tôi không hiểu bạn vừa nói gì, và tất cả những cái tên này đều gây nhầm lẫn. Này, tôi chỉ đang tải một loạt dữ liệu từ máy chủ, trước đây tôi có thể chỉ cần đưa jQuery từ CDN và lấy dữ liệu bằng lệnh gọi AJAX, tại sao tôi không thể làm như vậy? -Bây giờ là năm 2016 rồi, không ai dùng jQuery nữa, nó chỉ còn là một mớ mã spaghetti. Ai cũng biết điều đó. Đúng vậy. Vậy giải pháp thay thế của tôi là tải ba thư viện để lấy dữ liệu và hiển thị bảng HTML. -Vâng, bạn bao gồm ba thư viện đó nhưng đóng gói chúng lại với một trình quản lý mô-đun để chỉ tải một tệp. Tôi hiểu rồi. Vậy trình quản lý mô-đun là gì? - Định nghĩa phụ thuộc vào môi trường, nhưng trên web chúng ta thường muốn nói đến bất kỳ thứ gì hỗ trợ mô-đun AMD hoặc CommonJS. Đúng rồi. Còn AMD và CommonJS thì sao…? -Định nghĩa. Có nhiều cách để mô tả cách nhiều thư viện và lớp JavaScript tương tác với nhau. Bạn biết đấy, xuất và yêu cầu? Bạn có thể viết nhiều tệp JavaScript định nghĩa API AMD hoặc CommonJS và bạn có thể sử dụng thứ gì đó như Browserify để đóng gói chúng lại. Được rồi, điều đó có lý… Tôi nghĩ vậy. Browserify là gì? -Đây là công cụ cho phép bạn đóng gói các phụ thuộc được mô tả của CommonJS vào các tệp có thể chạy trong trình duyệt. Công cụ này được tạo ra vì hầu hết mọi người đều xuất bản các phụ thuộc đó trong sổ đăng ký npm. đăng ký npm? -Đây là kho lưu trữ công cộng rất lớn, nơi những người thông minh đặt mã và các phần phụ thuộc dưới dạng mô-đun. Giống như CDN? -Không hẳn vậy. Nó giống như một cơ sở dữ liệu tập trung nơi bất kỳ ai cũng có thể xuất bản và tải xuống thư viện, do đó bạn có thể sử dụng chúng cục bộ để phát triển và sau đó tải chúng lên CDN nếu bạn muốn. Ồ, giống như Bower! -Đúng vậy, nhưng bây giờ là năm 2016 rồi, không ai sử dụng Bower nữa. À, tôi hiểu rồi… vậy thì tôi cần tải thư viện từ npm phải không? -Vâng. Ví dụ, nếu bạn muốn sử dụng React, bạn tải xuống mô-đun React và nhập nó vào mã của bạn. Bạn có thể làm điều đó cho hầu hết mọi thư viện JavaScript phổ biến. Ồ, giống như Angular vậy! - Angular là của năm 2015. Nhưng đúng vậy. Angular sẽ ở đó, cùng với VueJS hoặc RxJS và các thư viện thú vị khác của năm 2016. Bạn có muốn tìm hiểu về những thư viện đó không? Hãy gắn bó với React, tôi đã học quá nhiều thứ rồi. Vậy, nếu tôi cần sử dụng React, tôi sẽ lấy nó từ npm này rồi sử dụng Browserify này? -Đúng. Có vẻ như quá phức tạp khi chỉ cần lấy một loạt các phụ thuộc và liên kết chúng lại với nhau. -Đúng vậy, đó là lý do tại sao bạn sử dụng trình quản lý tác vụ như Grunt hoặc Gulp hoặc Broccoli để tự động chạy Browserify. Chết tiệt, bạn thậm chí có thể sử dụng Mimosa. Grunt? Nuốt nước bọt? Súp lơ xanh? Mimosa? Chúng ta đang nói về cái quái gì thế này? - Trình quản lý tác vụ. Nhưng chúng không còn hay nữa. Chúng tôi đã sử dụng chúng vào khoảng năm 2015, sau đó chúng tôi sử dụng Makefiles, nhưng bây giờ chúng tôi đóng gói mọi thứ bằng Webpack. Makefile? Tôi nghĩ nó chủ yếu được sử dụng trong các dự án C hoặc C++. -Vâng, nhưng rõ ràng là trên web chúng tôi thích làm mọi thứ phức tạp rồi quay lại với những điều cơ bản. Chúng tôi làm điều đó mỗi năm hoặc lâu hơn, chỉ cần chờ đợi, chúng tôi sẽ lắp ráp trên web trong một hoặc hai năm nữa. Thở dài. Bạn có nhắc đến thứ gì đó gọi là Webpack không? -Đây là một trình quản lý mô-đun khác cho trình duyệt, đồng thời cũng là một trình chạy tác vụ. Giống như phiên bản tốt hơn của Browserify. Ồ, được thôi. Tại sao lại tốt hơn? -Vâng, có lẽ không tốt hơn, nó chỉ mang tính chủ quan hơn về cách các phụ thuộc của bạn nên được liên kết. Webpack cho phép bạn sử dụng các trình quản lý mô-đun khác nhau, không chỉ các trình quản lý CommonJS, ví dụ như các mô-đun được hỗ trợ ES6 gốc. Tôi thực sự bối rối về vấn đề CommonJS/ES6 này. -Mọi người đều vậy, nhưng bạn không nên quan tâm nữa với SystemJS. Chúa ơi, một danh từ khác-js. Được rồi, và SystemJS này là gì? -Không giống như Browserify và Webpack 1.x, SystemJS là trình tải mô-đun động cho phép bạn liên kết nhiều mô-đun trong nhiều tệp thay vì đóng gói chúng trong một tệp lớn. Đợi đã, nhưng tôi nghĩ chúng ta muốn xây dựng các thư viện trong một tệp lớn và tải tệp đó lên! -Đúng vậy, nhưng vì HTTP/2 đã ra đời nên nhiều yêu cầu HTTP thực sự tốt hơn. Đợi đã, vậy chúng ta không thể thêm ba thư viện gốc cho React sao?? -Không hẳn vậy. Ý tôi là, bạn có thể thêm chúng dưới dạng tập lệnh bên ngoài từ CDN, nhưng khi đó bạn vẫn cần phải đưa Babel vào. Thở dài. Và điều đó tệ phải không? -Đúng vậy, bạn sẽ bao gồm toàn bộ babel-core, và nó sẽ không hiệu quả cho sản xuất. Trong sản xuất, bạn cần thực hiện một loạt các tác vụ trước để chuẩn bị cho dự án của mình, khiến nghi lễ triệu hồi Satan trông giống như công thức nấu trứng luộc. Bạn cần thu nhỏ tài sản, làm xấu chúng, chèn css nội tuyến ở trên, trì hoãn tập lệnh, cũng như- Tôi hiểu rồi, tôi hiểu rồi. Vậy nếu bạn không đưa thư viện trực tiếp vào CDN, bạn sẽ làm thế nào? -Tôi sẽ biên dịch nó từ Typescript bằng cách sử dụng kết hợp Webpack + SystemJS + Babel. Typescript ư? Tôi tưởng chúng ta đang viết mã bằng JavaScript! -Typescript LÀ JavaScript, hay nói đúng hơn là siêu tập của JavaScript, cụ thể hơn là JavaScript ở phiên bản ES6. Bạn biết đấy, phiên bản thứ sáu mà chúng ta đã nói đến trước đó? Tôi nghĩ ES2016+ đã là siêu tập của ES6 rồi! TẠI SAO chúng ta lại cần thứ gọi là Typescript này? -Ồ, vì nó cho phép chúng ta sử dụng JavaScript như một ngôn ngữ có kiểu dữ liệu và giảm lỗi thời gian chạy. Bây giờ là năm 2016, bạn nên thêm một số kiểu dữ liệu vào mã JavaScript của mình. Và Typescript rõ ràng có thể làm được điều đó. -Flow cũng vậy, mặc dù nó chỉ kiểm tra kiểu dữ liệu trong khi Typescript là siêu tập của JavaScript cần được biên dịch. Thở dài… và Flow thì sao? hàm -Đây là trình kiểm tra kiểu tĩnh do một số người ở Facebook tạo ra. Họ đã mã hóa nó bằng OCaml, vì lập trình rất tuyệt. OCaml? Lập trình hàm? -Đó là thứ mà bọn trẻ sành điệu ngày nay dùng, bạn biết đấy, năm 2016 ư? Lập trình hàm? Hàm bậc cao? Currying? Hàm thuần túy? Tôi không hiểu bạn vừa nói gì. -Không ai làm điều đó ngay từ đầu. Bạn chỉ cần biết rằng lập trình hàm tốt hơn OOP và đó là những gì chúng ta nên sử dụng vào năm 2016. Đợi đã, tôi đã học OOP ở trường đại học, tôi nghĩ là nó tốt sao? -Java cũng vậy trước khi bị Oracle mua lại. Ý tôi là, OOP đã từng tốt vào thời đó, và nó vẫn có công dụng cho đến ngày nay, nhưng giờ đây mọi người đều nhận ra rằng việc sửa đổi trạng thái cũng giống như việc đá trẻ con, vì vậy giờ đây mọi người đang chuyển sang các đối tượng bất biến và lập trình hàm. Những người của Haskell đã gọi nó trong nhiều năm, - và đừng để tôi bắt đầu với những người của Elm - nhưng may mắn thay, trên web hiện nay chúng ta có các thư viện như Ramda cho phép chúng ta sử dụng lập trình hàm trong JavaScript thuần túy. Bạn chỉ nêu tên cho vui thôi à? Ramnda là cái quái gì thế? -Không. Ramda. Giống như Lambda. Bạn biết đấy, thư viện của David Chambers? David là ai? -David Chambers. Anh chàng tuyệt vời. Chơi trò Coup rất giỏi. Một trong những người đóng góp cho Ramda. Bạn cũng nên xem Erik Meijer nếu bạn nghiêm túc muốn học lập trình chức năng. Và Erik Meijer là…? - Anh chàng lập trình chức năng nữa. Anh chàng tuyệt vời. Anh ta có một loạt các bài thuyết trình mà anh ta chê bai Agile trong khi mặc chiếc áo sơ mi màu kỳ lạ này. Bạn cũng nên xem một số bài viết của Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani- Được rồi. Tôi sẽ dừng bạn ở đây. Tất cả những điều đó đều tốt và ổn, nhưng tôi nghĩ tất cả những điều đó chỉ phức tạp và không cần thiết để chỉ lấy dữ liệu và hiển thị nó. Tôi khá chắc rằng tôi không cần biết những người này hoặc học tất cả những điều đó để tạo một bảng có dữ liệu động. Hãy quay lại React. Làm thế nào tôi có thể lấy dữ liệu từ máy chủ bằng React? - Thực ra bạn không lấy dữ liệu bằng React, bạn chỉ hiển thị dữ liệu bằng React. Ôi trời ơi. Vậy bạn dùng cái gì để lấy dữ liệu? -Bạn sử dụng Fetch để lấy dữ liệu từ máy chủ. Xin lỗi? Bạn sử dụng Fetch để lấy dữ liệu à? Bất kỳ ai đặt tên cho những thứ đó đều cần một từ điển đồng nghĩa. -Tôi biết đúng không? Lấy tên của triển khai gốc để thực hiện XMLHttpRequests trên máy chủ. Ồ, thì ra là AJAX. -AJAX chỉ là việc sử dụng XMLHttpRequests. Nhưng chắc chắn rồi. Fetch cho phép bạn thực hiện AJAX dựa trên các lời hứa, sau đó bạn có thể giải quyết để tránh tình trạng gọi lại. Gọi lại địa ngục? -Đúng vậy. Mỗi lần bạn thực hiện một yêu cầu không đồng bộ với máy chủ, bạn cần phải đợi phản hồi của nó, sau đó bạn phải thêm một hàm trong một hàm, được gọi là kim tự tháp gọi lại từ địa ngục. Ồ, được thôi. Và lời hứa này có giải quyết được vấn đề không? -Thật vậy. Bằng cách thao tác các lệnh gọi lại thông qua các lời hứa, bạn có thể viết mã dễ hiểu hơn, mô phỏng và kiểm tra chúng, cũng như thực hiện các yêu cầu đồng thời cùng một lúc và chờ cho đến khi tất cả chúng được tải. Và điều đó có thể thực hiện được với Fetch? -Có, nhưng chỉ khi người dùng của bạn sử dụng trình duyệt thường xanh, nếu không, bạn cần phải bao gồm polyfill Fetch hoặc sử dụng Request, Bluebird hoặc Axios. Trời ơi, tôi cần biết bao nhiêu thư viện vậy? Có bao nhiêu thư viện vậy? - Đó là JavaScript. Phải có hàng ngàn thư viện đều làm cùng một việc. Chúng tôi biết các thư viện, thực tế là chúng tôi có những thư viện tốt nhất. Thư viện của chúng tôi rất lớn, và đôi khi chúng tôi đưa hình ảnh của Guy Fieri vào đó. Bạn vừa nói Guy Fieri à? Chúng ta hãy giải quyết vấn đề này. Các thư viện Bluebird, Request, Axios này làm gì? -Chúng là các thư viện thực hiện XMLHttpRequests trả về các lời hứa. Phương pháp AJAX của jQuery không phải cũng bắt đầu trả về lời hứa sao? -Chúng tôi không sử dụng từ “J” vào năm 2016 nữa. Chỉ cần sử dụng Fetch và polyfill khi nó không có trong trình duyệt hoặc sử dụng Bluebird, Request hoặc Axios thay thế. Sau đó quản lý lời hứa bằng await trong một hàm bất đồng bộ và bùng nổ, bạn có luồng điều khiển thích hợp. Đây là lần thứ ba bạn nhắc đến từ await nhưng tôi không hiểu nó là gì. -Await cho phép bạn chặn một cuộc gọi không đồng bộ, cho phép bạn kiểm soát tốt hơn thời điểm dữ liệu đang được lấy và tăng khả năng đọc mã tổng thể. Thật tuyệt vời, bạn chỉ cần đảm bảo thêm cài đặt trước stage-3 trong Babel hoặc sử dụng plugin syntax-async-functions và transform-async-to-generator. Điều này thật điên rồ. -Không, điều điên rồ là bạn cần phải biên dịch trước mã Typescript rồi biên dịch lại bằng Babel để sử dụng await. Sao thế? Nó không có trong Typescript sao? -Có trong phiên bản tiếp theo, nhưng kể từ phiên bản 1.7, nó chỉ nhắm tới ES6, vì vậy nếu bạn muốn sử dụng await trong trình duyệt, trước tiên bạn cần biên dịch mã Typescript nhắm tới ES6, sau đó biên dịch mã Babel để nhắm tới ES5. Lúc này tôi không biết phải nói gì nữa. -Nhìn này, dễ lắm. Mã hóa mọi thứ trong Typescript. Tất cả các mô-đun sử dụng Fetch biên dịch chúng để nhắm mục tiêu ES6, chuyển đổi chúng bằng Babel trên cài đặt trước giai đoạn 3 và tải chúng bằng SystemJS. Nếu bạn không có Fetch, hãy polyfill nó hoặc sử dụng Bluebird, Request hoặc Axios và xử lý tất cả các lời hứa của bạn bằng await. Chúng ta có những định nghĩa rất khác nhau về dễ dàng. Vì vậy, với nghi lễ đó, cuối cùng tôi đã lấy được dữ liệu và bây giờ tôi có thể hiển thị nó bằng React phải không? -Ứng dụng của bạn có xử lý được bất kỳ thay đổi trạng thái nào không? Ờ, tôi không nghĩ vậy. Tôi chỉ cần hiển thị dữ liệu thôi. -Ồ, cảm ơn Chúa. Nếu không thì tôi đã phải giải thích cho bạn về Flux và các triển khai như Flummox, Alt, Fluxible. Mặc dù thành thật mà nói thì bạn nên sử dụng Redux. Tôi sẽ chỉ lướt qua những cái tên đó. Một lần nữa, tôi chỉ cần hiển thị dữ liệu. -Ồ, nếu bạn chỉ hiển thị dữ liệu thì bạn không cần React ngay từ đầu. Bạn sẽ ổn với một công cụ tạo mẫu. Bạn đùa tôi à? Bạn nghĩ điều này buồn cười à? Đó có phải là cách bạn đối xử với những người thân yêu của mình không? -Tôi chỉ đang giải thích những gì bạn có thể sử dụng thôi. Dừng lại. Dừng lại đi. -Ý tôi là, ngay cả khi chỉ sử dụng công cụ tạo mẫu, tôi vẫn sẽ sử dụng tổ hợp Typescript + SystemJS + Babel nếu tôi là bạn. Tôi cần hiển thị dữ liệu trên một trang, không phải thực hiện đòn kết liễu MK gốc của Sub Zero. Chỉ cần cho tôi biết công cụ tạo mẫu nào cần sử dụng và tôi sẽ thực hiện từ đó. - Có rất nhiều thứ, bạn quen thuộc với thứ nào? Ugh, không nhớ tên. Lâu lắm rồi. -jTemplates? jQote? TINH KHIẾT? Ờ, không quen lắm. Còn cái nào nữa không? - Minh bạch? JSRender? MarkupJS? KnockoutJS? Cái đó có ràng buộc hai chiều. Còn cái nữa à? -PlatesJS? jQuery-tmpl? Handlebars? Một số người vẫn sử dụng nó. Có thể. Có cái nào tương tự như cái cuối cùng không? - Ria mép, gạch chân? Tôi nghĩ bây giờ ngay cả lodash cũng có một cái, nhưng đó là chuyện của năm 2014. Ờ... có lẽ là mới hơn. -Jade? DustJS? KHÔNG. -DotJS? EJS? KHÔNG. - Nunjucks? V.v.? KHÔNG. -Ồ, dù sao thì cũng chẳng ai thích cú pháp Coffeescript cả. Jade à? Không, bạn đã nói rồi mà Jade. - Ý tôi là Pug. Ý tôi là Jade. Ý tôi là, Jade giờ là Pug. Thở dài. Không. Không nhớ nữa. Bạn sẽ dùng cái nào? -Có lẽ chỉ là chuỗi mẫu gốc ES6. Để tôi đoán nhé. Và điều đó đòi hỏi ES6. -Chính xác. Tùy thuộc vào trình duyệt tôi sử dụng mà cần có Babel. -Chính xác. Nếu tôi muốn đưa vào mà không cần thêm toàn bộ thư viện lõi, tôi cần tải nó dưới dạng một mô-đun từ npm. -Chính xác. Điều này đòi hỏi Browserify hoặc Wepback, hoặc nhiều khả năng là thứ gì đó có tên là SystemJS. -Chính xác. Trong trường hợp lý tưởng, trừ khi đó là Webpack, thì nên quản lý nó bằng một trình chạy tác vụ. -Chính xác. Tuy nhiên, vì tôi phải sử dụng lập trình hàm và ngôn ngữ có kiểu dữ liệu nên trước tiên tôi cần biên dịch trước Typescript hoặc thêm thứ Flow này. -Chính xác. Và sau đó gửi nó tới Babel nếu tôi muốn sử dụng await. -Chính xác. Vì vậy, tôi có thể sử dụng Fetch, promises, control flow và tất cả những điều kỳ diệu đó. -Đừng quên thêm polyfill Fetch nếu nó không được hỗ trợ, Safari vẫn không xử lý được. Bạn biết không. Tôi nghĩ chúng ta đã xong ở đây rồi. Thực ra, tôi nghĩ tôi đã xong. Tôi đã xong với web, tôi đã xong với JavaScript hoàn toàn. - Không sao đâu, trong vài năm nữa tất cả chúng ta sẽ đều viết mã bằng Elm hoặc WebAssembly. Tôi sẽ quay lại phần backend. Tôi không thể xử lý được nhiều thay đổi, phiên bản, phiên bản, trình biên dịch và trình biên dịch này. Cộng đồng JavaScript thật điên rồ nếu nghĩ rằng bất kỳ ai cũng có thể theo kịp điều này. -Tôi hiểu rồi. Vậy thì bạn nên thử cộng đồng Python nhé. Tại sao? -Bạn đã từng nghe đến Python 3 chưa? Cập nhật: Cảm ơn bạn đã chỉ ra lỗi đánh máy và lỗi sai, tôi sẽ cập nhật bài viết như đã ghi chú. Thảo luận trên HackerNews và Reddit .