🚀 go-pugleaf

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ł. Do tego to by jeszcze bardzo zaciemniło Twoje
rozwiązanie, zwłaszcza jakbyś musiał zsynchronizować kilka promises. 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.

> 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
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
ekrany. To nie jest proste rozwiązanie. Idealizujesz je, bo jesteś autorem.
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.

> 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.

> 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 ;)

Hint: nikt Ci nie broni używać pakietów npm w procesie gulpa. Prościej
jednak jest trzymać się konwencji.

> * Usuwam niepotrzebną zależność od Grunt-a/Gulp-a

To nie jest argument.

> * Nie muszę czekać, aż autor pakietu dla Grunt-a/Gulp-a uaktualni mi go

Pakiety npm też nie zawsze są aktualne.

> * 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? ;)

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

> * 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.

> 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
* Musisz w wielu miejscach wynajdować koło na nowo
* Uzyskujesz strasznie rozwlekły kod, bo patrz wyżej

>> 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 ;)

-- 
Borys Pogoreło
borys(#)leszno,edu,pl