Ja i pričam o tome. Trebalo bi znati većinu karakteristika jezika da bi se ispravno postavio temelj.
Meni bi nerealno bilo za očekivati da ljudi pristupe nečem što ne podržava 90% trenutne sintakse ili obrnuto što podržava tek 10% (uslovno rečeno, banalizujem) - vrlo puno bi’ (lično) mor’o znati u trenutnoj nomenklaturi da bi’ pristupio tako nečem. (Tipkam naglas.)
1 Like
Tipkam ja kostur normJS a u najobicnijem editoru, pa cu ga onda prenesti na neki online dokument.
Btw…otkrio sam jedan jako zanimljiv novitet.
Zamisli klasicni pristup i sada imas Perinu i Ivinu skriptu. I Perina i Ivina skripta trebaju trim() metodu. No Perina skripta tu metodu dobiva preko jQuery.a a Ivina preko Lodasha…neka treca skripta preko nekog treceg librirya. Sto se desava? Nastaju tri nepotrebna dependencya i projekt je zagušen sa suviše nepotrebnog smeća.
Realno, sve tri trim() metode koje oni koriste su isti opažajni prirodni objekt. Jer objekt nosi neku svrhu…a ovdje imamo samo jednu svrhu. Te iako imamo tri librarya koji omogućavaju tri trim metode, to je jedna funkcionalnost. Stoga, i trim metodu možemo opisati standardom. Standarizirati input, output i što body mora odraditi. Tu nam to postaje komponenta, isto kao sto je i dropdown. Ha-ca!
Što smo postigli? Unutar normJS.a bilo koja komponenta se može pozivati na trim metodu kao da je to dio sintakse normJS-a. NormJS će omogućiti da trim bude includan. A tko će biti proizvođač trim komponente, to je nebitno. To upravo ostavlja mogućnost proizvođačima trim komponente da se takmiče da njihova bude najbolja…najoptimiziranija…drugim riječima, da trim komponenta, isto kao i svaka druga…evoluira ka beskonačnom savršenstvu kroz nadmetanje tj.evoluciju.
Sve metode koje je Lodash uočio da su korisne, su upravo samo dio cijelog skupa metoda/komponenti koje se mogu standarizirati…i time omogućiti i da taj bazen komponenti evoluira kroz utjecaj zajednice.
Ovo je tako sick. 
Na jednoj razini to onda rješava problem da te iste metode uočavamo i unutar različitih programskih jezika. Jer trim ne egzistencira unutar JSa, on svoje mjesto pronalazi i u PHPu i u C#…i u svakom drugom algoritamskom jeziku koji je evoluirao određeni stupanj od asemblera. Stoga, trim ne smije biti ograničen različitosti sintakse!
Trim je u ovom primjeru samo predstavnik bilo koje metode koju uočavamo da smo je već standarizirali načinom korištenja. Tj. da se standarizirala potreba za njom.
Može li objašnjenje u čemu se tačno ogleda prednost ovog gore u odnosu na ovo dole? Koja je to superiorna karakteristika prvog citata koja izbjegava posljedicu u drugom citatu?
1 Like
Baš sam neki dan naletio.
@bozoou ovo rješava 100 % tvoje probleme na .netu, obratite se sa povjerenjem 
https://blazor.net/
Poceli ljudi uvidjati da jedan dio toga ne valja ili veci dio.
Izmislili ljudi funkcionalno programiranje, koje bas i nije prihvaceno u 21.st, izmislili objektno programiranje da se rijese problemi koje su imali kod proceduralnog programiranja, iako je c jos uvijek kao jezik dosta koristen.
Onda njim nije bilo dovoljno OOP, pa su izmislili design patterne da se uvede reda. Ni to nije bilo dovoljno pa su postale popularne razno razne arhitekture kao mvc, mvvm i sl, nadalje, ekipi ne valja sql, pa izmisljaju orm i sl.
Ni to nije bilo dovoljno, pa se izmislilo domain driven development i hrpa slicnih arhitektura, i sad sve dalje, sve se vise komplicira.
Da se odma ogradim, ucim design patterne, znam OOP, proucavam domain driven development itd.
Npr. Sto se tice JS i ostalog, najradije bi za projekte koristio cisti JS.
Ponovit ću samo najbitnije.
Kada se izvede na dobar način validacija standarda tih konponenti koje treba standarizirati, onda će to biti cross browser kompatibilno bez specijalnog angažmana od strane browsera, što trenutno nemamo.
A da je potrebno, sigurno da je potrebno…štoviše, neizbježno je… vrijeme će pokazati. 
Ocito je da nisi pisao mnogo JS-a, ako tako mislis 
2 Likeova
JS nisam puno, ali dovoljno.
Sto nedostaje JS-u? Nekome se JS gadi, nekome ne. Tako je kod svakog jezika.
Jezik kao jezik, znam treba vise tipkati, mozda kompliciranije i sl. Isto kao da kazes zasto ljudi koriste c, kad imaju c++, rust, go lang i sl.
Uvijek ce biti onih koji ce koristiti C lang.
Da mi se pruzi prilika raditi C lang, jucer bi pristao.
Nisam jedan od onih koji se hvataju za nove stvari cim se pojave zato da budem drukciji ili zato jer je to kul.
Ništa, zato su se nad njim i izgradile razne tehnoligije.
Ne fali ništa ni asembleru…
Onom jeziku kojem fali, nad njim se ne gradi…nego izumire.
I vecina tih tehnologija opet ima odredjene probleme.
Svaka tehnologija koja je izgrađena nad asemblerom ima neke svoje probleme
Zato je tu normJS (Tj. bit će 
)
S tobom uvijek neke rasprave oko jezika, a nigdje nekih konkretnih cinjenica
Ne nedostaje nista, boljeg za Browser trenutno nema.
Sta cekas ? Poslova za C ima svugdje i cak sta vise odlicno su placeni.Rece mi neki dan kolega da je vidio neki oglas za C developera 150k eura, lokacija Berlin.
Right tool for right job.Zasto su Docker i Kubernetes pisani u Go, a ne u C ?
Radim, nemam vremena ni za sebe.
Imam uvjet, a to je remote job.
Za sada ne selim u inozemstvo.
A remote poslova za C developera nema ? Daj ne zaj.
Nisam naletio jos na takve oglase.
Neznam gdje traziti takve poslove, osim stackoverflow i facebooka.
Ali ne c++, nego cisti C.
Toptal npr. ?
Al ja imam osjecaj da ti hladno trollas cijelo vrijeme
Ni lošijeg. JS je jedina opcija za browser Nema ništa pored JS-a. (Znam da znas )
…e sad, postoje jezici koji se kompajliraju u JS. To je sad vec filozofsko pitanje jesu li oni JS ili nisu.
Ali to su svakako jezici koji su nastali nad JS-om, a ne pored njega.
Znaci sve su to unuci JS-a, ako već nisu JS.