Path: csiph.com!.POSTED.204-73-239-109.cust.centrio.cz!not-for-mail From: Cezary Tomczyk Newsgroups: pl.comp.lang.javascript Subject: Re: dlaczego firstChild oraz childNodes[0] mam undefined? Date: Fri, 24 Mar 2017 09:53:02 +0100 Organization: csiph.com Internet News Service Message-ID: References: <5d210841-ac34-4a0b-9981-9fe8d5e61d4c@googlegroups.com> <1qyr04lt73a9k.2i4h5jx0p963$.dlg@40tude.net> <20170316120955.4c2fcf01@pe.regionet.pl> <07b85c99-5512-4bf8-a85b-32e2693318a2@googlegroups.com> <1bw0p3palg9q0$.1iffa42jnbl49.dlg@40tude.net> <1exqgczs770q5.1ncnughms5d0a.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 24 Mar 2017 08:53:05 +0000 (UTC) Injection-Info: csiph.com; posting-host="204-73-239-109.cust.centrio.cz:109.239.73.204"; logging-data="27382"; mail-complaints-to="admin@kev009.com" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: csiph.com pl.comp.lang.javascript:3370 On 23/03/2017 21:46, Borys Pogoreło wrote: > Dnia Thu, 23 Mar 2017 10:41:11 +0100, Cezary Tomczyk napisał(a): > >>> A jaki miałeś problem z Gulpem? Grunt faktycznie nie jest zbyt elastyczny z >>> uwagi na deklaratywne podejście, ale w Gulpie możesz napisać prawie >>> wszystko, to w końcu zwykły JS + strumienie. >> >> No właśnie dlatego, że mam dostępny Promise, to Gulp nie jest mi potrzebny. > > A nie widzę, byś go używał. Nie. Aktualnie nie używam. A nawet przyznam się, że używałem Gulpa bardzo króciótko i przy jednym projekcie. Grunt-a używałem przez kilka lat. > Do tego to by jeszcze bardzo zaciemniło Twoje > rozwiązanie, zwłaszcza jakbyś musiał zsynchronizować kilka promises. Promise.all - to wszystko, co jest potrzebne i jest dostępne. Chyba, że myślisz o czymś innym. > Nie wspominając już o zabawie z łapaniem wyjątków, itd. Ze strumieniami jest > znacznie łatwiej, do ich scalania i synchronizowania masz gotowe narzędzia, > a ich użycie to 1-2 linijki. "catch" z Promise-a powinien pomóc. Niektóre npm moduły zwracają Error object. >> To żadna kombinacja. Przypatrz się temu dokładnie. Bierzesz pakiet npm i >> używasz go całkiem normalnie: wejście -> wyjście. > > A po drodze odpalasz binarkę CLI eslint, musisz ją skonfigurować, > samodzielnie obsłużyć błędy i do tego zupełnie nie widać, co jest wynikiem > działania tej funkcji. Coś tam sobie leci w pętli i nie bardzo wiadomo, co A wrapper do G/G to jak działa? > się dzieje i gdzie szukać efektów (co to jest "report" i jak go czytać? co > to jest "formatter" i czemu pojawia się dopiero na końcu, choć nazwa > wskazuje na coś potrzebnego w trakcie procesu?). A całość jest długa na dwa Wszystko jest opisane w dokumentacji: http://eslint.org/docs/user-guide/command-line-interface > ekrany. To nie jest proste rozwiązanie. Idealizujesz je, bo jesteś autorem. Absolutnie nie idealizuję. Z resztą, nie wymyśliłem niczego nowego. Przykładowo eslint https://github.com/eslint/eslint/blob/master/Makefile.js korzysta z tego samego podejścia do build-a. Ba! Nawet z samego NPM-a możesz korzystać: https://medium.com/@dabit3/introduction-to-using-npm-as-a-build-tool-b41076f488b0 > Proste rozwiązanie to jest wziąć garść plików, złączyć je w jeden strumień, > wrzucić w eslint z konfiguracją i coś zrobić ze strumieniem wyjściowym. I > nie przejmować się zanadto obsługą błędów, bo robi to za nas narzędzie. Jak masz proste kroki w buildzie, to wszystko się zgadza. Jeszcze raz podkreślę - każdy używa to, co jest dla niego najlepsze albo musi, bo jest już to w projekcie od jakiegoś czasu. Jeżeli ląduję w projekcie z G/G, to nie marudzę tylko tego używam ;-) A poza tym, zapominasz o innych argumentach. Przykład: https://gist.github.com/elijahmanor/179e47828bf760c218bb3820d929836d >> Osobiście, po jakimś czasie doszedłem do wniosku, że Grunt/Gulp za >> bardzo ograniczają mnie i w zasadzie zdefiniowanie i napisanie kroków do >> build-a jest banalnie proste: > > Ja mam nieodparte wrażenie, że gulpa nawet nie spróbowałeś na dobre, bo > wcześniej stworzyłeś to swoje rozwiązanie. Próbowałem, ale bardzo krótko i przy jednym projekcie. Z resztą, przeszedłem na inne podejście, które według mnie, jest bardziej elastyczne. Może odrobinę więcej czasu zajmuje napisane zadania, ale nie jest to też aż tak skomplikowane. Sądzę, że trochę przesadzasz w drugą stronę ;-) >> 1. Definiujesz co chcesz osiągnąć. >> 2. Dobierasz sobie pakiet npm. >> 3. Piszesz kilka linijek kodu, by przekazać parametry do pakietu npm i tyle. > > No popatrz, opisałeś gulpa ;) :D > Hint: nikt Ci nie broni używać pakietów npm w procesie gulpa. Prościej > jednak jest trzymać się konwencji. Trzymanie się konwencji jest pewnym ułatwieniem w organizacji pracy, ale jednocześnie, osobiście, nie wykluczam indywidualnego podejścia. Wszystko zależy od sytuacji i potrzeb. >> * Usuwam niepotrzebną zależność od Grunt-a/Gulp-a > > To nie jest argument. W w/w linku są podane argumenty, a ja także podałem je w swoim artykule. >> * Nie muszę czekać, aż autor pakietu dla Grunt-a/Gulp-a uaktualni mi go > > Pakiety npm też nie zawsze są aktualne. Pewnie, ale pakiety dla G/G jeszcze bardziej ;-) >> * Nie muszę nic hackować, bo albo korzystam z gotowych pakietów npm >> (jeśli są wystarczające), albo piszę sam. > > A czym jest hackowanie, jak nie tym ostatnim? ;) Hack to obejście. Ja niczego nie obchodzę :-) Ot, korzystam z pakietów npm i tyle. > Nawiasem mówiąc pakiety gulp nie są jakieś przesadnie skomplikowane. > > gulp-babel to prosty wrapper na moduł npm i wygląda tak: > https://github.com/babel/gulp-babel/blob/master/index.js No i teraz pytanie po co mi wrapper skoro mogę skorzystać bezpośrednio z pakietu npm ;-) >> * Do konkretnego zadania mogę wybrać jakikolwiek pakiet npm, spełniający >> moje wymagania. Mając Grunt-a/Gulp-a muszę brać pod uwagę to, że pakiet >> był specjalnie dla G/G. > > Nie musisz, ale tak jest wygodniej. No więc najpierw muszę znaleźć coś, co zadziała z G/G, a jeśli nie ma, to pozostaje mi własne rozwiązanie, które potem muszę podpiąć pod G/G. >> Do minusów: >> * Trzeba przeczytać i zrozumieć kod :D >> * Więcej nie pamiętam, ale możesz dopisać kolejne punkty tutaj ;-) > > * Tworzysz rozwiązanie in-house, z którym musisz sobie radzić sam I tak, i nie. Po mojej "in-house" stronie jest tylko to, co ja napisałem. Reszta to pakiety npm. Tak, czy inaczej, wsparcie community jest. > * Musisz w wielu miejscach wynajdować koło na nowo Nie bardzo wiem, co takiego muszę wynajdować na nowo. > * Uzyskujesz strasznie rozwlekły kod, bo patrz wyżej Nie powiedziałbym, że rozwklekły, ale ok. Za to mam pełną kontrolę i swobodę nad tym, co określone zadanie ma robić. Poza tym, build piszesz raz i działa latami. Nie trzeba do tego codziennie zaglądać, jak do źródeł aplikacji ;-) >>> Widzę, że w komentarzach Ci napisali w sumie to samo ;) >> >> Zdania są podzielone i to jest normalne. Nie oczekuję tego, iż G/G >> zostanie porzucony czy nagle wszyscy przestaną z tego korzystać. >> Zaprezentowałem swój punkt widzenia. > > Na blogaskach generalnie wypada chwalić w komentarzach, nawet takie > wynaturzenia jak JSS ;) :-) Jednym z plusów takiego rozwiązania, o którym napisałem, jest brak zależności od konkretnego rozwiązania do builda. Przy okazji, przypomina mi się sytuacja historycznie: * Grunt - tego teraz używamy. * Gulp - Grunt już je be, teraz Gulp jest super. * Browserify - nie znasz? Teraz to jest na topie :-) * Webpack - nie, już Browserify nie jest dobre. * Rollup (http://rollupjs.org/) - teraz Rollup musi być najlepszy. Ja wiem, że są rożnice w tym, co one potrafią, ale to już inna bajka. -- Cezary Tomczyk http://www.ctomczyk.pl/