Build systems pentru web client side - inovatie sau o complicatie inutila?

Rasfoind printre multitudinea de frameworks Javascript am dat peste Grunt si Gulp care imi dau senzatia ca s-a mers prea departe cu reinvetarea rotii.

Chiar era nevoie sa introducem si build systems pentru treburi client-side? Nu ma atrag in mod deosebit nici cele server-side dar macar acolo sunt justificate de complexitatea ridicata.

De ce trebuie totul complicat cu sintaxa inventata de unul si altul cand pot scrie intr-un simple shell script cele 2-3 comenzi de care am nevoie sa dau minify la css/js si eventual sa transform typescript in js sau sa rulez niste teste?

Pai marketing. Buzz word. Se mai face un training, se mai vinde o carte, se mai angajeaza un om ca deh, acum trebuie si expert in grunt.
Dpmdv e bine ca se schimba tehnologiile. Peste 10-15 ani vom face tot acelasi lucru doar cand in alt limbaj. Vom putea fi daca vrem angajati pe vesnicie ).

Nu mi se pare nici inovatie, nici inventie inutila, e normal sa ai un build tool la ora actuala pe js, starea de fapt a limbajului o cere. Nu mi se pare nici inovativ, pur si simplu s-au creat tools in node pt ca pe client asta e limbajul folosit.
Js s-a maturizat enorm lately, iar multe app-uri client side sunt la fel de complexe ca orice aplicatie de backend. De altfel un SPA cu backend Rest este mult mai complex pe client decat pe server.
Nu prea inteleg argumentul tau cu comenzile in consola, daca stai sa scrii de fiecare data aceleasi comenzi in consola, cam cat timp iti ia sa dezvolti o aplicatie? Grunt sau gulp vin cu pachete dedicate pt tot felul de task-uri (gen img min pt optimizare imagini), watchere cu auto reload pe js/CSS/HTML si multe alte goodies. Nu cred ca ai lucrat pe o aplicatie ceva mai mare de js construita cu module de browserify/common js daca sustii ce spui mai sus.

Btw vezi ca grunt e deja batran, iar gulp desi inca folosit destul de mult incepe incet sa moara, inlocuit de webpack si npm as a build tool. http://blog.keithcir...s-a-build-tool/

@potae expert grunt?! orice front end decent stie node si poate sa lucreze fara probleme cu grunt/ gulp/ webpack/ npm.

Edited by DILAS, 04 April 2016 - 00:09.

DILAS, on 04 aprilie 2016 - 00:04, said:

Am zis comenzi intr-un shell script. In consola tot maxim o comanda ajung sa dau. Nu pomenesc de make sau msbuild ca ma injura lumea.

O buna parte din task-uri nici nu le vad rostul in a fi rulate foarte des. De exemplu, nu stiu ce pierd daca aplic minificarea css-ului o singura data, cand fac deploy la aplicatie VS la fiecare 3 caractere modificate.
La fel cu optimizarea imaginilor. Introduc una, aplic optimizarea, salvez rezultatul, nu ma mai ating de el.

@dani true ce zici, dar majoritatea front enzilor nu stiu sa faca bash scripts, cu atat mai putin msbuild, maven sau alte tool-uri. Plus ca pt minificarea CSS-ului sau Js-ului tot iti trebuie un tool, cel mai probabil scris in node, pt ca n-o sa te apuci sa scrii tu unul. La fel ca sa folosesti browserify ca sa ai access la npm pe front end etc. Tendinta actuala ce-i drept e sa mearga spre npm ca build tool, ceea ce pana la urma inseamna tot o comanda in consola, care ruleaza alte comenzi in consola intr-o ordine prestabilita de package.json.

Minificarea sau optimizare de imagini de regula o rulezi in task-ul separat de prod. In general build-urile de gulp sau orice altceva sunt parametrizabile cu ceea ce ai nevoie pt fiecare environment. Eg: pe client o sa ai pornite source maps, iar codul o sa fie concatenat fara sa fie minificat, img opt n-o sa se foloseasca probabil deloc, endpoint-urile rest in care dai or sa fie generate dintr-un obiect de config cu localhost ca environment sau alt domeniu in functie de instanta in care vrei sa dai, etc.

Edited by DILAS, 04 April 2016 - 20:41.

Depinde.

Uneori e util un build system, în aplicații complexe în front end, cu multe js decuplate, cu interdependențe.

Într-o astfel de situație:

Graful de dependințe te ajută să încarci în pagină doar ce e necesar
- și în ordinea corectă (topologică)
- și totuși să te încadrezi intr-un Frame TCP

Problema nu e la tooling, ci la oameni: mulți sunt prea incompetenți și folosesc aceste scule mult prea complexe pentru proiectele lor banale, pentru a își masca incompetența, în loc să folosească ce trebuie, de exemplu shell scripts.

Deci amândoi aveți dreptate.

Cine sa le introduca? In general au fost gandite si si-au gasit utilitatea in proiecte mari iar lumea le-a adoptat, sau in majoritatea cazurilor abuzat de ele.

Oricum, dupa nedumeriri se vede ca nu prea ai lucrat cu ele si faci parte din categoria celor care probabil nu au nevoie de task automation.

Edited by laffin, 05 April 2016 - 09:38.