Czy JQuery i podobne narzędzia mogą być wbudowane w instalację przeglądarki?

19

Po przeczytaniu kolejnego pytania na temat JQuery i CDN jest możliwe, aby narzędzia takie jak JQuery „przychodziły” z przeglądarką, zmniejszając / eliminując potrzebę pierwszego pobrania z CDN lub z własnego serwera hosta.

Pliki JQuery są dość małe, więc możesz łatwo mieć wiele (wszystkich?) Różnych wersji w ramach instalacji przeglądarki. Teraz wystarczy, by to zwiększyło powierzchnię instalacji i czas pobierania samej przeglądarki.

Następnie strony mogą najpierw sprawdzić „lokalny”, przed CDN (który następnie buforuje), a następnie domyślnie pobierać z samego serwera strony.

Jeśli jest to wykonalne, czy zostało to zrobione, a jeśli nie, dlaczego nie zostało zrobione?

jquery web-browser

— ozz
źródło

3

Gdy dana funkcja JavaScript staje się tak wszechobecna, że wszędzie jest potrzebna, zostaje dodana do języka. Array.prototype.forEach, Array.prototype.indexOf, Object.createWszystko to są przykłady kodu, który został wiązane do silnika samej JavaScript.

— zzzzBov,

Jestem pewien, że Chrome zaproponuje rozwiązanie, które oferuje użytkownikowi końcowemu opcję zainstalowania rozszerzenia z możliwością buforowania niezbędnych plików jQuery / javascript podczas pierwszego renderowania strony? Jeśli użytkownik odmówi, wymusza żądanie jak zwykle. Opcja „nie pytaj mnie ponownie” może wyłączyć tę opcję. W ustawieniach może znajdować się obszar, w którym użytkownik końcowy może wybrać, które pliki js mają być przechowywane w pamięci podręcznej przeglądarki za pomocą prostej listy wyboru. Zawsze będą wysyłane niestandardowe pliki js do klienta, ale wydaje się, że wyeliminowanie plików js wysyłanych do klienta na żądanie zoptymalizowałoby p

— yardpenalty

1

Którą wersję sugerujesz uwzględnić? Co powiesz na przyszły tydzień?

— pdr

@pdr - stare pytanie, z dużą ilością odpowiedzi negatywnych za zrobienie tego. ALE można łatwo spakować najnowszą wersję z wydaniem przeglądarki i pozwolić kodowi użytkownika wrócić do żądania nowszej wersji z CDN, jeśli jest to wymagane. Z przełomowymi zmianami, takimi jak JQuery 2.0, możesz mieć jedno i drugie i pozwolić na wybór kodu. Ale wszystko jest nieme :)

— ozz

15

Nie ma technologicznego powodu, dla którego nie mogliby. Nie jest to jednak konieczne i jest sprzeczne z podstawową filozofią sieci. Nie jest to konieczne, ponieważ można osiągnąć prawie to samo z nagłówkiem dalekiej przyszłości. Jest to sprzeczne z filozofią sieci, ponieważ powoduje odgórne, scentralizowane uprawnienia, na których bibliotekach powinno / nie się wiązać z przeglądarką.

Edycja: biblioteki JS są tam przede wszystkim po to, aby ułatwić sobie obsługę DOM. Nie sądzę, aby dołączanie bibliotek stron trzecich do przeglądarki było właściwym sposobem na uprzyjemnienie DOM API.

— dan_waterworth
źródło

1

dzięki Dan - jakieś linki mogę przeczytać na temat tego, co opisujesz?

— ozz

1

Twierdziłbym, że konieczność pobierania megabajtów na megabajty popularnych bibliotek za każdym razem, gdy żądam strony, jest sprzeczna z inną fundamentalną filozofią sieci polegającą na utrzymywaniu małych i przystępnych stron internetowych. W końcu wiele osób wciąż korzysta z modemów i ma wolne połączenia satelitarne.

— wałek klonowy

4

Operacja kanału korzeniowego sprawiłaby, że DOM API byłby przyjemniejszy ...

— Donal Fellows

1

@maple_shaft, to nieco podstępny argument. Zminimalizowana dystrybucja jQuery wynosi 31 KB. Chociaż z pewnością istnieją strony internetowe, które ładują szaloną liczbę różnych bibliotek, pytanie jest specyficzne dla jQuery i nie ma rozliczania złych programistów.

— Adam Crossland

16

W rzeczywistości to, co opisujesz, istnieje już od lat. To się nazywa buforowanie . I jest dostępny nie tylko dla JQuery, ale dla wszystkiego, co Twoja przeglądarka może pobrać.

Następnie strony mogą najpierw sprawdzić „lokalny”, przed CDN, a następnie domyślnie pobrać z samego serwera strony.

To właśnie robi każda przeglądarka. Najpierw sprawdza lokalną pamięć podręczną, a następnie w razie potrzeby pobiera ją z CDN. Przy odpowiedniej konfiguracji pamięci podręcznej nawet przez wiele miesięcy nie ma możliwości obejścia serwera (w celu sprawdzenia nowszej wersji).

Włączenie JQuery do ustawień przeglądarki:

Dodaj niepotrzebną złożoność do aplikacji i konfiguracji przeglądarki,
Dodaj niepotrzebną złożoność procesu aktualizacji,
Zwiększ liczbę aktualizacji, aby zachować aktualną wersję JQuery, nawet dla osób, które jej nie potrzebują,
Dodaj zamieszanie: dlaczego JQuery, a nie Prototype, lub inny framework, obraz, plik CSS itp.?
itp.

Zwiększenie złożoności oprogramowania bez korzyści pod względem funkcji, wydajności itp. Jest bardzo złym pomysłem.

— Arseni Mourzenko
źródło

Dzięki. Tak, moje pytanie nie było jasne. Jestem DOBRZE świadomy tego, co się dzieje. Mówię o wyeliminowaniu potrzeby nawet pierwszego pobrania. Zaktualizuję pytanie.

— ozz

dziękuję z wszystkich powodów, aby NIE uwzględniać w konfiguracji przeglądarki :-)

— ozz

6

Nie można wyeliminować potrzeby pierwszego pobrania. Jeśli JQuery jest uwzględnione w instalacji, jest ono pobierane po raz pierwszy, gdy osoba pobiera plik wykonywalny instalacji (następnie jest pobierane ponownie przez aktualizacje, gdy nowa wersja JQuery jest wydawana).

— Arseni Mourzenko

2

Nie eliminuje to spadku wydajności, ale przenosi go z wizyty na pierwszej stronie do pobrania pliku wykonywalnego instalacji, co oznacza, że ogólnie rzecz biorąc, jest to przeciwieństwo oszczędności wydajności. Nie eliminuje to potrzeby CDN, jeśli nie chcesz obsługiwać starszych przeglądarek i przeglądarek nieaktualizowanych od czasu wydania ostatniej wersji JQuery.

— Arseni Mourzenko

1

@Wszystko Jeśli chcesz to omówić dalej, weź to na czacie.

— wałek klonowy

5

Nie zapominaj, że jQuery jest biblioteką js, wygląda na to, że stała się de facto i jest postrzegana jako panaceum (do tego stopnia, że zapada w pamięć na SO), ale to tylko biblioteka js.

Wszystko, co jest znormalizowane do skryptowania (EMCAScript), jest już zawarte w przeglądarce, wszystko inne dodane do innych przeglądarek stałoby się niestandardowe i skończyłyby się problemy z przeglądarkami niestandardowymi (takie jak model zdarzeń IE ), które wpływają częściowo na to, dlaczego biblioteki takie jak jQuery zostały utworzone.

Krótka odpowiedź: można je uwzględnić, ale nie powinny.

— StuperUser
źródło

5

Buforowanie w przeglądarce zapewnia coś bardzo podobnego do tego, o czym mówisz. Powinno być tak, że jQuery lub jakakolwiek inna biblioteka JS byłaby pobierana raz, a następnie pobierana z pamięci podręcznej na kolejne żądania.

Chociaż jQuery może być najbardziej wszechobecną biblioteką JavaScript, nie jest jedyną i wydaje mi się, że uczynienie z niej zainstalowanego komponentu przeglądarki byłoby szkodliwe dla ekosystemu JS. Konkurencja jest zdrowa i generalnie prowadzi do innowacji, a my, programiści i użytkownicy oprogramowania, nie bylibyśmy dobrze obsłużeni, gdyby jQuery zajmowało specjalną pozycję.

Po uwzględnieniu buforowania korzyść, którą zyskujesz, jest bardzo, bardzo minimalna. Zminimalizowana wersja jQuery ma tylko 31 KB. To nie jest uzasadnienie dla zmiany czegokolwiek .

— Adam Crossland
źródło

dzięki Adam - tak, znam pierwszy scenariusz pobierania, buforowania. Moje myśli też to zastąpią. JQuery był tylko 1 przykładem, ale zgadzam się z twoimi przemyśleniami na temat konkurencji, wydaje się, że to może być główny powód, dla którego sugeruję, że się nie zdarzyło. Macie wtedy różne przeglądarki z różnymi zestawami „domyślnych” komponentów itd.

— oz

Zaktualizowałem pytanie, aby wspomnieć, że jestem świadom buforowania :-)

— oz