Ca o continuare a acestei discuții:
Citatul ăsta face un sumar excelent al întregului ecosistem JS:
And that is why everything is crazy. Most of these tools you think you have to have are solving problems you don’t have NOR WILL YOU EVER HAVE.
4 Likes
Sarumana pentru link, sintetizeaza foarte bine scarba mea pentru ce a ajuns Javascript-ul la momentul actual. Nu ne mai place sa facem lucruri ‘the easy way’, le facem pentru ca asa spune X, sau Y, sau StackOverflow. Cred ca cei care urmaresc HackerNews au observat acum cateva saptamani pluginul de Sublime care facea autocomplete de pe SO. Sa fim seriosi …
Javascript development IS crazy. Sunt chestii in JS care mi se par mai complicate decat C/C++, iar ES6 aduce un nou nivel de complexitate. Totusi, solutia din punctul meu de vedere este sa folosesti ce ai nevoie.
Ma uitam prin codul postat de tine @iamntz si desi intelegeam problema si simplificarea facuta de tine, totusi simteam ca mi se netezesc cutele creierului incercand sa imi dau seama de ce s-ar face asa ceva in modul respectiv. Nu cred ca exista o aplicatie (nu vorbesc despre top tier, chestii care necesita optimizari de milisecunde, whatever) care sa aiba nevoie de gulp. Sau de bower. Sau composer.
Ne simplifica tool-urile respective munca, sau ne-o simplifica pe moment, urmand sa ne incarcam memoria cu alta documentatie, alte functii, alte metode, alte chestii, care per total nu iti usureaza nimic? Vreunul dintre voi are probleme cu memoria? Eu unul da.
You read some React docs, “Redux is a predictable state container for JavaScript apps.” Sweet! You’ll definitely need one of those.
Mda.
3 Likes
În naivitatea mea, consider că o problemă de recursivitate se rezolvă… ei bine, recursiv. 
Vezi tu, gulp sau grunt sunt utile și pentru alte lucruri, nu doar pentru JS. Eu le folosesc pentru a automatiza lucruri ce altfel ar trebui să le fac manual. Minificarea (presupun că la asta te referi când spui optimizare) o ignor de cele mai multe ori.
Composer e util, bower… nu prea.
Setupul meu simplist include Browserify + npm modules. Incerc sa folosesc cat se poate de mult npm scripts ( http://substack.net/task_automation_with_npm_run ), in cazul in care setupul e foarte complex voi folosi gulp.
Cu cat se includ mai multe layere de abstractizare cu atat mai mult se complica situatia (probleme de interoperabilitate intre tool-uri, de intelegere a codului, etc).
Un exemplu: am incercat sa fac un setup de code coverage cu ES6 (babel) acum cateva luni la serviciu si am reusit foarte greu, pentru ca istanbul (la momentul ala, nu stiu acum) nu suporta ES6 out of the box. Am gasit pana la urma un repo obscur pe undeva care arata cum se face.
Bottom line pentru mine: keep it stupid simple. Daca ai un site simplu de facut, poate jQuery + lodash.template e cea mai buna solutie.
2 Likes
Hehe, gone are the days cand lucrurile se faceau logic 
Minificare/obfuscare/optimizare in cazul google closure compiler.
Sunt utile, majoritatea lucrurilor din jurul nostru sunt utile, dar sunt ele si necesare? E necesar sa invat gulp/grunt (dau mereu exemplele astea doua pentru ca imi place enorm numele lor, dar se aplica la un milion de alte tooluri) sau pur si simplu pot avea un fisier text cu numele fiecarul fisier din proiect pe o linie, si un build script care sa faca doar asta ;
cat project.filelist | xargs cat >> proiect.debug.js
Si sa-mi construiasca un fisier debug care contine totul din proiectul respectiv, pe care il poti apoi atasa unui proiect in Jenkins sau whatever CI tool foloseste fiecare, minificandu-l, optimizandu-l, atasandu-i teste, whatever? Una din problemele majore pe care am avut-o cu grunt (sau gulp, nu mai stiu exact) era nu detecta suficient de rapid modificarile mele incat trebuia sa stau dupa el sa-si dea seama ca vreau sa-mi refaca build-ul. Acum, cu mini-scriptul de mai sus atasat intr-un Build System in Sublime, totul merge seamless. In cazul meu, normal, probabil ca altcineva are nevoie de tool-urile respective, ori proiectul este prea mare, ori vrea sa invete ceva nou, etc.
Cred ca totul se reduce de fapt la : pot face asta singur sau am nevoie de ajutor? In ziua de azi, nu prea mai facem nimic singuri, probabil din comoditate. Iar varianta 2 ne poate duce foarte usor inspre problema ‘left-pad’, securitatea npn si dependenta de ‘dependinte’. Si mare mea problema, acumularea de mult prea multe informatii, asimilarea documentatiei, etc.
Cum naiba lucra lumea acum 30 de ani fara ele? Si s-au trimis oameni in spatiu fara npn, nu?
3 Likes
Make are 39 ani. Aș zice că IT-ul a avut nevoie de unelte pentru automatizare destul de devreme
Ohoho, dar make este chiar util, make nu mai e un tool in sensul in care composer e un tool.
Nu înțeleg comparația dintre make/gulp/grunt și composer.
Nu era o comparatie mot-a-mot, era mai mult o comparatie intre diverse tool-uri care sunt utile, dar nu necesare (in acceptiunea mea). Make e un tool al dracului de necesar, as zice
Nu e vorba de comoditate. Eu de exemplu prefer sa folosesc un modul deja existent, bine testat + documentat decat sa reinventez roata pentru chestii de baza. Cred ca as putea sa scriu left-pad fara nicio problema, sau alte librarii gen ‘event-emitter’, ‘logger’, etc. Defapt, cred ca as putea sa scriu si o implementare de gulp. Dar de ce as face asta, cand sunt deja existente, bine testate, cu o comunitate puternica in spate care updateaza proiectele respective zilnic?
Cred ca exista o linie intre a refolosi chestii utile in aplicatiile tale si a adopta tot ce e nou si flashy. Problema e ca unii se baga ‘cu capul inainte’ in a folosi cele mai noi tendinte.
Păi și cu ce e mai bună o unealtă care îți permite să automatizezi diverse task-uri comparativ cu o unealtă ce-ți permite să automatizezi dependințele?
Îți dai seama că alternativa la composer install ar fi să te duci pe profilul de github al fiecărui pachet folosit în aplicația ta, să faci download -> unzip -> copy în proiectul tău?
Perfect de acord, se poate face si asa, si asa. Orice se poate face in mai multe variante. Iarasi, nu trebuie sa-mi luati parerea drept o autoritate in domeniu, e doar o parere personala, fiecare face lucrurile cum doreste, bineinteles cu implicatiile (si responsabilitatile) ce rezulta din asta.
In definitiv, faptul ca nu dam unzip unei dependinte, e o comoditate, suntem in 2016 totusi, nu e cazul sa salvam datele pe cartele perforate ca acum n ani. Dar poti sa dai unzip si sa nu te simti stupid pentru asta
Dar cand ajungem intr-o situatie de genul fiasco-ului ‘left-pad’ si problemelor de securitate pe care le-a avut npn, poate calea asta e gresita. Zic eu.
Fără nici un dubiu este o comoditate. Dar tot o comoditate este și automatizarea oferită de Make/Rake/Ant/Gulp/Grunt. La o adică poți rula toate comenzile manual, fără să te simți stupid că faci manual ceva ce ai putea automatiza 
PS: nu e NPN (că nu-i tranzistor), este NPM: node package manager
1 Like
Corect, npm, nu stiu de imi e mai usor sa-i zic ca tranzistorului, probabil reminiscente electroniste Bine ca nu i-am zis MOSFET
Sigur, se poate face si asa. Problema e ca se aduna lucrurile pe care trebuie sa le faci manual si iti iau timp. Poti sa folosesti gulp/grunt/make/ant si sa automatizezi totul.
Situatiile de gen left-pad vor fi evitate pe viitor prin masurile noi impuse de cei de la NPM Inc. De asemenea in productie e recomandat sa ai propriul tau npm registry si pe cat posibil sa ai un whitelist cu module acceptate && verificate de tine.
Articolul mi se pare stupid. Compara un “Hello, world!” facut cu unelte moderne cu unul plain javascript.
De ce nu compara un site mai inteligent cu ceva baze de date, ca dor suntem in 2016 :)) ?
Eu am inceput sa folosesc gulp, bower si composer, odata ce am inceput sa invat laravel.
Mi se pare superb, e usor si frumos. Cred ca utilitatea acestor tool-uri se observa mult mai bine in proiecte mari.
Mie imi simplifica munca, nu foarte mult momentan, dar vad cu ce m-ar ajuta intr-un proiect mai mare.
Ca veni vorba, stiti ce n-am vazut eu, pana acum? un PPM (PHP Package Manager) scris in PHP.
Deasemenea, poate acesta este si motivul pentru care PHP ori nu a dat chix, ori nu mai este in top…
S-a menționat composer de nouă ori numai în acest topic și tu nu ai auzit de un package manager scris în PHP?
5 Likes
Daca e un proiect foarte simplu eu ma descurc cu npm si cateva require-uri. Daca e ceva mai complex eu zic ca te complici prea mult fara un compiler in productie.
Ideea e ca iti poti face propriul workflow, eu am realizat o intreaga aplicatie de contabilitate care prelucreaza fisiere excel si genereaza facturi/diferite rapoarte cu design modern in 2 zile cu node si nu l-am mai folosit in viata mea. Ideea e ca daca ai un plan pentru o aplicatie si incepi sa folosesti tool-urile in loc sa le inveti iti dai seama foarte rapid ce iti trebuie si ce nu, fiindca nu poti invata ditamai sistemul de automatizare cand ai nevoie de program in 2 zile.
Intradevar, acum trebuie sa ii fac un refactoring serios fiindca e scris ca naiba, dar totusi nu e asa greu sa il refac dupa ce am invatat tool-uri mai avansate.
Chiar mi s-a parut foarte simplu prima data sa folosesc jade cu express pentru a face layout-ul la tabele pentru facturi. Am folosit JS exclusiv pentru backend.
2 Likes
Vroiam sa accentuez faptul ca acel package manager (care a cauzat atatea controverse, datorita left-pad) ar putea fi unul din motivele principale pentru care JS a continuat sa urce (constant?) in cota de piata, in timp ce este posibil ca php ar fi putut avea parte de o crestere in cota de piata, daca ar avea parte de un package manager (scirs in php, care sa poata fi rulat pe shared hosting, sau localhost, fara a avea nevoie de “chestii in plus”) care sa fie recomandat de developeri, pentru share-uirea de librarii scrise in php, precum si faptul ca un astfel de package manager ar putea adice un (sur)plus de crazyness in procesul de dezvoltare cu/in php, putand rezulta intr-o scadere a calitatii produselor scrise in php (cu o tangenta la acelasi efect, fiind (re)produs de/in wordpress.