Những lợi ích gì để phát triển JavaScript bản địa? [đóng cửa]

Dựa vào việc phát triển jQuery đơn giản hơn bao nhiêu, khi so sánh với JavaScript nguyên gốc, điều gì khiến mọi người bỏ qua các thư viện như jQuery hoàn toàn?

Đây có phải là do jQuery có những hạn chế hay nó chậm? Ý tôi là, nếu jQuery quá dễ so với javascript gốc, lý do nào khiến mọi người vẫn phải sử dụng javascript thuần túy?

Hãy nói về xe hơi.

Đợi đã, chúng ta đã làm rồi - hãy nhớ rằng thời gian chúng ta gặp nhau, một thời gian trước? Chúng tôi đã nói về xe hơi. Trong thực tế, bạn dường như là khá chuyên gia về xe hơi. Bạn đã có thể giải thích chi tiết, tất cả những gì đúng, sai và thú vị về cuộc đua Công thức 1 mới nhất. Bạn biết tất cả các mẫu xe của Lamborghini, bao gồm giá cả và tính sẵn có của chúng. Bạn thậm chí đã có suy nghĩ về việc mua chiếc Ferrari 599 GTB Fiorano của riêng bạn và đang tiết kiệm cho nó (Tôi cá rằng bữa tối bít tết không giúp được gì nhiều).

Trong khi giải thích lỗi của Toyota bằng một giọng nói hào hứng, tuyệt vời, bạn đột nhiên nhảy khỏi ghế và hét lên không trung, vẫy nắm đấm của bạn về: "Chết tiệt tất cả, tôi là một chuyên gia tuyệt vời về tất cả những thứ liên quan đến xe hơi! Tôi ' Tôi sẽ trở thành thợ sửa xe! "

Và vì vậy bạn đã đi. Bạn đã có một cuộc phỏng vấn, Boss Man cũng ấn tượng như tôi với kiến ​​thức của bạn, và bạn được tuyển dụng. Khách hàng đầu tiên bước vào. Ly hợp của anh ta bị hỏng. Bạn đã kiểm tra nó và không biết phải làm gì. Thực tế, bạn hoàn toàn không biết làm thế nào để làm theo lời khuyên mà ông chủ đưa ra cho bạn. Bạn đã bị sa thải.

Nhưng làm thế nào mà có thể được!? Bạn biết tất cả mọi thứ về xe hơi! Ngoại trừ ... mọi thứ về xe hơi. Bạn có thể biết rất rõ chiếc xe mơ ước của mình có động cơ V12, nhưng bạn không biết điều đó thực sự có nghĩa là gì.

Vì vậy, bạn không phải là một thợ sửa xe, thực sự - bạn là một người đam mê xe hơi. Và cho đến khi bạn tìm hiểu làm thế nào xe ô tô hoạt động , bạn sẽ vẫn là một người đam mê.

Bây giờ hãy để tôi hỏi bạn. Làm thế nào để $.fn.textlàm việc? Còn bạn thì $.fnsao? Họ thực sự có ý nghĩa gì? Làm thế nào để $(something)trả lại một thứ khổng lồ chứa đựng những thứ, và chính xác thì đó là gì? Bạn có thể sao chép chức năng của chúng, ít nhất là một chút, trên lý thuyết không? Bạn có thể đối phó mà không có jQuery?

Nói rằng "JavaScript gốc là khó" chỉ là ... sai. Đầu tiên và quan trọng nhất, vì JavaScript là ngôn ngữ không liên quan gì đến DOM , chủ yếu là những gì trừu tượng hóa của jQuery. Thứ hai bởi vì một khi bạn tìm hiểu một chút về DOM, bạn đã có thể vượt qua các lỗi trình duyệt chéo phổ biến nhất. Nhưng chỉ là một bí mật nhỏ - ban đầu mọi thứ đều khó khăn. Phân chia dài là một con chó cái ở lớp 5.

Là một loại suy thứ hai cho câu trả lời này: jQuery là JavaScript DOM (không hoạt Javascript ngôn ngữ, chỉ DOM) như Array.prototype.forEachlà for. Nó hoạt động, cho 99% các trường hợp. Và nó hoạt động tốt. Nhưng với 1% không được bảo hiểm, bạn cần biết cách sử dụng forvòng lặp, nếu chỉ để thực tế. Toàn bộ câu trả lời này dựa trên khía cạnh "tinh khiết" hơn của câu hỏi và thậm chí không phải là khía cạnh kỹ thuật (ví dụ như kích thước của thư viện và một số điều khác như được giải thích trong câu trả lời của Michael Dorrant). Bởi vì tôi yêu thích JavaScript và khi mọi người dường như bỏ nó sang một bên một cách tình cờ nói "pah, những người javascript ngớ ngẩn đó" và vẫy đôi găng tay trắng lạ mắt, nó đi xuống đạo đức.

Nếu bạn có thể chấp nhận sự thật rằng bạn sẽ luôn là người đam mê JavaScript, vậy tôi là ai để ngăn bạn? Nhưng nếu bạn muốn trở thành một lập trình viên JavaScript, trước tiên bạn phải có kiến ​​thức ít nhất là chọn giữa việc sử dụng jQuery (hoặc bất kỳ thư viện nào khác) và không sử dụng thư viện. Tìm hiểu DOM. Tìm hiểu làm thế nào để sử dụng nó. Viết thư viện nhỏ của riêng bạn hoặc chỉ một số bộ sưu tập các hàm trợ giúp. Và một khi bạn đã hiểu biết về DOM và bạn chọn sử dụng jQuery - godspeed. Sự lười biếng được trao cho những người làm việc chăm chỉ.

Những lý do tôi biết:

1. Khi nhu cầu là cực kỳ nhỏ, hãy nói 1 onclick.

2. Khi tốc độ tải xuống rất quan trọng và thư viện jQuery quá lớn VÀ bạn không phải viết nhiều mã (tùy chỉnh) để thay thế.

3. Khi tích hợp với các công nghệ khác, đôi khi js thô là tốt hơn.

4. Khi làm việc trên một hệ thống cũ (còn gọi là 'sản xuất') đã được viết bằng js với các mẫu đã thiết lập.

jQuery chỉ đơn giản là một khung công tác - một tập hợp các công cụ được viết bằng JavaScript. Bằng cách sử dụng bộ công cụ đó, bạn vẫn đang sử dụng JavaScript. Một số người thích viết JavaScript bằng các công cụ jQuery cung cấp, một số người chọn không, người khác chọn các bộ công cụ khác.

Một số lý do bạn có thể muốn viết JavaScript "thuần túy" mà không cần jQuery:

• Các trang tải nhanh hơn mà không bao gồm các tệp jQuery bổ sung
• Một số khung có thể không tương thích với jQuery
• Mã được viết không làm bất cứ điều gì mà jQuery giúp
• Mã này đang được viết cho người khác sử dụng và yêu cầu jQuery làm phụ thuộc sẽ khiến việc chia sẻ trở nên khó khăn hơn
• Tác giả mã muốn kiểm soát nhiều hơn jQuery cung cấp

jQuery, như bất kỳ thư viện hoặc khung công tác nào, thêm một lớp lỗi khác . Tôi thích nó, nhưng tôi cũng đã mất một ngày để tìm kiếm một lỗi xuất hiện trong lõi jQuery chứ không phải mã của tôi (một dịp hiếm hoi, nhưng không phải là hiếm).

Ngoài ra, tôi không tìm thấy bất kỳ lý do nào khác để không sử dụng nó:

• Chi phí tối thiểu, đặc biệt nếu bạn đi với phiên bản Google được lưu trữ ,
• Nó giúp các nhà phát triển Javascript ít kinh nghiệm viết mã sạch hơn và hiệu quả hơn,
• Đó chủ yếu là đa nền tảng, có thể tiết kiệm cuộc sống khi bạn phải đối phó với các trình duyệt cũ hơn,
• Bộ sưu tập lớn các plugin giúp tôi viết các nguyên mẫu trong thời gian rất ngắn,
• DOM có ý nghĩa,
• Vân vân...

NHƯNG nó không bao giờ nên được sử dụng để thay thế kiến ​​thức Javascript. Nếu bạn không biết cách thực hiện bằng Javascript thuần túy, ban đầu bạn có thể thoát khỏi thư viện nhưng về lâu dài bạn sẽ trả tiền cho nó.

Và tất nhiên, có tất cả chúng ta đã bị nhốt trong trận chiến sinh tử với IE6 trong một vài năm, và sẽ không dễ dàng từ bỏ những mánh khóe học đường cũ của chúng ta để ủng hộ một món đồ chơi mới sáng bóng.

Trong môi trường trình duyệt, bạn cần một công cụ chuẩn hóa trình duyệt chéo. Một công cụ như vậy có hai hương vị

• kết thúc các đối tượng máy chủ với các đối tượng mới hoạt động theo cùng một cách trên các trình duyệt
• mở rộng các đối tượng máy chủ để triển khai API DOM.

Nói chung, bạn có thể sử dụng các tiện ích này theo một trong ba cách

• sử dụng các hàm nhỏ như addClasshoặc setTexttrong toàn bộ mã của bạn khi và nơi bạn cần chúng
• viết thư viện chuẩn hóa trình duyệt chéo của riêng bạn
• sử dụng một cái hiện có.

Bạn cần một số cơ chế chuẩn hóa nếu không bạn sẽ nhận được hỗ trợ trình duyệt chéo.

Đối với việc sử dụng một cái hiện có, điều đó là tốt. Tôi sẽ không sử dụng jQuery. Cá nhân tôi hiện đang viết thư viện của riêng mình ( DOM-shim nó sửa các trình duyệt mà không để lộ API propietory nước ngoài. Nó biến trình duyệt của bạn thành một trình duyệt được chuẩn hóa hoạt động tốt).

Nếu bạn không cần trừu tượng hóa DOM, hỗ trợ trình duyệt chéo và trình duyệt cũ - bạn có thể dễ dàng đi mà không cần jQuery.

Đây là trường hợp khi bạn đang phát triển các tiện ích mở rộng trình duyệt, tập lệnh greasemonkey (đôi khi), công cụ xử lý số, phát triển cho Node.js hoặc các môi trường không có trình duyệt khác.

Cùng với các câu trả lời khác ở đây, đặc biệt là của Michael Durrant , tôi sẽ thấy tốc độ là lý do chính khiến tôi thỉnh thoảng chọn sử dụng JavaScript thô.

Gần đây tôi đã làm việc với rất nhiều hình ảnh động hoặc các tác vụ đòi hỏi nhiều CPU khác và đôi khi JavaScript thô còn nhanh hơn nhiều so với khi tôi đi qua jQuery.

Một ví dụ là nơi tôi muốn thay đổi độ mờ đục của một position: fixedyếu tố liên quan đến khoảng cách trên trang mà người dùng đã cuộn xuống. Hiệu ứng quá chậm khi tôi sử dụng jQuery cho việc này, khiến cho việc cuộn bị giật và hiệu ứng mờ dần bị phá hỏng. Tôi đã chuyển sang sử dụng JavaScript thẳng và mọi thứ đều mượt mà trong tất cả trừ IE <= 8.

Tôi cần phải mở đầu câu trả lời của tôi với một số trung thực cởi mở. Tôi yêu jQuery. Nó làm cho cuộc sống của tôi trở nên dễ dàng hơn và làm cho mã JavaScript trở nên khai báo hơn, đó là cách tôi tin rằng mọi thứ nên hoạt động.

jQuery làm được nhiều thứ

Có, bạn có thể thêm plugin
Có, bạn có thể mở rộng bộ chọn
Có nó đơn giản hóa hình ảnh động

nhưng jQuery không làm mọi thứ

Bạn đã bao giờ thử làm việc trong nhiều bối cảnh cửa sổ với jQuery chưa? jQuery rất khó xử lý các bối cảnh cửa sổ khác nhau vì nó giữ nguyên bản gốc windowvà documentbối cảnh từ cửa sổ mà nó được gọi.

Tôi đã viết một số mã ở đây và ở đó để tạo ra các cửa sổ bật lên * và jQuery có thể chỉ đơn giản là theo cách mà tôi đang cố gắng thực hiện. Thêm một tham chiếu mới vào jQuery trong cửa sổ con thường có thể làm mọi thứ tồi tệ hơn bằng cách làm cho khó khăn hơn để biết bối cảnh jQuery nào đang được sử dụng.

_{* nghĩ về cửa sổ bật lên của Gmail để soạn email trong một cửa sổ mới, không phải quảng cáo spam}

Sử dụng nó khi nó làm cho mã đơn giản hơn

Thời gian để sử dụng jQuery là khi bạn có thể làm cho mã của mình đơn giản hơn, ngắn hơn, dễ đọc hơn và nhanh hơn.

Thời gian không sử dụng jQuery là khi nó không làm cho mã của bạn đơn giản hơn, ngắn hơn, dễ đọc hơn hoặc nhanh hơn. Nếu bạn cần tinh chỉnh thời gian tải, bạn có thể không muốn sử dụng jQuery vì chi phí sự kiện.

Như bạn sẽ biết, jQuery là một khung công tác có mục đích chung cung cấp rất nhiều phương thức mà nhiều người trong chúng ta không sử dụng trong các dự án của mình. (Một số trong số chúng tôi chưa từng sử dụng.)

Có hai lý do chính cho việc không sử dụng jQuery hoặc bất kỳ khung công tác được thiết lập tốt nào khác.

1. Dự án không đủ lớn hoặc phức tạp để sử dụng một khung như vậy: Trong trường hợp này, lập trình viên đưa ra quyết định có căn cứ dựa trên kinh nghiệm và kiến ​​thức của mình về JavaScript. Điều này sẽ giúp anh ta giảm trọng lượng trang và cũng kiểm soát nhiều hơn về mã.

2. Lập trình viên phát triển khung riêng của mình Tôi đã thấy một dự án trong công ty của tôi có khung JavaScript riêng. Lý do họ trích dẫn là nếu họ đang sử dụng jQuery và có bất kỳ lỗi nào để khắc phục, họ phải đợi đến phiên bản tiếp theo. Hơn nữa, nếu có một tính năng được thêm vào, họ cần phải hỏi nhóm jQuery về nó hoặc thêm một plugin mặc dù làm cho nó trở thành một plugin sẽ không phải là một ý tưởng hay (họ đã đưa ra ví dụ về việc sử dụng một .livethứ tương tự trong chúng khuôn khổ ngay cả trước khi nó được thêm chính thức vào JQuery). Có khung riêng của bạn cung cấp cho bạn nhiều quyền kiểm soát hơn đối với mã. Nhược điểm là bạn cần phát minh lại bánh xe liên quan đến các vấn đề tương thích trình duyệt, v.v. Ngoài ra, nếu quá trình phát triển không tốt, khung của bạn sẽ phình to và sẽ chỉ tăng thời gian để duy trì nó.

Mike

Tôi nghĩ mọi người chống lại việc sử dụng một số thư viện là do phụ thuộc vào giải pháp cơ sở hạ tầng / thư viện đó để thực hiện một số nhiệm vụ.

Nhưng hãy cẩn thận để nhớ các ngôn ngữ đến và đi như các thư viện trong thời gian dài.

Vì vậy, có lẽ đó là phạm vi thời gian. Có thể mọi người ngần ngại đầu tư vào một thư viện mà có lẽ không có ở đó - hoặc có nhiều động lực đằng sau nó trong thời gian dài.

Riêng tôi? Tôi không phản đối việc sử dụng JQuery nói riêng. Tôi cũng nhìn vào Box2d.js hoặc ba.js và thà chấp nhận chúng ngay cả khi thời hạn sử dụng ngắn hạn hơn là bỏ lỡ những loại trái cây mà chúng phải cung cấp.

Điểm mấu chốt của Mike là có rủi ro trong thời hạn sử dụng của thư viện bạn chọn và tôi nghĩ rằng một số người trong cộng đồng javascript có thể đã bị mất do thư viện hoặc dự án sắp kết thúc và có thể vừa nói - không bao giờ nói lại.

Tôi muốn nói rằng vấn đề chính là ngày càng nhiều người (đại đa số?) Không biết cách viết mã bằng JavaScript nữa. Nếu jQuery không thể làm gì đó, họ không thể làm điều đó.

Đã đến lúc các ví dụ javascript đơn giản trở nên khó thực hiện. Không có gì chống lại jQuery; đó là một khuôn khổ tuyệt vời Tôi đã có rất nhiều ý tưởng hay từ nó, nhưng mọi người nên học JavaScript trước và sau đó học một khung. Cá nhân tôi thấy khuôn khổ của mình linh hoạt hơn và phù hợp hơn với nhu cầu của mình, và vâng, đôi khi tôi phát minh lại bánh xe nhưng toàn quyền kiểm soát và kiểm soát các sửa lỗi là một lợi ích rất lớn cho phép bạn sẵn sàng đưa công việc vào học JavaScript.

Không chỉ vậy. Biết JavaScript vanilla làm cho nó thú vị hơn rất nhiều khi chơi và thử nghiệm các tính năng mới hơn thay vì chờ đợi triển khai dựa trên khung. Ngoài ra, tôi không đổ lỗi cho jQuery vì đây chủ yếu là một thư viện DOM , nhưng nó có thể gây khó khăn khi mở rộng quy mô với các dự án lớn. Các khung khác làm tốt hơn công việc này; Nguyên mẫu đến với tâm trí.

Nói tóm lại, đó là một khuôn khổ tuyệt vời, nhưng không phải là tất cả mọi người cuối cùng làm cho nó trở thành.

Tôi có thể thêm hai lý do nữa không được đề cập:

1. Khi tôi chọn công nghệ hoàn toàn mới, rất nhiều lần, tôi sẽ bắt đầu với các công trình cấp thấp hơn trước khi chuyển sang công nghệ cấp cao hơn. Tôi chủ yếu là nhà phát triển C ++ / C #, nhưng trước đây khi tôi mới bắt đầu chơi với HTML / CSS / JavaScript, tôi đã chọn không sử dụng bất kỳ khuôn khổ nào vì trước tiên tôi muốn hiểu về công nghệ (đó là JavaScript chính ngôn ngữ) mà các khung đó được xây dựng trên đầu trang.

   • Phải nói rằng, tôi đã phát hiện ra jQuery và sẽ không bao giờ muốn quay lại mã hóa bằng tay những gì jQuery có thể làm cho bạn trong 1-2 dòng mã.

2. Tôi không biết mức độ phổ biến của nó, nhưng đối với tôi, dường như có rất nhiều người khi họ nhìn thấy khung / công nghệ / ngôn ngữ tiếp theo, phản hồi đầu tiên của họ là "không phải là một API khác để tôi học!" Họ không quan tâm đến việc jQuery dễ dàng như thế nào, nhưng họ chỉ đơn giản xem nó như đang cản trở họ và phân phối công việc bằng cách sử dụng các phương thức "đúng và thử" của họ. Đây là cùng loại người từ chối sử dụng thư viện Boost hoặc bất kỳ STL nào và tiếp tục sử dụng malloc cho mọi thứ. Bạn đã hỏi tại sao họ chọn JavaScript thuần trên jQuery và trong thực tế, họ không bao giờ chọn vì hầu hết thời gian họ từ chối đánh giá jQuery ngay từ đầu và hoàn toàn hài lòng với tốc độ phát triển hiện tại của họ, bất kể nó chậm như thế nào.

jQuery là một thư viện được viết bằng và cho JavaScript. Ý tưởng là nó làm cho tất cả những điều JavaScript khó khăn / tẻ nhạt trở nên đơn giản, do đó tăng tốc thời gian phát triển và làm cho các tập lệnh của bạn có nhiều khả năng hoạt động trên nhiều trình duyệt.

Điều gì làm cho jQuery thích hợp hơn để sử dụng:

• Nhanh
• Thư viện JavaScript nhẹ
• CSS 3Tuân thủ
• Hỗ trợ nhiều trình duyệt.
• Khung công tác jQuery có thể mở rộng và xử lý các thao tác DOM, CSS, Ajax , các sự kiện và hình ảnh động.

JavaScript là một ngôn ngữ trong khi jQuery là một thư viện được viết bằng JavaScript.

Dưới đây là những lý do khiến JavaScript thích hợp hơn để sử dụng thay vì jQuery:

1. Nó tải toàn bộ thư viện tập lệnh jQuery mỗi lần với trang. Đó là nhược điểm của trang web xử lý truy vấn nhanh / nhanh.
2. Đôi khi khung công tác jQuery sụp đổ / xung đột với các khung công tác khác.
3. Nếu bạn đang viết mã đơn giản để chỉ chọn một phần tử và hiển thị các thay đổi thì JavaScript gốc sẽ tốt hơn nhiều.
4. Nếu các hoạt động nhỏ và được thực hiện trong một vài dòng mã JavaScript thì sử dụng jQuery là không tốt.

Do những lý do này, tôi thích sử dụng JavaScript để tránh khung công tác jQuery. Sẽ tốt hơn nhiều nếu học JavaScript thay vì phụ thuộc vào một thư viện như vậy ...

Ngay cả khi bạn muốn mở rộng chúng, bạn cần viết mã bằng JavaScript. Đó cũng là một cuộc nói chuyện lớn. Các nhà phát triển phụ thuộc vào các thư viện này, vì vậy để có quyền kiểm soát các dự án, JavaScript tốt hơn là sử dụng các khung công tác.

Tôi nghĩ mọi người sử dụng jQuery vì nó đơn giản hơn, dễ dàng hơn và mạnh mẽ hơn và vì nó giúp họ quên đi IE. Ngoài ra, đối với các chức năng tùy chỉnh, mọi người sử dụng javascript. Hãy thử tham khảo DOC để biết thêm chi tiết