Dlaczego w przeglądarkach nie zainstalowano jQuery?

19

Korzystam z jQuery na kilku moich stronach internetowych i chociaż używam CDN do jego obsługi, to po prostu nie ma sensu, aby odwiedzający pobierał jQuery za każdym razem. jQuery musi być najczęściej używaną strukturą JavaScript na świecie - czy nie ma większego sensu, jeśli przeglądarki mają po prostu domyślnie zainstalowane?

W ten sposób milionom razy dziennie można zapobiec pobieraniu jQuery. Albo z własnych stron internetowych, albo z CDN.

Wszystko, co byłoby naprawdę potrzebne, to jakieś zdanie typu:

 <!--[if jQuery gt 11]>

Czy istnieje coś, co pomoże mi uniemożliwić podróż do CDN, jeśli już mają jQuery w pamięci podręcznej z innej witryny?

cache browsers jquery

— użytkownik1914292
źródło

3

pytanie brzmi - dlaczego użytkownik musi tworzyć nowe pliki do pobrania z witryn lub sieci CDN w celu uzyskania czegoś, co już ma? jQuery jest obsługiwany z wielu lokalizacji i w wielu wersjach. Niepokoi mnie szybkość strony, a użytkownicy są zaniepokojeni przepustowością (szczególnie mobilną). Jeśli biblioteka ma złoty standard - dlaczego go nie wykorzystać? Istnieją inne przykłady, które z pewnością bym przyjął z zadowoleniem - o ile istnieje dla nich uzgodniony standard (np. Numer wersji).

— user1914292

27

Dlaczego jQuery, ale nie Angular, MooTools, Underscore, ...? A które wersje każdej z nich? Czy przeglądarki powinny zawierać kopie każdej biblioteki JavaScript, jaką kiedykolwiek stworzono?

— user253751

15

„Niestety, nie możesz korzystać z mojej witryny, dopóki nie uaktualnisz przeglądarki do wyższej wersji 0.1”

— VLAZ

4

Odpowiedni

— Charlie,

4

buforowanie jest do tego stworzone. w przeciwnym razie, obsługa wersja byłoby w zasadzie niemożliwe

— njzk2

55

Jeśli udostępniasz jQuery z popularnej sieci CDN, takiej jak Google Hosted Libraries lub cdnjs , nie zostanie ona ponownie pobrana, jeśli odwiedzający był w witrynie, która odwoływała się do niego z tego samego źródła (o ile wersja buforowana nie wygasła).

jQuery jest popularną biblioteką, tak jak mówisz, ale powiązanie jej z przeglądarką prawdopodobnie nie nastąpi z kilku powodów:

jQuery jest stosunkowo niewielki (w porównaniu do bibliotek, które czasami są wbudowane w przeglądarki, takie jak Flash). Największe wąskie gardła w wydajności w przeciętnej witrynie prawdopodobnie nie są spowodowane pobieraniem jQuery.
Udoskonalenia JavaScript / ECMAScript oznaczają, że programiści nie muszą coraz bardziej polegać na jQuery. (Zobacz youmightnotneedjquery.com .)
Istnieje wiele innych popularnych bibliotek JavaScript. Przeglądarki nie są zaprojektowane jako repozytoria kodu JavaScript. Śledzenie popularności skryptów, upuszczanie mniej popularnych bibliotek i utrzymywanie aktualności może najlepiej pozostawić twórcom stron internetowych poszczególnych witryn.

— Nacięcie
źródło

Rozumiem to, ale teraz używam code.jquery.com jako CDN. Jednak gdy inna strona korzysta z googleapis lub cdjns, przeglądarka PONOWNIE pobierze jQuery z tej innej sieci CDN. To po prostu nie ma sensu i kosztuje dużo czasu / przepustowości w całym miejscu. Jeśli dodasz do tego, że w większości przypadków ludzie chcieliby czegoś takiego jak jQuery1.7 +, będzie jeszcze gorzej. Rozumiem twój punkt widzenia, że przeglądarki nie są repozytoriami, ale czy nie bylibyśmy w stanie wymyślić jakiejś reguły „pamięci podręcznej z wielu źródeł”?

— user1914292

24

@ user1914292 Przydałoby się to tylko wtedy, gdy wszystkie przeglądarki posiadały wszystkie wersje jQuery, jakie kiedykolwiek istniały, i jeśli przechwytywały wszelkie żądania do dowolnego znanego źródła jQuery, zastępując je wersją buforowaną. Jeśli istnieje choćby niewielka różnica, może to powodować błędy, których debugowanie jest niemożliwe. Sytuację dodatkowo pogarsza fakt, że buforowanie sieciowe działa i działa od dziesięcioleci. Twoja przeglądarka nie jest jedyną pamięcią podręczną tych żądań jQuery - wiele routerów w drodze do przeglądarki robi to samo. Problem został rozwiązany dawno temu, kiedy przepustowość miała znaczenie :)

— Luaan

4) Co się stanie, jeśli kod jquery w konkretnej witrynie zależy od funkcji, która została zasadniczo zmieniona w ostatniej aktualizacji i nie spełnia już tego, czego oczekuje kod?

— Shadur

1

@ Ejay nie, to nie działa jako mechanizm śledzenia, ponieważ 99% czasu żądanie jest obsługiwane z pamięci podręcznej przeglądarki.

— suriv

1

@BenSteward Tak, użyj narzędzi programistycznych przeglądarki i sprawdź panel Sieć . Na przykład Chrome pokaże buforowane zasoby z „pamięcią podręczną dysku” lub „pamięcią podręczną” w kolumnie „rozmiar” i widmową wartością w kolumnie „status” (o ile nie masz „Wyłącz pamięć podręczną” (podczas gdy DevTools is open) ”aktywne w ustawieniach narzędzi programistycznych). Może zależeć od nagłówków kontroli pamięci podręcznej i innych czynników określających, co zostanie buforowane i na jak długo. developer.mozilla.org/en-US/docs/Web/HTTP/Caching

— Nick

21

JQuery nie jest nie tylko popularną biblioteką JS, ale przeglądarka może potencjalnie zawierać wiele wersji. Google CDN obecnie wymienia: 42 wersje jQuery; 44 wersje interfejsu użytkownika jQuery; 6 wersji jQuery Mobile.

Lepiej pozwolić twórcom stron internetowych określić, która wersja biblioteki ma zostać pobrana na podstawie wymagań ich witryny. Jeśli użyjesz bieżącej wersji produkcyjnej jQuery na swojej stronie i załadujesz ją z bardziej popularnej sieci CDN, istnieje duża szansa, że twoi użytkownicy i tak już ją buforują.

— Andrew Lott
źródło

14

Przeglądarka jest silnikiem, nie jest obowiązkiem projektanta silnika dowiedzieć się, jaki rodzaj paliwa i dodatkowych części zamierzasz włożyć do samochodu i uwzględnić go dla Ciebie. Gdyby to zrobili, przeglądarki byłyby ogromnym nadękiem, ponieważ następnym pytaniem będzie „dlaczego tylko jQuery?”, A my ostatecznie utrzymalibyśmy repozytoria zależności.

Czy uwzględnimy również wszystkie wersje? Co jeśli ktoś chciałby użyć wersji niestandardowej? Co jeśli ktoś nie chciałby korzystać z tej biblioteki? Jak często będą się łączyć i wyświetlać najnowsze wydania? Czy skończymy z różnymi przeglądarkami z różnymi wersjami jQuery? Nie mogą nawet w równym stopniu zaimplementować standardowych funkcji HTML, CSS i JavaScript. Co się stanie, jeśli jeden z opiekunów przeglądarki nie będzie uwzględniał biblioteki ani jej konkretnej wersji?

Przeglądarki zapewniają bloki konstrukcyjne i środowisko, w którym można zbudować nie ukończone rozwiązanie.

Umieszczenie jQuery w przeglądarce nie spowoduje, że Twoja strona ładuje się błyskawicznie, ponieważ w dzisiejszych czasach nie jest to największe wąskie gardło, jednak możemy się zgodzić, że jQuery jest niepotrzebnie dużą biblioteką, ale jej celem nigdy nie była szybka biblioteka (biorąc pod uwagę pasmo). Istnieje wiele innych bibliotek, które zostały zaprojektowane z myślą o szybkim ładowaniu i są lekkie jak Zepto .

Jeśli naprawdę martwisz się wielkością i wykorzystaniem przepustowości jQuery, nie używaj go. Czy kiedykolwiek słyszałeś o Vanilla JS ? Jest to jeszcze bardziej popularna biblioteka, z której dosłownie korzysta prawie każdy, w tym sama jQuery! I spełniło już Twoje marzenie, ponieważ jest zawarte w każdej przeglądarce!

— totymedli
źródło

2

Powodem korzystania z biblioteki takiej jak jQuery jest kompatybilność.

Przeglądarki stają się bardziej zgodne ze standardami, ale korzystając z biblioteki jquery, dostarczasz siebie, nie musisz się martwić różnicami między rodzinami przeglądarek a wersjami

Dostarczając jquery na pewno masz spójny interfejs API.

Jeśli mamy wbudowaną jquery w przeglądarkę, musisz sprawdzić, którą wersję ma użytkownik, a my wracamy do wyszukiwania w przeglądarce i „Najlepiej oglądać tę stronę w ...”

Tak więc wbudowanie jquery w przeglądarkę nie ma sensu.

Również buforowanie działa, więc nawet jeśli użytkownik nie ma jeszcze swojej wersji jquery, należy go pobrać tylko raz.

— Lenne
źródło

-3

Myślę, że respondenci tutaj nie rozumieją, że odpowiedzią na to pytanie jest to, że przeglądarki powinny prawdopodobnie obejmować najczęściej używane biblioteki, wypełniania itp. Po stronie klienta.

Jak podaje osoba zadająca pytanie, można użyć komentarzy warunkowych, aby zapewnić, że osobom korzystającym z przeglądarek, które nie zawierają jquery, zostanie dostarczona odpowiednia wersja.

Jquery zawiera także własną obsługę zgodności wstecznej poprzez migrację, pozwalając na komentarze warunkowe, aby zapewnić retro wsparcie dla kogoś ze spakowaną wersją starszej biblioteki jquery bez pobierania całej nowej biblioteki.

Argument ZA umieszczeniem ich w przeglądarkach dotyczyłby nie tylko wygody użytkownika i kosztów, ale także planety, na której żyjemy. Wykorzystanie danych ma ogromny wpływ na globalne zanieczyszczenie, a zapewnienie, że niepotrzebny transfer danych zostanie zminimalizowany, może mieć dramatyczny wpływ na nasz ślad węglowy.

Zasadniczo w celu dodania dodatkowych kilku megabajtów wzdęcia w spakowanej przeglądarce - te same dane są niepotrzebnie przesyłane około miliardów razy dziennie.

To pogarsza wrażenia użytkowników dla wszystkich w Internecie. I kosztuje duże firmy ogromne kwoty pieniędzy.

Jako programista po prostu stworzyłbyś niezbędne wymagane awarie, tak jak to obecnie robimy w IE itp., Więc w czym problem - prawdopodobnie powinien zostać uwzględniony?

— Andy Bbop
źródło

1

Jest to styczne do pytania. Pytanie brzmi „dlaczego nie przeglądarki i co mogę z tym zrobić”, a nie „dlaczego przeglądarki powinny”.

— Stephen Ostermiller

OP, zastanawiając się nad swoim punktem, jest zainteresowany zmniejszeniem ruchu do CDN, jeśli platforma już istnieje w pamięci podręcznej przeglądarki, być może nawet z innej strony. Osobiście nie widzę tego, chyba że istnieje wspólny sposób odwoływania się do frameworka.

— closetnoc

Większość ludzi nie powiedziała również najbardziej odpowiedniej odpowiedzi na to pytanie, a mianowicie, że jQuery nie jest standardem internetowym, a przeglądarki obsługują tylko standardy sieciowe, które zmieniają się powoli i są oparte na podstawach. jQuery został pierwotnie stworzony, aby podstawy działały spójnie między przeglądarkami, więc włączenie jQuery jest jak dołączenie łatki do naprawy przeglądarek, ale przeglądarki już w końcu same się naprawiają. Już teraz widzimy zmniejszone użycie jQuery, czego częściowo dowodzą liczne artykuły „Nie potrzebujesz jQuery”.

— Rob

Stephen. Pytanie nie brzmi „dlaczego nie przeglądarki i co mogę z tym zrobić”. To jest twoje przemyślenie. Pytanie brzmi: dlaczego tego nie robią, a osoba pytająca wyraźnie stwierdza, że po prostu zrobienie tego i stworzenie nowych ram postępowania z pojawiającymi się problemami faktycznie przyniosłoby ogromną potencjalną korzyść wszystkim użytkownikom sieci.

— Andy Bbop,

Wszyscy musicie przestać bronić swoich przestarzałych uprzedzeń i zaakceptować, że wszyscy nadal możecie się uczyć. Aha, a także nauczyć się czytać. #Bronie. „Rozważając swój punkt widzenia, OP jest zainteresowany zmniejszeniem ruchu do CDN”. Nie, mówi, że może to zaoszczędzić ogromne przepustowości, czy to po stronie klienta, czy CDN. Przeczytaj Effing Post.

— Andy Bbop