Volio bih da cujem sta tacno ? 
Moze i PP, da se ne kvari tema 
Osim znanja programiranja i logike, bitne su ideje, vizija, a prije svega teorijsko znanje, standard itd.
Ako osoba ima vise znanja, to vise ideja dolazi u glavu i kad se nesto krene raditi , prvo se provjeri da li nesto slicno postoji(google is your friend), da li to odgovara potrebama, ako ne odgovara, prouci se sve sto postoji iz te domene i onda se ide raditi alat, ako se vec mora raditi.
Jedno je raditi nesto za zabavu da se nauci, ali prije takvog ucenja, treba nauciti teoriju, a drugo ako se radi profi alat koji odgovara potrebama, ali opet tu treba znanja.
Kao sto je @tpojka spomenuo za joel test, sve vise se pojavljuje u oglasima kao uvjet.
Sa 10 bodova od 12 si u problemu ili u prijevodu, pao si, 11 se tolerira, a 12 se prihvaca.
Clanak je napisan jos 2000. god.
Naletio neki dan na clanak.
Zapocetak, nemoj shvatit moj post preozbiljno…ja to malo kroz šalu spomenuh. Vue je odličan i vjerovatno na druge načine nadoknađuje ono što sam ja imao u svom pristupu.
Recimo mogao sam u templateu pisati sintaksu:
<template >
<div id="#mainBox" >...
<div id="#adBox" >..
</template >
…kasnije nakon što bi inicijalizirao app nad tim templateom, ti elementi bi mi bili dohvatljivi kao: app.mainBox ; app.adBox
…dok bi u pozadini ti elementi dobili neki generički ID koji bi napravio tu vezu izmeđe app-a i elementa. Taj generički ID je u svom nazivu sadržavao keyword iz kojeg nastaje…pa bi sve bilo pregledno kod scopeanja/inspektanja elementa koji nastaje iz templatea.
Ako bi mi se takva instrukcija id="#mainBox" nalazila na više mjesta unutar templatea, ili unutar foreach metode …onda bi kasnije te elemente imao dohvatljive na način app.mainBox[0] ; app.mainBox[1]; …itd.
Ja doduše nisam imao modele kao Vue, pa sam ovim gornjim pristupom postavljao cijele elemente u model i kasnije bio fleksibilan što ću raditi s elementom ili nj. value vrijednošću, ako bi se radilo o inputu…
Druga stvar, koju mislim da Vue nema. Ali nisam siguran…tiče se SEOa.
Kako sam smatrao da je plus za seo da se cijeli html renderira prije isporuke stranice, htio sam da se HTML iz templatea generira već na serveru. I onda sam imao isti alat i na strani servera koji je već tamo generirao cijeli HTML. Zatim bi se app opet inicijalizirao na client strani i sve varijable bi se automatski učitale u app, kao da je isti inicijalno kreiran na client strani.
Mrzilo me malo održavanje/razvoj tog template engine sustava jer sam imao poprilično podudarajućeg code-a za client i server side i to je bio neizbježan DRY. Doduše, uz komentar notacije u codeu si jasno možemo dati do znanja da promjena nekog bloka codea zahtjeva promjenu tamo gdje je taj code dupliciran. Tko god pribjegava kršenju DRY pristupa, toplo ću ga savjetovati da si radi te notacije. Poslje izmjene idu sa manje glavobilje i manje šanse su da se zaboravi upgrejdati sav DRY code.
Ja uz svaki dry blok okačim ovo:
//#dry-gsrt69865fhzd5gfrh
…generički natipkam niz simbola koji kopiram na oba mjesta i onda me CTRL+F lako vodi na sva mjesta gdje je DRY narušen.
Kako god, dry uvijek treba izbjegavat…ali potreba alata koji radi isto/slično na client i server side, me bogme prisilila na dry avanturu.
A kako mrzim dry (nije subjektivno nego opravdano), već sam i tu mozgao o parserima koji bi JS djelove kompajlirali u PHP, …ne da te parsere koristim na živo…nego da mi barem skrate rad pretipkavanja codea. I imao sam nekakve alatiće koji bi mi barem neke trivijalne stvari konvertirale u php… pa sam manje morao ručno. Time is money.
P.S. da nebi bio krivo shvaćen. Sve ovo o DRYu nije bila mana korištenja sustava…korištenje nije imalo veze sa tim dry-om! Nego sam se to osvrnuo na problematiku razvoja sustava koji radi isto na više različitih platformi.
Ako mislis recimo na ovakvo nesto.
Php ima modul koji se zove v8js, za renderiranje js-a na server side, u kakvom je stanju,neznam.
Kod nodejs, ako je app pisan u vuejs ili react , page se moze generirati na server side strani sto je za nodejs prirodno.
Nisam siguran da je nodeJS postojao kad sam ja ovo pravio. (2012)
Ako i je…koliko je bio poznat i pouzdan.
S druge strane…ne mozemo svaki problem rješavati na način da drastično mijenjamo koncept razvoja.
Ako se netko izgradio na PHPu, njemu nije rješenje koje uvjetuje zamjenu PHPa…sa nodeJS u ovom slučaju.
A sigurno da ima raznih načina uvijek…ne negiram to. Isto tako ima puno i slijepih ulica, treba biti svjestan i toga 
Ima i v8js za php, sto sam napisao.
Vidio…kao što rekoh, uvijek ima puno načina. Doduše upitno je koji je ispravan način, tj. dobro odabran put. Dok ne probamo, teško je znat…
Meni je fascinantno, kako ti @bozoou pokusavas svoje neznanje i nerazumijevanje pretvoriti u svoje prednosti i to iz dana u dan i iz sata u sat.
E da, daj nam objasni molim te zasto mrzis DRY.
NodeJS je 2012 bio vec jako stabilan s obzirom na to da je prva stable verzija izasla davne 2009 u 2 mjesecu.
1 Like
I iz minute u minutu.
Nikog nisam demotivis’o. Pročitaj opet.
Ovo je neka ž-produkcija interpretacija koja apsolutno veze nikakve sa rečenim (il’ bar onim što sam rek’o) nema?
Al’ svak’ ima pravo da vjeruje u šta želi. U umjetnosti se pravac zove impresionizam.
1 Like
Ali najjači je bio kraj, Belmin sruši zgradu s teškim naoružanjem…a ti zaključiš: “Dečki, to naoružanje je samo 2% težine moje zgrade, znači 98% sam je ja srušio” xd xd. A to kaj muha nije niš obavljala, to nikog briga 
Saberi se čovječe.
Nema objasnjenja zasto mrzis ili ne volis DRY.
Coek puko ka kokica.
1 Like
Zato jer je code puno bolji kad sve što možeš ponoviti ponoviš što više puta. Onda klijentima prodaš priču kako je code pun megabajta, a što više je uvijek i bolje. To je zakljucak mog frenda dok je ljepio tapete i spajao dvokomponentno ljepilo. Postigao je takvu čvrstoću ljepila, da taj kameni blok nikada nije ni uspio izvaditi iz lavora. Ako ljepilo može biti otporno kao kamen, što nebi naš code ko stijena.
A stijenje je lako održavati…vidiš da u prirodi same opstaju i ne propadaju. Muhe in ne mogu ništa. 
Ja se najiskrenije nadam da se ti sad s ovi salis i da to ne mislis ozbiljno. Ako to ne mislis ozbiljno onda bih stvarno voli znat odgovor na moje postavljeno pitanje, a ne neki podjebavacki odgovor.
2 Likeova
Glupost, klijent mora dobiti ono sto treba i klijenta nije briga koliko je mb i sl.
Zato se u pola firmi sw raspada , a o kvaliteti code-a uopce ne zelim pricati.
Sory, onaj tko ne zna prodati kvalitetu ispred kvantitete, taj bolje neka ne radi.
1 Like
Još kol’ko je juče™, kleo se i glavu nam probij’o značajem DRY-ja.
2 Likeova
Pa momci, kada vi niti jednu raspravu ne uspijevati voditi ozbiljno, što se nebi i ja zaebavao. 
Vidim, jorgi nije ni ukapirao šalu xd…a i CC tek napola xd.