Witajcie mam mętlik w głowie i wydaje mi się że im więcej szukam i czytam tym mniej wiem.... Chciałbym powoli odejść od samego jQuery i skupić się bardziej na czystym, zorientowany "obiektowo" javascripcie. Wiem że są różne wzorce projektowe jednak nie mam takiej wiedzy i doświadczenia, żeby móc stwierdzić który jest lepszy (dysponowanie pamięcią, wydajność, łatwość nauki), a co najważniejsze który pozwoli mi miękko wejść w takie frameworki jak angular czy backbone? Podoba mi się Module Pattern ale widzę że dużą popularność ma Prototypal Pattern. Bardzo proszę o rozjaśnienie sytuacji, może przedstawienie obecnych trendów itp Każdy wpis będzie cenny. Pozdrawiam

podchodzisz trochę od d... strony To frameworki uczą cię wzorców, po to, żebyś stał się lepszym programistą, a nie odwrotnie.



Angular jest za bardzo zopiniowany. Pisząc w Angularze przestajesz pisać w normalnym, czystym JavaScripcie, bo musisz pisać tak jak Angular od ciebie wymaga. Plusem jest to, że owszem, nauczysz się paru ciekawych wzorców projektowych, choćby wstrzykiwanie zależności (depedency injection), które jest stosowane w Angularze wielu miejscach. Także nauczysz się składania aplikacji z powiązanych ze sobą komponentów(dyrektyw). Co prawda w Angularze komponenty są niedorobione pod kątem implementacji, ale jeśli traktować to jako wzorzec projektowy Komponentu (który wciela x innych frameworków), to bardzo okej. Nauczysz się też pewnych antypatternów, np. to jak nie należy tworzyć modułów w JavaScripcie (angularowe moduły oparte to porażka roku). Jeśli chodzi o inne wzorce, to Angular wykorzystuje również wzorzec Serwisu, który pozwala oddzielić logikę aplikacji od wyświetlania (chodzi o to, że pisząc komponent ("dyrektywę") możesz część kodu umieścić w zewnętrznych obiektach ("serwisach"), dzięki czemu nie bruździsz sobie).

Jednak Angular ma 3 minusy: 1. trudny w nauce 2. uciążliwy przy dłuższym korzystaniu 3. Obecna wersja jest już przestarzała, a nowego Angulara 2 (który ma być już lepszy i prostszy) jeszcze nie ma.

Co do Backbone to bardzo fajny framework na początku. Opiera się na dość prostych zasadach, nauczy cię pewnych rzeczy, choćby MV*, programowania opartego na słuchaniu zdarzeń, otworzy oczy na pewne rzeczy jak może być budowana aplikacja (po zaznajomieniu się z Backbone, potem nawet jak robiłem coś na czystym jQuery, to starałem się wcielać pewne zasady, które zauważyłem w Backbone).

Minusem (choć dla niektórych to będzie plus) Backbone'a jest na to, że wszystko musisz robić samemu, i ten framework to tak jakby nie framework (bo mówię, opierając się na jQuery można napisać atrapę Backbone'a i nie będzie dużo gorsza). Ale dla celów edukacji Backbone jest okej.

Jeszcze jest React, czyli framework, który polega w zasadzie na robieniu komponentów i składaniu ich w większe komponenty. I całą aplikację robisz na komponentach, a potem łączysz to z jakimiś źródłami danych (albo jednym źródłem). Możesz się z niego nauczyć bardziej modularnego podejścia. Poza tym React w dużej mierze opiera się na paradygmatach programowania funkcyjnego, co też jest dużym bonusem do nauki. Zachęca również do bardziej odpowiedzialnego podejścia w kwestii programowania, zwraca uwagę na niemutowalność (czyli niezmienność obiektów) oraz na odpowiednie oddzielenie widoku od kodu logiki (zwykle poprzez tzw. architekturę Flux, która nie jest niczym nowym, ale jest ładnym buzzwordem). Jako że React cię nie pilnuje (możesz robić co chcesz), to powinieneś sam dbać o pewne rzeczy, albo będziesz miał burdel w kodzie i w działaniu. Uczy to odpowiedzialności.

W zasadzie bardzo łatwy do wejścia, chociaż jest wskazane, żebyś nauczył się przy okazji ustawić sobie build system w jakimś Babelu. Nie jest to konieczne co prawda, ale ten krok pozwoli na używanie JSX, czyli składni HTMLa w plikach JS (w React szablony komponentów tworzy się w plikach JS).


Obecne trendy w JavaScript są takie, że wraca się do rzeczy sprzed kilkudziesięciu lat oraz odkrywa rzeczy dawno odkryte przez programistów innych języków czy działek programowania. Więc chcesz być na czasie w JavaScripcie - nie zamykaj się na JavaScript - to sam będziesz pionierem i uważany za mesjasza wśród frontendowców.

Jeśli chodzi jednak o konkretne implementacje starych jak świat wzorców projektowych w JavaScript to tu masz ściągę:
http://addyosmani.com/resources/essentialj...npatterns/book/

Po pierwsze... zostaniesz moim mistrzem?! jestem w szoku Twojej wypowiedzi! za którą bardzo bardzo dziękuje. Wracając do tematu, miałem już doświadczenie z angularem (wiem czym są serwisy, dyrektywy, controllery, routowanie) jednak w bardzo bardzo podstawowym zakresie (pracowałem przy 1 projekcje). Wykładałem się np przy tworzeniu dyrektywy z bootstrapa i pracy ze zmiennymi i metodami.. nie bardzo rozumiałem jakie występują między nimi zależności... o co chodzi z tym dziedziczeniem itp. Wtedy zdałem sobie sprawę, że nic nie umiem że brakuje mi wiedzy w zakresie OOP javascriptu, że mój kod pisany w większości w jQuery jest niechlujny, zlany, że można wszystko robić lepiej. Tylko hmm dalej nie wiem co mam robić bo moim celem jest pisanie fajnego kodu z czystej kartki, a nie koniecznie angażowanie do tego celu kombajnu jakim jest np angular. Np. mam projekt w którym trzeba napisać w js jakąś fajną galerię zdjęć no i fajnie jakbym mógł stworzyć przy tym opensurcowy plugin który wrzucę na gita i zawsze będzie można go wykorzystać a nie klepać jakis jednorazoway kod jquery, który ciężko będzie później zaimplementować w innym projekcie.

Mam chęć rozwoju tylko potrzebuje kogoś kto wskaże mi drogę...

True. Teraz środowisko JS odkrywa magię Unixa: jest moda na tworzenie super lekkich, modularnych rozwiązań, gdzie jeden moduł wykonuje jedną, konkretną rzecz. I wszystko w oparciu o moduły: http://addyosmani.com/writing-modular-js/

A jeśli już mówimy o React: warto od razu poczytać sobie o Web Components i eventowej architekturze aplikacji (http://www.slideshare.net/nzakas/scalable-javascript-application-architecture)

Bardzo dziękuje za odpowiedz, jak dla mnie modułowe podejście jest łatwiejsze (https://www.youtube.com/watch?v=m-NYyst_tiY) i czytelniejsze, ale czy lepsze (wydajność, rynek pracy)?

haha, spoko


Co do wydajności to we frontendzie jest podstawowa zasada, która w 90% przypadków się sprawdza:
- JavaScript jest szybki, jeśli coś wolno działa to zapewne jest to DOM
To przeglądarka zamula. Ustawianie styli na elementach DOM, wstawianie czegoś do DOM, usuwanie, scrollowanie okna przeglądarki, wyświetlanie elementów w przeglądarce itp.
To czy zrobisz sobie moduły w JS, to gra minimalną rolę. Ponieważ JS jest szybki. Przeglądarki są wolne.

Na tym bazuje zresztą React, że odświeża tylko te elementy DOM, które się zmieniły i dlatego jest szybciej (chociaż również w React można zrobić wolno działającą aplikację, jeśli się niewłaściwie go użyje)



ze względu na rynek pracy: warto poznać Module Pattern taki, jak tam opisany, bo będziesz go używał nieraz pewnie, chociaż niekoniecznie... przy tworzeniu modułów. W zasadzie nazwa modułu jest myląca, bo może posłużyć do tworzenia modułu, ale równie dobrze do tworzenia zwykłych obiektów, ew. do izolowania zwykłych obiektów, czyli może posłużyć do kreacji i enkapsulacji czegokolwiek. Może lepiej byłoby to określać inaczej, np. "Encapsulation with IIFE" (IIFE to właśnie samowywołująca się funkcja). Ale cóż, przyjęło się że jest to Module Pattern

do samego robienia modułów zwykle używa się jakiegoś systemu modułów. Najpopularniejsze obecnie to chyba
- CommonJS (czyli `require('nazwamodułu')` itp.)
teoretycznie to są moduły z NodeJS, ale przy użyciu choćby Browserify można je "kompilować" i odpalać potem w przeglądarce.

- moduły z ES6
żeby ich użyć też używa się specjalnego "kompilatora" (czy raczej transpilatora), np. Babel, który transpiluje kod z ES6 (standard nie wspierany w całości przez przeglądarki) do ES5 (powszechny standard).

- moduły z Angulara
Ale one nie są kompatybilne z niczym, więc będziesz ich mógł używać tylko w Angularze, ponieważ twórcy Angulara postanowili, że będą hipsterami i wymyślą własny system modułów, zamiast użyć jakiegoś istniejącego. Nie dziwne, że teraz muszą przepisywać całego Angulara Takie i podobne rzeczy po prostu są słabe na dłuższą metę.


ten link jest przykry, bo pokazuje patologię programowania w JS - że do wszystkiego jest ileś konkurencyjnych rozwiązań. Na szczęście powoli wchodzą moduły z ES6 (po 20 latach istnienia języka dorobili do niego moduły!), więc pewnie niedługo wszyscy będą robić na tych modułach, ew. wspierając się np. CommonJS, które jest bardziej dynamiczne i pozwala na większą dowolność w ładowaniu modułów (co jest jednak wadą pod pewnymi względami), niż pozwala na to instrukcja `import` z ES6.



to warto nie tylko w odniesieniu do Reacta, ale ogólnie do dobrych praktyk programowania. BTW chyba miałeś na myśli "modułowej" bo w tym linku z Slideshare bardziej o modułach i decouplingu jest.

PrinceOfPersia czytając Twoje wpisy rozlewa mi się mózg na klawiaturę i zdaje sobie sprawę jak małym robaczkiem jestem w tym ogródku... ale na pewno się nie zniechęcam i powoli będę parsować temat hmm na podstawie wpisów i tego co widzę w necie wywnioskowałem że najpierw spróbuje wchłonąć wiedzę z zakresu http://addyosmani.com/resources/essentialj...tternjavascript. Przy okazji pokaże wam fragment kodu mojego autorstwa i bardzo prosiłbym o przykład jak mógłby on wyglądać w prototpe pattern. Są w nim najczęściej używane przeze mnie elementy (pętle, tablice, zmienne, ajax, eventy). W modułowym wzorcu widziałem jak facet fajnie oddzielił widok (renderował go) od funkcjonalności w prototype też tak się da?

[HTML] pobierz, plaintext 
<script>
            $('#saveText').on('click', function(){
 
 
                // zmienne 
                var ed = tinyMCE.get('content');
                var co = tinyMCE.get('comment');
                var terminy = [];
                var catalogs = [];
                var control = 1;
 
 
                // pobiera wybrane terminy
                for (i = 0; i < termCount; i++) { 
                    terminy.push({nazwa: $('.form-termin-name-'+i).val(), termin: $('.date-val-'+i).val()});
 
                }
 
 
                // pobiera wybrane katalogi
                $('.category-tree input[type="checkbox"]:checked').each(function(){
                    catalogs.push($(this).val());
                });
 
 
                // walidacja
                if ($('.form-title-text').val() == ''){
                    $('.form-title-text').css('border', '2px solid #ff5454');
                    control = 0;
                }
 
                // if walidacja == 1
                if(control == 1){
                    $.ajax({
                        type: 'POST',
                        url: base_url+'index.php/document/save_document',
                        data: {
                                'nameText': $('.form-title-text').val(), 
                                'contentText': ed.getContent(), 
                                'directoryText': catalogs,  
                                'commentText': co.getContent(),
                                'terminy': terminy
                            },
                        success: function(res) {
                            if (res){
                                showInfo('success', 'Tekst został pomyślnie zapisany! ');
                                location.replace(base_url+'index.php/edycja-dokumentu/'+res+'/edit');
                            }
                        },
                        error: function(res) {
                            showInfo('error', 'Błąd połączenia z serwerem! ');
                        } 
                    });
                }
 
            });
</script>
[HTML] pobierz, plaintext 

No właśnie teoretycznie nie node.js stosuje syntax nie do końca zgodny ze specyfikacją.

I to mnie dziwi, bo moduły z Angulara są bardzo podobne do AMD i nie powinno być aż tak wielkich trudności z przepisaniem Angulara na AMD.

Dopóki nie zostanie wytworzony standard asynchronicznego loadera dla nich, to raczej zostanie transpilowanie ich do CJS albo nawet AMD (jeśli async loader jest wymogiem dla aplikacji).

A czym jest komponent, jeśli nie modułem, który powinien być odizolowany od reszty i wystawiać eventowe API?

@d4ng hint: patterny można łączyć Prototype pattern ma raczej sens przy kodzie obiektowym - a Twój taki (jeszcze) nie jest.

Tu masz rację, zapędziłem się w tym postrzeganiu modułu jedynie jako poziomu organizacji na poziomie pliku (CommonJS itp.), że znikła mi szersza perspektywa tego, że koncepcyjnie wszystko może być modułem, choćby pojedyncza funkcja.

Czyli mamy moduł jako sposób na organizację samego kodu (po to, żeby człowiek się połapał w programie) oraz moduł w sensie koncepcyjnym.

Czasem to jest to samo, czasem nie. Można zrobić aplikację choćby na modułach CommonJS, ale nie zachowując żadnych dobrych praktyk i zrobić np. 10 plików, który każdy jest zależny od 5 innych.
Czyli moduły w sensie organizacji kodu, ale już nie koncepcyjnie.

Z drugiej strony można zrobić aplikację w jednym pliku, który będzie miał np. 2000 linijek kodu, ale porobić tę aplikację jak najbardziej ładnie i modułowo.


Hmmm... Rozumiem o czym piszesz, bo niby owszem, eventy to dobra metoda na uniezależnienie modułów, ale z drugiej strony:
- eventowe API może istnieć bez modułów (praca w jQuery na przykład, też opiera się na eventach, a jednak ludzie piszą spaghetti code w jQuery i nie robią w nim żadnych modułów)

- Poza tym można stworzyć modularną aplikację połączoną na niezależne od siebie części, bez użycia zdarzeń (wszystko co jest niemutowalne i bezstanowe - w sumie eventy są potrzebne tylko do tego, żeby zmienić stan obiektu/aplikacji. Jeśli nie zmieniasz stanu, nie potrzebujesz eventów)

Jeszcze jest taka sprawa taka, że rozwiązania bazujące na eventach często oznaczają to, że moduły uzależniają się albo od globalnego obiektu odpowiadającego za rozprowadzanie eventów, albo od konkretnego interfejsu obiektów np. mogą zakładać, że moduły będą zawierać metodę "emit" (albo "notify" jak było na tych slajdach), a co oznacza, że nie zawsze da się wyjąć moduł z aplikacji A i wsadzić do aplikacji B.

Chociaż oczywiście można napisać tak apkę, żeby się dało (np. korzystając w modułach jedynie z callbacków które wchodzą na wejściu, a nie zakładać nic o dispatcherze czy o interfejsie obiektów - za to będzie odpowiadał już specjalnie przygotowany callback).


No dobra. Jak się ma czas i ochotę, to pewnie i na CommonJS można "przepisać".
Tym niemniej nikt nie będzie przepisywał ręcznie dziesiątek czy setek modułów Angulara (chyba, że od początku aplikacja by była tak pisana).
A jeśli aplikacja jest oparta na hipsterskich modułach angularowych (tudzież innych "bytach" - w sumie kontrolery, serwisy czy dyrektywy to też pewnego rodzaju moduły) to nie da się jej zanalizować istniejącymi narzędziami. Tzn. nie musi być w ogóle oparta o jakieś wymyślne moduły. Nawet jakby zrobili ją na zwykłych obiektach JS czy klasach ES6 też byłoby okej (taki ma być Angular 2, ale jeszcze go nie ma). Wtedy można robić np. takie rzeczy:
http://hughsk.io/colony/


to znaczy? Możesz "poelaborować" trochę więcej ?



Dzięki. W sumie właśnie się zastanawiam, że może powinienem więcej pisać na swoim blogu o programowaniu, skoro to ludzi ciekawi.

Akurat to było odniesienie prosto do Web Components. Od strony używającego komponentu całość de facto sprowadza się do tego:

Cała zawartość tego elementu jest zamknięta w Shadow DOM tak, że nic nie wycieka na zewnątrz. Tutaj logicznym sposobem komunikacji ze światem zewnętrznym są po prostu eventy DOM-owe (poprzez interfejs CustomEvent), np. ładny colorpicker po wybraniu koloru po prostu odpali zdarzenie change. Bo tylko to w sumie interesuje developera korzystającego z tego komponentu.

Jednak eventy dla całej aplikacji: why not?

Hm… Ja jednak jakoś wolę odróżniać zdarzenia DOM-owe od "innych". Nie wiem, może mam już jakieś eventowe zboczenie.

To też zależy gdzie piszemy taką aplikację. Np w środowiskach node'owych de facto standardem jest natywny EventEmitter. Jasne, można pokombinować, żeby apka nic nie musiała wiedzieć o dispatcherze - pytanie tylko czy zawsze się to opłaca? Jeśli przyjmiemy, że z danych komponentów będzie korzystać dany zespół, to raczej nie będą zmieniać samego szkieletu aplikacji w różnych projektach.

Da się i na CMD Raczej chodziło mi o to, że nie rozumiem decyzji devów Angulara. Po co wytworzyli własny "standard" zamiast skorzystać z wzorców używanych w społeczności od lat?

Chodzi głównie o sposób eksportowania rzeczy z modułu. Wg specki (coś mi ich strona nie chce działać, hm) można to robić tylko i wyłącznie przy pomocy exports. A w nodejs przeważająca większość modułów eksportowana jest przez module.exports. Niby nic, ale niezgodność jest.

Kurcze ciesze się że z tego tematu powstała taka ciekawa dyskusja, bogata w więdze i doświadczenie.


Co to jest? z dalszej treści wywnioskowałem że to jakiś kompilator z wersji ES6 na ES5?


jaka jest różnica między jednym a drugim (fundamentalna)


co to jest emit i notifly? różnice? przykład? zastosowanie?


Śmiało, czytałem Twoje wpisy (widze że masz lekkość w pisaniu) jak również bloga i krytyka Comandera, bardzo fajnie piszecie, jest tam dużo cennej wiedzy. hmm co do tematu to fajnie by było napisać o dobrych praktykach żeby własnie uniknąć wspomnianego wcześniej "spaghetti code w jQuery"



yy? Shadow DOM to coś innego od DOM?

i na koniec...


ok, ale praktycznie cały kod przekleję jak będę robił część odpowiedzialną za update bądź użyje go do zapisania nie strony tylko np wpisu w części blogowej... Wtedy za każdym razem mam powielać kod? Czy da się to jakoś fajnie podzielić żebym mógł korzystać z jego fragmentów w innych funkcjach? Czy da się jakoś oddzielić cześć funkcjonalna od widoku i eventu (tzn na pewno się da ale bardziej chodzi mi tu o dobre praktyki)?

Dokładnie to transpiler.

CJS jest synchroniczne, AMD asynchroniczne. Z tej różnicy de facto wynikają wszystkie inne W zarzuconym przeze mnie artykule Osmaniego jest to dokładnie opisane.

emit/notify to po prostu metoda, przez którą dany moduł porozumiewa się z resztą świata. Jeśli zachodzi w nim jakaś zmiana, emituje informację o niej.
Najprostszym przykładem mechanizmu tego typu są zdarzenia w DOM, np. kliknięcie przycisku na stronie emituje zdarzenie click, pod które się można podpiąć ($.fn.on czy "tradycyjnie" addEventListener). Tego typu mechanizm można przenieść "wyżej", do samej aplikacji.

W Chrome kliknij sobie prawym przyciskiem myszy na np. polu odpowiedzi i wybierz "Zbadaj element", a następnie zajrzyj do #shadow-root Najlepsze artykuły o tym mają na HTML5 Rocks: http://www.html5rocks.com/en/tutorials/web...ents/shadowdom/

Nie. Jeśli dwa miejsca w kodzie robią bardzo podobną rzecz, to najprawdopodobniej da się z tego zrobić jedną klasę/funkcję i wykorzystywać ją później zamiast powielania wszędzie tego samego lub bardzo podobnego kodu.

Zrobić z tego funkcję Albo moduł.

W JS też istnieje MVC i podobne patterny, więc tędy droga. Ale jak takie rozdzielenie zachodzi, to już zależy od frameworka. Warto sobie popatrzeć np na http://todomvc.com/ żeby mieć jakieś porównanie.