Izbor MVC frejmvorka: Zašto sam izabrao Ember i zbog čega je to sjajna odluka

Dory Zideon, programer i preduzetnik koji radi iz Beograda je nedavno krenuo da koristi Ember, a u ovom tekstu priča o načinu na koji je izabrao Ember naspram alternativa, kako je bilo početi sa ovim frejmvorkom, koji su prednosti i nedostaci i zbog čega je pobornik logike “konvencija ispred konfiguracije”.

Dori Zidon
17/09/2015

Kada sam počeo da radim sa Originateom na novom projektu, dobio sam slobodu da samostalno izaberem stack. Uslovi CEOa su bili jednostavni: kreiranje MVP-ja koji će zameniti postojeće procese planiranja resursa koji danas koristimo. Ovo je značilo zamenu njihovog proces zasnovog na Excelu veb aplikacijom. Rekao sam mu: ne brini, napraviću ti nešto za dve-tri nedelje.

I tako sam se zaseo za svoj računar sa apsolutnom slobodom da izaberem alate. Trebalo je da budem jako srećan.

Ali nisam. Bio sam istresiran. Zaista sam želeo da ih impresioniram, da koristim najnovije tehnologije.

Znao sam JavaScript veoma dobro i prošao sam kroz nekoliko Node projekata, tako da sam njega izabrao. Nisam imao mnogo relacionih podataka, pa sam izabrao Mongo.

Ali koji frontend frejmvork izabrati da bih napravio brzu i elegantnu single-page aplikaciju?

Proces donošenja odluke

Zaista sam želeo da izaberem najbolji, ali kako ulazak u rutinu sa frejmvorkom može da traje od nekoliko dana do nekoliko nedelja, nisam imao vremena za gubljenje.

Koji da izaberem? Angular? Knockout? Backbone? Ember? Meteor? Bio sam u frci.

Koristio sam mnoge tehnologije tokom proteklih godina, ali nisam zaista eksperimentisao sa Angularom, Knockoutom ili Emberom. Koristio sam Backbone, ali je previše zbrkan za moj ukus i ne baš dobro struktuiran.

Tako da sam počeo da čitam o svim tehnologijama.

“Ne” na keca:

Meteor je delovao fenomenalno — veoma pametni ljudi koji grade sjajan koncept. Ideja frontenda i bekenda u istom sistemu deluje neverovatno. Zapravo sam pisao sličan kod u nekom od mojih prethodnih projekata kako bi pomerio modele iz frontenda u bekend, pa sam se odmah povezao sa konceptom. Ipak, Meteor je još u ranoj fazi i nijedno veliko proizvodno okruženje ga nije koristilo u tom momentu, pa sam ga eliminisao iz izbora. Skoro sam pogledao šta ima novo kod njih i primetio sam da su puno napredovali i da im dobro ide. To je jedna od tehnologija na koju ću obraćati pažnju.

Backbone — nikada ga nisam previše voleo a nisam ni veliki fan Maironettea. Za moj ukus je previše zbrkan.

Izbor između preostalih:

Angular — najpopularniji u to vreme, sa dosta podrške budući da je Googleov proizvod. Ipak, pročitao sam i žalbe na to što koristi svoje idiome i inženjerske koncepte koji moraju da se nauče da bi se koristio. Bez obzira, to je bio najpopularniji i najšire korišćeni MVC tako da nisam planirao da ga odbacim bez razmatranja.

Ember — dok sam čitao o Emberu i istraživao, saznao sam da je najspecifičniji od svih frejmvorka i da zahteva praćenje veoma specifične strukture da bi se koristio, dok se Angular više zasniva na konfigurisanju. Takođe sam video da je Ember stabilan i da ga koristi podosta ozbiljnih kompanija.

Odluka nije bila jednostavna ali sam na kraju odabrao Ember, iz dva glavna razloga:

• Ember i Angular su mi delovali najstabilnije, sa najozbiljnijim korisnicima koji ih koriste u produkciji.

• Emberova konvencija ispred konfiguracije. Ember te tera da pratiš određenu strukturu, što može biti vrlo dobra stvar pošto rešava mnoge inženjerske odluke umesto tebe. Plus, niko ne mora da ti bude “policajac za kod” koji bi vodio računa da su fajlovi u odgovarajućim direktorijumima, ili da su klase nazvane odgovarajućim imenima. Svidelo mi se to, a kako nisam samo inženjer već i projektni menadžer i vođa tima, i da sam morao da uklapam više developera iz različitih vremenskih zona u projekat, pomislio sam da bi to bilo sjajno. I, baš sam bio u pravu.

Početak sa Emberom:

Sada, nakon što sam izabrao svoje alate, bilo je vreme da krenem sa konkretnim radom na svom MVPu.

Naravno, počeo sam sa Emberovim zvaničnim tutorijalom. Međutim, on je bio zasnovan na korišćenim Ember-Data. Ember-Data je sloj sličan ORMu koji nije integralni deo Embera. Obezbeđuje frontend sa modelima, i svim povezanim operacijama, i koristi dependency injection za ubacivanje “store” objekta u sve delove Ember aplikacije. Iako je koncept sjajan, u vreme kada sam počinjao Ember-Data je bio odvojen od Embera, i spomenuli su da će uskoro biti integrisan. Stoga sam odlučio da je preveliki rizik da se oslonim na njega pa sam razvio sopstveni sloj podataka, koristeći sopstveni store. Dok pišem ovaj post, još uvek nije našao svoj put u glavni branch i prošao je kroz mnoge značajne izmene. Imajući to na umu, odluka je bila veoma dobra.

Prva nedelja sa Emberom je bila bolna. Koncept konvencije ispred konfiguracije znači da s jedne strane postoji Emberov način, s druge Emberov način. Pokušaji da nešto uradite na ne-Ember način samo dovodi do frustriranja i neće vas odvesti nigde, pa je najbolji način da razumete šta Ember očekuje i da to uradite tako. Na primer, recimo da hoćemo da ažuriramo pojedine elemente, sakrijemo ih ili prikažemo, itd. Dok bismo ih u tradicionalnom jQueryju vezali za neki događaj, Ember način nalaže da dodamo akciju na element.

Ember nakon nekoliko meseci:

Kada razumete kako Ember funkcioniše i šta treba da se radi, postajete super produktivni i možete da izbacujete kod za mali deo vremena od onoga koliko bi vam inače trebalo.

Ember ima vrlo specifičan način interakcije svih objekata u sistemu. Ember vam pruža odličan ruter, gde svaka ruta ima određenu tačku u kojoj učitava model (bilo samostalan model objekt, POJO ili Ember data modele), kontroler objekat koji se uveže oko modela i može da obezbedi različita sračunata polja ili da poveže različite modele zajedno, upravlja akcijama i drugo, uz view koji uvezuje templejte koje koriste HTMLBars (bivši Handlebars). Evo ga anatomski dijagram:

Ember_Anatomy

Ember zaista pruža okvir da napravite sjajne stvari na vrlo jednostavan način (kada skapiramo na koji način ih Ember postavlja); odjednom sam završavao cele strane i kompleksne UI komponente brzinom svetlosti, tako da sam ih kasnije koristio i na drugim mestima. Kada se ubrzate sa Emberom, obožavaćete ga (ili se bar nadam).

Epilog izbora Embera:

Moje Ember putovanje je bilo veoma uzbudljivo. Počelo je sa Emberom 1.3 i sada migriram na Ember 1.10 sa Ember-clijem. Napisao sam kompletan sloj podataka za moju Ember aplikaciju, koja sada ima 150.000 linija koda i koriste je značajne kompanije u produkciji. Prošao sam kroz otpimizaciju performansi i imam nekoliko interesantnih obzervacija o Emberu:

• Mi štreberi volimo tehnologije iz tehničkih razloga. Ali, razlog zbog kog ja volim Ember je poslovan — konvencija ispred konfiguracije. Ovo znači da možete da nove inženjere možete da ubacujete na projekat ili da ih sklanjate sa njega, dogod razumeju Ember mogu vrlo brzo biti produktivni.

• Tokom rada na ovom projektu, pomagao sam kompaniji sa implementacijom novog konsultantskog ugovora. Kako je mušterija koristila Ember to mi je omogućilo da lako primetim nedostatke u dizajnu i da izolovano refaktorišem, umesto da odbacujem te delove.

• Kompanija je imala još jednu bazu koda za koju je svako sugerisao da se odbaci. Kod je zaista bio loš na više nivoa, ali pošto je to bio Ember bilo ga je lako spasiti — refaktorisati i isprebacivati deliće, učiniti ga korisnim i “refaktorabilnim”, štedeći tako kompaniji mesece rada.

• Zaposlio sam nekoliko inženjera da rade na ovom projektu, sa različitih mesta širom sveta. Bio sam očaran time kako su brzo ušli u štos sa Emberom i, iako su bili juniori, Ember im je omogućio da budu veoma produktivni već prvog dana.

• Ember-Cli sistem je sjajan dodatak koji vodi računa o velikom broju stvari, ne postoji drugi MVC frejmvork koji to obezbeđuje.

Nailazim na sve više i više kompanija koje koriste Ember i sam sam veliki pobornik logike “konvencija ispred konfiguracije” zajedno sa Embera. Istina, postoji nedostatak toga što je Ember primorao svoje korisnike da na konstantno refaktorisanje baze koda, ali verujem da je i dalje bolje od toga kako je Angular 2.0 sve odbacio! Takođe, kada koristite najnoviju i najbolju verziju, očekivano je da će se stvari menjati, a Ember sve u svemu omogućuje developerima i menadžerima projekta i proizvoda da dosta dobiju za ono što ulože. Naprosto mislim da je najkompletniji i moj je prvi izbor frontend MVCa za CRUD aplikacije.

Hvala na čitanju i nadam se da vam je moje iskustvo koristilo.

Dori je ovaj članak originalno objavio na engleskom, na svom blogu. 

Dori Zidon

Objavio/la članak.

četvrtak, 17. Septembar, 2015.

IT Industrija

🔥 Najčitanije

jakob

subota, 10. Jun, 2017.

Za mene je jDerth.js zakon.

dejo

četvrtak, 17. Septembar, 2015.

Nije los ember, ali ako mene pitate ali vue.js je buducnost! Jednostavniji je dosta od Embera i angulara, ne tera vas da pratite nikakvu posebnu arhitekturu ili konvenciju i ima taman ono sto je potrebno (2 way data binding i jos neke korisne stvarcice) i vrlo brzo se uci! Koristim ga vec neko vreme u produkciji i prezadovoljan sam