JavaScript można wczytywać na kilka różnych sposobów, m. in. statycznie i dynamicznie, w tym synchronicznie lub asynchronicznie.
W niniejszym wpisie przyjrzę się więc różnym sposobom wczytywania plików JavaScript do tworzonych dokumentów HTML, porównam ich wydajność i użyteczność, wymienię główne wady i zalety. Do dzieła!
Prolog
W dzisiejszych czasach w coraz większym stopniu bazujemy na kodzie JavaScript, który to pozwala nam na coraz więcej, powoli wypierając flash i alternatywne technologie.
Twórcy języka dostarczają ciągle nowe fjuczery, np. XMLHttpRequest, canvas, browser history, Server-Sent Events, Web Workers i inne. Zwiększa to interakcję z użytkownikiem i jednocześnie ułatwia życie programisty.
Z czasem jednak pojawia się problem – dochodzimy do stanu, w którym spora część aplikacji została oparta na JavaScript. Do dokumentu musimy dołączyć kilka lub kilkanaście plików JavaScript i zrobić to w sposób efektywny i optymalny, pamiętając o tym, że im mniej requestów do serwera tym lepiej.
Jak więc poradzić sobie z wczytywaniem zewnętrznych plików JavaScript? Poniżej kilka rozwiązań tego problemu.
Statyczne wczytywanie plików JavaScript
Zazwyczaj wczytujemy skrypty w sposób statyczny, czyli przez umieszczenie na stronie elementu SCRIPT z odpowiednim adresem:
1 | <script type="text/javascript" src="scripts.js"></script> |
Kod taki jak powyższy wrzucamy na sam dół dokumentu HTML, tuż przed zamknięciem tagu BODY i cieszymy się już skryptami na naszej stronie.
Jednak metoda ta nie jest wydajna czy wygodna, lecz prosta i dlatego najczęściej wykorzystywana. W przypadku większej ilości plików JavaScript (a dla własnej wygody warto rozbijać kod na wiele plików) nasz kod może wyglądać następująco (kopiuj & wklej z nk.pl):
1 2 3 4 5 6 7 8 9 10 11 12 13 | <script type="text/javascript" charset="UTF-8" src="http://0.s-nk.pl/script/base:286a"></script> <script type="text/javascript" charset="UTF-8" src="http://1.s-nk.pl/script/packs/ready_all:ecc6"></script> <script type="text/javascript" charset="UTF-8" src="http://0.s-nk.pl/script/last_photos:f83f"></script> <script type="text/javascript" charset="UTF-8" src="http://1.s-nk.pl/script/sledzik/sledzik_box_initializer:2794"></script> <script type="text/javascript" charset="UTF-8" src="http://0.s-nk.pl/script/events_controller:7674"></script> <script type="text/javascript" charset="UTF-8" src="http://0.s-nk.pl/script/generic_multi_tab:3c51"></script> <script type="text/javascript" charset="UTF-8" src="http://0.s-nk.pl/script/user_tab_box:94cc"></script> <script type="text/javascript" charset="UTF-8" src="http://0.s-nk.pl/script/friends_list2:973d"></script> <script type="text/javascript" charset="UTF-8" src="http://0.s-nk.pl/script/friends_select:fca8"></script> <script type="text/javascript" charset="UTF-8" src="http://1.s-nk.pl/script/main_search_friends_select:97e4"></script> <script type="text/javascript" charset="UTF-8" src="http://0.s-nk.pl/script/statcounter:a648"></script> <script type="text/javascript" charset="UTF-8" src="http://1.s-nk.pl/script/last_video/last_video:8f91"></script> <script type="text/javascript" charset="UTF-8" src="http://0.s-nk.pl/script/packs/sledzik_shout_box:f20f"></script> |
Tragedia.
Oczywiście możemy wykorzystać do swej pracy jakiś kompresor JavaScript – narzędzie w języku serwerowym, które połączy i skompresuje wszystkie pliki w jeden wielki przy generowaniu dokumentu HTML i następnie będzie przetrzymywał go w cache do czasu zmiany pliku źródłowego. Jest to świetne rozwiązanie, wykorzystane przeze mnie w większości wykonanych projektów.
Asynchroniczne wczytywanie JavaScript
Wraz z nadejsciem HTML5 pojawiło się pewne wsparcie dla powyższego kodu z nk.pl – teraz możemy używać wielu plików JavaScript nie martwiąc się o tzw. Maximizing Parallel Downloads. Mowa oczywiście o asynchronicznym wczytywaniu plików JavaScript.
Więcej o asynchronicznym wczytywaniu plików JavaScript poczytasz w opisie narzędzia Steve’a Souders: ControlJS – async loading.
Niemniej jednak nadal pozostaje kilka innych problemów, jak choćby mnóstwo requestów (jeśli mamy wiele plików JavaScript), które niepotrzebnie zapychają serwer.
Dynamiczne wczytywanie plików JavaScript
Przy ostatnim projekcie, w którym wykorzystywałem masę małych skryptów wpadłem na pomysł, by je wczytywać dynamicznie dla danej podstrony w ściśle określonych sytuacjach. Nie chciałem tworzyć jednego wielkiego pliku ani serwować kodu statycznie, gdyż niektóre funkcjonalności były potrzebne jedynie dopiero po interakcji użytkownika (np. po zaznaczaniu checkbox’a pojawiało się pole na wpisanie daty, więc ładowałem skrypt kalendarza).
Jak więc widzisz, takie rozwiązanie ma bardzo fajną zaletę – oszczędzasz transfer wczytując odpowiedni kod HTML dopiero wtedy, gdy go potrzebujesz.
Przejdźmy więc do opisu sposobów wczytywania kodu dynamicznie:
„Goły” JavaScript
Nie potrzebujemy żadnej wyspecjalizowanej biblioteki JavaScript do wczytywania zewnętrznych plików JavaScript. Wystarczy bowiem dynamicznie utworzyć znacznik SCRIPT i zaserwować odpowiedni plik, a resztą zajmie się przeglądarka. Tak też robi Google Analytics:
1 2 3 4 5 6 7 8 9 10 11 | (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = 'ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })(); |
Co tutaj się dzieje?
- Wszystko wrzucamy do funkcji, która zaraz po wczytaniu sama się wykonuje:
1
2
3(function() {
// ..
})(); - Tworzymy znacznik SCRIPT i ustawiamy jego atrybut type=”text/javascript”.
- Aktywujemy asynchroniczność.
- Zapodajemy adres skryptu JavaScript do załadowania.
- Całość osadzamy w dokumencie HTML.
Jak więc widzisz, w prosty sposób załadowaliśmy asynchronicznie i dynamicznie plik JavaScript.
$script.js
Na szczęście nie musimy każdorazowo wpisywać powyższego kodu, bowiem z pomocą przychodzą biblioteki ułatwiające powyższe operacje wczytywania zewnętrznych plików JavaScript.
Jednym z prostszych i szybszych w implementacji jest $script.js. Dzięki niemu możemy ładować wiele plików JavaScript w ustalonej przez nas kolejności, np. :
1 2 3 4 5 | $script('jquery.js', function() { $script('my-jquery-plugin.js', function() { $script('my-app-that-uses-plugin.js'); }); }); |
W powyższym przykładzie najpierw wczytujemy jquery.js. Jeśli uda się sukcesywnie załadować ten plik, wykonywana jest funkcja callback. W funkcji tej wczytujemy plugin, po którym załadowaniu wczytywany jest jeszcze jeden plugin.
Wszystko to sprawia, że zagnieżdżamy w sobie wiele różnych wczytywań plików JavaScript, co jest bardzo nieprzyjemne w pracy. Tak stworzony kod nie jest czytelny przy większej ilości skryptów, więc możemy spróbować wywoływać callbacki w inny sposób:
1 2 3 4 5 6 7 8 9 10 | $script('jquery.js', 'jquery'); $script('my-jquery-plugin.js', 'plugin'); $script.ready('jquery', function() { // plugin code... }); $script.ready('plugin', function() { // use your plugin :) }); |
Wczytujemy tutaj podany plik, jednocześnie podając w drugim parametrze jego identyfikator. W kolejnych liniach kodu możemy dokonać sprawdzenia jego statusu ładowania, dzięki czemu nie musimy już pisać wieloblokowego i nieczytelnego kodu.
LABjs – Loading And Blocking JavaScript
Dużą ciekawszą alternatywą alternatywą do łatwiejszego wczytywania i zarządzania dynamicznie załadowanym kodem jest LABjs, którego właśnie ostatnio użyłem w swoim projekcie. Pozwala on na przyjemne ładowanie wielu plików JavaScript tylko w ściśle określonych warunkach oraz w ustalonej kolejności.
1 2 3 4 5 | $LAB .script("framework.js").wait() .script("plugin.framework.js") .script("myplugin.framework.js").wait() .script("init.js").wait(); |
Jak widzisz, LABjs udostępnia świetny interfejs do wczytywania kolejnych plików JavaScript. W powyższym przykładzie wczytujemy plik framework.js i czekamy aż zostanie w 100% załadowany do przeglądarki klienta. Po wczytaniu tego pliku wczytujemy plugin i od razu kolejny plugin – czekając aż plugin myplugin.framework.js się wczyta. Na koniec wczytywany jest plik init.js. Już chyba łatwiej i przyjemniej nie można.
Z LABjs możemy robić wiele więcej, jak choćby wczytywać kilka skryptów na raz:
1 2 3 4 5 6 7 | $LAB .script("script1.js", "script2.js", "script3.js") .wait(function(){ // wait for all scripts to execute first script1Func(); script2Func(); script3Func(); }); |
O wszystkich funkcjonalnościach przeczytasz na stronie projektu w dokumentacji LABjs.
Head JS
Kolejną biblioteką ułatwiającą ładowanie zewnętrznych plików JavaScript jest Head JS. Biblioteka ta, podobnie jak powyższe, pozwala praktycznie na to samo, oferując inną składnię:
1 2 3 4 5 | head.js("/path/to/jquery.js", "/google/analytics.js", function() { // all done }); |
Head JS zawiera dodatkowo kilka innych funkcjonalności, jak np. wykrywanie, czy dana przeglądarka obsługuje pewne elementy CSS3 lub HTML5. W przypadku gdy obsługuje możemy wykonać określone czynności, np. wczytać skrypt sterujący obiektem VIDEO. Jest też kilka ciekawych funkcjonalności, jak choćby:
1 2 3 4 5 | <script> var head_conf = { screens: [640, 1024, 1280, 1680] }; </script> <script src="/js/head.min.js"></script> |
Kod taki sprawi, że tylko dla powyższych rozdzielczości ekranu będziemy ładować zewnętrzne pliki JavaScript.
ControlJS
Na koniec zostawiam bibliotekę genialnego Steve’a Souders – ControlJS.
Steve Souders to człowiek od optymalizacji witryn internetowych (głównie front-end), pracownik Google. Napisał on kilka książek, które zostały przetłumaczone także na język polski i które szczerze polecam – można z nich wynieść masę praktycznej wiedzy.
Wracając jednak do ControlJS – jest to biblioteka pozwalająca wczytywać wiele plików JavaScript w sposób dynamiczny i asynchroniczny. Co prawda użycie tej biblioteki wymaga stosowania niestandardowych atrybutów HTML na elementach SCRIPT, niemniej to nic strasznego. Tak wygląda przykładowy kod HTML:
1 2 | <script data-cjsexec=false type="text/cjs" data-cjssrc="jquery.min.js"></script> <script data-cjsexec=false type="text/cjs" data-cjssrc="fg.menu.js"></script> |
Zauważ również, że typ skryptu został zmieniony z text/javascript na text/cjs (walidator wysypie zapewne błędy). Dzieje się tak dlatego, by skrypty te nie były automatycznie wykonywane przez przeglądarkę po wczytaniu, a dopiero na żądanie klienta.
Na co pozwala ControlJS?
- Asynchroniczne ładowanie zewnętrznych plików JavaScript.
- Wczytywanie kodu JavaScript dopiero po wczytaniu kodu HTML.
- Wczytywaniu zewnętrznych plików JavaScript i ich wykonywanie w momencie gdy dopiero tego zażądamy.
- Bez ingerencji w kod HTML (jeśli zawiera elementy SCRIPT) przemianowanie odwołań do skryptów na asynchroniczne.
ControlJS posiada także bardzo przyjemną składnię do kontrolowanego wczytywania zewnętrznych plików w określonych sytuacjach:
1 2 3 4 | examplesbtn.onclick = function() { CJS.execScript("jquery.min.js"); CJS.execScript("fg.menu.js", createExamplesMenu); }; |
Dla powyższego przykładu wybieramy element i dodajemy do niego zdarzenie onclick. Po kliknięciu przez użytkownika w ten element wczytywane są dwa pliki. Po wczytaniu tego drugiego wykonywana jest funkcja zwrotna – createExamplesMenu.
Krótkie podsumowanie
Jak więc można zauważyć po ilości dostępnych bibliotek do dynamicznego ładowania zewnętrznych plików JavaScript, technika ta staje się coraz popularniejsza i kusząca w użyciu.
Możemy w ten sposób bezboleśnie i szybko wczytywać odpowiednie skrypty w wybranych sytuacjach, oszczędzając transfer serwera i czas klienta.
Z drugiej strony nadal kuszące jest wrzucanie wszystkich plików JavaScript w jeden ogromny i nie martwić się w szczegółowe dobieranie odpowiednich plików w ściśle określonych zdarzenia – kompresja i złączenia robią swoje.
Wszystko więc zależy od ilości skryptów i częstotliwości ich użytkowania – im bardziej interaktywną aplikację tworzysz, tym bardziej powinieneś być przekonany do dynamicznego wczytywania plików JavaScript.
A Ty w jaki sposób wczytujesz zewnętrzny kod JavaScript? Zachęcam do dzielenia się swoimi doświadczeniami w tym temacie.
Osobiście używałem minify – wszystko i tak siedzi w cache. Aczkolwiek powoli przestawiam się na podejście przez Ciebie zaprezentowane, tak więc wielkie dzięki za podsumowanie w jednym miejscu tych popularniejszych rozwiązań :)
Wymieniłeś kilka zewnętrznych bibliotek, a chyba warto wspomnieć, że jQuery też ma odpowiednią metodę w standardzie.
@michal
Słuszna uwaga, faktycznie zapomniałem o jQuerowym $.getScript. Przy swoim projekcie także myślałem nad użyciem tej funkcji, jednak podobnie jak wspomniana powyżej biblioteka $script.js, także i tutaj zmuszają nas do blokowego pisania, co nie jest dobrym rozwiązaniem.
Do jednego czy dwóch skryptów można ją wykorzystać, ale nie większej ich ilości, bo powstanie coś takiego:
2
3
4
5
6
7
8
9
$.getScript('ajax/plugin.framework.js', function() {
$.getScript('ajax/myplugin.framework.js', function() {
$.getScript('ajax/init.js', function() {
alert('all done');
});
});
});
});
Bardzo dobry i wartościowy wpis, dziękuję i gratuluję!
Przy małych projektach szkoda zachodu z dynamicznym ładowaniem skryptów, a przy duzych i tak lepiej skorzystać ze sprawdzonych narzędzi (jak np genialne Google Closure: co może dać lepsze referencje jak oparte na nim GMail czy Google Reader)
Trzeba pamiętać, źe kompresja JS a asynchroniczne i nieblokujące wczytywanie, to dwie różne rzeczy. Nic nie stoi jednak na przeszkodzie, żeby ze sobą współgrały.
Ja np. robię coś takiego, że pliki JS wspólne dla wszystkich podstron serwisu (albo przynajmniej znacznej większości) kompresuję i łączę w jeden. Pozostałe pliki, zależne od podstron dołączam osobno. To pierwsza optymalizacja.
Druga, to nieblokujące wczytywanie. Najprościej przerzucić skrypty na sam dół kodu strony – zaraz przed . Dzięki temu pozwolimy wyrenderować przeglądarce stronę bez czekania na JS, ponieważ nie będzie musiała czekać na np. ewentualne document.write’y, które przecież mogą gdzieś tam w ładowanych skryptach wystąpić. W teorii nowe silniki optymalizują trochę ten proces i nie czekają, ale i tak lepiej im pomóc.
Kolejna rzecz to doładowywanie skryptów dopiero kiedy rzeczywiście są potrzebne. Przydatna praktyka w sporych i ciężkich JSowo serwisach, ale lekko bezsensowna przy prostych stronach. W szczególności nie widzę sensu doładowywania niewielkich skryptów, których zawartość powinna być dostępna dla przeglądarki jak najszybciej po akcji wykonanej przez użytkownika – jak ten kalendarz po kliknięciu w ikonkę (no chyba że ma np. 50kB). Klikam, request po plik, pobranie zawartości, przeparsowanie, wykonanie -> zawsze to lekkie zmniejszenie responsywności.
Nie ma co oszczędzać jakoś strasznie na transferze. Jeśli taką bibliotekę przelecimy jakimś packerem, później apache gzipem, to waży ona kilka kB. Nie tu szukałbym optymalizacji.
Trafił mi się ostatnio w pracy projekt, który zakładał przechodzenie pomiędzy podstronami serwisu bez przeładowywania części strony (której ładowanie trwa zbyt długo). Podczas przejścia na następną podstronę należało doładować odpowiednie skrypty i w momencie kiedy będą dostępne wykonać jakiś tam kod. Postanowiłem wykorzystać Head.js, bibliotekę, której prostota przypadła mi do gustu. Wszystko zaimplementowałem – pod Chrome wspaniale śmiga. Pod Fxem i Operą nie – callbacki, które powinny być odpalone w momencie załadowania skryptów nie są wykonywane. Skrypty się pojawiają, ich zawartość jest dostępna, ale callbacki milczą, żadnych błędów, nic.
Spróbowałem stworzyć PoC żeby zgłosić błąd, ale nic z tego – próby uproszczenia przykładu kończyły się tym, że wszystko śmigało pod każdą z przeglądarek. Gdybym miał więc oceniać Head.js, to odradzam. Nie wiem gdzie był błąd, ale na mój gust nie po mojej stronie. Poza tym w Head.js nie za bardzo podobało mi się to, że biblioteka ta nie służy tylko do ładowania skryptów ale robi też np. wykrywanie ficzerów przeglądarki (tak na marginesie – z błędem). Trochę to bez sensu.
W każdym razie – dzięki za przegląd dostępnych bibliotek. Kiedy następnym razem będę musiał z czegoś skorzystać sprawdzę jakąś inną z Twojej listy :)
BTW. Zdeczka za mały font jest na tej stronie – ciężko mi się czyta.
BTW2. Może rozwinę trochę swoje myśli z tego komcia na blogu… Ciekawe czy znajdę czas :)
@Piotrek, Twój komentarz jest prawie dłuższy niż cały mój wpis :-) w dodatku bardzo wartościowy.
A więc po kolei:
1) Zgadzam się – dobrze jest połączyć kilka głównych plików w jeden i kompresować/trzymać w buforze, a resztę pliczków trzymać osobno i wczytywać dopiero po wejściu na podstronę xyz – też tak najczęściej robię/robiłem.
2) O osadzaniu JavaScriptu przed zamknięciem BODY też już gdzieś na blogu wspominałem niejednokrotnie i technika ta jest mi znana / lubiana / polecana.
3) W przypadku wspomnianego kalendarza to funkcjonalność ta nie była potrzebna „od razu”, a po 1-3 sekundzie najszybciej. Klient zaznaczał checkbox, że posiada drukarkę. W tym samym momencie odkrywałem ukryte przyciski + wczytywałem plik kalendarza. Zanim klient doszedł do pola z wyborem daty to miał dwa inne pola do wypełnienia – w tym czasie spokojnie zdążył się załadować kalendarz (ponad 20kb).
4) head.js nie testowałem, natomiast LABjs i bardzo polecam tą bibliotekę. Podczas kolejnej okazji zamierzam jeszcze przetestować ControlJS – posiada kilka fajnych funkcji, które nie posiadają inne biblioteki, jak np. wykonanie wczytanego kodu JavaScript dopiero na żądanie.
5) Też ciężko mi się czyta tego bloga, dlatego już pracuję nad redesignem :-)
Summa summarum, dziękuję za tak konkretny komentarz i z chęcią poczytam, jeśli postanowisz samemu rozwinąć temat na swoim blogu ;)
Ad3. Skoro tak, to zwracam honor :)
Ad4. Jeśli znajdę czas na przygotowanie biblioteki do obsługi tego XHRowego przechodzenia pomiędzy podstronami, to przetestuję coś z tych rozwiązań, które podałeś. Bo w tej chwili z powodu braku callbacków musiałem dostosować JS, a może uda mi się tę bibliotekę zrobić tak żeby dało się ją odpalić z jednej linii.
Jeszcze jest jeden sposób.
Dla każdej podstrony tworzy się jeden plik zawierający wszystkie skrypty dla niej przeznaczone.
Jeśli mała stronka – to i tak w 90% będzie jeden plik ze wszystkimi skryptami.
A przy większych, ilość requestów per dodatkowy skrypt… przegrywa z jednym plikiem.
@Michał: można i tak. Widziałem, że tak robisz w swoim frameworku :-) Też będę musiał u siebie coś podobnego zaimplementować – przydaje się zwłaszcza w tych bardziej statycznych projektach (z niewielką ilością JavaScript).
Kolejna świetna biblioteka warta wspomnienia: yepnope.js. Przydatne zwłaszcza przy wczytywaniu tzw. HTML5 Cross Browser Polyfills. W połączeniu z Modernizr jest naprawdę przydatnym i fajnym rozwiązaniem:
2
3
4
5
test : Modernizr.geolocation,
yep : 'normal.js',
nope : ['polyfill.js', 'wrapper.js']
});
Genialny wpis. Dawno nie czytałem tak merytorycznego tekstu. Oby więcej takich publikacji. Już nie mogę się doczekać :)
Witam, miałbym jedno pytanie.
Chciałbym wczytać plik .js po przejściu na podstronę, która jest wczytywana za pomocą AJAX’a poprzez Lab.js, lecz nie za bardzo wiem jak to zrobić, mógłbyś mnie oświecić ?
@Jacek:
pozwól, że przedstawię to na pseudo-kodzie:
2
3
4
5
success: function(data) {
$LAB.script('/script.js');
}
});
:)
Hmm to się nie sprawdzi u mnie, ale dziękuje za odpowiedź.
Tak przeglądam tą dokumentację i patrze na kawałek twojego skryptu i miałbym za to inne pytanie czy dzięki lab.js mógłbym wczytać jakiś plik np. po wystąpieniu jakiegoś zdarzenia(np. klik w w element o id=”laduj”) ?
P S
co do samego artykułu pierwsza klasa, w końcu artykuł o czymś co ciężko znaleźć w polskiej ‚sieci’ :)
@Jacek: to o czym piszesz to absolutne podstawy JavaScript – zajrzyj proszę do jakiegoś kursu (https://developer.mozilla.org/pl/docs/JavaScript) i poznasz odpowiedzi na powyższe pytania.
Oj moje pytanie nie było na poziomie :/
Trochę zbyt odbiegłem od JS i za bardzo skupiłem się na samym .script(„adres”).jakaś_funkcja(), zamiast napisać jakiś warunek i w niem .script(), ehh przepraszam za ten spam nie najwyższych lotów…
Dziękuje za pomoc :)
Następnym razem postaram się lepiej zaprezentować moją wiedze co do JS, gdyż wydaje mi się, że znajduję się nad dnem :]
@Jacek: bez przesady. Nie ma sprawy, zawsze chętnie służę pomocą, choć przy takich podstawach wolę odesłać do kompleksowego kursu – nie ma sensu bym ponownie tłumaczył coś, co już zostało wytłumaczone n razy. Swoją drogą link, który podałem, stanowi świetne źródło wiedzy – polecam jako lekturę :)
MDN jest mi bardzo dobrze znaną stroną.
Jeszcze raz dziękuje za pomoc ;) i nie ukrywam, że czekam na kolejne wpisy dotyczące JS
Do asynchronicznego ładowania plików polecam bibliotekę „autoloadjs” :
https://github.com/szagi3891/autoloadjs
Działa ona na zasadzie wczytywania potrzebnych „modułów” wraz ze spełnieniem wszystkich wymaganych zależności. Moduły sami sobie definiujemy w pliku konfiguracyjnym. Biblioteka wczytuje skrypty nawet jeśli w bibliotece została użyta instrukcja document.write (demo pokazuje że można za jej pomocą wczytać nawet google mapy)
@szagi3891:
1) może i się czepiam, ale ten atrybut „data_load” wygląda kiepsko. Nie mogło być data-load czy data-config? W końcu od tego są atrybuty data-*.
2) w pliku konfiguracyjnych pozwalasz wczytać zarówno pliki JS, jak i CSS; tylko dlaczego format rozpoznajesz po rozszerzeniu pliku? A co jeśli jakiś zaciągany z zewnątrz plik nie będzie miał rozszerzenia? Pliki powinieneś rozpoznawać na podstawie typu MIME, ewentualnie zdefiniować w pliku konfiguracyjnym co jest CSS, co JS.
Poza tym jest ok, choć ja mimo wszystko preferuję RequireJS :)
Istotnie „data_load” to jest niedopatrzenie. Zmienię nazwę tego atrybutu na „data-load” w kolejnej wersji.
Jeśli zaciągany plik nie ma rozszerzenia to jest traktowany jako javascript. Wychodzę z założenia że skoro plik ma rozszerzenie js to jest plikiem js, a jeśli css to jest plikiem css. Nie można przewidzieć każdej możliwej sytuacji i jeśli biblioteka nie stosuje się do tak prostej zasady żeby mieć właściwe rozszerzenie to zastanawiałbym się nad jej użyciem :)
Super że używasz requirejs, będę miał zatem pytania :)
Na początku również chciałem użyć tej biblioteki ale zatrzymały mnie dwie rzeczy.
google maps używają document.write do wczytania kolejnego pliku i z tego co wyczytałem trzeba stosować sporą kombinację alpejską żeby wczytać google mapy za pomocą requirejs. Czy Tobie udało się poprawnie wczytywać google mapy w swoich projektach za pomocą tej biblioteki ?
Druga rzecz, to żeby móc użyć jquery to trzeba stosować jej zmodyfikowaną wersję, czy potwierdzasz ?
No i czy np. za pomocą requirejs mógłbyś wczytać np. bibliotekę colorbox ?
Celem biblioteki autoloasjs było to żeby była maksymalnie przeźroczysta dla projektu. Nie chciałem modyfikować źródeł już gotowych bibliotek tylko móc je asynchronicznie wczytać i użyć.
Hej,
Ciekawy artykuł. Mógłbyś na przyszłość cenne uwagi z komentarzy i nowe ciekawostki dopisywać do artykułu? Np. wspominasz o : yepnope.js, ale w komentarzu.
Przy linkach brakuje mi elementu title. Zwłaszcza w takich linkach jak zerknij tu przyklad1, przyklad2, ktore odwołują sie do zewnętrznych serwisow.
Jakby dało jeszcze radę rozszerzyć content, żeby tak kod nie trzeba było przewijać. W dobie FullHD i Retina 2500px…
@Lechus: cześć, dzięki za komentarz.
Ad. 1) Raczej nie widzę potrzeby by na bieżąco aktualizować wpisy – jest z tym za dużo roboty, która przyniosłaby niewielkie korzyści. Jeśli bowiem ktoś jest zainteresowany tematem to z pewnością zapozna się też z treścią komentarzy (nie przepuszczam spamu ani niemerytorycznych treści, więc niewiele tego zostaje :)).
Ad. 2) Przy linkach faktycznie brakuje czasem elementu TITLE. Po części z lenistwa, po części z braku takiej potrzeby (nie ma sensu powtarzać to co jest w anchorze). Postaram się na przyszłość dokładniej opisywać odsyłacze.
Ad. 3) Tutaj w pełni się zgadzam – korzystam z dość starego, darmowego szablonu do WordPressa. Za jakiś czas wdrożę zupełnie nowy szablon, który będzie responsywny i bardziej czytelny.
W komentarzach poruszasz kwestię AMD w oparciu o RequireJS, ale w samym wpisie nie pokazujesz nic o takim podejściu (także nic CommonJS). Uważasz to za inną klasę sposobów ładowania, czy po prostu tak wyszło?
@Patryk yarpo Jar: z tego co pamiętam to w momencie pisania tego wpisu nie było jeszcze wtedy AMD/RequireJS (albo były niedoskonałe/nikt o nich nie słyszał).
[…] dwa lata temu opisywałem sposoby wczytywania plików JavaScript, gdzie wymieniłem kilka fajnych bibliotek do asynchronicznego doczytywania […]