Mã JavaScript phức tạp nhất
Lúc đầu, JavaScript có vẻ khá đơn giản. Tuy nhiên, ngôn ngữ này có nhiều sắc thái, mạnh mẽ và phức tạp hơn đáng kể so với những gì người ta tin tưởng ban đầu. Nhiều điểm phức tạp của JavaScript dẫn đến một số vấn đề phổ biến—10 vấn đề trong số đó chúng tôi thảo luận ở đây—khiến mã không hoạt động như dự kiến. Điều quan trọng là phải nhận thức được và tránh những cạm bẫy này trong hành trình trở thành nhà phát triển JavaScript bậc thầy Show
Qua Ryan J. Peterson Ryan là một kiến trúc sư, doanh nhân và nhà phát triển. Anh ấy có kỹ năng xây dựng các hệ thống phần mềm có thể mở rộng, có thể mở rộng trên đám mây CHIA SẺ CHIA SẺ Ghi chú của biên tập viên. Bài viết này được nhóm biên tập của chúng tôi cập nhật vào ngày 19 tháng 7 năm 2022. Nó đã được sửa đổi để bao gồm các nguồn gần đây và phù hợp với các tiêu chuẩn biên tập hiện tại của chúng tôi Ngày nay, JavaScript là cốt lõi của hầu như tất cả các ứng dụng web hiện đại. Đó là lý do tại sao các vấn đề về JavaScript và việc tìm ra lỗi gây ra chúng luôn được đặt lên hàng đầu đối với các nhà phát triển web Các thư viện và khung dựa trên JavaScript mạnh mẽ để phát triển ứng dụng một trang (SPA), đồ họa và hoạt hình cũng như các nền tảng JavaScript phía máy chủ không có gì mới. JavaScript đã thực sự trở nên phổ biến trong thế giới phát triển ứng dụng web và do đó là một kỹ năng ngày càng quan trọng để thành thạo Lúc đầu, JavaScript có vẻ khá đơn giản. Và thực sự, để xây dựng chức năng JavaScript cơ bản vào một trang web là một nhiệm vụ khá đơn giản đối với bất kỳ nhà phát triển phần mềm có kinh nghiệm nào, ngay cả khi họ mới sử dụng JavaScript. Tuy nhiên, ngôn ngữ này có nhiều sắc thái, mạnh mẽ và phức tạp hơn đáng kể so với những gì người ta tin tưởng ban đầu. Thật vậy, nhiều điểm phức tạp của JavaScript dẫn đến một số vấn đề phổ biến khiến nó không hoạt động—10 vấn đề trong số đó chúng tôi thảo luận ở đây—điều quan trọng cần lưu ý và tránh trong hành trình trở thành nhà phát triển JavaScript bậc thầy Sự cố JavaScript #1. Tham chiếu không chính xác đến Game.prototype.restart = function () { this.clearLocalStorage(); var self = this; // Save reference to 'this', while it's still this! this.timer = setTimeout(function(){ self.clearBoard(); // Oh OK, I do know who 'self' is! }, 0); }; 6Không thiếu sự nhầm lẫn giữa các nhà phát triển JavaScript về từ khóa 6 của JavaScriptKhi các kỹ thuật mã hóa JavaScript và các mẫu thiết kế ngày càng trở nên tinh vi trong những năm qua, đã có sự gia tăng tương ứng về sự phổ biến của các phạm vi tự tham chiếu trong các lệnh gọi lại và các lần đóng, đây là một nguồn khá phổ biến của “ 6/sự nhầm lẫn đó” gây ra các sự cố JavaScriptHãy xem xét đoạn mã ví dụ này
Thực thi đoạn mã trên dẫn đến lỗi sau
Tại sao? . Lý do bạn gặp phải lỗi trên là vì khi bạn gọi 9, bạn thực sự đang gọi 0. Do đó, hàm ẩn danh được truyền cho 9 đang được xác định trong ngữ cảnh của đối tượng 2, không có phương thức 3Một giải pháp truyền thống, tương thích với trình duyệt cũ là chỉ cần lưu tham chiếu của bạn tới 6 trong một biến mà sau đó có thể được kế thừa bởi lệnh đóng; . g
Ngoài ra, trong các trình duyệt mới hơn, bạn có thể sử dụng phương pháp 5 để chuyển vào tham chiếu thích hợp
Sự cố JavaScript #2. Suy nghĩ có phạm vi cấp khốiNhư đã thảo luận trong Hướng dẫn tuyển dụng JavaScript của chúng tôi, một nguồn gây nhầm lẫn phổ biến giữa các nhà phát triển JavaScript (và do đó là nguồn lỗi phổ biến) là giả định rằng JavaScript tạo phạm vi mới cho mỗi khối mã. Mặc dù điều này đúng với nhiều ngôn ngữ khác, nhưng nó không đúng với JavaScript. Ví dụ, xem xét đoạn mã sau 4Nếu bạn đoán rằng cuộc gọi 6 sẽ xuất ra 7 hoặc đưa ra lỗi, thì bạn đã đoán sai. Tin hay không tùy bạn, nó sẽ xuất ra 8. Tại sao?Trong hầu hết các ngôn ngữ khác, đoạn mã trên sẽ dẫn đến lỗi vì "cuộc sống" (i. e. , phạm vi) của biến 9 sẽ bị giới hạn trong khối 40. Tuy nhiên, trong JavaScript, đây không phải là trường hợp và biến 9 vẫn nằm trong phạm vi ngay cả sau khi vòng lặp 40 hoàn thành, giữ lại giá trị cuối cùng của nó sau khi thoát khỏi vòng lặp. (Hành vi này tình cờ được gọi là biến cẩu. )Hỗ trợ cho phạm vi cấp khối trong JavaScript có sẵn thông qua từ khóa 43. Từ khóa 43 đã được hỗ trợ rộng rãi bởi các trình duyệt và công cụ JavaScript back-end như Node. js trong nhiều năm nayNếu đó là tin tức đối với bạn, bạn nên dành thời gian để đọc về phạm vi, nguyên mẫu, v.v. Sự cố JavaScript #3. Tạo rò rỉ bộ nhớRò rỉ bộ nhớ là sự cố JavaScript gần như không thể tránh khỏi nếu bạn không có ý thức mã hóa để tránh chúng. Có rất nhiều cách để chúng xảy ra, vì vậy chúng tôi sẽ chỉ nêu bật một số trường hợp phổ biến hơn của chúng Rò rỉ bộ nhớ Ví dụ 1. Các tham chiếu lơ lửng đến các đối tượng không còn tồn tạiHãy xem xét đoạn mã sau 4Nếu bạn chạy đoạn mã trên và theo dõi việc sử dụng bộ nhớ, bạn sẽ thấy rằng mình đã bị rò rỉ bộ nhớ đáng kể, rò rỉ toàn bộ megabyte mỗi giây. Và ngay cả Trình thu gom rác thủ công (GC) cũng không giúp được gì. Vì vậy, có vẻ như chúng tôi đang rò rỉ 45 mỗi khi 46 được gọi. Nhưng tại sao?
tiếng riu ríu Hãy xem xét mọi thứ chi tiết hơn Mỗi đối tượng 47 chứa đối tượng 45 1 MB của chính nó. Mỗi giây, khi chúng ta gọi 46, nó sẽ giữ một tham chiếu đến đối tượng 47 trước đó trong 41. Nhưng chúng tôi vẫn không nghĩ rằng đây sẽ là một vấn đề, vì mỗi lần như vậy, 41 được tham chiếu trước đó sẽ bị hủy đăng ký (khi 41 được đặt lại qua 44). Và hơn nữa, chỉ được tham chiếu trong phần thân chính của 46 và trong hàm 46, thực tế là chưa bao giờ được sử dụngVì vậy, một lần nữa chúng tôi lại tự hỏi tại sao có rò rỉ bộ nhớ ở đây Để hiểu chuyện gì đang xảy ra, chúng ta cần hiểu rõ hơn về hoạt động bên trong của JavaScript. Cách điển hình mà các bao đóng được triển khai là mọi đối tượng chức năng đều có liên kết đến một đối tượng kiểu từ điển đại diện cho phạm vi từ vựng của nó. Nếu cả hai hàm được xác định bên trong 46 thực sự sử dụng 41, thì điều quan trọng là cả hai đều nhận được cùng một đối tượng, ngay cả khi 41 được gán nhiều lần, vì vậy cả hai hàm đều chia sẻ cùng một môi trường từ vựng. Nhưng ngay sau khi một biến được sử dụng bởi bất kỳ bao đóng nào, nó sẽ kết thúc trong môi trường từ vựng được chia sẻ bởi tất cả các bao đóng trong phạm vi đó. Và sắc thái nhỏ đó là nguyên nhân dẫn đến sự rò rỉ bộ nhớ sởn gai ốc nàyRò rỉ bộ nhớ Ví dụ 2. Tài liệu tham khảo thông tưHãy xem xét đoạn mã này 0Ở đây, 00 có một bao đóng giữ tham chiếu đến 01 (thông qua 02). Cũng bằng cách gán 00 cho 04, tham chiếu vòng được tạo; . e. 01 → 00 → 01 → 00 → 01…Thật thú vị, ngay cả khi 01 bị xóa khỏi DOM, tham chiếu vòng tròn ở trên sẽ ngăn cản việc thu thập 01 và 00, và do đó, rò rỉ bộ nhớTránh rò rỉ bộ nhớ. Các yếu tố cần thiếtQuản lý bộ nhớ của JavaScript (và đặc biệt là thu gom rác) phần lớn dựa trên khái niệm về khả năng tiếp cận đối tượng Các đối tượng sau đây được cho là có thể truy cập được và được gọi là "gốc"
Các đối tượng được lưu giữ trong bộ nhớ ít nhất miễn là chúng có thể truy cập được từ bất kỳ gốc nào thông qua tham chiếu hoặc chuỗi tham chiếu Có một Trình thu gom rác trong trình duyệt để dọn sạch bộ nhớ bị chiếm bởi các đối tượng không thể truy cập được; . Thật không may, khá dễ dàng để kết thúc với các đối tượng “thây ma” không còn được sử dụng nhưng GC vẫn cho rằng “có thể truy cập được”. ” Sự cố JavaScript #4. Nhầm lẫn về bình đẳngMột trong những tiện ích trong JavaScript là nó sẽ tự động ép buộc bất kỳ giá trị nào được tham chiếu trong ngữ cảnh boolean thành giá trị boolean. Nhưng có những trường hợp điều này có thể gây nhầm lẫn vì nó thuận tiện. Ví dụ, một số điều sau đây đã được biết là gây rắc rối cho nhiều nhà phát triển JavaScript 4Đối với hai đối tượng cuối cùng, mặc dù trống (điều này có thể khiến người ta tin rằng chúng sẽ đánh giá bằng 43), cả 44 và 45 đều là các đối tượng trên thực tế và bất kỳ đối tượng nào cũng sẽ bị ép buộc theo giá trị boolean là 46 trong JavaScript, phù hợp với Như những ví dụ này chứng minh, các quy tắc ép buộc kiểu đôi khi có thể rõ ràng như bùn. Theo đó, trừ khi ép buộc kiểu được mong muốn rõ ràng, tốt nhất nên sử dụng 47 và 48 (thay vì 49 và 20), để tránh bất kỳ tác dụng phụ ngoài ý muốn nào của ép buộc kiểu. ( 49 và 20 tự động thực hiện chuyển đổi loại khi so sánh hai đối tượng, trong khi 47 và 48 thực hiện phép so sánh tương tự mà không cần chuyển đổi loại. )Và hoàn toàn là một điểm phụ—nhưng vì chúng ta đang nói về ép buộc kiểu và so sánh—điều đáng nói là so sánh 25 với bất kỳ thứ gì (kể cả 25. ) sẽ luôn trả về 43. Do đó, bạn không thể sử dụng các toán tử đẳng thức ( 49, 47, 20, 48) để xác định xem một giá trị có phải là 25 hay không. Thay vào đó, hãy sử dụng chức năng toàn cầu 53 tích hợp sẵn 2Vấn đề JavaScript #5. Thao tác DOM không hiệu quảJavaScript làm cho việc thao tác DOM tương đối dễ dàng (tôi. e. , thêm, sửa đổi và xóa các phần tử), nhưng không làm gì để thúc đẩy việc thực hiện hiệu quả Một ví dụ phổ biến là mã thêm một loạt các Phần tử DOM cùng một lúc. Thêm một phần tử DOM là một hoạt động tốn kém. Mã thêm nhiều phần tử DOM liên tiếp không hiệu quả và có khả năng hoạt động không tốt Một giải pháp thay thế hiệu quả khi cần thêm nhiều phần tử DOM là sử dụng các đoạn tài liệu để thay thế, nhờ đó cải thiện hiệu quả và hiệu suất Ví dụ 5Ngoài hiệu quả được cải thiện vốn có của phương pháp này, việc tạo các phần tử DOM đính kèm rất tốn kém, trong khi việc tạo và sửa đổi chúng trong khi tách rời và sau đó gắn chúng mang lại hiệu suất tốt hơn nhiều Vấn đề JavaScript #6. Sử dụng sai định nghĩa hàm bên trong vòng lặp Game.prototype.restart = function () { this.clearLocalStorage(); var self = this; // Save reference to 'this', while it's still this! this.timer = setTimeout(function(){ self.clearBoard(); // Oh OK, I do know who 'self' is! }, 0); }; 40Hãy xem xét mã này 0Dựa trên đoạn mã trên, nếu có 10 phần tử đầu vào, nhấp vào bất kỳ phần tử nào trong số chúng sẽ hiển thị “Đây là phần tử #10”. Điều này là do, vào thời điểm 55 được gọi cho bất kỳ phần tử nào, vòng lặp 40 ở trên sẽ hoàn thành và giá trị của 9 sẽ là 10 (cho tất cả chúng)Đây là cách chúng tôi có thể khắc phục các sự cố đã nói ở trên bằng JavaScript để đạt được hành vi mong muốn 1Trong phiên bản mã được sửa đổi này, 58 được thực thi ngay lập tức mỗi khi chúng ta đi qua vòng lặp, mỗi lần nhận giá trị hiện tại của 59 và liên kết nó với một biến 00 có phạm vi. Hàm bên ngoài trả về hàm bên trong (cũng sử dụng biến 00 có phạm vi này) và phần tử 55 được đặt thành hàm bên trong đó. Điều này đảm bảo rằng mỗi 55 nhận và sử dụng đúng giá trị 9 (thông qua biến 00 có phạm vi)Vấn đề JavaScript #7. Không tận dụng đúng kế thừa nguyên mẫuMột tỷ lệ cao đáng ngạc nhiên các nhà phát triển JavaScript không hiểu đầy đủ và do đó không tận dụng hết các tính năng của kế thừa nguyên mẫu Đây là một ví dụ đơn giản. Hãy xem xét mã này 2Có vẻ khá đơn giản. Nếu bạn cung cấp tên, hãy sử dụng tên đó, nếu không, hãy đặt tên thành 'mặc định'. Ví dụ 3Nhưng điều gì sẽ xảy ra nếu chúng ta làm điều này 4Sau đó chúng tôi sẽ nhận được 5Nhưng sẽ không tốt hơn nếu điều này trở lại 'mặc định'? 6Với phiên bản này, 06 kế thừa thuộc tính 07 từ đối tượng 08 của nó, nơi nó được đặt (theo mặc định) thành 09. Do đó, nếu hàm tạo được gọi mà không có tên, tên sẽ mặc định là 10. Và tương tự, nếu thuộc tính 07 bị xóa khỏi một thể hiện của 06, thì chuỗi nguyên mẫu sẽ được tìm kiếm và thuộc tính 07 sẽ được truy xuất từ đối tượng 08 nơi giá trị của nó vẫn là 09. Vì vậy, bây giờ chúng tôi nhận được 7Vấn đề JavaScript #8. Tạo các tham chiếu không chính xác cho các phương thức sơ thẩmHãy xác định một đối tượng đơn giản và tạo một thể hiện của nó, như sau 8Bây giờ, để thuận tiện, hãy tạo một tham chiếu đến phương thức 16, có lẽ để chúng ta có thể truy cập nó chỉ bằng 17 chứ không phải bằng cách dài hơn 18 9Và để chắc chắn rằng mọi thứ trông giống copacetic, hãy in ra giá trị của biến 16 mới của chúng ta 0đầu ra 1Được, tuyệt đấy. Có vẻ ổn Nhưng bây giờ, hãy nhìn vào sự khác biệt khi chúng ta gọi 18 so với. tài liệu tham khảo thuận tiện của chúng tôi 17 2Có chuyện gì? . Do đó, giá trị của 6 là 2, không phải là phiên bản 26 của 27Vì vậy, nếu chúng ta thực sự cần tạo một tham chiếu đến một phương thức hiện có của một đối tượng, chúng ta cần đảm bảo thực hiện nó trong không gian tên của đối tượng đó, để bảo toàn giá trị của 6. Một cách để làm điều này sẽ như sau 3Vấn đề JavaScript #9. Cung cấp một Chuỗi làm Đối số Đầu tiên cho Uncaught TypeError: undefined is not a function 29 hoặc Uncaught TypeError: undefined is not a function 30Để bắt đầu, hãy làm rõ một số điều ở đây. Cung cấp một chuỗi làm đối số đầu tiên cho 29 hoặc 30 bản thân nó không phải là một sai lầm. Đó là mã JavaScript hoàn toàn hợp pháp. Vấn đề ở đây là một trong những hiệu suất và hiệu quả. Điều hiếm khi được giải thích là nếu bạn chuyển một chuỗi làm đối số đầu tiên cho 29 hoặc 30, nó sẽ được chuyển đến hàm tạo hàm để được chuyển đổi thành một hàm mới. Quá trình này có thể chậm và không hiệu quả, và hiếm khi cần thiếtThay vào đó, cách khác để truyền một chuỗi làm đối số đầu tiên cho các phương thức này là truyền vào một hàm. Hãy xem xét một ví dụ Sau đó, đây sẽ là cách sử dụng khá điển hình của 30 và 29, chuyển một chuỗi làm tham số đầu tiên 4Lựa chọn tốt hơn sẽ là chuyển một hàm làm đối số ban đầu; . g 5Vấn đề JavaScript #10. Không sử dụng được “Chế độ nghiêm ngặt”Như đã giải thích trong Hướng dẫn tuyển dụng JavaScript của chúng tôi, “chế độ nghiêm ngặt” (i. e. , bao gồm 37 ở đầu tệp nguồn JavaScript của bạn) là một cách tự nguyện thực thi phân tích cú pháp nghiêm ngặt hơn và xử lý lỗi trên mã JavaScript của bạn khi chạy, cũng như giúp mã này an toàn hơnMặc dù, phải thừa nhận rằng, việc không sử dụng chế độ nghiêm ngặt không phải là một “sai lầm”, nhưng việc sử dụng nó ngày càng được khuyến khích và việc bỏ qua nó ngày càng bị coi là hình thức xấu. Dưới đây là một số lợi ích chính của chế độ nghiêm ngặt
Giảm thiểu các vấn đề về JavaScript bằng cách tiếp cận thông minh hơnĐiều này đúng với bất kỳ công nghệ nào, bạn càng hiểu rõ hơn lý do và cách thức JavaScript hoạt động và không hoạt động, mã của bạn sẽ càng vững chắc và bạn càng có thể khai thác hiệu quả sức mạnh thực sự của ngôn ngữ này. Ngược lại, việc thiếu hiểu biết đúng đắn về các mô hình và khái niệm JavaScript thực sự là nguyên nhân gây ra nhiều vấn đề về JavaScript Làm quen hoàn toàn với các sắc thái và sự tinh tế của ngôn ngữ là chiến lược hiệu quả nhất để cải thiện trình độ và tăng năng suất của bạn. Tránh nhiều lỗi JavaScript phổ biến sẽ hữu ích khi JavaScript của bạn không hoạt động Đọc thêm trên Blog Kỹ thuật Toptal
Hiểu những điều cơ bảnCác lỗi phổ biến trong JavaScript là gì?Các lỗi phổ biến mà các nhà phát triển mắc phải khi mã hóa JavaScript bao gồm suy nghĩ sai về cách hoạt động của từ khóa "this", giả định không chính xác về phạm vi khối và không tránh rò rỉ bộ nhớ. Sự phát triển của JavaScript theo thời gian đã để lại nhiều cạm bẫy nếu tuân theo các mẫu mã hóa cũ Làm cách nào tôi có thể cải thiện kỹ năng JavaScript của mình?Bạn có thể cải thiện kỹ năng JavaScript của mình bằng cách áp dụng các phương pháp hay nhất để sử dụng trong mã thực và đọc về các sắc thái vốn có trong ngôn ngữ để nhận biết các tính năng và giới hạn nâng cao hơn của nó Tại sao tôi viết mã lỗi?Mã lỗi có thể trông hoàn toàn vô hại trên bề mặt. Bằng cách tìm hiểu về các sự cố JavaScript phổ biến, bạn có thể bắt đầu hiểu điều gì làm cho các mẫu mã hóa nhất định gặp vấn đề và cách tránh chúng trong mã của riêng bạn JavaScript có vấn đề không?Một số người có thể cho rằng bản thân ngôn ngữ JavaScript có vấn đề. Thật vậy, nó có những thiếu sót, nhưng nó cũng phổ biến—vì vậy bạn nên hiểu cách điều hướng chúng nếu bạn (giống như hầu hết các nhà phát triển ngày nay) phải làm việc với một số dạng mã JavaScript thẻ JavaScriptWebFrontEndBackEndNgười làm việc tự do? Tìm công việc tiếp theo của bạn. Công việc lập trình viên JavaScript Xem thông tin đầy đủ Ryan J. Peterson Kỹ sư phần mềm Thông tin về các Tác giả Ryan là một kiến trúc sư, doanh nhân và nhà phát triển hàng đầu. Anh ấy tự hào về năng lực đã được chứng minh trong việc xây dựng các hệ thống và phần mềm có thể mở rộng, có thể mở rộng trên đám mây. Anh ấy viết mã có thể được duy trì và mở rộng theo thời gian khi các hệ thống và yêu cầu kinh doanh thích ứng với nhu cầu thị trường hoặc xoay trục theo hướng kinh doanh cốt lõi Thuê Ryan Bình luậnnước sôi Bài viết tuyệt vời số 7 là tốt nhất nước sôi Bài viết tuyệt vời số 7 là tốt nhất Julio Saito bài tốt. Ngoài ra, ở lỗi # 8, bạn có thể sử dụng. var whoAmI = obj. tôi là ai. liên kết (đối tượng); Julio Saito bài tốt. Ngoài ra, ở lỗi # 8, bạn có thể sử dụng. var whoAmI = obj. tôi là ai. liên kết (đối tượng); hasanyasin Bài báo tuyệt vời. Tôi sẽ thực hiện một vài bổ sung nhỏ, chủ yếu xem xét những người tương đối mới về JavaScript. Đối với #2, ví dụ 2, có thể hữu ích khi đề cập đến việc tránh sử dụng `phần tử` bên trong hàm, họ có thể truy cập phần tử bằng cách sử dụng đối số hàm và thay vào đó là `this`. Đối với #6. IMHO, cách tạo bao đóng cho các phần tử theo cách này không phải là một cách hay. Điều này được đưa ra như một ví dụ rất nhiều lần trên mạng mà tôi đoán rằng, bất kỳ ai đang cố gắng học JavaScript sẽ lấy điều này làm mẫu. Tôi làm điều này trên một tập hợp các phần tử mà tôi chắc chắn rằng sẽ rất hạn chế về số lượng. Trong các trường hợp khác, tôi thích thêm các thuộc tính vào chính các đối tượng DOM và sau đó tiếp cận nó từ bên trong trình xử lý sự kiện. Đối với số 8. Tôi đoán ở cuối phần này, sẽ rất hữu ích nếu thêm việc sử dụng `bind` để làm điều này. Ví dụ đã cho chỉ hiển thị vấn đề; . tôi đã có obj. phương pháp và nó thực sự không thành vấn đề nếu tôi có obj. method_shortcut. Tôi thấy nhiều nhà phát triển đang cố gắng tạo lối tắt cho bảng điều khiển. đăng nhập và sau đó thoát khi họ thấy điều đó; . log` không hoạt động như họ mong đợi. Thật dễ dàng để có một phím tắt cho bảng điều khiển. đăng nhập, mặc dù. `log = bảng điều khiển. đăng nhập. bind(console)` Sau đó, bạn có thể sử dụng log() làm phím tắt. Điều này thật tuyệt, đặc biệt là khi gỡ lỗi bẩn bằng bảng điều khiển thay vì trình gỡ lỗi. Một nơi khác mà bạn muốn có lối tắt là sử dụng phương thức `hasOwnProperty` của nguyên mẫu `Object`. Bạn có thể có lối tắt của mình, giả sử `hasprop` như thế này; . gọi . liên kết (Đối tượng. nguyên mẫu. hasOwnProperty) ``` Sau đó, thay vì điều này. ``` Đối tượng. nguyên mẫu. hasOwnProperty. gọi (myobj, property_name) ``` bạn có thể làm điều này. ``` hasprop(myboj, property_name) ``` Tôi ngạc nhiên khi thấy các kỹ sư phát cuồng vì sử dụng. thuộc tính độ dài trong các phần thân và điều kiện của vòng lặp thay vì lưu vào bộ nhớ đệm trước vòng lặp chủ yếu với mối quan tâm về ảnh hưởng của quyền truy cập thuộc tính đối với hiệu suất; . Tôi tin rằng `hasOwnProperty` là một ví dụ điển hình cho điều này. Tôi yêu `ràng buộc`. Nó khiến tôi cảm thấy như mình đang ở trong Haskell. p // ứng dụng một phần. Haskel. ``` thêm a b = a + b add5 = thêm 5 ``` JavaScript. ``` hàm add(a,b) { return a+b } var add5 = add. liên kết (null, 5); . Nếu bạn đặt `null` làm đối số đầu tiên cho `bind` thì nó sẽ không đặt `this` cho hàm. Lưu ý thêm, `this` được dùng để chỉ đối tượng chung (`window` trong trình duyệt) khi một hàm được gọi với `null` cho `this`; hasanyasin Bài báo tuyệt vời. Tôi sẽ thực hiện một vài bổ sung nhỏ, chủ yếu xem xét những người tương đối mới về JavaScript. Đối với #2, ví dụ 2, có thể hữu ích khi đề cập đến việc tránh sử dụng `phần tử` bên trong hàm, họ có thể truy cập phần tử bằng cách sử dụng đối số hàm và thay vào đó là `this`. Đối với #6. IMHO, cách tạo bao đóng cho các phần tử theo cách này không phải là một cách hay. Điều này được đưa ra như một ví dụ rất nhiều lần trên mạng mà tôi đoán rằng, bất kỳ ai đang cố gắng học JavaScript sẽ lấy điều này làm mẫu. Tôi làm điều này trên một tập hợp các phần tử mà tôi chắc chắn rằng sẽ rất hạn chế về số lượng. Trong các trường hợp khác, tôi thích thêm các thuộc tính vào chính các đối tượng DOM và sau đó tiếp cận nó từ bên trong trình xử lý sự kiện. Đối với số 8. Tôi đoán ở cuối phần này, sẽ rất hữu ích nếu thêm việc sử dụng `bind` để làm điều này. Ví dụ đã cho chỉ hiển thị vấn đề; . tôi đã có obj. phương pháp và nó thực sự không thành vấn đề nếu tôi có obj. method_shortcut. Tôi thấy nhiều nhà phát triển đang cố gắng tạo lối tắt cho bảng điều khiển. đăng nhập và sau đó thoát khi họ thấy điều đó; . log` không hoạt động như họ mong đợi. Thật dễ dàng để có một phím tắt cho bảng điều khiển. đăng nhập, mặc dù. `log = bảng điều khiển. đăng nhập. bind(console)` Sau đó, bạn có thể sử dụng log() làm phím tắt. Điều này thật tuyệt, đặc biệt là khi gỡ lỗi bẩn bằng bảng điều khiển thay vì trình gỡ lỗi. Một nơi khác mà bạn muốn có lối tắt là sử dụng phương thức `hasOwnProperty` của nguyên mẫu `Object`. Bạn có thể có lối tắt của mình, giả sử `hasprop` như thế này; . gọi . liên kết (Đối tượng. nguyên mẫu. hasOwnProperty) ``` Sau đó, thay vì điều này. ``` Đối tượng. nguyên mẫu. hasOwnProperty. gọi (myobj, property_name) ``` bạn có thể làm điều này. ``` hasprop(myboj, property_name) ``` Tôi ngạc nhiên khi thấy các kỹ sư phát cuồng vì sử dụng. thuộc tính độ dài trong các phần thân và điều kiện của vòng lặp thay vì lưu vào bộ nhớ đệm trước vòng lặp chủ yếu với mối quan tâm về ảnh hưởng của quyền truy cập thuộc tính đối với hiệu suất; . Tôi tin rằng `hasOwnProperty` là một ví dụ điển hình cho điều này. Tôi yêu `ràng buộc`. Nó khiến tôi cảm thấy như mình đang ở trong Haskell. p // ứng dụng một phần. Haskel. ``` thêm a b = a + b add5 = thêm 5 ``` JavaScript. ``` hàm add(a,b) { return a+b } var add5 = add. liên kết (null, 5); . Nếu bạn đặt `null` làm đối số đầu tiên cho `bind` thì nó sẽ không đặt `this` cho hàm. Lưu ý thêm, `this` được dùng để chỉ đối tượng chung (`window` trong trình duyệt) khi một hàm được gọi với `null` cho `this`; ajaniashish Bài viết rất hay và những lỗi mà bạn đề cập trong bài viết này thường là do các lập trình viên mắc phải, nhưng theo quan điểm của tôi thì hầu hết các lỗi phổ biến nhất là #1 và #3, thường khi tôi xem lại mã của các thành viên trong nhóm của mình, tôi thấy hai lỗi này và chúng hoàn toàn . Cảm ơn bạn đã chia sẻ bài viết tốt như vậy ajaniashish Bài viết rất hay và những lỗi mà bạn đề cập trong bài viết này thường là do các lập trình viên mắc phải, nhưng theo quan điểm của tôi thì hầu hết các lỗi phổ biến nhất là #1 và #3, thường khi tôi xem lại mã của các thành viên trong nhóm của mình, tôi thấy hai lỗi này và chúng hoàn toàn . Cảm ơn bạn đã chia sẻ bài viết tốt như vậy tamm Bài báo tuyệt vời tamm Bài báo tuyệt vời sebastianteres bài đăng tuyệt vời. Tôi khuyên bạn nên xem qua hướng dẫn Javascript của Mozilla (https. // nhà phát triển. mozilla. org/en-US/docs/Web/JavaScript/Guide/About) Nó bao gồm hầu hết các chủ đề được thảo luận tại đây. Đó là một điểm khởi đầu tuyệt vời cho các nhà phát triển javascript sebastianteres bài đăng tuyệt vời. Tôi khuyên bạn nên xem qua hướng dẫn Javascript của Mozilla (https. // nhà phát triển. mozilla. org/en-US/docs/Web/JavaScript/Guide/About) Nó bao gồm hầu hết các chủ đề được thảo luận tại đây. Đó là một điểm khởi đầu tuyệt vời cho các nhà phát triển javascript brianN2 Bài viết hay - chỉ thiếu Lỗi thường gặp #0 Sử dụng javascript ngay từ đầu. Nếu bạn muốn một ngôn ngữ tạo ra mã khủng khiếp, khó bảo trì và dễ tạo lỗi thì javascript có tất cả. JavaScript chưa bao giờ có nghĩa là làm những gì nó làm ngày nay, mọi tính năng mới chỉ làm cho ngôn ngữ trở nên tồi tệ hơn và phức tạp hơn để sử dụng. Thật không may, đó là điều mà mọi ngôn ngữ thành công đều gặp phải khi c ++ gặp vấn đề tương tự. Mọi thứ phải tương thích ngược, vì vậy mọi thứ không bao giờ đơn giản hơn mà chỉ phức tạp hơn. Vì javascript được sử dụng trong các trang web có thể không bao giờ được duy trì nên nó sẽ không bao giờ biến mất. Những bài viết như thế này rất hay nhưng chúng chỉ là bề nổi của những thứ được thực hiện dưới danh nghĩa JavaScript brianN2 Bài viết hay - chỉ thiếu Lỗi thường gặp #0 Sử dụng javascript ngay từ đầu. Nếu bạn muốn một ngôn ngữ tạo ra mã khủng khiếp, khó bảo trì và dễ tạo lỗi thì javascript có tất cả. JavaScript chưa bao giờ có nghĩa là làm những gì nó làm ngày nay, mọi tính năng mới chỉ làm cho ngôn ngữ trở nên tồi tệ hơn và phức tạp hơn để sử dụng. Thật không may, đó là điều mà mọi ngôn ngữ thành công đều gặp phải khi c ++ gặp vấn đề tương tự. Mọi thứ phải tương thích ngược, vì vậy mọi thứ không bao giờ đơn giản hơn mà chỉ phức tạp hơn. Vì javascript được sử dụng trong các trang web có thể không bao giờ được duy trì nên nó sẽ không bao giờ biến mất. Những bài viết như thế này rất hay nhưng chúng chỉ là bề nổi của những thứ được thực hiện dưới danh nghĩa JavaScript Melad dabbous Bài báo hay. tôi đã học nhiều điều từ nó Melad dabbous Bài báo hay. tôi đã học nhiều điều từ nó Ryan J. Peterson Tôi đồng ý rằng #6 lẽ ra phải là thứ không phải là phần tử DOM. Tôi nghĩ lý do nó được sử dụng trực tuyến nhiều như vậy là do `onclick` cũng là một trong những chức năng mà mọi người lần đầu tiên được giới thiệu. Tôi tập trung nhiều hơn vào việc đóng không nằm trong vòng lặp hơn là vào sự kiện DOM. Tôi đã có một bản nháp của ràng buộc được đề cập này nhưng đã chỉnh sửa nó để dễ đọc, bài đăng này thực sự có thể được mở rộng hơn nữa nhưng sau đó sẽ còn lại những gì để thảo luận trong các bình luận. Tuy nhiên, cảm ơn vì đã thêm giá trị vào đây trong các nhận xét, hy vọng người học cũng sẽ đọc các nhận xét đó Ryan J. Peterson Tôi đồng ý rằng #6 lẽ ra phải là thứ không phải là phần tử DOM. Tôi nghĩ lý do nó được sử dụng trực tuyến nhiều như vậy là do `onclick` cũng là một trong những chức năng mà mọi người lần đầu tiên được giới thiệu. Tôi tập trung nhiều hơn vào việc đóng không nằm trong vòng lặp hơn là vào sự kiện DOM. Tôi đã có một bản nháp của ràng buộc được đề cập này nhưng đã chỉnh sửa nó để dễ đọc, bài đăng này thực sự có thể được mở rộng hơn nữa nhưng sau đó sẽ còn lại những gì để thảo luận trong các bình luận. Tuy nhiên, cảm ơn vì đã thêm giá trị vào đây trong các nhận xét, hy vọng người học cũng sẽ đọc các nhận xét đó Ryan J. Peterson Đây là một khuyến nghị tuyệt vời, tôi thường xuyên tham khảo hướng dẫn này khi tra cứu thứ gì đó mà tôi không thể nhớ hoặc muốn đảm bảo rằng mình đã hiểu đúng Ryan J. Peterson Đây là một khuyến nghị tuyệt vời, tôi thường xuyên tham khảo hướng dẫn này khi tra cứu thứ gì đó mà tôi không thể nhớ hoặc muốn đảm bảo rằng mình đã hiểu đúng Ryan J. Peterson Đó là tình trạng tương tự với những nhận xét không mang lại giá trị cho bài tập trong học tập. Thành thật mà nói, JavaScript sẽ không sớm biến mất. Với cuộc cách mạng ECMA 6 và v8, ít nhất nó đang được cải thiện. Để nói rằng "JavaScript không bao giờ có nghĩa là làm những gì nó làm ngày hôm nay. " bỏ qua điều đó bằng cách phá vỡ mục đích của công nghệ, chúng tôi đã thấy những tiến bộ như internet, đã phá vỡ mục đích giao tiếp tốt hơn thành vô số khả năng. Mặc dù tôi đánh giá cao ý kiến của bạn, nhưng tôi vẫn cảm thấy như những bình luận sôi nổi về JavaScript, Ruby, PHP hoặc bất kỳ ngôn ngữ nào khác tạo ra sự phân chia không cần thiết giữa quyết định chủ quan của ngôn ngữ lập trình và môi trường thường không do chúng tôi viết mã. Trong tương lai, tôi sẽ đánh giá cao những bình luận mang tính xây dựng. Cảm ơn bạn Ryan J. Peterson Đó là tình trạng tương tự với những nhận xét không mang lại giá trị cho bài tập trong học tập. Thành thật mà nói, JavaScript sẽ không sớm biến mất. Với cuộc cách mạng ECMA 6 và v8, ít nhất nó đang được cải thiện. Để nói rằng "JavaScript không bao giờ có nghĩa là làm những gì nó làm ngày hôm nay. " bỏ qua điều đó bằng cách phá vỡ mục đích của công nghệ, chúng tôi đã thấy những tiến bộ như internet, đã phá vỡ mục đích giao tiếp tốt hơn thành vô số khả năng. Mặc dù tôi đánh giá cao ý kiến của bạn, nhưng tôi vẫn cảm thấy như những bình luận sôi nổi về JavaScript, Ruby, PHP hoặc bất kỳ ngôn ngữ nào khác tạo ra sự phân chia không cần thiết giữa quyết định chủ quan của ngôn ngữ lập trình và môi trường thường không do chúng tôi viết mã. Trong tương lai, tôi sẽ đánh giá cao những bình luận mang tính xây dựng. Cảm ơn bạn brianN2 Xin lỗi bạn đã không nhận được bản chất nhẹ nhàng của nhận xét hoặc quan điểm được đưa ra. JavaScript là một trong những ngôn ngữ làm việc của tôi cũng như C++, vì vậy nó khó có thể trở thành ngọn lửa đối với những ngôn ngữ đó. Nhận xét mang tính xây dựng và phù hợp về một bài viết về những lỗi thường gặp, nếu ngôn ngữ tốt hơn thì sẽ ít vấn đề hơn. Điều tuyệt vời là ' sử dụng siêu hạn chế ' mang lại tính năng kiểm tra loại nghiêm ngặt và lập trình thực tế, loại bỏ một số tính năng ít được mong muốn hơn, có lẽ dành cho phiên bản trong tương lai - tôi có thể mơ ước brianN2 Xin lỗi bạn đã không nhận được bản chất nhẹ nhàng của nhận xét hoặc quan điểm được đưa ra. JavaScript là một trong những ngôn ngữ làm việc của tôi cũng như C++, vì vậy nó khó có thể trở thành ngọn lửa đối với những ngôn ngữ đó. Nhận xét mang tính xây dựng và phù hợp về một bài viết về những lỗi thường gặp, nếu ngôn ngữ tốt hơn thì sẽ ít vấn đề hơn. Điều tuyệt vời là ' sử dụng siêu hạn chế ' mang lại tính năng kiểm tra loại nghiêm ngặt và lập trình thực tế, loại bỏ một số tính năng ít được mong muốn hơn, có lẽ dành cho phiên bản trong tương lai - tôi có thể mơ ước Ryan J. Peterson Lỗi của tôi. Gần đây tôi đã phải đối mặt với những trò troll nhật ký tiêu cực và tôi đã mất đi sự hài hước. Vâng, một phiên bản tương lai là nơi chúng ta có thể đặt hy vọng và ước mơ của mình Ryan J. Peterson Lỗi của tôi. Gần đây tôi đã phải đối mặt với những trò troll nhật ký tiêu cực và tôi đã mất đi sự hài hước. Vâng, một phiên bản tương lai là nơi chúng ta có thể đặt hy vọng và ước mơ của mình Sushil Kumar Bài báo tuyệt vời. Đây là những lỗi phổ biến mà các lập trình viên mới làm quen, giống như tôi, mắc phải. Đặc biệt là #1 và #2 Sushil Kumar Bài báo tuyệt vời. Đây là những lỗi phổ biến mà các lập trình viên mới làm quen, giống như tôi, mắc phải. Đặc biệt là #1 và #2 MobilePundits Most of the time when the project deadline is near and due to this In the hurry of development and releasing most of the people don't pay attention over all these java script mistakes. You shared a nice and informative post. I recommended. Phonegap mobile app development MobilePundits Most of the time when the project deadline is near and due to this In the hurry of development and releasing most of the people don't pay attention over all these java script mistakes. You shared a nice and informative post. I recommended. Phonegap mobile app development Vladimir Grichina Equality in JS is so confusing that you also have made a mistake when describing mistake #4 :) To check if value x is NaN you have to compare it to itself, i.e.:
Vladimir Grichina Equality in JS is so confusing that you also have made a mistake when describing mistake #4 :) To check if value x is NaN you have to compare it to itself, i.e.:
Serge Batishchev Bài báo tuyệt vời. Bạn có thể làm rõ mặc dù mức độ chính xác của vấn đề ở đây. "Thật thú vị, ngay cả khi phần tử bị xóa khỏi DOM, vòng tròn tự tham chiếu ở trên sẽ ngăn không cho phần tử và onClick được thu thập và do đó, rò rỉ bộ nhớ. " Tôi có ấn tượng rằng rò rỉ tham chiếu vòng loại DOM-JS chỉ là vấn đề đối với IE7 trở xuống (do việc xử lý riêng GC cho đối tượng DOM và JS nếu tôi nhớ không lầm). Bởi vì, thực sự, các tham chiếu vòng tròn không phải là vấn đề đối với GC, miễn là các đối tượng trong "vòng lặp" không thể truy cập được từ bên ngoài. Hoặc tôi đang thiếu một cái gì đó trong ví dụ của bạn mà thực tế là giữ một trong các đối tượng từ bên ngoài? Serge Batishchev Bài báo tuyệt vời. Bạn có thể làm rõ mặc dù mức độ chính xác của vấn đề ở đây. "Thật thú vị, ngay cả khi phần tử bị xóa khỏi DOM, vòng tròn tự tham chiếu ở trên sẽ ngăn không cho phần tử và onClick được thu thập và do đó, rò rỉ bộ nhớ. " Tôi có ấn tượng rằng rò rỉ tham chiếu vòng loại DOM-JS chỉ là vấn đề đối với IE7 trở xuống (do việc xử lý riêng GC cho đối tượng DOM và JS nếu tôi nhớ không lầm). Bởi vì, thực sự, các tham chiếu vòng tròn không phải là vấn đề đối với GC, miễn là các đối tượng trong "vòng lặp" không thể truy cập được từ bên ngoài. Hoặc tôi đang thiếu một cái gì đó trong ví dụ của bạn mà thực tế là giữ một trong các đối tượng từ bên ngoài? Kostas An alternative for #6 using IIFE..
Kostas An alternative for #6 using IIFE..
Khách Rò rỉ bộ nhớ Ví dụ #1 dường như không hợp lệ. Không có rò rỉ bộ nhớ ở đó. Mỗi lần chức năng replaceThing() được thực thi, trướcThing được đặt thành không xác định trước và sau đó nhận tham chiếu tới theThing để mỗi lần mất 1mb bộ nhớ và không bị rò rỉ mem Khách Rò rỉ bộ nhớ Ví dụ #1 dường như không hợp lệ. Không có rò rỉ bộ nhớ ở đó. Mỗi lần chức năng replaceThing() được thực thi, trướcThing được đặt thành không xác định trước và sau đó nhận tham chiếu tới theThing để mỗi lần mất 1mb bộ nhớ và không bị rò rỉ mem tôi biết Hôm nay mới biết cái này. biến x = 12; . log(out) // xuất ra '12' và không đúng hoặc sai; tôi biết Hôm nay mới biết cái này. biến x = 12; . log(out) // xuất ra '12' và không đúng hoặc sai; vô danh JavaScript có nhiều giá trị trung thực/sai hơn "true" và "false" và sẽ trả về "giá trị cuối cùng" cho. ,. , &, và && toán tử. http. // vi. wikipedia. org/wiki/Short-circuit_evaluation Các nhà phát triển JavaScript có thể sử dụng điều này để tạo lợi thế cho họ. // không sử dụng giá trị cuối cùng function(name) { if (name) { return name; . "Cục kẹo"; . //Nếu không, chúng tôi đánh giá RHS và trả về "kẹo" } vô danh JavaScript có nhiều giá trị trung thực/sai hơn "true" và "false" và sẽ trả về "giá trị cuối cùng" cho. ,. , &, và && toán tử. http. // vi. wikipedia. org/wiki/Short-circuit_evaluation Các nhà phát triển JavaScript có thể sử dụng điều này để tạo lợi thế cho họ. // không sử dụng giá trị cuối cùng function(name) { if (name) { return name; . "Cục kẹo"; . //Nếu không, chúng tôi đánh giá RHS và trả về "kẹo" } cintalauraramarimari JavaScript is very important for modern web applications, let's say obat keputihan gatal berbau to the health of women cintalauraramarimari JavaScript is very important for modern web applications, let's say obat keputihan gatal berbau to the health of women Ben Randles-Dunkley Ý bạn là AS3? Ben Randles-Dunkley Ý bạn là AS3? Terry Marr bài đăng tuyệt vời. Người mới bắt đầu cần những ví dụ cụ thể về mã tốt và xấu để học hỏi. Bạn đã làm điều này một cách xuất sắc, đặc biệt là với #3 rò rỉ bộ nhớ ví dụ 1. Tuy nhiên, trong ví dụ 2, ví dụ tham chiếu vòng tròn, thật tuyệt khi thấy phiên bản cố định của mã. Bạn có thể chỉnh sửa để cung cấp điều đó không? Terry Marr bài đăng tuyệt vời. Người mới bắt đầu cần những ví dụ cụ thể về mã tốt và xấu để học hỏi. Bạn đã làm điều này một cách xuất sắc, đặc biệt là với #3 rò rỉ bộ nhớ ví dụ 1. Tuy nhiên, trong ví dụ 2, ví dụ tham chiếu vòng tròn, thật tuyệt khi thấy phiên bản cố định của mã. Bạn có thể chỉnh sửa để cung cấp điều đó không? Ali Sẽ không bao giờ hiểu một điều. Nếu đó là một ngôn ngữ phi logic (đúng như vậy) với rất nhiều lỗi ngớ ngẩn thì tại sao mọi người vẫn sử dụng nó? Ali Sẽ không bao giờ hiểu một điều. Nếu đó là một ngôn ngữ phi logic (đúng như vậy) với rất nhiều lỗi ngớ ngẩn thì tại sao mọi người vẫn sử dụng nó? javinievas Bạn quên đề cập đến vấn đề dấu phẩy ở cuối. tôi đã nhìn thấy nó rất nhiều. dict = {"a". 1, "b". 2,} javinievas Bạn quên đề cập đến vấn đề dấu phẩy ở cuối. tôi đã nhìn thấy nó rất nhiều. dict = {"a". 1, "b". 2,} Robert Jackson HÀNG ĐẦU. có người gửi email cho tôi yêu cầu sắp xếp thời gian phỏng vấn. Thời gian được cung cấp là từ 2 giờ sáng đến 8 giờ sáng. Tôi gửi lại email nói rằng điều đó thật điên rồ. Tôi được thông báo rằng tôi sẽ nhận được tin từ một người khác có thể ở múi giờ của tôi. tôi không bao giờ nghe lại. Toptal nằm ở chỗ quái nào????????????????????? . Thử hỏi có người trong nước còn thức lúc phỏng vấn và gọi trước khi giả làm công ty thật không????????????????????? Robert Jackson HÀNG ĐẦU. có người gửi email cho tôi yêu cầu sắp xếp thời gian phỏng vấn. Thời gian được cung cấp là từ 2 giờ sáng đến 8 giờ sáng. Tôi gửi lại email nói rằng điều đó thật điên rồ. Tôi được thông báo rằng tôi sẽ nhận được tin từ một người khác có thể ở múi giờ của tôi. tôi không bao giờ nghe lại. Toptal nằm ở chỗ quái nào????????????????????? . Thử hỏi có người trong nước còn thức lúc phỏng vấn và gọi trước khi giả làm công ty thật không????????????????????? Norbert Không cần IIFE ở đây, hãy sử dụng phương pháp Nguyên mẫu mảng như. cho mỗi. Tiết kiệm nhiều lần gõ phím và làm cho mã dễ hiểu và dễ đọc hơn. Tuy nhiên, việc chuyển đổi nodeList thành Array trước tiên rất quan trọng, nhưng điều đó cũng dễ dàng. Mảng. từ (tài liệu. getElementsByTagName('đầu vào')). forEach(function (item, index) { item. addEventListener('click', function (sự kiện) { console. log("Đây là phần tử #" + index); . ví dụ làm việc. http. //jsbin. com/bexohageje/edit?html,js,bảng điều khiển Norbert Không cần IIFE ở đây, hãy sử dụng phương pháp Nguyên mẫu mảng như. cho mỗi. Tiết kiệm nhiều lần gõ phím và làm cho mã dễ hiểu và dễ đọc hơn. Tuy nhiên, việc chuyển đổi nodeList thành Array trước tiên rất quan trọng, nhưng điều đó cũng dễ dàng. Mảng. từ (tài liệu. getElementsByTagName('đầu vào')). forEach(function (item, index) { item. addEventListener('click', function (sự kiện) { console. log("Đây là phần tử #" + index); . ví dụ làm việc. http. //jsbin. com/bexohageje/edit?html,js,bảng điều khiển Kostas Gọn gàng. Mặc dù, tôi nghĩ hiện tại, Array. nguyên mẫu. from cần một polyfill để hoạt động trên tất cả các trình duyệt Kostas Gọn gàng. Mặc dù, tôi nghĩ hiện tại, Array. nguyên mẫu. from cần một polyfill để hoạt động trên tất cả các trình duyệt Norbert Correct, but polyfills are A-OK with me. working example: http://jsbin.com/nuxucirudo/edit?html,js,consoleNorbert Correct, but polyfills are A-OK with me. working example: http://jsbin.com/nuxucirudo/edit?html,js,consoleNorbert > Nó được triển khai trong mọi trình duyệt đang sử dụng. > Tất cả các máy tính đều có trình duyệt mặc định. > Trình duyệt được yêu cầu khá nhiều để làm bất cứ điều gì trực tuyến. > Nó thực sự là một ngôn ngữ biểu cảm và mạnh mẽ rất năng động. > Không có ngôn ngữ lập trình nào khác được bật trong trình duyệt theo mặc định. Nhưng không sợ. Nếu bạn không thích javascript, bạn không cần phải sử dụng nó. Bạn có thể biên dịch/biên dịch sang javascript từ nhiều ngôn ngữ mà bạn có thể thích. TypeScript, Ruby, C, Scala chỉ để kể tên một số. với asm. js, mã mà các công cụ này tạo ra thực sự có thể rất nhanh. Chỉ hy vọng họ đi kèm với một trình sửa lỗi tốt, vì nếu không thì bạn sẽ &^*%ed Norbert > Nó được triển khai trong mọi trình duyệt đang sử dụng. > Tất cả các máy tính đều có trình duyệt mặc định. > Trình duyệt được yêu cầu khá nhiều để làm bất cứ điều gì trực tuyến. > Nó thực sự là một ngôn ngữ biểu cảm và mạnh mẽ rất năng động. > Không có ngôn ngữ lập trình nào khác được bật trong trình duyệt theo mặc định. Nhưng không sợ. Nếu bạn không thích javascript, bạn không cần phải sử dụng nó. Bạn có thể biên dịch/biên dịch sang javascript từ nhiều ngôn ngữ mà bạn có thể thích. TypeScript, Ruby, C, Scala chỉ để kể tên một số. với asm. js, mã mà các công cụ này tạo ra thực sự có thể rất nhanh. Chỉ hy vọng họ đi kèm với một trình sửa lỗi tốt, vì nếu không thì bạn sẽ &^*%ed Norbert I'm very confused by this as well, So this is broken, because of reasons the article explains: Perhaps we can try to do away with the 'element' reference like this: Working example: http://jsbin.com/becamexive/edit?html,js,output NOTE: I had to edit the authors code, because it wasn't working/doing anything/the thing that was intended.Norbert I'm very confused by this as well, So this is broken, because of reasons the article explains: Perhaps we can try to do away with the 'element' reference like this: Working example: http://jsbin.com/becamexive/edit?html,js,output NOTE: I had to edit the authors code, because it wasn't working/doing anything/the thing that was intended.Norbert doThis is attempted, if it returns a truthy value the next thing it attempted, etc. until the last thing in the sequence and that is whatever is actually returned from the expression. Javascript considers 0, null, undefined, '' as falsy and everything else is considered truthy. I personally would have liked an empty array to have been falsy, but Ey, can't have it all I guess.Norbert doThis is attempted, if it returns a truthy value the next thing it attempted, etc. until the last thing in the sequence and that is whatever is actually returned from the expression. Javascript considers 0, null, undefined, '' as falsy and everything else is considered truthy. I personally would have liked an empty array to have been falsy, but Ey, can't have it all I guess.Norbert Bạn có thể điều tra chuyển mã/biên dịch sang javascript từ bất kỳ ngôn ngữ nào bạn thích. Mặc dù vậy, bạn có thể viết mã hôi thối bằng bất kỳ ngôn ngữ nào, nhưng ở một số ngôn ngữ thì dễ hơn ở một số ngôn ngữ khác. Vâng, rất dễ mắc lỗi trong Javascript, không có nghĩa là hoàn toàn không có gì đẹp ở đó và chúng ta nên loại bỏ tất cả những lỗi đó. Cá nhân tôi không đồng ý rằng một 'chế độ' khác trong javascript sẽ là một cải tiến. TC39 dường như đồng ý với điều đó hầu hết thời gian. Bạn thực sự nghĩ chính xác những bổ sung nào trong ES5 và ES6 (ngoài các lớp) làm cho ngôn ngữ trở nên tồi tệ hơn? . Trân trọng, không có ý định đốt lửa Norbert Bạn có thể điều tra chuyển mã/biên dịch sang javascript từ bất kỳ ngôn ngữ nào bạn thích. Mặc dù vậy, bạn có thể viết mã hôi thối bằng bất kỳ ngôn ngữ nào, nhưng ở một số ngôn ngữ thì dễ hơn ở một số ngôn ngữ khác. Vâng, rất dễ mắc lỗi trong Javascript, không có nghĩa là hoàn toàn không có gì đẹp ở đó và chúng ta nên loại bỏ tất cả những lỗi đó. Cá nhân tôi không đồng ý rằng một 'chế độ' khác trong javascript sẽ là một cải tiến. TC39 dường như đồng ý với điều đó hầu hết thời gian. Bạn thực sự nghĩ chính xác những bổ sung nào trong ES5 và ES6 (ngoài các lớp) làm cho ngôn ngữ trở nên tồi tệ hơn? . Trân trọng, không có ý định đốt lửa brianN2 Thật kỳ lạ khi nghĩ rằng rất nhiều tính năng mới thực sự làm cho JavaScript tốt hơn (. ), hãy nghiêm khắc và nó thậm chí còn tốt hơn. Vấn đề là bạn phát triển diện tích bề mặt ngôn ngữ càng lớn thì càng khó học và sử dụng chính xác, càng có nhiều khả năng xảy ra lỗi và hành vi không xác định. Một ngôn ngữ cần '===' cũng như '==' thực sự có vấn đề. Bạn hoàn toàn đúng khi biên dịch/biên dịch sang JavaScript sẽ là một cách để thực hiện. Trình biên dịch không có tính mong manh (hoặc bản ngã. ) trong số chúng ta, những người lập trình con người. Vì vậy, có lẽ một tập hợp con được biên dịch của ngôn ngữ 'hiện đại' loại bỏ tất cả sự mơ hồ và hành trang của JavaScript là cách tốt nhất? brianN2 Thật kỳ lạ khi nghĩ rằng rất nhiều tính năng mới thực sự làm cho JavaScript tốt hơn (. ), hãy nghiêm khắc và nó thậm chí còn tốt hơn. Vấn đề là bạn phát triển diện tích bề mặt ngôn ngữ càng lớn thì càng khó học và sử dụng chính xác, càng có nhiều khả năng xảy ra lỗi và hành vi không xác định. Một ngôn ngữ cần '===' cũng như '==' thực sự có vấn đề. Bạn hoàn toàn đúng khi biên dịch/biên dịch sang JavaScript sẽ là một cách để thực hiện. Trình biên dịch không có tính mong manh (hoặc bản ngã. ) trong số chúng ta, những người lập trình con người. Vì vậy, có lẽ một tập hợp con được biên dịch của ngôn ngữ 'hiện đại' loại bỏ tất cả sự mơ hồ và hành trang của JavaScript là cách tốt nhất? bdiscus forEach là một giải pháp tuyệt vời cho nhiều thứ, nhưng nó có nhược điểm. Nó rất chậm so với một vòng lặp được lưu trong bộ nhớ cache đơn giản, vì nó tạo thành một lệnh gọi hàm cho mỗi lần lặp khá tốn kém. Vì vậy, nếu bạn định xử lý một lượng lớn phần tử, bạn nên sử dụng một vòng lặp for được lưu trong bộ nhớ cache đơn giản, nếu không thì forEach sẽ ổn thôi. So sánh hiệu suất tại đây (đối với tôi, Chrome chậm hơn 73% đối với mỗi người). https. //jsperf. com/cho-vs-foreach/37 bdiscus forEach là một giải pháp tuyệt vời cho nhiều thứ, nhưng nó có nhược điểm. Nó rất chậm so với một vòng lặp được lưu trong bộ nhớ cache đơn giản, vì nó tạo thành một lệnh gọi hàm cho mỗi lần lặp khá tốn kém. Vì vậy, nếu bạn định xử lý một lượng lớn phần tử, bạn nên sử dụng một vòng lặp for được lưu trong bộ nhớ cache đơn giản, nếu không thì forEach sẽ ổn thôi. So sánh hiệu suất tại đây (đối với tôi, Chrome chậm hơn 73% đối với mỗi người). https. //jsperf. com/cho-vs-foreach/37 BeGe1 #8 is incorrect. It states that the reason for the change in the "this" keyword is that the variable declaration pointing to the function is created in the global scope. This is incorrect. The "this" keyword is a matter of dynamic scope, not lexical. It's not about where the variable pointing to the function is declared, it's about how it's called. The reason the first one outputs "MyObj" is because it's called as an object property, so that object becomes the "this" keyword. The second one is called not as an object property, so its "this" keyword is whatever the default "this" is (in this case the global object window since it's not in strict mode). Proof of that is this code, add it to the end of the code you were doing: (function myFunc(){ var whoAmI2 = whoAmI; whoAmI2(); // outputs "window", even though was "declared" in a function })(); function MyConstructor() { var whoAmI3 = whoAmI; whoAmI3(); } var mc = new MyConstructor(); // "window", even though is declared in an instantiated objectWhy does it do that? Again...because it's about how it's called, not where it's declared. Just like whoAmI , whoAmI2 and whoAmI3 are called NOT as a property on an object, so (not in strict mode) it ends up with the "this" keyword meaning the global object (i.e. window) just the same as whoAmI even though the variables pointing to them are declared in vastly different circumstances.BeGe1 #8 is incorrect. It states that the reason for the change in the "this" keyword is that the variable declaration pointing to the function is created in the global scope. This is incorrect. The "this" keyword is a matter of dynamic scope, not lexical. It's not about where the variable pointing to the function is declared, it's about how it's called. The reason the first one outputs "MyObj" is because it's called as an object property, so that object becomes the "this" keyword. The second one is called not as an object property, so its "this" keyword is whatever the default "this" is (in this case the global object window since it's not in strict mode). Proof of that is this code, add it to the end of the code you were doing: (function myFunc(){ var whoAmI2 = whoAmI; whoAmI2(); // outputs "window", even though was "declared" in a function })(); function MyConstructor() { var whoAmI3 = whoAmI; whoAmI3(); } var mc = new MyConstructor(); // "window", even though is declared in an instantiated objectWhy does it do that? Again...because it's about how it's called, not where it's declared. Just like whoAmI , whoAmI2 and whoAmI3 are called NOT as a property on an object, so (not in strict mode) it ends up with the "this" keyword meaning the global object (i.e. window) just the same as whoAmI even though the variables pointing to them are declared in vastly different circumstances.James Edward Lewis NaN cũng sai và thật kỳ lạ, các phiên bản đầu tiên của JavaScript có Boolean(false) mới cũng bị sai James Edward Lewis NaN cũng sai và thật kỳ lạ, các phiên bản đầu tiên của JavaScript có Boolean(false) mới cũng bị sai James Edward Lewis Tôi cũng hiểu rằng các phiên bản cũ của IE (một lần nữa, IE7-) đã sử dụng tính năng đếm tham chiếu thay vì đánh dấu và quét, do đó, các chu kỳ tham chiếu không thực sự có thể truy cập được từ mã toàn cầu hoặc ngăn xếp cuộc gọi hiện tại sẽ không được giải phóng, ngay cả khi James Edward Lewis Tôi cũng hiểu rằng các phiên bản cũ của IE (một lần nữa, IE7-) đã sử dụng tính năng đếm tham chiếu thay vì đánh dấu và quét, do đó, các chu kỳ tham chiếu không thực sự có thể truy cập được từ mã toàn cầu hoặc ngăn xếp cuộc gọi hiện tại sẽ không được giải phóng, ngay cả khi James Edward Lewis Điều đó có thể trở thành hiện thực với đề xuất 'sử dụng mạnh mẽ', hiện đã được triển khai trong V8 James Edward Lewis Điều đó có thể trở thành hiện thực với đề xuất 'sử dụng mạnh mẽ', hiện đã được triển khai trong V8 James Edward Lewis Ví dụ ở cuối #1 nên viết lại để đi vào trọng tâm của vấn đề. Trò chơi. nguyên mẫu. khởi động lại = hàm () { cái này. ClearLocalStorage(); . hẹn giờ = setTimeout (cái này. cài lại. liên kết (cái này), 0); . nguyên mẫu. đặt lại = chức năng () { cái này. ClearBoard(); . }; . nguyên mẫu. khởi động lại = hàm () { cái này. ClearLocalStorage(); . hẹn giờ = setTimeout (cái này. rõ ràngBoard. liên kết (cái này), 0); . Bản thân ClearBoard, khi được truyền dưới dạng đối số cho một hàm, sẽ được giải quyết trước khi gọi và khi được gọi có cùng ngữ cảnh như một hàm thông thường, đây là một vấn đề nếu Game. nguyên mẫu. ClearBoard cũng đề cập đến điều này bên trong mã riêng của nó. Sự khác biệt là trong ví dụ như đã viết, việc tắt liên kết sẽ dẫn đến một lỗi đã biết, cửa sổ đó. ClearBoard không phải là một chức năng, trong khi trong ví dụ viết lại của tôi, điều này. ClearBoard có thể không gây ra lỗi mà thay vào đó sẽ tạo và ảnh hưởng đến các biến toàn cục, thay vì các thành viên của thể hiện mà bạn đã trích xuất phương thức từ đó James Edward Lewis Ví dụ ở cuối #1 nên viết lại để đi vào trọng tâm của vấn đề. Trò chơi. nguyên mẫu. khởi động lại = hàm () { cái này. ClearLocalStorage(); . hẹn giờ = setTimeout (cái này. cài lại. liên kết (cái này), 0); . nguyên mẫu. đặt lại = chức năng () { cái này. ClearBoard(); . }; . nguyên mẫu. khởi động lại = hàm () { cái này. ClearLocalStorage(); . hẹn giờ = setTimeout (cái này. rõ ràngBoard. liên kết (cái này), 0); . Bản thân ClearBoard, khi được truyền dưới dạng đối số cho một hàm, sẽ được giải quyết trước khi gọi và khi được gọi có cùng ngữ cảnh như một hàm thông thường, đây là một vấn đề nếu Game. nguyên mẫu. ClearBoard cũng đề cập đến điều này bên trong mã riêng của nó. Sự khác biệt là trong ví dụ như đã viết, việc tắt liên kết sẽ dẫn đến một lỗi đã biết, cửa sổ đó. ClearBoard không phải là một chức năng, trong khi trong ví dụ viết lại của tôi, điều này. ClearBoard có thể không gây ra lỗi mà thay vào đó sẽ tạo và ảnh hưởng đến các biến toàn cục, thay vì các thành viên của thể hiện mà bạn đã trích xuất phương thức từ đó Serge Batishchev Không. May mắn thay, rò rỉ này chỉ áp dụng cho các liên kết vòng DOM-JS (lúc đó được mô hình hóa bằng COM). https. // msdn. Microsoft. com/en-us/library/dd361842%28v=vs. 85%29. aspx?f=255&MSPPError=-2147217396 Serge Batishchev Không. May mắn thay, rò rỉ này chỉ áp dụng cho các liên kết vòng DOM-JS (lúc đó được mô hình hóa bằng COM). https. // msdn. Microsoft. com/en-us/library/dd361842%28v=vs. 85%29. aspx?f=255&MSPPError=-2147217396 brianN2 hy vọng. . ) brianN2 hy vọng. . ) MikeL Giống như những người khác đã nói, các toán tử logic trong Javascript lợi dụng thực tế là JS có khái niệm về giá trị trung thực và giá trị sai để trả về các giá trị thực (vì tất cả chúng đều là trung thực hoặc sai) chứ không phải là một giá trị boolean thực tế. Đó là lý do tại sao nó rất phổ biến để thấy các biểu thức như. . x (phủ định kép) chuyển đổi bất kỳ giá trị nào thành giá trị boolean thực tế. Nó thường được sử dụng bởi vì các nhà phát triển thích các booleans thực sự mặc dù nó hiếm khi cần thiết trong JS MikeL Giống như những người khác đã nói, các toán tử logic trong Javascript lợi dụng thực tế là JS có khái niệm về giá trị trung thực và giá trị sai để trả về các giá trị thực (vì tất cả chúng đều là trung thực hoặc sai) chứ không phải là một giá trị boolean thực tế. Đó là lý do tại sao nó rất phổ biến để thấy các biểu thức như. . x (phủ định kép) chuyển đổi bất kỳ giá trị nào thành giá trị boolean thực tế. Nó thường được sử dụng bởi vì các nhà phát triển thích các booleans thực sự mặc dù nó hiếm khi cần thiết trong JS MikeL Ở #9, tôi nghĩ bạn (gần như) đã bỏ qua vấn đề quan trọng nhất khi chuyển một chuỗi vào hàm setTimeout. Nếu bạn chuyển một hàm, thì hàm đó sẽ được gọi trong phạm vi mà nó được xác định (giống như lệnh gọi setTimeout nếu đó là một hàm ẩn danh như trong ví dụ của bạn) nhưng nếu bạn chuyển một chuỗi thì nó sẽ được phân tích cú pháp thành một hàm và . Bạn gợi ý về vấn đề này với biến msgValue nhưng tôi nghĩ đó là đối số chính chống lại việc truyền thân hàm dưới dạng chuỗi. Làm điều đó thậm chí sẽ không thể thực hiện được nếu msgValue là bất kỳ thứ gì không thể tuần tự hóa MikeL Ở #9, tôi nghĩ bạn (gần như) đã bỏ qua vấn đề quan trọng nhất khi chuyển một chuỗi vào hàm setTimeout. Nếu bạn chuyển một hàm, thì hàm đó sẽ được gọi trong phạm vi mà nó được xác định (giống như lệnh gọi setTimeout nếu đó là một hàm ẩn danh như trong ví dụ của bạn) nhưng nếu bạn chuyển một chuỗi thì nó sẽ được phân tích cú pháp thành một hàm và . Bạn gợi ý về vấn đề này với biến msgValue nhưng tôi nghĩ đó là đối số chính chống lại việc truyền thân hàm dưới dạng chuỗi. Làm điều đó thậm chí sẽ không thể thực hiện được nếu msgValue là bất kỳ thứ gì không thể tuần tự hóa tiếng anh phụ Rất đẹp. Đặc biệt là ở chế độ nghiêm ngặt tiếng anh phụ Rất đẹp. Đặc biệt là ở chế độ nghiêm ngặt Oren Zomer [2,3,10]. sort() đưa ra [10,2,3] do so sánh chuỗi. Có ngôn ngữ lập trình nào khác làm điều đó không? Oren Zomer [2,3,10]. sort() đưa ra [10,2,3] do so sánh chuỗi. Có ngôn ngữ lập trình nào khác làm điều đó không? Micheal Simkin [ 2, 3, 10 ]. sắp xếp ( (a, b) => a - b ) Micheal Simkin [ 2, 3, 10 ]. sắp xếp ( (a, b) => a - b ) Oren Zomer Vâng, tôi biết đây là cách đúng để sắp xếp một mảng số - nhưng đối với các nhà phát triển đã quen với các ngôn ngữ khác như Python, nơi các số được sắp xếp chính xác theo mặc định (và sắp xếp danh sách kiểu hỗn hợp đặt số trước chuỗi), thì không phải vậy Oren Zomer Vâng, tôi biết đây là cách đúng để sắp xếp một mảng số - nhưng đối với các nhà phát triển đã quen với các ngôn ngữ khác như Python, nơi các số được sắp xếp chính xác theo mặc định (và sắp xếp danh sách kiểu hỗn hợp đặt số trước chuỗi), thì không phải vậy Micheal Simkin vâng. tôi cũng ngạc nhiên Micheal Simkin vâng. tôi cũng ngạc nhiên Michel H bài tốt. Thanks Michel H bài tốt. Thanks Jair Humberto Có vẻ như mọi hàm ẩn danh sẽ luôn ở trong ngữ cảnh toàn cầu, không chỉ trong các hàm giống như setTimeout Jair Humberto Có vẻ như mọi hàm ẩn danh sẽ luôn ở trong ngữ cảnh toàn cầu, không chỉ trong các hàm giống như setTimeout Vladimir Vakhromeev Cố gắng sử dụng Số. isNaN() thay vì chỉ isNaN(). https. // nhà phát triển. mozilla. org/en/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN Vladimir Vakhromeev Cố gắng sử dụng Số. isNaN() thay vì chỉ isNaN(). https. // nhà phát triển. mozilla. org/en/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN Dmitri Pavlutin Nice post, thanks. JavaScript becomes more and more popular. At first look it seems simple, but it's an illusion. Anyone looking to pass the mistake #1 (this keyword) can check this article. To pass #4 (equality) can check this one. Dmitri Pavlutin Nice post, thanks. JavaScript becomes more and more popular. At first look it seems simple, but it's an illusion. Anyone looking to pass the mistake #1 (this keyword) can check this article. To pass #4 (equality) can check this one. ramemwe Tôi yêu em. bạn thật tuyệt vời dòng này đã cứu mạng tôi var self = this ; ramemwe Tôi yêu em. bạn thật tuyệt vời dòng này đã cứu mạng tôi var self = this ; Khaled Monsoor chẳng phải đây là thứ mà họ gọi là "tối ưu hóa sớm". ? Khaled Monsoor chẳng phải đây là thứ mà họ gọi là "tối ưu hóa sớm". ? bdiscus Cảm ơn, một năm sau và tôi có thể đồng ý với bạn bdiscus Cảm ơn, một năm sau và tôi có thể đồng ý với bạn Kálmán Kéri Vấn đề ở đây là GC đếm tham chiếu không thể giải phóng các chu kỳ tham chiếu trong khi các trình thu thập sao chép, nén và đánh dấu và quét có thể. Nói chung, nó không liên quan gì đến một ngôn ngữ cụ thể trừ khi thông số kỹ thuật của nó quy định loại GC nào sẽ được sử dụng. Về Javascript, đây là một bài viết làm rõ. https. // nhà phát triển. mozilla. org/en-US/docs/Web/JavaScript/Memory_Management#Garbage_collection Kálmán Kéri Vấn đề ở đây là GC đếm tham chiếu không thể giải phóng các chu kỳ tham chiếu trong khi các trình thu thập sao chép, nén và đánh dấu và quét có thể. Nói chung, nó không liên quan gì đến một ngôn ngữ cụ thể trừ khi thông số kỹ thuật của nó quy định loại GC nào sẽ được sử dụng. Về Javascript, đây là một bài viết làm rõ. https. // nhà phát triển. mozilla. org/en-US/docs/Web/JavaScript/Memory_Management#Garbage_collection chim sẻ Thích bài viết. rất nhiều thông tin cho sinh viên học ngôn ngữ, lỗi này sẽ giúp bạn chỉ huy ngôn ngữ chim sẻ Thích bài viết. rất nhiều thông tin cho sinh viên học ngôn ngữ, lỗi này sẽ giúp bạn chỉ huy ngôn ngữ Anand Siddharth Đó là lý do tại sao Typescript ra đời Anand Siddharth Đó là lý do tại sao Typescript ra đời Deadpool Chúng tôi hiểu rồi. Bạn ghét Javascript. Nhưng có lẽ đó không phải là lỗi của Javascript và bạn chỉ là một nhà phát triển kém? Deadpool Chúng tôi hiểu rồi. Bạn ghét Javascript. Nhưng có lẽ đó không phải là lỗi của Javascript và bạn chỉ là một nhà phát triển kém? Deadpool Tôi không cố tỏ ra ngầu. Javascript có những nhược điểm của nó, nhưng những nhược điểm đó vượt trội so với các đặc quyền và khả năng của nó Deadpool Tôi không cố tỏ ra ngầu. Javascript có những nhược điểm của nó, nhưng những nhược điểm đó vượt trội so với các đặc quyền và khả năng của nó Deadpool Chờ đợi. bạn đang gọi tôi là "thằng ngốc chết tiệt," bởi vì tôi không biết quá trình làm việc của bạn? . Thấy nó lố bịch thế nào không? . Câu trả lời của BẠN khiến bạn trông giống như một tên hề khốn nạn muốn tỏ ra ngầu bằng cách bash Javascript. Thật buồn cười khi bạn đề cập đến PHP, bởi vì Javascript là PHP mới, nơi thật thú vị khi nói về nó, bởi vì nó "là ngôn ngữ tồi tệ nhất. " Hãy tiếp tục và tiếp tục nhảy vào đoàn xe. Nếu bạn ghét Javascript đến vậy, thì tại sao bạn lại sử dụng nó? Deadpool Chờ đợi. bạn đang gọi tôi là "thằng ngốc chết tiệt," bởi vì tôi không biết quá trình làm việc của bạn? . Thấy nó lố bịch thế nào không? . Câu trả lời của BẠN khiến bạn trông giống như một tên hề khốn nạn muốn tỏ ra ngầu bằng cách bash Javascript. Thật buồn cười khi bạn đề cập đến PHP, bởi vì Javascript là PHP mới, nơi thật thú vị khi nói về nó, bởi vì nó "là ngôn ngữ tồi tệ nhất. " Hãy tiếp tục và tiếp tục nhảy vào đoàn xe. Nếu bạn ghét Javascript đến vậy, thì tại sao bạn lại sử dụng nó? Humphrey Pietersen Tôi thấy mình đang sử dụng Array. từ (NodeList). forEach(mục, chỉ mục),. khá thường xuyên những ngày này. Tôi nghĩ nó hoạt động như bạn nói. Tiết kiệm rất nhiều dòng. Tôi không thể tin được mình đã viết rất ít mã như thế nào để đạt được một tabMenu đẹp mắt. Cười lớn Humphrey Pietersen Tôi thấy mình đang sử dụng Array. từ (NodeList). forEach(mục, chỉ mục),. khá thường xuyên những ngày này. Tôi nghĩ nó hoạt động như bạn nói. Tiết kiệm rất nhiều dòng. Tôi không thể tin được mình đã viết rất ít mã như thế nào để đạt được một tabMenu đẹp mắt. Cười lớn John Peter Bài báo tuyệt vời. Người mới bắt đầu cần xem cái này. Tương tự như thế này 7 sai lầm mà mọi nhà phát triển JavaScript nên tránh. (https. //www. mầm non. com/7-sai lầm-mọi-javascript-nhà phát triển-nên-tránh/) John Peter Bài báo tuyệt vời. Người mới bắt đầu cần xem cái này. Tương tự như thế này 7 sai lầm mà mọi nhà phát triển JavaScript nên tránh. (https. //www. mầm non. com/7-sai lầm-mọi-javascript-nhà phát triển-nên-tránh/) Heena Kwag cảm ơn vì bài viết tuyệt vời. Tôi muốn xin phép bạn dịch bài viết này sang tiếng Hàn và xuất bản nó trên một blog do công ty điều hành (https. // ui. nướng. com/) và trên trang wiki Github của chúng tôi (https. //github. com/nhn/fe. jav). Tôi sẽ trích dẫn nguồn gốc và không sử dụng nó để đạt được bất kỳ giá trị tiền tệ nào. Xin vui lòng cho tôi biết những gì bạn nghĩ, và hy vọng bạn có một ngày tuyệt vời. ) Heena Kwag cảm ơn vì bài viết tuyệt vời. Tôi muốn xin phép bạn dịch bài viết này sang tiếng Hàn và xuất bản nó trên một blog do công ty điều hành (https. // ui. nướng. com/) và trên trang wiki Github của chúng tôi (https. //github. com/nhn/fe. jav). Tôi sẽ trích dẫn nguồn gốc và không sử dụng nó để đạt được bất kỳ giá trị tiền tệ nào. Xin vui lòng cho tôi biết những gì bạn nghĩ, và hy vọng bạn có một ngày tuyệt vời. ) Elias Hasle bài viết hay. . -) #5. Tại sao sao chép sâu đoạn đã tạo thay vì chỉ nối thêm nó? . #6 được giải quyết bằng "let" thay vì "var" trên bộ đếm. Không cần đóng cửa Elias Hasle bài viết hay. . -) #5. Tại sao sao chép sâu đoạn đã tạo thay vì chỉ nối thêm nó? . #6 được giải quyết bằng "let" thay vì "var" trên bộ đếm. Không cần đóng cửa Sutapa Mondal bài viết tuyệt vời Sutapa Mondal bài viết tuyệt vời. thực sự rất hữu ích John Weiss Olivia Wilson #3 không gây rò rỉ bộ nhớ, mọi chức năng bên trong sẽ được thu thập bởi GC ông chiến đấu Tôi có thể dịch nó sang tiếng Trung và đăng nó không? rodrigo Ví dụ đầu tiên về rò rỉ bộ nhớ không hoạt động nữa. Để khắc phục, bạn có thể xóa chức năng không sử dụng và chỉ cần thêm bàn điều khiển. đăng nhập vào điều ban đầu trong một số phương pháp. Điều ban đầu là trong quá trình đóng cửa, chắc chắn rồi, nhưng tôi nghĩ trình duyệt đã thông minh hơn và có thể cho bạn biết bạn không sử dụng nó. Ngoài ra, chức năng không sử dụng dường như không liên quan Điều khó học nhất trong JavaScript là gì?Các khái niệm khó hiểu nhất trong JavaScript . đệ quy Phạm vi cẩu kế thừa nguyên mẫu liên kết(), gọi(), áp dụng() giảm() máy phát điện tìm về() Mã phức tạp nhất là gì?Malbolge . Malbolge được phát minh vào năm 1998 bởi Ben Olmstead. Esolang này được coi là ngôn ngữ lập trình phức tạp nhất.
Mức độ nâng cao của JavaScript là gì?Đó là ngôn ngữ kịch bản phía máy khách rất mạnh giúp trang web của bạn sống động và tương tác hơn . Nó là ngôn ngữ lập trình giúp bạn thực hiện một thiết kế phức tạp và đẹp mắt trên các trang web.
Tại sao cú pháp JavaScript lại khó như vậy?JavaScript rất khó học vì nó là ngôn ngữ lập trình không đồng bộ . Nó cũng là một luồng, có nghĩa là nó sử dụng bản chất không đồng bộ của nó theo một cách hoàn toàn khác so với hầu hết các ngôn ngữ lập trình khác. |