Pozdrav, nisam baš znao odabrati naslov…ali eto, imam jednu “ćaknutu” ideju, pa reko da je makar podijelim i čujem pokoje mišljenje.
Zapravo ne mislim da je ćaknuta, mislim da je genijalna, heh…ali da je relativno teško sprovodiva.
Uglavnom, imam osjećaj da cijela zajednica u webu osjeća da neki vrag ne štima…stvari se mahnito razvijaju (što je ok), ali sistem nema “glavu i rep”. Takav kaos onda zapravo spriječava puni potencijal zajedničkog razvoja…te ovaj mahniti razvoj je možda samo vrh sante kako bi trebalo biti.
O čemu maštam, tj. što me točno muči?
Recimo osoba A razvija neku JS komponentu, neka to bude dialog. I sada osoba A želi dodati tom dialogu metodu da ima loader koji se vrti dok dialog čeka neki proces da završi. Znači, sada moramo raditi i s loaderom. Recimo da je loader komponenta koja je već ugrađena u taj projekt i osoba A će za funkcionalnost dialoga iskoristtii postojeći loader. Čini se ok, ALI…kako će taj dialog iskoristiti osoba B, koja u svom projektu koristi već neki loader?
Hoće li osoba B prihvatiti kompromis pa imati dva različita tipa loadera? Em će to vizualno morati usklađivati…em ima razno raznih problema što koristi dva različita loadera…što nikako ne želi.
Što preostaje, pretumbati source code dialoga, da ga poveže sa loaderom koji već postoji unutar projekta. To će raditi, ali nije li to bačeno vrijeme? Nije li također bačeno vrijeme osobe A koja je razvijala nešto što se ne može ponovno koristiti bez popravaka…
Kada bi trebali usklađivati samo dvije komponente, nebi bio problem, ALI …mi imamo brdo komponenti koje koristi jedan moderni web: dropdown, radio, checkbox, popUp, title, buttons, form … …jedan prosječan framework nudi 30-ak bitnih komponenti.
Da li je rješenje držati se nekog frameworka koji nudi dovoljan izbor komponenti?
Mislim da nikako. To je nož u leđa za napretak. Danas postoji pregršt frameworka, i svi pokušavaju ponuditi sve. Kakvog to smisla ima? Koliko je to bačeno energije? Kako bi napretak izgledao kada bi netko sav taj trud da napravi novi framework uložio da napravi samo jednu uber-super komponentu? Koja će biti frendly u suživotu sa svim ostalim uber-super komponentama koje radi ostatak zajednice?
No danas s ovakvim mentalitetom zajednice je to nemoguće…jer…
Recimo, osoba C razvija “chat” komponentu, koji se odvija u dialogu koji se automatski pali kada se pojavi nova poruka. (Možda glup primjer, nebitno.)
Sada osoba C da bi razvila tu chat komponentu mora koristiti određeni dialog (koji odabere ili sama razvije)…pa time povlači i korištenje određenog loadera koji se koristi sa tim dialogom…i kakav tek onda imamo čušpajz kada tu komponentu krene koristiti osoba koja već ima neki svoj dialog u projektu i svoj loader… Sada je već posao to prepakirati da radi…a tek smo na komponetni koja koristi 2 komponente ispod/unutar sebe…
Ja sam prilično uvjeren da web treba komponente čija se funkcinalnost sastoji od 100-njak ugrađenih komponenti. Kako će se takve komponente seliti od projekta do projekta…i međusobno skladno funkcionirati?
**Ključ je u tome …da bi međusobno funkcionirale, trebaju moći komunicirati! A da bi uspješno komunicirale, trebaju razgovarati istim jezikom!
Zamislite da postoji dogovoreni jezik za metode dialoga:
dialog.setContent()
dialog.show()
dialog.close()
Sada osoba C koja razvija chat unutar dialoga može razvijati taj chat bez da se stvori ikakva zavisnost te komponente od specifičnog dialoga kojeg će odabrati osoba C.
Zašto nema zavisnosti od specifičnog dialoga?
Zavisnosti nema dok se god chat komponenta koristi unutar projekata koji pričaju zajedničkim jezikom. tj. koji poštuju određeni dogovoreni standard, što je u ovom slučaju dogovor da dialog ima metode: .setContent() .show(), .close()
Recimo da se taj standard zove normJS i Pero Perić razvija projekt koji poštuje standard normJS, to znači da koristi isključivo komponente koje poštuju taj standard ili razvija svoje u skladu sa standardom.
I sada Pero Perić koristi CHAT komponentu od osobe C i boli ga ona stvar koji dialog je koristila osoba C, zato jer i Pero Perić ima ugrađen dialog sa metodama: setContent() .show(), .close() i taj dialog je registrirao u svoj projekt kao normJS.dialog.
Sada CHAT komponenta na “slijepo” poziva akciju: normJS.dialog.show() …i stvar radi! Chat komponenta nije pukla iako Pero Perić nije dovlačio točno onaj dialog koji je koristila osoba C prilikom razvoja…
Ako do ovdje nisam bio jasan, slobodno me upozorite što nisam dobro prezentirao. Nije lako sažeti ideju, mada mislim da je načelno prilično jednostavna.
Problematika?
Ono što je potrebno danas, nije bilo potrebno jučer. Znači da standard koji bi uveli u normJS će se s vremenom narušiti. Web je živ…stvari se razvijaju i dogovoreni standardi će brzo postati nedovoljni.
Ali zato, standard niti ne mora biti krut! Standardi se mogu promatrati kroz svoje verzije…i tako bi recimo standard “verzija 2” za dialog mogao definirati nove dvije metode:
dialog.animationOpen();
dialog.animationClose();
…animacije su već iza nas (ali nekada su se pojavile kao noviteti) Mi ne znamo što nosi budućnost i kakve novitete, tako da je logično očekivati da bi standardi morali moći evoluirati od onih koji se propišu danas. No to ne stvara problem, jer za svaku komponentu koju bi se definiralo standardom normJS, znalo bi se od kojih komponenti zavisi i od kojih verzija standarada tih komponenti. Te bi kod registracije komponenti u normJS za pojedini projekt, relativno jednostavna automatska logika mogla upozoriti korisnika da mu nedostaje neka komponenta, ili neka komponenta nema dovoljnu razinu standarda. To bi znači bila zadaća samog normJS-a, koji definira standard, ali i da provjeri je li sve usklađeno. I to bi se moglo izvesti po automatizmu. Da stvar bude bolja…normJS bi mogao i automatski pronaći korisniku sve komponente koje mu nedostaju.
Kako to?
Pa normJS bi u prvu ruku bila (knjiga) popis komponenti i standarada koje moraju zadovoljiti. NormJS nebi proizvodio komponente…on bi samo definirao najidealniji način na koje bi neki developer volio koristiti komponente. Znači popis metoda. To bi bio pristup: “HowToUseFirst”. Znači na prvo mjesto staviti kako bi nešto bilo najelegantnije koristiti i po tome definirati standard, a onda neka se zajednica natječe tko će napraviti bolju komponentu koja ispunjava postavljeni standard. Kada netko napravi komponentu koja upotpunjuje standard, normJS bi to mogao i automatski testirati da li ta komponenta ispunjava postavljeni standard…te ako ispunjava, ona bi tada mogla postati dio normJS-a.
I tako bi normJS znao što ima na raspolaganju i mogao bi svakom developeru pomoći odabrati, doslovice i automatski instalirati sve komponente koje mu trebaju unutar projekta.
Ako vas sve ovo podsjeća na npmJS, definitivno ima sličnosti u korištenju…mogućnosti instalacija, ali nije ista svrha!
Vjerujem da sa razvojem takvog pristupa, webu bi se vratilo ono što je imao nekada kada je bilo malo komponenti. Tj. kada su gotovo sve komponente bile nativne, opisane samo sa HTML tagom. Nekada, kada si koristio input polje, kucao si <input type='text' value='nesto'/> i stvar je uvijek radila. Kakve inicijalizacije, kakvi bakarači…nije bilo brige. Sva funkcionalnost na stranici je znala kako input izgleda i mogli su međusobno komunicirati. (Osim IE-a koji je uvijek pomalo pričao svojim jezikom, i dobar je pokazatelj na vrstu problema koji danas imamo puno većeg srazmjera)
Znači, svi su znali što je input i kako dohvatiti i postaviti vrijednost u njega. Da si razvijao ne znam što…nije te bilo briga da to kasnije neće raditi, jer u svakom projektu su stizali isti INPUTI, i već postojeći code je znao kako s njima komunicirati.
No onda se pojaviše custom komponente, poput custom dropdowna…i svaki na svoj način dohvaća/postavlja vrijednost. A još imamo evente onChange, onOvo, onOno… svaki u svom smjeru vuče kako se developeru tog dropdowna prohtjelo. Pa ti napravi stabilnu komponentu, a ne znaš kako ćeš sa dropdownom komunicirati u prvom sljedećem projektu…
Uglavnom, sa razvojem normJS-a, pojavili bi se takvi alatići o kakvim niti ne sanjamo. Pošto bi svi znali “kako pričaju” komponente koje su u igri …inicijalizacija bi se dešavala u pozadini. Tako reći osjećaj bi bio isti kao kada se koristi input tag <input> kojeg browser za nas inicijalizira i nemamo mi brige o tome. Tako i ovdje, web bi počeo izgledati kao da ima defaultno uber-super lijepe i funkcionalne komponente, naš trud bi se sveo na to da ih umećemo kao što umećemo input tag.
Trude se i browseri to omogućiti, možemo primjetiti taj HTML koji se razvija, nekada si morao koristiti custom date-picker komponentu, sada samo definiraš <input type='date' /> i stvar radi (skoro). To je u jednu ruku to što pričam, ali ne mogu browseri ispratiti ono što bi mogla zajednica suradnjom. I neznam kako se točno browseri ujedinjuju u svojim normama, ali definitivno je potrebna ruka vodilja kao kao što bi bio alat normJS.
Poanta je da bi zajednički jezik omogućio razvoj koji je teško naslutiti, predvidjeti…nebo je granica.
I da nebi bilo zabune…ovo nije nikakva ideja da se izmisli standard i da se nekim zakonom nekoga prisiljava da isti koristi. To bi bilo naprosto nemoguće!
Ideja je samo da se ponudi standard, a da ga prihvati tko želi. Samo je fora u tome da oni koji bi prihvatili standard…takoreći bi sjeli u ubrzani vlak i ta zajednica bi mogla multiplicirati svoje snage (a ne da svako razvija sve) …i odjuriti daleko, daleko naprijed.
I još šećer za kraj, sve to sam zamislio na način da je zajednica ta koja definira standarde…ne ja niti bilo tko drugi. NormJS bi bio međuostalim platforma gdje bi developeri mogli raspravljati i predlagati standarde. Nekakvim sistemom bodovanja bi normJS prigrlio određene predložene standarde i tim putem bi se prvo standardi razvijali… a onda komponente to slijedile.
Bilo bi divno gledati sve to kako radi po automatizmu, a ima potencijal upravo da se posloži automatski.
(Što je umjetna inteligencija, ako nije to…kada mehanika rasuđuje služeći se inteligencijom različitih individualaca…ali to je tema za sebe xd)
Heto, podijelih…slobodno komentirajte, kritizirajte.
Ja inače već dosta dugo ovo imam u glavi…i tek što sam površno krenuo ovim putem, osjetio sam koja se moć krije iza ovoga. Iskreno se nadam da ću skupiti snage i odvažnosti da kreiram alat normJS o kojem pričam…pa makar služio samo meni, bit ću zadovoljan ako će stvar šljakat. 
Btw…dvoumim se i oko imena: normJS vs adapterJS ? Heh…
…pa da odgovorim…
