Khi nào nên sử dụng Vanilla JavaScript so với jQuery?


238

Tôi đã nhận thấy trong khi theo dõi / cố gắng trả lời các câu hỏi phổ biến của jQuery, rằng có một số thực tiễn nhất định sử dụng javascript, thay vì jQuery, thực sự cho phép bạn viết ít hơn và làm ... cùng một số tiền. Và cũng có thể mang lại lợi ích hiệu suất.

Một ví dụ cụ thể

$(this) đấu với this

Bên trong một sự kiện nhấp tham chiếu id đối tượng được nhấp

jQuery

$(this).attr("id");

Javascript

this.id;

Có bất kỳ thực hành phổ biến khác như thế này? Khi một số thao tác Javascript nhất định có thể được thực hiện dễ dàng hơn mà không cần đưa jQuery vào hỗn hợp. Hay đây là một trường hợp hiếm gặp? (của một "phím tắt" jQuery thực sự cần nhiều mã hơn)

EDIT: Mặc dù tôi đánh giá cao các câu trả lời liên quan đến jQuery so với hiệu suất javascript đơn giản, tôi thực sự đang tìm kiếm các câu trả lời định lượng hơn nhiều. Trong khi sử dụng jQuery , các trường hợp thực sự sẽ tốt hơn (khả năng đọc / nén) để sử dụng javascript đơn giản thay vì sử dụng $(). Ngoài ví dụ tôi đã đưa ra trong câu hỏi ban đầu của mình.


Tôi không chắc là tôi hiểu câu hỏi. Bạn có đang tìm kiếm ý kiến ​​về giá trị của việc sử dụng mã thư viện hoặc bạn đang tìm kiếm các kỹ thuật tương thích với trình duyệt không phải là jQuery tương tự this.id?
dùng113716

1
Từ các câu trả lời, có vẻ như mọi người đều coi câu hỏi này là triết học, vì tôi dự định nó sẽ rất định lượng, vì gần như tổng hợp một danh sách các trường hợp như trường hợp tôi đã nêu ra là các thực tiễn (mal) phổ biến.
jondavidjohn


Câu trả lời:


207
  • this.id (như bạn đã biết)
  • this.value(trên hầu hết các loại đầu vào. chỉ các vấn đề tôi biết là IE khi <select>không có valuethuộc tính được đặt trên các <option>thành phần của nó hoặc đầu vào radio trong Safari.)
  • this.className để có được hoặc thiết lập toàn bộ thuộc tính "lớp"
  • this.selectedIndexdựa vào a <select>để lấy chỉ mục đã chọn
  • this.optionschống lại một <select>để có được một danh sách các <option>yếu tố
  • this.textchống lại <option>để có được nội dung văn bản của nó
  • this.rowschống lại một <table>để có được một bộ sưu tập các <tr>yếu tố
  • this.cellschống lại a <tr>để có được các tế bào của nó (td & th)
  • this.parentNode để có được cha mẹ trực tiếp
  • this.checkedđể nhận trạng thái đã kiểm tra của checkbox Cảm ơn @Tim Down
  • this.selectedđể nhận trạng thái đã chọn của option Cảm ơn @Tim Down
  • this.disabledđể có được trạng thái bị vô hiệu hóa của input Cảm ơn @Tim Down
  • this.readOnlyđể có được trạng thái readOnly của một lời input cảm ơn @Tim Down
  • this.hrefchống lại một <a>yếu tố để có được nóhref
  • this.hostnamechống lại một <a>yếu tố để có được miền của nóhref
  • this.pathnamechống lại một <a>yếu tố để có được con đường của nóhref
  • this.searchdựa vào một <a>phần tử để có được chuỗi truy vấn của nóhref
  • this.src chống lại một yếu tố hợp lệ để có một src

...Tôi nghĩ rằng bạn có được ý tưởng.

Sẽ có lúc hiệu suất là rất quan trọng. Giống như nếu bạn đang thực hiện một cái gì đó trong một vòng lặp nhiều lần, bạn có thể muốn bỏ jQuery.

Nói chung, bạn có thể thay thế:

$(el).attr('someName');

với:

Ở trên là từ kém. getAttributekhông phải là sự thay thế, nhưng nó lấy ra giá trị của một thuộc tính được gửi từ máy chủ và tương ứng của nó setAttributesẽ đặt nó. Cần thiết trong một số trường hợp.

Các câu dưới đây sắp xếp nó. Xem câu trả lời này để điều trị tốt hơn.

el.getAttribute('someName');

... để truy cập một thuộc tính trực tiếp. Lưu ý rằng các thuộc tính không giống như các thuộc tính (mặc dù đôi khi chúng phản chiếu lẫn nhau). Tất nhiên là có setAttribute.

Giả sử bạn có một tình huống nhận được một trang nơi bạn cần mở ra tất cả các thẻ thuộc một loại nhất định. Nó ngắn và dễ dàng với jQuery:

$('span').unwrap();  // unwrap all span elements

Nhưng nếu có nhiều, bạn có thể muốn thực hiện một API DOM gốc:

var spans = document.getElementsByTagName('span');

while( spans[0] ) {
    var parent = spans[0].parentNode;
    while( spans[0].firstChild ) {
        parent.insertBefore( spans[0].firstChild, spans[0]);
    }
    parent.removeChild( spans[0] );
}

Mã này khá ngắn, nó hoạt động tốt hơn phiên bản jQuery và có thể dễ dàng được tạo thành một chức năng có thể sử dụng lại trong thư viện cá nhân của bạn.

Có vẻ như tôi có một vòng lặp vô hạn với bên ngoài whilewhile(spans[0]), nhưng vì chúng ta đang xử lý một "danh sách trực tiếp" nên nó được cập nhật khi chúng ta thực hiện parent.removeChild(span[0]);. Đây là một tính năng khá tiện lợi mà chúng ta bỏ lỡ khi làm việc với một Array (hoặc đối tượng giống như Array) thay vào đó.


2
thật tuyệt ... vì vậy, chủ yếu nó xoay quanh từ khóa này không ngừng được gói vào một đối tượng jQuery.
jondavidjohn

1
@jondavidjohn: Vâng, có một số bản sửa lỗi rất hay trong một số trường hợp, như this.valuekhi có một vài quirks trình duyệt trong một số trường hợp nhất định. Tất cả phụ thuộc vào nhu cầu của bạn. Có nhiều kỹ thuật hay, dễ dàng mà không cần jQuery, đặc biệt là khi hiệu năng là rất quan trọng. Tôi sẽ cố gắng nghĩ về nhiều hơn.
dùng113716

3
Tôi đã định viết một câu trả lời nhưng thay vào đó tôi sẽ thêm các đề xuất cho bạn. Nói chung, attr()được sử dụng quá mức. Nếu bạn chỉ giao dịch với một yếu tố thì bạn sẽ hiếm khi cần attr(). Hai trong số các mục yêu thích của tôi là sự nhầm lẫn xung quanh thuộc checkedtính của các hộp kiểm (tất cả các loại câu thần chú bí ẩn xung quanh đó : $(this).attr("checked", "checked"), $(this).is(":checked")v.v.) và tương tự là thuộc selectedtính của <option>các yếu tố.
Tim Down

1
Aaargh, @patrick, noooo: bạn đã đề xuất getAttribute(). Bạn gần như không bao giờ cần nó : nó bị hỏng trong IE, không phải lúc nào cũng phản ánh trạng thái hiện tại và dù sao nó cũng không phải là thứ jQuery làm. Chỉ cần sử dụng tài sản. stackoverflow.com/questions/4456231/ Mạnh
Tim Down

1
Tôi đã sử dụng JS rất lâu và tôi không biết về className, thx.
IAd CHƯƠNG

60

Câu trả lời đúng là bạn sẽ luôn phải chịu một hình phạt hiệu năng khi sử dụng jQuery thay vì JavaScript nguyên gốc 'đơn giản'. Đó là bởi vì jQuery là một Thư viện JavaScript. Nó không phải là một phiên bản JavaScript mới lạ mắt.

Lý do khiến jQuery mạnh mẽ là vì nó tạo ra một số thứ quá tẻ nhạt trong tình huống trình duyệt chéo (AJAX là một trong những ví dụ tốt nhất) và giải quyết sự mâu thuẫn giữa vô số trình duyệt có sẵn và cung cấp API nhất quán. Nó cũng dễ dàng tạo điều kiện cho các khái niệm như chuỗi, lặp lại ngụ ý, vv, để đơn giản hóa làm việc trên các nhóm yếu tố với nhau.

Học jQuery không thay thế cho việc học JavaScript. Bạn nên có một cơ sở vững chắc ở cái sau để bạn hoàn toàn đánh giá cao những gì biết về cái trước sẽ giúp bạn dễ dàng hơn.

- Chỉnh sửa để bao gồm các ý kiến ​​-

Vì các ý kiến ​​nhanh chóng chỉ ra (và tôi đồng ý với 100%), các tuyên bố trên đề cập đến mã điểm chuẩn. Giải pháp JavaScript 'bản địa' (giả sử nó được viết tốt) sẽ vượt trội hơn một giải pháp jQuery hoàn thành điều tương tự trong gần như mọi trường hợp (tôi rất muốn xem một ví dụ khác). jQuery tăng tốc thời gian phát triển, đó là một lợi ích đáng kể mà tôi không có ý định hạ thấp. Nó tạo điều kiện dễ đọc, dễ theo dõi mã, nhiều hơn một số nhà phát triển có khả năng tự tạo.

Theo tôi thì câu trả lời phụ thuộc vào những gì bạn đang cố gắng đạt được. Nếu, như tôi đoán dựa trên tham chiếu của bạn về lợi ích hiệu suất, bạn sẽ đạt được tốc độ tốt nhất có thể ra khỏi ứng dụng của mình, sau đó sử dụng jQuery giới thiệu chi phí mỗi khi bạn gọi $(). Nếu bạn đang tìm kiếm tính dễ đọc, tính nhất quán, khả năng tương thích trình duyệt, v.v., thì chắc chắn có những lý do để ưu tiên jQuery hơn JavaScript 'bản địa'.


8
Tôi rất muốn xem một ví dụ về tình huống mà jQuery có thể vượt trội hơn so với việc triển khai trong JS thuần túy. Bất kể bạn làm gì, nếu bạn đang sử dụng jQuery (hoặc bất kỳ thư viện nào khác cho vấn đề đó), bạn có chức năng không thể tránh khỏi. Không có cách nào để thoát khỏi (mặc dù) chi phí nhỏ được tạo ra từ cuộc gọi $(). Nếu bạn không thực hiện cuộc gọi đó, bạn sẽ tiết kiệm thời gian.
gddc

16
Một giải pháp tự làm bằng văn bản kém có lẽ sẽ chậm hơn. Nhóm jQuery đã thực thi một số JavaScript hiệu quả cao trong gói. Xem câu trả lời của @ Freelancer's.
Stephen

3
Một giải pháp được viết kém sẽ luôn là một giải pháp được viết kém và đó không phải là lỗi của ngôn ngữ. Nó không thay đổi thực tế rằng thư viện sẽ phải chịu chi phí mà chức năng 'bản địa' có thể tránh được nếu được suy nghĩ kỹ.
gddc

11
@gddc Tôi nghĩ rằng ví dụ tốt nhất trong đó jQuery "vượt trội" (đọc bên ngoài hộp điểm chuẩn) JS thuần túy đang giảm thời gian phát triển (đó là một giá trị kinh doanh lớn) và thử nghiệm đơn giản hóa
Ben

13
Tất cả những gì bạn đã viết là đúng, nhưng bạn đã bỏ qua những gì @Ben ghi chú ở trên. jQuery làm cho nhà phát triển nhanh hơn và mạnh mẽ hơn. Xem triển khai KillClass () này mà tôi đã viết nhiều năm trước và được sử dụng rất nhiều. Bạn biết gì? Nó bị hỏng cho các trường hợp cạnh nhất định. Mã kém là mã kém và mã sai là mã sai, nhưng sử dụng jQuery thường làm cho nhà phát triển viết mã tốt hơn và đúng hơn. Hầu hết thời gian, máy tính là đủ nhanh; đó là những nhà phát triển cần sự giúp đỡ.
Phrogz

38

Có một khung gọi là ... oh đoán xem? Vanilla JS. Hy vọng bạn sẽ có được trò đùa ...: D Nó hy sinh mức độ dễ đọc của mã cho hiệu suất ... So sánh nó với jQuerydưới đây bạn có thể thấy rằng việc truy xuất một DOMphần tử nhanh hơn IDgần 35 lần. :)

Vì vậy, nếu bạn muốn hiệu suất, bạn nên thử Vanilla JS và rút ra kết luận của riêng mình. Có thể bạn sẽ không gặp phải JavaScript khi treo GUI của trình duyệt / khóa luồng UI trong mã chuyên sâu như trong forvòng lặp.

Vanilla JS là một khung công tác đa nền tảng nhanh, nhẹ, để xây dựng các ứng dụng JavaScript mạnh mẽ, đáng kinh ngạc.

Trên trang chủ của họ có một số so sánh hoàn hảo:

nhập mô tả hình ảnh ở đây


1
@Leniel Macaferi Oh Man tôi thích câu trả lời này! Tôi đã không nhận ra rằng hiệu suất giữa vanilla và các khung khác có thể tạo ra sự khác biệt như vậy! Dù sao Hội trường của sự nổi tiếng cho câu trả lời này !! PS: Bạn cũng đã làm cho trang web?
Steve

17

Đã có câu trả lời được chấp nhận nhưng tôi tin rằng không có câu trả lời nào được nhập trực tiếp ở đây có thể là toàn diện trong danh sách các phương thức / thuộc tính javascript gốc của nó thực sự được đảm bảo hỗ trợ trình duyệt chéo. Vì điều đó tôi có thể chuyển hướng bạn đến quirksmode:

http://www.quirksmode.org/compabilities.html

Nó có lẽ là danh sách toàn diện nhất về những gì hoạt động và những gì không hoạt động trên trình duyệt nào ở bất cứ đâu. Đặc biệt chú ý đến phần DOM. Nó là rất nhiều để đọc nhưng vấn đề không phải là đọc tất cả mà là sử dụng nó như một tài liệu tham khảo.

Khi tôi bắt đầu nghiêm túc viết các ứng dụng web, tôi đã in ra tất cả các bảng DOM và treo chúng lên tường để tôi biết trong nháy mắt những gì an toàn để sử dụng và những gì cần phải hack. Những ngày này tôi chỉ cần google một cái gì đó nhưquirksmode parentNode compatibility khi tôi có nghi ngờ.

Giống như bất cứ điều gì khác, đánh giá chủ yếu là một vấn đề kinh nghiệm. Tôi thực sự không khuyên bạn nên đọc toàn bộ trang web và ghi nhớ tất cả các vấn đề để tìm ra khi nào nên sử dụng jQuery và khi nào nên sử dụng JS đơn giản. Chỉ cần nhận thức được danh sách. Nó đủ dễ để tìm kiếm. Theo thời gian, bạn sẽ phát triển một bản năng khi thích hợp với JS.


PS: PPK (tác giả của trang web) cũng có một cuốn sách rất hay mà tôi khuyên bạn nên đọc


14

Khi nào:

  1. bạn biết rằng có hỗ trợ đa trình duyệt cho những gì bạn đang làm và
  2. Nó không phải là nhiều mã hơn để gõ, và
  3. nó không đáng kể để đọc và
  4. bạn hoàn toàn tin tưởng rằng jQuery sẽ không chọn các triển khai khác nhau dựa trên trình duyệt để đạt được hiệu suất tốt hơn, sau đó:

sử dụng JavaScript. Nếu không thì sử dụng jQuery (nếu bạn có thể).

Chỉnh sửa : Câu trả lời này áp dụng cả khi chọn sử dụng jQuery tổng thể so với bỏ nó, cũng như chọn có sử dụng vanilla JS trong jQuery hay không. Lựa chọn giữa attr('id').iddựa vào lợi ích của JS, trong khi lựa chọn giữa removeClass('foo')so với .className = .className.replace( new Regexp("(?:^|\\s+)"+foo+"(?:\\s+|$)",'g'), '' )nghiêng về jQuery.


3
Tôi nghĩ rằng OP dự định sử dụng jQuery, nhưng tự hỏi nên sử dụng JavaScript nguyên gốc ở đâu và khi nào trong các phương thức jQuery của mình.
Stephen

.classList.remove('foo')dường như hoạt động tốt trong các trình duyệt mới hơn
Tyilo

3
@Tyilo classList.remove là một phần của API ClassList HTML5 không được triển khai trong IE9, ví dụ: caniuse.com/#feat=
classlist

13

Câu trả lời của người khác đã tập trung vào câu hỏi chung về "jQuery so với JS đơn giản". Đánh giá từ OP của bạn, tôi nghĩ rằng bạn chỉ đơn giản là tự hỏi khi nào nên sử dụng vanilla JS nếu bạn đã chọn sử dụng jQuery. Ví dụ của bạn là một ví dụ hoàn hảo về thời điểm bạn nên sử dụng vanilla JS:

$(this).attr('id');

Là cả chậm hơn và (theo tôi) ít đọc hơn:

this.id.

Nó chậm hơn vì bạn phải quay một đối tượng JS mới chỉ để truy xuất thuộc tính theo cách của jQuery. Bây giờ, nếu bạn đang sử dụng $(this)để thực hiện các hoạt động khác, thì bằng mọi cách, hãy lưu trữ đối tượng jQuery đó trong một biến và hoạt động với điều đó. Tuy nhiên, tôi đã gặp phải nhiều tình huống khi tôi chỉ cần một thuộc tính từ phần tử (như idhoặc src).

Có bất kỳ thực hành phổ biến khác như thế này? Khi một số thao tác Javascript nhất định có thể được thực hiện dễ dàng hơn mà không cần đưa jQuery vào hỗn hợp. Hay đây là một trường hợp hiếm gặp? (của một "phím tắt" jQuery thực sự cần nhiều mã hơn)

Tôi nghĩ rằng trường hợp phổ biến nhất là trường hợp bạn mô tả trong bài viết của bạn; mọi người gói $(this)trong một đối tượng jQuery không cần thiết. Tôi thấy điều này thường xuyên nhất với idvalue(thay vì sử dụng$(this).val() ).

Chỉnh sửa: Đây là một bài viết giải thích tại sao sử dụng jQuery trong attr()trường hợp chậm hơn. Thú nhận: đã đánh cắp nó từ wiki thẻ, nhưng tôi nghĩ rằng nó đáng được đề cập cho câu hỏi.

Chỉnh sửa lại: Với ý nghĩa về khả năng đọc / hiệu suất của việc chỉ truy cập trực tiếp các thuộc tính, tôi có thể nói rằng một quy tắc tốt có lẽ là cố gắng sử dụng this.<attributename>khi có thể. Có thể có một số trường hợp điều này không hoạt động vì sự không nhất quán của trình duyệt, nhưng có lẽ tốt hơn nên thử điều này trước và quay lại với jQuery nếu nó không hoạt động.


hah, cảm ơn vì đã đọc câu hỏi;) ... vậy đây có phải là ngoại lệ rộng hơn không?
jondavidjohn

@jondavidjohn: Thành thật mà nói, tôi rất do dự khi thực hiện cuộc gọi đó. Tôi nghĩ là có, thường là lợi thế của bạn khi sử dụng jQuery do những lo ngại về trình duyệt chéo. Có những ví dụ khác, như this.style.display = 'none'. Như vậy có tốt hơn $(this).hide()không? Tôi cho rằng cái sau dễ đọc hơn, nhưng cái trước có khả năng nhanh hơn. Sẽ không hại gì khi tự mình thử nghiệm để xem liệu một số hành động nhất định sẽ hoạt động trên các trình duyệt mà không có jQuery - Đây thường là những gì tôi làm trước khi gói một phần tử trong đối tượng jQuery để thực hiện thao tác.
Andrew Whitaker

10

Nếu bạn chủ yếu quan tâm đến hiệu suất, ví dụ chính của bạn đánh vào đầu đinh. Gọi jQuery một cách không cần thiết hoặc dư thừa là, IMHO, nguyên nhân chính thứ hai của hiệu năng chậm (đầu tiên là truyền tải DOM kém).

Đây thực sự không phải là một ví dụ về những gì bạn đang tìm kiếm, nhưng tôi thấy điều này thường xuyên đến mức nó đề cập đến: Một trong những cách tốt nhất để tăng tốc hiệu suất của các tập lệnh jQuery của bạn là lưu trữ các đối tượng jQuery và / hoặc sử dụng chuỗi:

// poor
$(this).animate({'opacity':'0'}, function() { $(this).remove(); });

// excellent
var element = $(this);
element.animate({'opacity':'0'}, function() { element.remove(); });

// poor
$('.something').load('url');
$('.something').show();

// excellent
var something = $('#container').children('p.something');
something.load('url').show();

thật thú vị ... sự tách biệt giữa khởi tạo var và hành động này có thực sự dẫn đến tăng hiệu suất xử lý không? hoặc chỉ cho phép hành động tự thực hiện (làm cho nó ít bị vướng hơn tôi đoán ...)
jondavidjohn

1
Nó chắc chắn dẫn đến tăng hiệu suất, nhưng chỉ khi bạn sử dụng lại yếu tố được chọn. Vì vậy, trong trường hợp cuối cùng var something, tôi không thực sự cần phải lưu trữ đối tượng jQuery (vì tôi đã sử dụng chuỗi), nhưng dù sao tôi cũng làm điều đó theo thói quen.
Stephen

2
Mặt khác, lấy ví dụ tương tự. Gọi $('.something')hai lần có nghĩa là jQuery phải duyệt qua DOM hai lần để tìm tất cả các phần tử với bộ chọn đó.
Stephen

2
Trong trường hợp ví dụ đầu tiên, bộ nhớ đệm $(this)giảm các cuộc gọi đến hàm jQuery. Điều này sẽ cung cấp cho bạn mức tăng nhiều nhất trong một kịch bản vòng lặp.
Stephen

2
@Alnitak Thông báo đó elementbằng $(this). Điều đó không chứa nhiều yếu tố.
Stephen

8

Tôi đã tìm thấy có sự trùng lặp giữa JS và JQ. Mã bạn đã hiển thị là một ví dụ tốt về điều đó. Thành thật mà nói, lý do tốt nhất để sử dụng JQ trên JS chỉ đơn giản là khả năng tương thích trình duyệt. Tôi luôn nghiêng về JQ, ngay cả khi tôi có thể hoàn thành điều gì đó trong JS.


8
Sẽ là một điều kỳ diệu nếu không có sự trùng lặp nào, bởi vì JQuery là JavaScript.
simon

6

Đây là quan điểm cá nhân của tôi, nhưng vì jQuery dù sao cũng là JavaScript, tôi nghĩ về mặt lý thuyết nó không thể hoạt động tốt hơn vanilla JS bao giờ.

Nhưng thực tế nó có thể hoạt động tốt hơn so với JS viết tay, vì mã viết tay của một người có thể không hiệu quả như jQuery.

Điểm mấu chốt - đối với những thứ nhỏ hơn tôi có xu hướng sử dụng vanilla JS, cho các dự án chuyên sâu về JS tôi thích sử dụng jQuery và không phát minh lại bánh xe - nó cũng hiệu quả hơn.


1
Có rất nhiều ví dụ trong đó các thư viện vượt trội hơn vanilla JS. Nhiều phương thức nguyên mẫu tích hợp của JS được viết xấu, hóa ra.
Học thống kê bằng ví dụ

3

Danh sách thuộc tính trực tiếp của câu trả lời đầu tiên của this là một phần tử DOM khá đầy đủ.

Bạn có thể thấy cũng thú vị để biết một số người khác.

Khi đây là tài liệu:

  • this.formsđể có được một HTMLCollectiontrong các mẫu tài liệu hiện tại,
  • this.anchorsđể có được một HTMLCollectioncủa tất cả các HTMLAnchorElementsbằng nameđược thiết lập,
  • this.linksđể có được một HTMLCollectiontrong tất cả các HTMLAnchorElements hrefđược thiết lập,
  • this.imagesđể có được một HTMLCollectioncủa tất cả các HTMLImageElements
  • và tương tự với các applet không dùng nữa this.applets

Khi bạn làm việc với document.forms, document.forms[formNameOrId]có được hình thức được đặt tên hoặc xác định.

Khi đây là một hình thức:

  • this[inputNameOrId] để có được trường được đặt tên hoặc được xác định

Khi đây là trường mẫu:

  • this.type để có được loại trường

Khi tìm hiểu các bộ chọn jQuery, chúng ta thường bỏ qua việc học các thuộc tính thành phần HTML hiện có, rất nhanh để truy cập.


Các thuộc tính bạn đã đề cập được xác định trong đặc tả HTML Cấp độ 2 của DOM và được hỗ trợ rộng rãi. document.embedsdocument.pluginscũng được hỗ trợ rộng rãi (DOM 0). document.scriptscũng là một bộ sưu tập tiện lợi, được xác định trong đặc tả HTML5 và được hỗ trợ rộng rãi (và Firefox 9+ ).
Rob W

@Robw Vì vậy, danh sách bây giờ có thể đầy đủ, và chắc chắn hữu ích và nhanh chóng. Cảm ơn;)
lib3d

2

Như thường lệ, tôi đến muộn bữa tiệc này.

Đó không phải là chức năng bổ sung khiến tôi quyết định sử dụng jQuery, hấp dẫn như vậy. Sau tất cả, không có gì ngăn cản bạn viết các chức năng của riêng bạn.

Có một thực tế là có rất nhiều thủ thuật cần tìm hiểu khi sửa đổi DOM để tránh rò rỉ bộ nhớ (Tôi đang nói về bạn IE). Để có một tài nguyên trung tâm quản lý tất cả các loại vấn đề đó cho tôi, được viết bởi những người là những người lập trình mã hóa tốt hơn rất nhiều so với tôi, đó là liên tục được xem xét, sửa đổi và kiểm tra là do thần gửi.

Tôi đoán loại này rơi vào đối số hỗ trợ / trừu tượng hóa trình duyệt chéo.

Và dĩ nhiên jQuery không loại trừ việc sử dụng JS thẳng khi bạn cần. Tôi luôn cảm thấy hai người dường như làm việc liền mạch với nhau.

Tất nhiên, nếu trình duyệt của bạn không được jQuery hỗ trợ hoặc bạn đang hỗ trợ môi trường cấp thấp (điện thoại cũ hơn?) Thì một tệp .js lớn có thể là một vấn đề. Hãy nhớ khi jQuery từng là nhỏ?

Nhưng thông thường sự khác biệt hiệu suất không phải là một vấn đề quan tâm. Nó chỉ phải đủ nhanh. Với các chu kỳ CPU của Gigahertz sẽ lãng phí mỗi giây, tôi quan tâm nhiều hơn đến hiệu suất của các lập trình viên của mình, tài nguyên phát triển duy nhất không tăng gấp đôi công suất cứ sau 18 tháng.

Điều đó nói rằng tôi hiện đang xem xét các vấn đề về khả năng truy cập và rõ ràng .innerHTML là một điều không nên với điều đó. jQuery tất nhiên phụ thuộc vào .innerHTML, vì vậy bây giờ tôi đang tìm kiếm một khung công tác sẽ phụ thuộc vào các phương thức hơi tẻ nhạt được cho phép. Và tôi có thể tưởng tượng một khung công tác như vậy sẽ chạy chậm hơn jQuery, nhưng miễn là nó hoạt động đủ tốt, tôi sẽ rất vui.


2

Đây là một câu trả lời phi kỹ thuật - nhiều công việc có thể không cho phép một số thư viện nhất định, chẳng hạn như jQuery.

Trên thực tế, trên thực tế, Google không cho phép jQuery sử dụng bất kỳ mã nào của họ (cũng không phải React, vì nó thuộc sở hữu của Facebook), điều mà bạn có thể không biết cho đến khi người phỏng vấn nói "Xin lỗi, nhưng bạn không thể sử dụng jQuery, nó không bật danh sách được phê duyệt tại XYZ Corporation ". Vanilla JavaScript hoạt động hoàn toàn ở mọi nơi, mọi lúc và sẽ không bao giờ cung cấp cho bạn vấn đề này. Nếu bạn dựa vào một thư viện, bạn sẽ có được tốc độ và sự dễ dàng, nhưng bạn sẽ mất tính phổ quát.

Ngoài ra, nói về phỏng vấn, nhược điểm khác là nếu bạn nói rằng bạn cần sử dụng một thư viện để giải quyết vấn đề JavaScript trong một bài kiểm tra mã, thì nó giống như bạn không thực sự hiểu vấn đề, có vẻ hơi tệ. Trong khi đó, nếu bạn giải quyết nó bằng JavaScript vanilla thô, điều đó chứng tỏ rằng bạn thực sự hiểu và có thể giải quyết mọi phần của bất kỳ vấn đề nào họ ném ra trước mặt bạn.


1

$(this) khác với this :

Bằng cách sử dụng, $(this)bạn đảm bảo nguyên mẫu jQuery được truyền vào đối tượng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.