Dodatkowo zapraszam (w szczególności uczestników GTUG-a, na którym było więcej kodu) do projektu na Githubie, gdzie wgrałem źródła.

Na koniec chciałem jeszcze podziękować organizatorom za trud włożony w dogranie tych spotkań i Wam, uczestnikom, za przybycie i zadawanie ciekawych pytań :). Do zobaczenia na następnych imprezach.

Podobne wpisy:

1. Wrocław wita JavaScript – Meet.JS i Wrocław GTUG
2. meet.js – JavaScriptowe spotkanie w realu
3. Node.js i middle-end – przenośny kod i emulacja przeglądarki

Meet.JS

Żeby się nie powtarzać, za Damianem Wielgosikiem:

Meet.js jako społeczna i darmowa platforma dzielenia się wiedzą o technologiach front-endowych rozwija się w niesamowitym tempie. Dzięki chłopakom z firmy Monterail.com spotkania meet.js będą organizowane również – obok Poznania, Warszawy i Krakowa – we Wrocławiu.

Pierwszy event odbędzie się w najbliższy czwartek 24.11.2011 w siedzibie Monterail. Start od 18!

Jednocześnie poszukiwani są prelegenci do tego ekscytującego wydarzenia. Jeśli chcesz podzielić się czymś o HTML5, CSS3 czy JS nie zastanawiaj się! Bartek Pietrzak, organizator meet.js, czeka na zgłoszenia wszystkich chętnych pod bartosz@monterail.com.

Więcej informacji na Facebooku, @meetjs i u Damiana.

Wrocław GTUG – Wrocław Google Technology User Group

Z braku weny, również cytat, tym razem z oficjalnej strony wydarzenia:

Zapraszamy serdecznie na pierwsze spotkanie wrocławskiej grupy GTUG.

Zaczniemy krótkim wprowadzeniem na temat działalności naszej grupy. Jednakże tematem wiodącym spotkania będą aplikacje dla platformy Chrome. Poruszone zostaną zagadnienia związane z możliwościami jakie daje ta platforma. Postaramy się zaprezentować przykładowe aplikacje oraz technologie wykorzystane do ich stworzenia.

Na koniec przedstawimy pomysły na kolejne eventy i ewentualne tematy kolejnych spotkań.

Po spotkaniu proponujemy wspólne wyjście na piwo :)

Spotkanie odbędzie się we wrocławskim biurze Google (Bema Plaza) we wtorek, 29 listopada, o godzinie 19:00. Możliwe są jeszcze drobne korekty dotyczące miejsca i na pewno pojawi się formularz rejestracyjny. Tak więc polecam śledzić WroGTUG-a, do wyboru – Facebook, Google+, @wroclawgtug.

Do zobaczenia!

Ja okazji nie przegapię i jeśli studia nie przeszkodzą, to pojawię się na obu spotkaniach. Sam niestety, ze względu na napięty czas przed obroną pracy inżynierskiej, nic nie powiem, ale prelegentów nigdy dość, więc chętni niech się zgłaszają :).

Przy okazji dowiedziałem się, że nie tylko ja uważam, że we Wrocławiu firm zajmujących się frontendem na poziomie praktycznie nie ma. Mamy setki korporacyjnych miejsc pracy dla programistów Javy i C#, ale związanych z webem prawie nie widać. Najgorzej wypada JavaScript, w związku z czym swój wzrok musiałem skierować na Poznań, Kraków, czy Warszawę. Trochę szkoda będzie wyjeżdżać :).

Podobne wpisy:

1. Moja prezentacja o Node.JS z Meet.JS i GTUG Wrocław
2. meet.js – JavaScriptowe spotkanie w realu
3. Walka Dart vs JavaScript – nokaut podczas ważenia

Pożal się Google

To co zrobiło Google, to żart. Cała historia z wewnętrznymi, nie do końca miłymi mailami z Google’a, które wyszły na światło dzienne, sam Dart i otoczka PR-owa jaką ma, to jedno wielkie nieporozumienie. Google się nie popisało i, moim skronym zdaniem, wyjdzie to tylko na dobre open webowi.

Wyobraźmy sobie, co by się stało gdyby Dart rzeczywiście powalał na kolana i miałby świetnie zaimplementowaną, super wydajną i dostępną out of the box w Chrome maszynę. Szybko znalazłoby się grono fan boy’ów, którzy bez zastanowienia zaczęliby pisać aplikacje „only for Chrome”, bądź „works best with Chrome”, z ewentualną, wątpliwej jakości, kompilacją do powolnego i starego JavaScriptu dla „gorszych przeglądarek”. (BTW. hello world w Dartcie skompilowany do JS to 17000 linii kodu :D).

Po chwili okazałoby się, że Google, wykorzystując swoją pozycję lidera na wielu rynkach, zaczyna (pośrednio – przez zadowolonych użytkowników) wymuszać na innych producentach implementację Darta. No dobra – wygrał, ale w czym problem, pytacie? W tym, że Google nie raczy podzielić się odpowiedniej jakości specyfikacją języka i Mozilla, MS, czy Opera zostają zmuszone do reverse engineeringu z Chrome’a. Brzmi jak głupia apokaliptyczna wizja? Problem w tym, że ten przypadek już mieliśmy z protokołem SPDY, ponieważ Mozilla została zmuszona przez Google do zgadywania jak on w szczegółach działa. Koniec końców, po wykonaniu nieprzyjemnej pracy, pozostali producenci i tak kończą z „gorszą” implementacją. Innymi słowy – wracamy do czasów wojny przeglądarek i nieczystych zagrań. W dodatku pieczę nad specyfikacją języka sprawuje Google i wcale nie mamy pewności, czy się nią podzieli.

Dalej brzmi to jak bajka? Ciekawostka – opublikowana „specyfikacja” (wczesny draft oczywiście) Darta ma 70 stron, a specyfikacja wiele razy mniej złożonego ES5 250 stron. I nie, nie z powodu wielkości fonta. Mówicie – są języki, które radzą sobie bez specyfikacji – Python, Ruby – i są świetne (ktoś wymienił PHP – strzał w stopę w tej dyskusji :D). Tak, ale implementuje je jeden producent. W webie to nie działa i nigdy nie działało. Chcecie żeby przeglądarki miały spójne implementacje, to nie cofajcie się teraz o krok wstecz (prawie jak cofać się do tyłu :P). Nie po to wielokrotnie straciliśmy włosy na głowie (a i twarz też, bo czasami głupio się przyznać – „jestem programistą JavaScript”), by zapominać czego nauczyła nas historia. Nie po to został włożony i nadal jest wkładany ogromny trud w to, by ujednolicić i dogłębnie dospecyfikować wykorzystywane przez nas technologie, byśmy teraz tę pracę skreślili i zaczęli od początku. W szczególności, że…

Na poważnie, czyli z forkowaniem za pan brat

… nie ma takiej potrzeby. Wiele osób, w tym i ja, narzeka na JavaScript. Niektórzy wciąż nie wiedzą ile naprawił ES5 ze strict modem, niektórzy też nie zdają sobie sprawy ile jeszcze problemów jest do rozwiązania. Większość jednak narzeka i moim zdaniem słusznie. Na szczęście trwają prace nad ES6 aka Harmony aka ES.next (w których oczywiście Google uczestniczy). O ile, co smutne, ale racjonalne, ES5 nie wprowadził żadnych (może poza strict modem) przełomowych zmian w JavaScriptcie, o tyle ES6 takie zmiany ma wprowadzić, włącznie z dużymi w składni (choć Marcoos mi ostatnio powiedział, że myślą o wydaniu pośrednim, bez zmian składniowych, stąd pośrednie nazwy – oby pomysł upadł – miejcie jaja, Panowie!).

Na pewno jednak ten właściwy ES6 zrywa ze wsteczną zgodnością. Jest więc pole do popisu i czas, by, jeśli ktoś się postara, niemal od nowa projektować pewne aspekty języka. Można mieć tylko jeden zarzut do Harmony – nic nie wiemy o planowanym terminie zakończenia prac. Jednym z argumentów zwolenników strategii Google jest to, że „nie chcieli czekać, aż się powolny komitet naprodukuje i jako największy gracz wzięli sprawy w swoje ręce”. Brzmi niemal przekonująco. Poza tym, że Darta też szybko w wersji stabilnej i szeroko dostępnej nie zobaczymy (jeśli w ogóle). W dodatku praktyka odległej wersji finalnych HTML5 i CSS3 pokazuje, że dzięki wczesnym prototypom częściowym możemy raz, że wiele poprawić jeszcze podczas prac nad specyfikacją, dwa że płynnie przejść pomiędzy wersjami i szybko z nowych ficzerów korzystać. Co prawda JavaScript, to nie CSS, gdzie możemy sobie pozwolić na graceful degradation, jednak gracze typu Google bez problemu mogą serwować inne źródła w zależności od zdolności przeglądarki (a i tak mówimy o kompilacji ES6 do ES3, bo polyfilli to nie będzie). W dodatku wiele osób pisze aplikacje w JavaScript na w miarę przewidywalne środowiska (intranet, komórki, serwer), gdzie problemu nie ma w ogóle.

Stąd przechodzę do pytania – dlaczego Google zamiast forkować istniejące rozwiązania, nie zdecydowało się na wczesną, testową implementację ES6 w V8 (choć zdaje się chodziły takie słuchy)? Dzięki temu mogłoby wpływać na prace komitetu (wprowadzać ficzery w V8 i pokazywać, że świetnie się przyjmują wśród developerów, bądź po prostu dobrze działają), przyspieszyć je i poprawić zawczasu wiele wątpliwych kwestii. Spotkałem się też z argumentem, że konkurencja jest przecież dobra. Owszem, mamy na szczęście kilku producentów i stosunkowo równomierny ich udział w rynku. Moim zdaniem to wystarcza, co widać choćby na przykładzie wcześniej przeze mnie wspomnianych HTML5 i CSS3 (kontrargument swoją drogą, to to, że wyścig rodzi kiepskie implementacje – vide koszmarne formsy).

Bawi mnie niezmiernie jeszcze jedna kwestia. Dart wcale nie jest fajny. Wygląda jak Java, jest toporny, nie ściągnie gawiedzi jak laska z cycem na wierzchu zwana CoffeeSkryptą (BTW. uroda z inteligencją w parze nie idzie – to może ten Dart taki zły nie jest? Małżeństwo z rozsądku? ;). Nie jest też wybitnie rewolucyjny, ani… odległy od ES6. Koncepcje, które znalazłem w Dartcie widywałem też w materiałach o ES6. Jego implementacja też póki co nie powala na ziemię pod względem wydajności, a był to przecież podobno jeden z powodów porzucenia JS. W dodatku pokazuje to jak wiele pracy jest do wykonania, by dogonić już wiele lat rozwijany engine V8. To jest kolejny powód dla którego nie rozumiem decyzji Google’a.

Jest też plus

Jest jednak jedna rzecz, która mi się podoba w Dartcie – szersza biblioteka standardowa (włączając w to sensowną implementację DOM-a). Uważam, że w tej chwili jednym z największych problemów JavaScriptu, jest brak ustandaryzowanych (mniej, lub bardziej formalnie) podstawowych narzędzi. Ja np. w najświeższym projekcie postanowiłem wykorzystać deferred i es5-ext skompilowane do niecommonjsowej postaci. Zastanawiałem się jednak, czy nie wolę underscore’a. Ale zaraz – deferred i tak korzysta z es5-ext, więc ten kod i tak załaduję (tutaj ukłon w kierunku Medikoo – na szczęscie es5-ext jest 100% zmodularyzowane, więc konfigurowalne). Potrzebowałem jeszcze czegoś do DOM-a. Z jQuery nie skorzystam, bo nie potrzebuję 90% (dosłownie!) tej biblioteki, w dodatku pokrywa mi się z deferred i trochę es5-ext, no i szukałem czegoś lekkiego. Trafiłem na xui.js, które okazało się niedopieszczone. Szukałem czegoś do single page apps – Backbone? Nieee… ktoś wymyślił, że dla XHR-a, delegate’a i deferred (i czegoś jeszcze?) skorzysta z jQuery. Jeszcze gorzej chyba ze Spine.js, gdzie znalazłem jakoś z 5 odniesień do jQuery, ale zaszytych głęboko w kodzie, bez możliwości łatwej podmiany. Przy całym tym śmietniku idiotycznych decyzji twórców tych (i wielu innych) narzędzi, są myślące osobniki, które wyprodukowały takie mini biblioteki jak Crossroads, czy js-signals. Robiące dokładnie jedną rzecz i nie zawierające zbędnych zależności.

Żalę się generalnie, ale nie bez powodu. Dart rozwiązałby połowę moich problemów. Mamy i promise’y, i wygodniejszego DOM-a. Dużo więcej ciekawych rzeczy niestety nie znalazłem, ale początek jest dobry. Uważam, że to jest aspekt języka, na który powinny zwrócić uwagę osoby pracujące nad ES6. Wiem na pewno, że jeden problem zostanie rozwiązany – zostaną wprowadzone natywne moduły. Trochę martwi mnie ich rozbieżność w stosunku do CommonJS-owej wersji (i trochę niezrozumiała dla mnie decyzja o wprowadzeniu nowej składni), ale może uda się to zgrabnie rozegrać.

Podsumowując

Nie wierzę, a przynajmniej nie chcę wierzyć, w sukces Darta. Póki co niczym mnie nie zainteresował i nie zamierzam się w niego zagłębiać. Mam nadzieję, że byłaby to strata czasu.

Zauważyliście pewnie, że brakuje w treści linków do źródeł. Tak – nie chce mi się. Google w tym wypadku pomoże :). Poza tym, nie chcę być wyrocznią, nie chcę napisać pracy doktorskiej, nie chcę nikogo zniszczyć, wypunktowując go bezlitośnie. Co więcej, możliwe, że sam niedługo zmienię na co poniektóre tematy zdanie, bo i nie mam pełnej wiedzy o tym co się dzieje i co się stanie. Powyższa opinia rodziła się we mnie jednak już kilka tygodni, więc nie jest też pisana pod wpływem wielkich emocji. Może więc jest racjonalna :).

Podobne wpisy:

1. Wrocław wita JavaScript – Meet.JS i Wrocław GTUG
2. Zarezerwowane słowa kluczowe w JavaScript – gramatyka języka
3. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings

1. Moja prezentacja o Node.JS z Meet.JS i GTUG Wrocław
2. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings
3. Zapraszam na darmowe szkolenie DevMeeting – middle-end w oparciu o NodeJS

Ekipa organizująca szkolenia zwróciła się do mnie z prośbą, bym zastąpił Davida, któremu wypadły pilne sprawy. Nie mogłem odmówić i zabrałem się za przygotowania. Czego możecie się spodziewać? Na pewno szkolenie będzie kręciło się w okół Node’a i middle-endu. W związku z obserwacjami dotyczącymi problemów, jakie z SSJS mieli uczestnicy warszawskiego meetingu, postaram się wyjaśnić, jak organizować kod, radzić sobie z asynchronicznością, czy pisać przenośne moduły w standardzie CommonJS. Poruszę więc kwestię odmiennych charakterystyk przeglądarkowego i serwerowego JavaScriptu. Wstęp ten przyda się do zadań praktycznych, które tak jak na pozostałych jesiennych meetingach będą kluczowym elementem Krakowskiego szkolenia.

Rejestracja jest darmowa i jeszcze otwarta. Do zobaczenia w Krakowie :)

Podobne wpisy:

1. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings
2. Moje prezentacje z DevMeetings i MeetJS
3. Node.js i middle-end – przenośny kod i emulacja przeglądarki

DevMeetings – hot topics

Na początku lata ekipa z DevMeetings zorganizowała trzydniowy DevCamp, na którym wykrystalizowały się trzy ciekawe backendowe tematy. Teraz nadszedł czas, aby przyjrzeć im się dokładniej. I tak odbędą się po kolei:

• Wydajność Node.JS kontra reszta świata (3 września, Poznań) – kontrowersyjny temat – ile prawdy jest we wszystkich stwierdzeniach o super wydajności Node’a? Trochę na ten temat dowiedzieliśmy się już na DevCampie (polecam zajrzeć do materiałów z naszych badań), jednak wiele osób krytykowało zastosowane podejście jako zbyt oderwane od rzeczywistości. Dlatego tym razem postaramy przygotować się prawdziwą aplikację i na tej podstawie wyciągnąć wnioski. Rozpoczęła się już dyskusja, o tym jak podejść do tematu. Ja oczywiście będę, a Ty wciąż możesz się zarejestrować.
• Bazy noSQL-owe – naturalny storage aplikacji JSON-owych (10 września, Warszawa) – drugi temat na czasie, czyli bazy noSQL-owe (np. CouchDB, MongoDB, Redis). Meeting powinien być interesujący dla zwolenników, jak i przeciwników tego typu rozwiązań, w końcu nie ma nic lepszego niż potężny flame :). Jedni i drudzy dodatkowo dowiedzą się jak radzić sobie w nowym środowisku, które wymaga nowego podejścia (żegnaj SELECT, witaj map-reduce). Tym razem mnie nie będzie, bo do Warszawy mi zbyt daleko, ale i tak polecam :). Również można się jeszcze zarejestrować.
• Middle-end w oparciu o serverside JavaScript (24 września, Kraków) – to temat, na który czekam z niecierpliwością. Z jednej strony bowiem wiem co to middle-end, o którym nawet pisałem, a na DevCampie bawiliśmy się w jego implementacje, z drugiej, faktyczna architektura całego przekroju zastosowań (nie tylko DOM po stronie serwera, ale też np. walidatory) jest dla mnie pewną zagadką. Polecam ten temat wszystkim, którzy zastanawiali się kiedyś tym, czy da się współdzielić kod pomiędzy serwerem i przeglądarką i jak do tego podejść. Ja oczywiście będę i zachęcam do rejestrowania się.

onGameStart – first HTML5 conference

Konferencja organizowana przez Michała Budzyńskiego odbędzie się 22-23 września w Warszawie. Michałowi udało się ściągnąć wielu ciekawych prelegentów, więc na pewno warto posłuchać co mają do powiedzenia. W szczególności, że temat gier budowanych przy użyciu pakietu HTML5+CSS3+JS, jest ostatnimi czasy bardzo na topie i dużo w tej kwestii się dzieje. Mnie niestety nie będzie, mimo że wygrałem bilet, ale polecam zainteresowanym. Bilety po 79 i 89 euro są jeszcze do kupienia. Można też spróbować wygrać bilet u Lidii Wilczyńskiej.

Front Row Conference

Konferencja poświęcona frontendowi, która odbędzie się 20-21 października w Krakowie. Póki co nie ogłoszono zbyt wielu prelegentów, ale dwóch może być Wam znanych. To wspomniany przeze mnie przed chwilą Michał Budzyński oraz znany uczestnikom DevMeetingów Marek Pawłowski. Bilety do kupienia po 123 euro. Na razie, przyznam szczerze, odnoszę wrażenie, że organizatorom idzie topornie z organizacją, ale kibicuję im, bo im więcej tego typu imprez w Polsce, tym lepiej.

Do zobaczenia we wrześniu i październiku!

Podobne wpisy:

1. Falsy Values 2011 – prawdziwy JavaScriptowy event
2. meet.js – JavaScriptowe spotkanie w realu
3. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings

W tym artykule chciałbym wyjaśnić czym jest hoisting i porównać deklaracje funkcji (function declarations) z wyrażeniami funkcyjnymi (function expressions). Zauważyłem, że są to tematy obce wielu programistom JavaScript i myślę, że o ile test z poprzedniego artykułu wielu z Was nie powinien sprawić problemu, o tyle poniższy ma szansę być małym zaskoczeniem. Taką mam przynajmniej nadzieję :).

Źródła z których korzystałem, umieściłem na końcu wpisu.

Sprawdź się!

Spróbuj rozpoznać co wydrukuje każde wywołanie console.log. Skrypt z wszystkimi pytaniami, wraz z odpowiedziami wrzuciłem na Gista.

Hoisting

console.log('3.1:', a);
 
console.log('3.2:', b);
var b = 1;
 
 
console.log('3.3:', c);
if (false) {
    var c = 1;
}
console.log('3.4:', c);
 
 
var d = 10;
(function () {
    if (d === 10) {
        var d = 20;
    }
    console.log('3.5:', d);
})();

Funkcje

a('4.1:');
var a = function (i) {
    console.log(i, '1');
};
function a(i) {
    console.log(i, '2');
}
a('4.2:');
 
 
function b() {
    console.log('4.3: 1');
}
function b() {
    console.log('4.4: 2');
}
b();
 
 
var c1 = function c2(i) {
    console.log(i, c1, c2);
};
c1('4.5:');
c2('4.6:');

Hoisting, czyli wynoszenie

Myślę, że nikomu nie powinien sprawić problemów przykład 3.1. To będzie oczywiście RerefenceError. Co jednak dostaniemy dla przykładu 3.2? Deklaracja zmiennej b znajduje się w kodzie poniżej próby jej użycia, a więc też błąd? Nie – dostaniemy wartość undefined.

Zachowanie to jest efektem hoistingu (po polsku – wynoszenie). Polskie tłumaczenie co prawda lepiej informuje nas o wyniku działania tej konstrukcji, jednak brzmi strasznie, tak więc będę go unikał (przynajmniej w rzeczowniku :).

Czym jest więc hoisting? Jest to wyniesienie deklaracji zmiennych, bądź funkcji do samego początku kontekstu deklaracji (najczęściej ciała funkcji – zasięg funkcyjny), przy jednoczesnym pozostawieniu inicjalizacji samej zmiennej w oryginalnym miejscu. Takie zachowanie jest spowodowane istnieniem dwóch etapów wykonywania kodu, o czym pisze Dmitry Soshnikov:

There are two stages of the code handling: (1) entering the context, where all the data are created, and (2) the code execution stage.

Dla przykładu przyjrzyjmy się następującej funkcji:

var fn = function () {
    var sth = getSomeStuff();
 
    var sthelse = [1, 2, 3];
    for (var i = 0; i < sthelse.length; ++i) {
        var sth = sthelse[i];
    }
 
    for (var i = 0; i < 3; ++i) {
        if (i > 10) var ok = true;
    }
};

Taka funkcja zostanie przez interpreter wykonana w następujący sposób:

var fn = function () {
    // etap 1. - deklaracje
 
    // zmienne automatycznie zostają
    // zainicjalizowane wartością undefined
    var sth, sthelse, i, ok;
 
    // etap 2. - wykonanie
 
    sth = getSomeStuff();
 
    sthelse = [1, 2, 3];
    for (i = 0; i < sthelse.length; ++i) {
        sth = sthelse[i];
    }
 
    for (i = 0; i < 3; ++i) {
        // wyjaśnienie pkt. 3.3: wszystkie deklaracje są wynoszone
        // nawet te do których interpreter nigdy nie dojdzie
        if (i > 10) ok = true;
    }
};

Jak widzisz, wszystkie zmienne zadeklarowane w obrębie całego ciała funkcji zostają zgromadzone na początku. By wyeliminować „magię”, identyczny zabieg stosują ręcznie niektórzy programiści JavaScript i deklarują wszystkie zmienne na samym początku ciała funkcji (czasami wraz z inicjalizacją tych wartości, których wartość jest znana od początku). Ja też tak postępuję jeśli ciało funkcji jest na tyle długie, że mógłbym pogubić się które zmienne mam zadeklarowane, a które nie. Przykład żywcem z kodu, który pisałem wczoraj:

var txt_ratio = Math.ceil(TXT_WIDTH / TXT_HEIGHT),
    rows, cols,
    geometry,
    x, y, i, t, d, xi, yi, rowi, coli;

Jak widać, bywa tego dużo :). Tak na marginesie, o ile w ogóle dobrą praktyką jest dzielić dłuższe funkcje na kilka osobnych, o tyle w JavaScriptcie jest to jeszcze ważniejsze. Dlaczego?

Wady hoistingu

Daleko szukać nie trzeba, by trafić na pierwsze wady hoistingu. W szczególności początkujący programiści nie lubią magii i niejawnych zachowań czy to we frameworkach, czy w językach samych w sobie. Spójrzmy na przykład 3.5 z testu (wyciągnąłem go z prezentacji Damiana Wielgosika):

var d = 10;
(function () {
    if (d === 10) {
        var d = 20;
    }
    console.log('3.5:', d);
})();

Na pierwszy rzut oka myślimy (sam przed chwilą to zrobiłem :D) – d jest równe 10, więc warunek się wykona i dostaniemy wartość 20. Nic bardziej mylnego. Powyższy kod zostanie wykonany w następujący sposób:

var d = 10;
(function () {
    var d; //undefined!
    if (d === 10) {
        d = 20;
    }
    console.log('3.5:', d);
})();

Nieco inny, ale nawet łatwiejszy do doświadczenia, przykład podał Dmitry Soshnikov:

var a = 10;
 
(function () {
    alert(a); // undefined ?
    var a = 20;
})();

CoffeScript na lekarstwo?

Problem ten dostrzegli autorzy CoffeScriptu i postanowili mu zaradzić:

outer = 1
changeNumbers = ->
  inner = -1
  outer = 10
inner = changeNumbers()

Powyższy kod zostanie skompilowany do:

var changeNumbers, inner, outer;
outer = 1;
changeNumbers = function() {
  var inner;
  inner = -1;
  return outer = 10;
};
inner = changeNumbers();

Widać, że zmiennych w ogóle nie trzeba deklarować, ponieważ są automatycznie deklarowane w pierwszym kontekście wystąpienia. Rozwiązuje to problem magii hoistingu, zabezpiecza nam obiekt globalny, ponieważ nie ma opcji, żeby niezadeklarowana zmienna wypłynęła do niego (w czystym JavaScriptcie sprawę załatwia strict mode – polecam). Co jednak jeśli chcemy ograniczyć zasięg zmiennej jedynie do zagnieżdżonej funkcji? Tego chyba autorzy CoffeeScript nie przewidzieli (jeśli się mylę, poprawcie mnie) i dla mnie to duża wada. Dlatego też z tego i kilku innych powodów mówię CoffeScriptowi nie.

A jakieś zalety?

Przedstawiłem wady hoistingu, ale pozostało pytanie – dlaczego w ogóle został wprowadzony, skoro powoduje tyle niejasności? Pytanie jest o tyle dobre, że nie udało mi się znaleźć na nie odpowiedzi. Jedyne o czym wspomina Dmitry Soshnikov to optymalizacja. Jak pokazał jeden z poprzednich przykładów, wyniesienie deklaracji zabezpieczyło nas przed redeklarowaniem zmiennej w pętli (sth), czy przy wielokrotnym użyciu (np. i). Hoisting nie jest jednak jedynym sposobem na radzenie sobie z tymi sytuacjami, tak więc wydaje się, że jego zastosowanie można uznać za złą decyzję twórców języka.

Deklaracje funkcji vs wyrażenia funkcyjne

Temat hoistingu łączy się zgrabnie z tematem funkcji. Okazuje się, że mamy w JavaScriptcie dwie konstrukcje składniowe do ich definiowania. ECMAScript5 specyfikuje obydwie następująco:

FunctionDeclaration :
 
    function Identifier ( FormalParameterListopt ) { FunctionBody }
 
FunctionExpression :
 
    function Identifier_opt ( FormalParameterListopt ) { FunctionBody }

Początkowo wydaje się, że jedyną różnicą jest opcjonalność identyfikatora funkcji. Różnica jednak wynika z możliwości umieszczenia obydwu konstrukcji w różnych kontekstach składniowych. Deklaracja funkcji znajduje się na równi z instrukcją (statement), zaś wyrażenie funkcyjne, jak sama nazwa wskazuje, jest wyrażeniem, które jest dopiero częścią instrukcji.

Domyślam się, że teraz wiesz, że jest jakaś różnica, ale nie wiesz dalej co z niej wynika :). W uproszczeniu można więc powiedzieć, że deklarację funkcji mamy tam gdzie funkcja nie jest wykorzystana jako wartość (jest osobną pseudo-instrukcją). Funkcja wykorzystana jako wartość (jest częścią instrukcji) jest wyrażeniem funkcyjnym. Przykłady:

// deklaracja funkcji
function a() {
}
 
// wyrażenie funkcyjne - zostało przypisane
// więc użycie jako wartość
var b = function (arg) {
    arg();
};
 
// przekazujemy wyrażenie funkcyjne
b(function () {});

Hoisting deklaracji rozwiązaniem testu

Definiując hoisting wspomniałem o tym, że zachodzi on również dla deklaracji funkcji. Inaczej niż w przypadku zmiennych, w tym wypadku wynoszona jest też cała „zawartość” funkcji, nie tylko inicjalizacja zmiennej do undefined. Bardzo spodobał mi się przykład, mojego własnego, skromnego autorstwa, na który, co ciekawe, sam się naciąłem :).

a('4.1:'); // -> 2
var a = function (i) {
    console.log(i, '1');
};
function a(i) {
    console.log(i, '2');
}
a('4.2:'); // -> 1

Na pierwszy rzut oka nie ma w tym żadnego sensu. Kiedy pomyślimy jednak jak wynoszone są deklaracje, wszystko staje się jasne:

var a;
function a(i) {
    console.log(i, '2');
}
a('4.1:'); // -> 2
 
a = function (i) {
    console.log(i, '1');
};
a('4.2:'); // -> 1

Okazuje się, że hoisting deklaracji funkcji niesie ze sobą jeszcze więcej problemów, niż hoisting deklaracji zmiennych. Załóżmy, że mamy dwa pliki ze skryptami. W pierwszym deklarujemy funkcję fn i w drugim również deklarujemy funkcję fn. W środowisku deweloperskim wszystko działa jak należy, jednak kiedy połączymy oba pliki na produkcję, funkcja z drugiego pliku nadpisuje funkcję z pierwszego i teraz również kod z pierwszego pliku korzysta z drugiej funkcji. Co prawda jest to też przykład kiepskiej architektury, ale zdarzyć się może.

Named Function Expressions

Pisałem o tym, że wyrażenie funkcyjne ma opcjonalny identyfikator. Wyrażenia funkcyjne z podanym identyfikatorem, to po prostu nazwane wyrażenia funkcyjne, czyli NFE. Okazuje się, że są bardzo przydatną konstrukcją, ponieważ identyfikator takiej funkcji nie jest widoczny z zewnątrz, a jedynie wewnątrz niej. Przykładem jest ostatnie zadanie z testu:

var c1 = function c2(i) {
    console.log(i, c1, c2);
};
c1('4.5:'); // -> function, function
c2('4.6:'); // -> ReferenceError

Pierwszy powód dlaczego NFE są przydatne, to wycofanie w strict modzie arguments.callee. Dzięki NFE wciąż możemy tworzyć rekurencyjne wywołania. Teraz zamiast pisać (przykład wzięty z wybitnego artykułu kangaxa o NFE):

(function (x) {
    if (x <= 1) return 1;
    return x * arguments.callee(x - 1);
})(10);

Napiszemy:

(function factorial(x) {
    if (x <= 1) return 1;
    return x * factorial(x - 1);
})(10);

Drugi powód to debugowanie. Niestety nienazwane wyrażenia funkcyjne, są niemal anonimowe. Używając ich widzimy później call stack pełen „anonymous function, anonymous function”. I co prawda Google się chwali, że Chrome identyfikuje funkcje anonimowe (po tym do jakich zmiennych, czy właściwości są przypisywane), ale według mnie nie działa to najlepiej. W dodatku jak nazwać funkcję przekazywaną jako callback do jakiejś funkcji? No nie da się. Dlatego w ostatnim projekcie zacząłem nazywać wiele funkcji. Na przykład:

var BigInteger = function BigInteger(num, base, c) {
//...
BigInteger.prototype._addOffset = function _BI_addOffset(n, w) {
//...
BigInteger.prototype.abs = function BI_abs() {

Miałem nie wspominać, ale żeby nie było – Z NFE związanych jest kilka błędów. Większość dotyczy starych wersji Safari (2.x) i Firefoksa (<=3), jednak największym problemem mogą być te związane z IE (<9). Na szczęście są stosunkowo "niekrytyczne", choć jeśli zamierzasz je stosować, to polecam artykuł kangaxa.

FD vs (N)FE – wynik walki

Zdecydowanie wyrażenia funkcyjne. Pomijamy część wad hoistingu, deklaracje funkcji (ponoć) nie wszędzie są dopuszczalne (aczkolwiek nie znalazłem przykładu gdzie nie są – może ktoś zna?), deklaracje funkcji to kiepska kalka z Javy oraz argument ostateczny – 90% naszego kodu to i tak będą wyrażenia funkcyjne.

Źródła, czyli poczytaj więcej

• Dmitry Soshnikov – Note 4. Two words about “hoisting” – bardzo lubię artykuły Dmitry’a, ponieważ schodzi aż do akademickiego poziomu,
• Damian Wielgosik (Ferrante) – prezentacja Just advanced JavaScript – polecam całą, ale część związana z tym artykułem zaczyna się od slajdu 132.,
• Angus Croll – Function Declarations vs. Function Expressions – uzupełnienie i rozjaśnienie tego o czym ja pisałem,
• Juriy „kangax” Zaytsev – Named function expressions demystified – niesamowicie dokładny przegląd dotyczący NFE (m.in. omówienie kilku błędów przeglądarek); tak długie, że nie przeczytałem, ale na pewno to zrobię :D.

Podobne wpisy:

1. Co lepiej wiedzieć o JavaScriptcie cz.1.: typy zasięgu i domknięcia
2. PHP: Statyczne zmienne funkcji — do czego mogą się przydać?
3. Najszybszy stworek – algorytm genetyczny w JavaScriptcie

Spośród listy tematów do opracowania wybrałem pierwsze 3, które moim zdaniem zgrabnie się łączą. Są to zasięg (scope), hoisting (widziałem tłumaczenie do wyniesienie, ale brzmi strasznie) oraz deklaracje funkcji (function declaration – dalej: FD) i wyrażenia funkcyjne (function expression – dalej: FE). Mam nadzieję, że rozjaśnienie tych tematów pozwoli zaoszczędzić komuś trochę czasu :).

Artykuł będzie składał się z dwóch części. Tę część poświęciłem typom zasięgu oraz domknięciom. Następna będzie dotyczyła (edit: już jest dostępna) hoistingu i funkcji.

Sprawdź się!

Na początek niekrótki zestaw krótkich testów. Spróbuj rozpoznać co wydrukuje każdy console.log. Skrypt z wszystkimi pytaniami, wraz z odpowiedziami wrzuciłem na Gista.

Cz.1.

var a = 1;
for (var a = 0; a < 10; ++a) {}
console.log('1.1:', a);
 
 
{
    var b = 1;
}
console.log('1.2:', b);
 
 
var c_fn = function () {
    var c = 1;
};
c_fn();
console.log('1.3:', c);

Cz.2.

var a = 1;
var a_fn = function () {
    return a;
};
 
console.log('2.1:', a_fn());
 
(function (fn) {
    var a = 2;
    console.log('2.2:', fn());
})(a_fn);
 
(function (fn) {
    a = 3;
    console.log('2.3:', fn());
})(a_fn);
 
console.log('2.4:', a_fn());
 
 
var b = [1, 2, 3, 4],
    b_i = 0;
 
for(; b_i < b.length; ++b_i) {
    b[b_i] = function () { return b_i; };
}
console.log('2.5:', b[0]());

Zasięg funkcyjny i blokowy

Jeśli wychowałeś się na JavaScriptcie, pierwszy test nie powinien sprawić Ci żadnego problemu. Jeśli jednak jesteś programistą Javy, bądź języka C(|++|#), to mogłeś odpowiedzieć źle. Jaka jest różnica? JavaScript jest językiem o zasięgu funkcyjnym, zaś pozostałe o zasięgu blokowym.

Analogiczny kod napisany w C++ (dla przykładów 1.1 i 1.2, ponieważ 1.3 jest niewykonalny) zwróciłby odpowiednio 1.1: 1, 1.2: error: ‘b’ was not declared in this scope.

int main() {
    int a = 1;
    for (int a = 0; a < 10; ++a) {}
    cout << a; // -> 1
 
    {
        int b = 1;
    }
    cout << b; // -> błąd kompilacji
 
    return 0;
}

Jak widać, blok, bądź konstrukcja for powodują pojawienie się nowego zasięgu. Po wykonaniu się pętli a wciąż jest równe 1 (więcej przykładów dla C++). Java zachowałaby się nieco inaczej, uniemożliwiając redefiniowanie zmiennej o tej samej nazwie, jednak ogólna zasada byłaby identyczna.

JavaScript za to, określając sobie zasięg zmiennej, nie zwraca uwagi na żadne bloki. Jedynym ograniczeniem dla niego jest funkcja. Każda zmienna zdefiniowana w funkcji jest widoczna w tej funkcji i w funkcjach zdefiniowanych w tej funkcji, ale nigdzie poza nią. Dzięki temu otrzymamy: 1.1: 10, 1.2: b, lecz: 1.3: ReferenceError.

Zostałem kiedyś zapytany, czy istnieje możliwość podejrzenia wewnętrznego scope’a funkcji. Odpowiedź jest na szczęście przecząca (przynajmniej wedle mojego stanu wiedzy). Tak ścisłe ograniczenie zasięgu pozwala nam bezwarunkowo zabezpieczyć kod przed ingerencją z zewnątrz. Stąd na pewno gdzieś już widziałeś konstrukcję:

(function () {
...
}());

Jest to samowykonująca się funkcja. Wszystko co zostanie zdefiniowane wewnątrz niej jest niedostępne z zewnątrz (o ile nie zostało zwrócone).

Zasięg statyczny

Napisałem, że zmienna zdefiniowana w funkcji jest widoczna w tej funkcji i w funkcjach zdefiniowanych w tej funkcji. Takie podejście nazywa się statycznym zasięgiem (druga nazwa to zasięg leksykalny – lexical scoping), z tego względu, że określenie zasięgu polega jedynie na analizie statycznego kodu programu. Przeciwstawnym podejściem jest dynamiczny zasięg, a więc scope funkcji określany jest w momencie jej wywołania, a nie definicji.

Przyjrzyjmy się drugiemu przykładowi do tej części:

var a = 1;
var a_fn = function () {
    return a;
};
 
(function (fn) {
    var a = 2;
    console.log('2.2:', fn()); // -> 1
})(a_fn);

Jak widać, mimo zadeklarowania var a = 2 w miejscu wywołania funkcji a_fn() zostanie zwrócone 1. Tak więc możemy powiedzieć, że funkcja zapamiętała otoczenie swojej definicji. Zachowanie takie nazywa się domknięciem, czyli jest to sławetny postrach początkujących – closure. O domknięciach chciałbym napisać kiedyś osobny artykuł, ale dla utrwalenia jeszcze jeden przykład:

var a = 1;
var outer = function () {
    var a = 2;
    return function () {
        console.log(a);
    };
};
 
var inner = outer();
inner(); // -> 2

Przez referencję, głupcze!

var b = [1, 2, 3, 4],
    b_i = 0;
 
for(; b_i < b.length; ++b_i) {
    b[b_i] = function () { return b_i; };
}
console.log('2.5:', b[0]()); // -> 4

To jest chyba najbardziej znany przykład na to, że zmienne zamykane są przez referencję, a nie przez wartość. Wszystkie cztery funkcje wskazują na tę samą zmienną b_i i są od niej zależne aż po swój kres. Dobrze o tym pamiętać, bo jest to źródłem wielu błędów.

Jeśli jednak chcemy aby funkcje zwracały odpowiednio: 0, 1, 2, 3, to co zrobić aby naprawić powyższy przykład? Zastosować kolejne domknięcie, tym razem jednak przekazując naszą zmienną jako argument, ponieważ te przekazywane są przez wartość (tylko typy proste).

var b = [1, 2, 3, 4],
    b_i = 0;
 
for(; b_i < b.length; ++b_i) {
    b[b_i] = (function (i) {
        return function () { return i; };
    }(b_i));
}
console.log(b[2]()); // -> 2

Zasięg blokowy w JavaScriptcie

Życie z niedoskonałym zasięgiem funkcyjnym (czasem połączonym z domknięciami) bywa nieprzyjemne. W poprzednim przykładzie musieliśmy dodać nadmiarową funkcję, co oznacza zaciemnienie kodu oraz spadek wydajności. Tak samo musielibyśmy się zachować gdybyśmy chcieli aby pętla for mogła iterować po wartości, która nie przesłoniłaby nam innej, zdefiniowanej wcześniej.

var i = 10;
...
for (var i = 0; i < 5; ++i) {}
...
console.log(i); // -> 5! 10 zostało przesłonięte

Twórcy EcmaScriptu szukali więc wyjścia i już w wersji EcmaScript 4 (trochę historii porzuconego standardu) zamierzali wprowadzić słowo kluczowe let mające służyć deklarowaniu zmiennej o zasięgu lokalnym – blokowym. Standard (a w zasadzie jego zalążek) został niestety porzucony na kilka lat i w okrojonym stanie wróci pod nazwą EcmaScript 6 aka Harmony (mój kolejny pomysł na wpis :).

Okazuje się jednak, że część porzuconego EcmaScriptu 4 została zaimplementowana w silniku Firefoksa. Są to JavaScript 1.7 i JavaScript 1.8. Zmienne lokalne są częścią wersji 1.7 i po przestawieniu silnika w odpowiedni tryb można z nich do woli korzystać. Co ciekawe silnik RingoJS domyślnie działa w wersji 1.8, co dawałoby mu ogromną przewagę nad silnikiem Node’a, gdyby nie jego słaba wydajność :).

Przykład wykorzystania let:

<script type="text/javascript;version=1.8">
    var b = [1, 2, 3, 4],
        b_i = 0;
 
    for(; b_i < b.length; ++b_i) {
        let i = b_i;
        b[b_i] = function () { return i; };
    }
    console.log(b[2]()); // -> 2
    console.log(i); // -> ReferenceError
</script>

Ciekawym pytaniem na koniec jest, czy zasięg funkcyjny ma jakiś sens? Czy wraz z wejściem zmiennych lokalnych nie powinniśmy porzucić var?

Ciąg dalszy nastąpi…

Podobne wpisy:

1. Co lepiej wiedzieć o JavaScriptcie cz.2.: hoisting, deklaracje funkcji i wyrażenia funkcyjne
2. Konsola Firebuga – „echowanie” Javascriptu
3. Obiektowy Javascript cz.1. – obiekt Twoim przyjacielem

• hoisting i function declaration vs definition,
• function and block scope + closures,
• dziedziczenie – zaległa część serii o obiektowym JavaScriptcie (cz.1., cz.2.),
• setTimeout vs setInterval – najpewniej pokusiłbym się o tłumaczenie artykułu Johna Resiga z dodatkowymi wstawkami np. o requestAnimationFrame,
• CORS lekarstwem na SOP (artykuł Kamila Brenka) – z uwydatnieniem tego który serwer musi odpowiednio odpowiadać oraz opisem preflighted requests,
• EcmaScript Harmony i JavaScript 1.8,
• obsługa klawiatury – ze zwróceniem na przytrzymywanie i powtarzanie,
• typ Number – dlaczego Math.pow(2, 53) == Math.pow(2, 53) + 1? :)

Mam wielką ochotę napisać na każdy z tych tematów. Boję się może jedynie dziedziczenia, którego sprawa jest na tyle kompleksowa, że praca nad artykułem mogłaby mnie wessać na wieki :). Cierpię jednak na chroniczny brak czasu, więc zachęcam również innych do podejmowania powyższych tematów. Do każdego mam już w głowie przygotowany krótszy, bądź dłuższy konspekt, którym mogę się podzielić.

Interesuje mnie również, czy macie pomysł na inne tematy, których opracowań brakuje w polskim internecie. Gdyby też jakieś z powyższych zagadnień było już w stopniu wystarczającym opisane po polsku proszę o komentarze. Nie ma się co powtarzać.

Podobne wpisy:

1. Obiektowy Javascript cz.1. – obiekt Twoim przyjacielem
2. Obiektowy JavaScript i właściwości chronione – w poszukiwaniu Świętego Graala
3. Zarezerwowane słowa kluczowe w JavaScript – gramatyka języka

Chciałbym zacząć od tego, że pojawiły się już pierwsze podsumowania researchów, jakie wykonaliśmy na DevCampie o ServerSide JavaScript (Node, v8cgi, RhinoJS). W tej chwili dostępnych jest 5 (z 22) tematów:

• Testy wydajności środowisk (CPU oraz I/O)
• Testy systemów generowania szablonów
• Protokoły
• Pisanie bezpiecznego kodu
• Zabezpieczanie kodu źródłowego

Czym w ogóle był DevCamp?

20 doświadczonych developerów spotkało się, by przebadać kwestie związane z praktycznym zastosowaniem JavaScriptu. Opracowaliśmy 18 tematów, zaimplementowaliśmy 4 różne wersje Twittera oparte o różne technologie ServerSide JavaScript. Prawie 40 godzin kodowania, kilka tysięcy commitów do repozytorium

Od siebie mogę dodać, że to były bardzo pobudzające 3 dni, podczas których wiele się nauczyłem. Rzadko ma się okazję spotkać tylu świetnych programistów JavaScript (i developerów w ogóle) i posłuchać co mają do powiedzenia.

Mając do dyspozycji całe 3 dni pierwsze dwa poświęciliśmy na typowy research, a trzeci na podsumowujące implementacje twitterów (miało nie być czata, a wyszedł norealtime’owy czat ;). Research podzielony był na 5 tematów: wydajność, bezpieczeństwo, bazy danych, integracja (middleware, middle-end, obsługa protokołów itp.) i projekty (organizacja kodu, hosting, testowanie itp.). Pierwszy jest oczywiście chwytliwy i nie brakowało na niego chętnych, następne dwa mnie mniej interesowały, a skupić postanowiłem się na dwóch ostatnich. Prace nad nimi natchnęły mnie do napisania artykułu i oto właśnie on.

Middle-end

Aby się nie powtarzać, pozwolę sobie zacytować siebie samego z nieopublikowanego jeszcze (już opublikowanego) podsumowania jednego z DevCampowych tematów:

Jedną z najbardziej interesujących zalet jakie wnosi idea SSJS jest możliwość wykorzystania tego samego kodu zarówno po stronie przeglądarki jak i po stronie serwera. Daje to możliwość współdzielenia części logiki, modelu, walidatorów, czy warstwy widoku. Najprościej przedstawia się sytuacja kiedy od razu napiszemy cały backend w JavaScriptcie, jednak w praktyce częściej będziemy integrować Node.js, czy inne rozwiązanie SSJS, z już istniejącą aplikacją.

Taką warstwę, znajdującą się pomiędzy backendem i frontendem, z zachowaniem pełnej logiki rozumowania, nazywamy middle-endem (po więcej informacji odsyłamy do twórcy tej koncepcji). Zwróćmy też uwagę by nie mylić middle-endu z middlewarem.

Aby myśleć o użyciu tego samego kodu po stronie przeglądarki i serwera musimy zadbać o dwie rzeczy – uruchamianiu skryptów w Nodzie w takim kontekście w jakim odbywa się to w przeglądarce (i najlepiej zupełnie oddzielonym od globalnego) oraz o odpowiednią architekturę naszego kodu, by był on przenośny. Pierwszą kwestię postaram się bardzo dokładnie zbadać w tym artykule. Drugą jedynie napocznę i może do niej wrócę kiedy nabiorę więcej projektowego doświadczenia w tym temacie.

Kontekst przeglądarki

console.log(this === window);
 
var a = 1;
console.log(this.a);
 
console.log(window);

Co otrzymamy jeśli ten kod uruchomimy w przeglądarce? Oczywiście będą to po kolei: true, 1, DOMWindow. To samo zachowanie chcielibyśmy uzyskać w Nodzie. Pierwszym naszym zadaniem będzie uzyskanie obiektu window, a więc implementacji DOM-a. Z pomocą przyjdzie nam moduł JSDOM, który mieliśmy okazję przetestować na DevCampie i który na tę chwilę implementuje DOM level 1 i 2 w 100%, DOM level 3 w 14%. Modułu tego możemy użyć przykładowo tak:

var jsdom = require('jsdom').jsdom,
    document = jsdom('<html><head></head><body>hello world</body></html>'),
    window = document.createWindow();
 
console.log(window.document.innerHTML);
// -> '<html><head></head><body>hello world</body></html>'
console.log(window.innerWidth);
// -> 1024

Następnie chcielibyśmy uruchomić skrypty w kontekście otrzymanego obiektu window. JSDOM w teorii posiada taką możliwość:

var jsdom = require('jsdom');
 
jsdom.env(
    '<p><a class="the-link" href="http://jsdom.org>JSDOM\'s Homepage</a></p>',
    [
        'http://code.jquery.com/jquery-1.5.min.js'
    ],
    function (errors, window) {
        console.log("contents of a.the-link:", window.$("a.the-link").text());
    }
);

Próba uruchomienia tego skryptu na dzień dzisiejszy kończy się… Błędem JSDOM-a.

TypeError: Cannot call method 'runInContext' of undefined
at Object.javascript (... lib/jsdom/level2/languages/javascript.js:17:14)

Co ciekawe ten sam przykład działał nam na DevCampie, a wynika to z braku zgodności pomiędzy wersjami 0.5 i 0.4.9 Node’a. Przy czym kiedy popatrzymy na historię modułu odpowiedzialnego za uruchamianie skryptów w JSDOM-ie, zobaczymy, że błąd ten został już naprawiony. Niestety od lutego tego roku nie została wydana żadna nowa wersja modułu.

Z ciekawości spróbowałem jeszcze uruchomić trunkową wersję JSDOM-a i niestety jest z nią wiele problemów. Tak więc w tej chwili radzę unikać wykonywania skryptów przy pomocy tego modułu.

Sandbox w Node.js

Opis problemów JSDOM-a tak naprawdę był jedynie anegdotą o tym jak niestabilne i zmienne jest to środowisko. Uważam, że (przynajmniej przy obecnym API JSDOM-a) skrypty powinniśmy uruchamiać sami. Podstawową zaletą tego rozwiązania jest to, że mamy wtedy pełną kontrolę nad kontekstem uruchomienia. Przykładowo mamy możliwość przekazania obiektu console z globalnego kontekstu Node’a, tak by uruchamiane skrypty mogły logować na konsolę systemową. Co prawda przekazując ten obiekt do uruchamianych skryptów narażamy się na to, że kod jakiegoś nieogarniętego programisty zmieni nam coś w globalnym kontekście Node’a. Przy pomocy Object.freeze() możemy się jednak przed tym zabezpieczyć (chyba że ktoś będzie np. specjalnie szukać dziur).

Do uruchamiania skryptów możemy wykorzystać moduł VM, z którego nas będzie interesować metoda runInNewContext(code, [sandbox], [filename]). Sposób jej użycia jest następujący:

var ctx = {
    a: 1
};
var b = true;
 
require('vm').runInNewContext('a++; b = false;', ctx);
 
console.log(ctx); // -> { a: 2, b: false }
console.log(b); // -> true

Z ciekawości sprawdźmy jakie zmienne mamy dostępne w naszym nowym globalnym kontekście. W tym celu do kontekstu wywołania przekażmy obiekt console:

var ctx = {
    a: 1,
    console: console
};
 
require('vm').runInNewContext('console.log(this);', ctx); // -> {}

Takie zachowanie może zdziwić i w bardzo specyficznych przypadkach mogłoby spowodować problemy z działaniem jakiegoś kodu. Jest jednak naturalne dla Node’a (choć nie dla mnie, bo go nie rozumiem – to nie wygląda na kwestię bezpieczeństwa), ale do obejścia:

require('vm').runInNewContext('for (var i in this) console.log(i);', ctx);
// -> a, console, i
 
require('vm').runInNewContext('console.log(Object.keys(this));', ctx);
// -> [a, console, i]
 
require('vm').runInNewContext('var b = 1; console.log(Object.keys(this));', ctx);
// -> [ 'a', 'console', 'i', 'b' ]

Z ciekawości dopisałem kilka testów jak zachowują się w Nodzie this i global (tak naprawdę to to jest globalny kontekst w Nodzie) i moją uwagę zwróciły dwa zachowania. Po pierwsze przy uruchamianiu skryptów z konsoli Node’a this === global, co nie jest prawdą przy uruchamianiu z pliku. Po drugie poniższy skrypt:

var a = 1;
console.log(global.a); // -> ?

Również inaczej zachowa się przy uruchamianiu z konsoli, niż przy uruchamianiu z pliku. W pierwszym przypadku otrzymamy 1, w drugim undefined. Dzięki temu można wysnuć teorię, że konsola Node’a działa właśnie w oparciu o moduł VM. Innym powodem (bądź jednym z powodów) może być to, że kod z plików uruchamiany jest jak moduł Node’a (dzięki medikoo za przypomnienie). Zabezpiecza nam to globalnego scope’a przed zaśmieceniem. Jako ciekawostkę mogę podać, że na DevCampie komuś przy debugowaniu kodu wyszło, że moduły są po prostu otaczane mniej więcej takim kodem: (function () { ... }).apply({}).

Reverse engineering modułu VM

Wróćmy jeszcze na chwilę do:

require('vm').runInNewContext('console.log(this);', ctx); // -> {}

Udało mi się też odkryć sposób aby skrypt wykonany został w ten sposób by console.log(this) nie było pustym obiektem. Kiedy szukałem rozwiązania zacząłem od takiego kodu:

var ctx = {
	console: console
};
ctx.g = ctx;
 
require('vm').runInNewContext('console.log(this);', ctx); // -> {}

Niestety wciąż dostawałem {} i zachowania Node’a w tym wypadku nie potrafię wyjaśnić w czysto JavaScriptowy sposób:

require('vm').runInNewContext('console.log("g" in this);', ctx); // -> true
 
require('vm').runInNewContext('console.log(Object.getOwnPropertyDescriptor(this, "g"));', ctx);
// -> { value: {},
//      writable: true,
//      enumerable: true,
//      configurable: true }
 
require('vm').runInNewContext('console.log(this.g === this);', ctx); // -> true
 
Object.defineProperty(ctx, 'h', { value: 1, enumerable: false });
require('vm').runInNewContext('console.log(this.h /*, h*/);', ctx); // -> undefined, Error

Nic nie da też zabawa z prototypem – raz, że ctx.__proto__ = ctx wyrzuci błąd, a dwa, że co prawda możemy prototyp sklonować, ale nic to nie zmieni. Kod powyższych testów znajduje się na Githubie.

Zbawieniem okazało się dopiero domknięcie:

var ctx = {
	console: console,
	g: function () { return ctx; }
};
 
require('vm').runInNewContext('console.log(this.g());', ctx);

I gdyby ktoś bardzo chciał mieć pełny obiekt globalny, to może skorzystać z poniższego kodu. Ostrzegam jednak, że od patrzenia na niego bolą oczy, a jego ograniczenia powodują, że jest bezużyteczny :D.

var runWithGlobal = function (code, ctx) {
    var vm = require('vm');
 
    ctx.g = function () { return ctx; };
    vm.runInNewContext('(function (g) { delete this.g;' +
        code +
    '}).call(g());', ctx);
};

Jak działa VM?

Po co w zasadzie o tym piszę? Otóż ponownie daje nam to pewien obraz tego w jaki sposób vm.runInNewContext uruchamia skrypty, a niestety tych informacji nie znajdziemy w dokumentacji. Otóż Node najprawdopodobniej kopiuje sobie do kontekstu właściwości z podanego obiektu. Co ciekawe robi to z pominięciem niewyliczalnych właściwości (test: this.h === undefined). W dodatku zwraca uwagę na odwołania cykliczne (przynajmniej w stosunku do samego obiektu globalnego) i aktualizuje je do nowo utoworzonego obiektu. Następnie w jakiś niejavascriptowy sposób ukrywa te zmienne w this, po czym wykonuje skrypt. Na sam koniec, z tego co udało mi się wyczytać, z powrotem przekopiowuje te zmienne do obiektu podanego jako kontekst. Przy wykonywaniu skryptu Node pozwala korzystać i z pełnego obiektu kontekstu (który można przekazać jedynie przez domknięcie), i z innych obiektów, w żaden sposób ich nie zabezpieczając. Możliwe są więc takie odwołania poza nowy kontekst wywołania, które mogą powodować pewne zagrożenia:

var obj1 = { a: 1 },
    obj2 = { a: 1 };
 
var ctx2 = {
    console: console,
    obj1: function () { return obj1; },
    obj2: obj2,
};
 
require('vm').runInNewContext('obj1().a += 100; obj2.a += 200;', ctx2);
 
console.log(obj1); // -> { a: 101 }
console.log(obj2); // -> { a: 201 }

To już koniec? Mamy przeglądarkę?

Pomijając ten drobny fakt, że globalne zmienne są z niewyjaśnionych powodów niewyliczalne, możemy uznać, że potrafimy uruchamiać skrypty w sposób w jaki robi to przeglądarka. Stworzyłem więc dwa pliki testowe, by mieć pewność, że zachowanie kontekstu będzie poprawne. Skrypty znajdują się tu i tu. Wykonywane są jeden po drugim tak by sprawdzić, że kontekst jest odpowiednio współdzielony.

Kod uruchamiający skrypty wygląda w skrócie tak:

var testScope = function (scope, name, log, method) {
    method = method || 'runInNewContext';
    vm[method](code1, scope);
    vm[method](code2, scope);
 
    console.log('separate globals:');
    console.log(typeof {}.e === 'undefined');
};

Stworzyłem też wersję dla przeglądarki, aby porównać wyniki.

Test 1 – porażka

Pierwszy test kontekstu, korzystając z tego co się dowiedzieliśmy:

(function () {
	var window = {
		a: 1,
		b: 2,
		console: console,
		assert: assert
	};
 
	window.window = window;
 
	testScope(window, '1');
})();
 
//Wynik:
//AssertionError: {}.e === 1 (24 linia script2.js)

Ten sposób uruchamiania skryptów nie przeszedł testów współdzielenia zmian w prototypach natywnych obiektów. W script.js dodaję do Object.prototype właściwość e = 1. Niestety nie jest ona dostępna w obiekcie utworzonym w script2.js.

Test 2 – nieudokumentowane metody zwane ficzerami

Okazuje się jednak, że istnieje jeszcze trzecia (poza runInThisContext(), o której nie wspomniałem, bo nie jest interesująca w tym temacie) metoda uruchamiania skryptów, która nie została udokumentowana. Jest to runInContext(code, ctx), przy czym drugim argumentem musi być obiekt utworzony przez również nieudokumentowaną metodę createContext(obj). Całość możemy uruchomić tak:

(function () {
	var window = vm.createContext({
		a: 1,
		b: 2,
		console: console,
		assert: assert
	});
 
	window.window = window;
 
	testScope(window, '3', false, 'runInContext');
})();

Okazuje się, że tym razem wszystkie testy przechodzą. Dlaczego te metody są nieudokumentowane i co w ogóle robią w Nodzie? To świetne pytanie do twórców, którzy sami na razie nie są pewni.

Myślę, że tym pozytywnym akcentem zakończę przydługą część o wspaniale udokumentowanym module VM :). Jeśli wyniki moich pedantycznych testów zainteresują choćby 10 osób, to trochę mnie to zdziwi. Pora na kilka moich przemyśleń dotyczących przenośności kodu pomiędzy środowiskami.

Przenośny kod

Na początku artykułu napisałem, że wspomnę o architekturze. Tak naprawdę na chwilę obecną mam jedynie kilka obserwacji i pomysłów. Dopiero możliwość ich zastosowania w praktyce pozwoli mi się przekonać ile w nich prawdy i sensu.

Przede wszystkim należy się zastanowić, czy w ogóle potrzebujemy specjalnego uruchamiania kodu w wydzielonym kontekście zbliżonym do tego w przeglądarce? To zależy w znacznej mierze od projektu. Jeśli mamy już wiele tysięcy linii niepewnego kodu JavaScript i nie ma takiej opcji byśmy zbyt mocno ingerowali w jego architekturę, a chcemy podpiąć jakoś Node’a, wtedy najlepiej dla nas będzie jeśli kod odseparujemy od kontekstu Node’a. Zabezpieczymy się tym samym przed bezsensownymi modyfikacjami globali, przed zaśmiecaniem globalnego kontekstu, a sam kod będzie działał w przyjaźniejszym mu środowisku, zbliżonym jak najbardziej do oryginalnego.

Jeśli kod został dobrze napisany, bądź dopiero siadamy do projektu i możemy przemyśleć podejście i od początku je testować, wtedy sposób uruchomienia współdzielonego kodu nie musi być tak bardzo faszystowski. Pliki ze skryptami dla przeglądarki, jeśliby zostały napisane na modłę CommonJSową, możnaby przecież bezpośrednio dołączać do Node’a.

Pojawia się w takim razie pytanie w jaki sposób moduły CommonJSowe, które w Nodzie ładowane są synchronicznie, ładować w przeglądarce asynchronicznie? Chyba najpopularniejsze w tej chwili rozwiązanie RequireJS umożliwia przekonwertowanie CommonJSowych skryptów na takie, które będą mogły być sensownie ładowane w przeglądarce. Nie znam API RequireJS, nie wiem czy konwersja działa sprawnie, ale uważam, że w tej chwili (dopóki ECMAScript Harmony nie udostępni swoich modułów) konwertowanie ma najwięcej sensu.

Na jakiej zasadzie mogłaby działać taka konwersja? Na przykład można zawartość pliku otoczyć wywołaniem funkcji przekazywanej do metody dodatkowej biblioteki. W dodatku wszystkie wywołania require() należałoby odnaleźć i dodać jako argument do wywołania tej metody. Callback z ciałem modułu powinien się wykonać dopiero po pobraniu się kodu wszystkich zależności. Przykładowo dla oryginalnego modułu:

var math = require('math'),
    async = require('async');
 
async.sth(math.sth());
...
 
exports.sth = 1;

Kod wynikowy mógłby wyglądać tak:

Require.load([ 'math', 'async' ], function (require, exports) {
 
    //module----
    var math = require('math'),
        async = require('async');
 
    async.sth(math.sth());
    ...
 
    exports.sth = 1;
    //module----
 
    return exports;
});

Napisanie funkcji wrapującej wydaje mi się trywialne. Nie mam co prawda pewności, że ten sposób nie ma jakichś ograniczeń, ale wszystko jest do sprawdzenia. W dodatku prawdopodobne jest, że RequireJS działa w zbliżony sposób do przedstawionego przeze mnie, ale daruję sobie sprawdzanie tego :).

Ostatnią rzeczą o jakiej chciałbym jeszcze napisać jest to, czego unikać by kod dało się na przykład jak najłatwiej przenieść z przeglądarki do standardu CommonJS.

• Nie korzystaj z niejavascriptowych globali. Jeśli co linię masz odwołanie do document, escape(), czy po prostu window, to Twój kod trudniej będzie przeportować do innego środowiska. Przyznam, że dopiero teraz, kiedy musiałem zmierzyć się z przenośnością kodu zrozumiałem dlaczego JSLint jest tak restrykcyjny pod tym względem. To naprawdę ma sens.
• Nie używaj this w globalnym kontekście – ani jako zamiennika dla window, ani do inicjalizacji zmiennych. Nie robi tego Node (najprawdopodobniej by rozdzielić zadanie obiektu globalnego od this, który ma inną rolę i tym samym zabezpieczyć się też przed przypadkowym zaśmiecaniem globalnego kontekstu), nie rób i Ty. Przyjmij nawet tę samą konwencję nazewniczą i zamykaj swoje skrypty np. w: (function (global) { ... }).call({}, window);
• Nie współdziel wielu zmiennych pomiędzy plikami (najlepiej tylko jedną, traktowaną jak exports), a łatwiej będzie Ci je potraktować jako moduły.

Podsumowanie

Na dniach pojawi się podsumowanie tematu middle-end z DevCampu, który to natchnął mnie do napisania tego przydługiego artykułu. Tak naprawdę prawie każda z poruszonych przeze mnie kwestii jakoś dotyczyła tego, z czym zetknęliśmy się podczas prac nad implementacją middle-endu, w postaci jaką sobie założyliśmy. Gdybyśmy nie chcieli symulować sytuacji, w której podpinamy się pod już działającą aplikację moglibyśmy podejść w ten prostszy sposób i spróbować wykorzystać np. RequireJS. Mogłoby się okazać, że rozwiązałby wszystkie nasze problemy dotyczące architektury aplikacji.

Osobiście myślę, że middle-end jako idea współdzielenia tej części aplikacji, która potrzebna jest i z przodu, i z tyłu, to przyszłość. Podobnie jak Getify twierdzę, że w każdej aplikacji middle-end gdzieś istnieje i naszym zadaniem jest go znaleźć, określić i wydzielić. Pytanie na przyszłość, jak to zrobić by się nie narobić i zrobić to dobrze :)

Podobne wpisy:

1. Zapraszam na darmowe szkolenie DevMeeting – middle-end w oparciu o NodeJS
2. Moja prezentacja o Node.JS z Meet.JS i GTUG Wrocław
3. JavaScript na jesień 2011