Milyen érzés megtanulni a JavaScriptet 2016-ban

A cikk írása során nem hoztak létre JavaScript- keretrendszert.

A következőket a Circle CI „Ez a jövő” című cikke ihlette. Az eredetit itt olvashatja el . Ez a darab csak egy vélemény, és mint minden JavaScript-keretrendszert, ezt sem szabad túl komolyan venni.

Hé, megkaptam ezt az új webes projektet, de őszintén szólva néhány éve nem sok webet kódoltam, és hallottam, hogy a táj kicsit megváltozott. Ön a legfrissebb webfejlesztő a környéken, igaz?

-A tényleges kifejezés Front End mérnök, de igen, én vagyok a megfelelő srác. 2016-ban webezek. Vizualizációk, zenelejátszók, repülő drónok, amelyek futballoznak, nevezd meg. Nemrég jöttem vissza a JsConf-ból és a ReactConf-ból, így ismerem a webalkalmazások létrehozásának legújabb technológiáit.

Hűvös. Létre kell hoznom egy oldalt, amely megjeleníti a felhasználók legfrissebb tevékenységét, tehát csak a REST végpontról kell lekérnem az adatokat, és megjeleníteni egyfajta szűrhető táblában, és frissíteni kell, ha bármi változás történik a szerveren. Arra gondoltam, hogy esetleg jQuery-t használok az adatok lekérésére és megjelenítésére?

-Jaj istenem ne, már senki sem használja a jQuery-t. Meg kell próbálnod megtanulni a Reactet, 2016 van.

Ó, rendben. Mi a React?

-Ez egy nagyon klassz könyvtár, amelyet néhány Facebook-fiú készítette, valóban irányítást és teljesítményt biztosít az alkalmazáshoz, mivel lehetővé teszi a nézetmódosítások egyszerű kezelését.

Ez jól hangzik. Használhatom a Reactot a szerverről származó adatok megjelenítésére?

-Igen, de először hozzá kell adnia a React és React DOM-ot könyvtárként a weboldalához.

Várj, minek két könyvtár?

- Tehát az egyik a tényleges könyvtár, a második pedig a DOM manipulálására szolgál, amit most már leírhat JSX-ben.

JSX? Mi az a JSX?

-A JSX csak egy JavaScript szintaxis-kiterjesztés, amely nagyjából úgy néz ki, mint az XML. Ez egy másik módja a DOM leírásának, gondoljon rá, mint egy jobb HTML-re.

Mi a baj a HTML-el?

-Ez 2016. Már senki sem kódolja közvetlenül a HTML-t.

Jobbra. Egyébként, ha hozzáadom ezt a két könyvtárat, akkor használhatom a Reactot?

-Nem egészen. Hozzá kell adnia a Babelt, és használhatja a Reactot.

Egy másik könyvtár? Mi az a Babel?

-Ó, a Babel egy transzpiler, amely lehetővé teszi a JavaScript meghatározott verzióinak megcélzását, miközben a JavaScript bármely verziójában kódol. A ReactJS használatához NEM KELL bevenned a Babelt, de ha nem teszed, akkor leragadsz az ES5 használatánál, és valljuk be, 2016 van, az ES2016+-ban kellene kódolnod, ahogy a többi menő gyerek csinálja.

ES5? ES2016+? Eltévedek itt. Mi az ES5 és ES2016+?

-ES5 az ECMAScript 5 rövidítése. Ezt a kiadást célozzák meg a legtöbben, mivel manapság a legtöbb böngésző alkalmazza.

ECMAScript?

-Igen, tudod, a JavaScript szkriptelési szabvány 1999-ben alapult az 1995-ös első kiadás után, akkoriban, amikor a JavaScriptet Livescriptnek nevezték el, és csak a Netscape Navigatorban futott. Ez akkoriban nagyon zavaros volt, de szerencsére most már nagyon világosak a dolgok, és 7 kiadásunk van ebből a megvalósításból.

7 kiadás. Tényleg. És az ES5 és ES2016+ az?

-Az ötödik és a hetedik kiadás.

Várj, mi történt a hatodikkal?

-Az ES6-ra gondolsz? Igen, úgy értem, minden kiadás az előző szuperkészlete, tehát ha ES2016+-t használ, akkor az előző verziók összes funkcióját használja.

Jobbra. És akkor miért használja az ES2016+-t ES6 helyett?

- Nos, használhatod az ES6-ot, de az olyan nagyszerű funkciók használatához, mint az aszinkron és a várakozás, az ES2016+ használatára van szükség. Ellenkező esetben elakad az ES6 generátorok korutinjaival, amelyek blokkolják az aszinkron hívásokat a megfelelő vezérlési folyamat érdekében.

Fogalmam sincs, mit mondtál, és ezek a nevek zavaróak. Nézze, éppen egy csomó adatot töltök be egy szerverről, régebben csak a jQuery-t tudtam beilleszteni egy CDN-ből, és csak megkaptam az adatokat AJAX-hívásokkal. Miért nem tehetem meg?

-2016-os ember, már senki nem használja a jQuery-t, egy rakás spagetti kódba kerül. Ezt mindenki tudja.

Jobbra. Tehát az én alternatívám az, hogy három könyvtárat töltök be az adatok lekéréséhez és egy HTML-tábla megjelenítéséhez.

- Nos, belefoglalja ezt a három könyvtárat, de összecsomagolja őket egy modulkezelővel, hogy csak egy fájlt tölthessen be.

Értem. És mi az a modulmenedzser?

-A definíció a környezettől függ, de a weben általában bármit értünk, ami támogatja az AMD vagy CommonJS modulokat.

Riiight. És az AMD és a CommonJS…?

- Definíciók. Vannak módok arra, hogy leírjuk, hogyan kell több JavaScript-könyvtárnak és osztálynak kölcsönhatásba lépnie. Tudod, exportál és igényli? Több JavaScript-fájlt is írhat, amelyek meghatározzák az AMD vagy a CommonJS API-t, és használhatja a Browserify-hoz hasonlót, hogy összecsomagolja őket.

Rendben, ennek van értelme… azt hiszem. Mi az a Browserify?

- Ez egy olyan eszköz, amely lehetővé teszi a CommonJS által leírt függőségek kötegelését a böngészőben futtatható fájlokhoz. Azért hozták létre, mert a legtöbb ember közzéteszi ezeket a függőségeket az npm nyilvántartásban.

npm rendszerleíró adatbázis?

-Ez egy nagyon nagy nyilvános adattár, ahol okos emberek kódot és függőséget helyeznek el modulként.

Mint egy CDN?

- Nem igazán. Ez inkább olyan, mint egy központosított adatbázis, ahol bárki publikálhat és letölthet könyvtárakat, így ezeket helyileg használhatja fejlesztéshez, majd ha akarja, feltöltheti egy CDN-re.

Ó, mint Bower!

-Igen, de most 2016 van, már senki sem használja a Bowert.

Ó, értem… szóval le kell töltenem a könyvtárakat az npm-ről?

-Igen. Tehát például, ha használni szeretné a Reactot, töltse le a React modult, és importálja azt a kódjába. Ezt szinte minden népszerű JavaScript-könyvtárnál megteheti.

Ó, mint Angular!

-A Angular olyan 2015. De igen. Az Angular ott lenne a VueJS vagy RxJS és más klassz 2016-os könyvtárak mellett. Szeretnél tanulni ezekről?

Maradjunk a Reactnál, már most túl sok mindent tanulok. Tehát, ha a React-ot kell használnom, lekérem erről az npm-ről, majd ezt a Browserify-t használom?

-Igen.

Ez túlságosan bonyolultnak tűnik ahhoz, hogy megragadjon egy csomó függőséget, és összekapcsolja őket.

- Ez az, amiért használsz olyan feladatkezelőt, mint a Grunt, a Gulp vagy a Broccoli, hogy automatizáld a Browserify futtatását. A fenébe, még a Mimosát is használhatod.

Röfög? Korty? Brokkoli? Mimóza? A fenéről beszélünk most?

-Feladatvezetők. De már nem menők. 2015-ben használtuk őket, aztán Makefiles-t, de most mindent Webpack-kel csomagolunk.

Makefiles? Azt hittem, hogy leginkább C vagy C++ projekteknél használták.

-Igen, de láthatóan a weben szeretjük bonyolulttá tenni a dolgokat, majd visszatérni az alapokhoz. Évente csináljuk, csak várj, egy-két éven belül a weben fogjuk összeszerelni.

Sóhaj. Említett valami Webpack-et?

- Ez egy másik modulkezelő a böngésző számára, miközben egyfajta feladat futtató is. Ez olyan, mint a Browserify jobb verziója.

Ó, oké. Miért jobb?

-Hát, lehet, hogy nem jobb, csak az a véleményem, hogy a függőségeit hogyan kell összekötni. A Webpack lehetővé teszi különböző modulkezelők használatát, nem csak a CommonJS-eket, így például a natív ES6 által támogatott modulokat.

Nagyon megzavart ez az egész CommonJS/ES6 dolog.

-Mindenki igen, de a SystemJS-el már nem kell törődni.

Jézus Krisztus, egy másik főnév-js. Rendben, és mi ez a SystemJS?

- Nos, a Browserify-tól és a Webpack 1.x-től eltérően a SystemJS egy dinamikus modulbetöltő, amely lehetővé teszi több modul összekapcsolását több fájlba ahelyett, hogy egy nagy fájlba kötné őket.

Várj, de azt hittem, egyetlen nagy fájlba akarjuk építeni a könyvtárainkat, és betölteni azt!

-Igen, de mivel most érkezik a HTTP/2, a többszörös HTTP-kérés valójában jobb.

Várj, nem adhatjuk hozzá a React három eredeti könyvtárát?

- Nem igazán. Úgy értem, felveheti őket külső szkriptként egy CDN-ből, de akkor is hozzá kell adnia a Babelt.

Sóhaj. És ez rossz ugye?

-Igen, az egész Babel-core-t beletennéd, és nem lenne hatékony a gyártás szempontjából. A gyártás során egy sor előfeladatot kell végrehajtania, hogy készen álljon a projektje, amelyek révén a Sátán megidézésének rituáléja úgy néz ki, mint egy főtt tojás receptje. Csökkentenie kell az eszközöket, elcsúfítania kell őket, be kell illesztenie a hajtás feletti css-t, el kell halasztania a szkripteket, valamint

Megvan, megvan. Tehát, ha nem venné fel közvetlenül a könyvtárakat egy CDN-be, hogyan tenné?

-Typescriptből átültetném Webpack + SystemJS + Babel kombinációval.

Gépelt? Azt hittem JavaScriptben kódolunk!

- A gépírás JavaScript, pontosabban a JavaScript szuperkészlete, pontosabban a JavaScript az ES6 verzión. Tudod, az a hatodik verzió, amiről korábban beszéltünk?

Azt hittem, az ES2016+ már az ES6 szuperkészlete! MIÉRT van most szükségünk erre a Typescript nevű dologra?

-Ó, mert lehetővé teszi számunkra, hogy a JavaScriptet gépelt nyelvként használjuk, és csökkentsük a futásidejű hibákat. 2016 van, érdemes néhány típust hozzáadni a JavaScript-kódhoz.

A Typescript pedig nyilván ezt teszi.

-A Flow is, bár csak a gépelést ellenőrzi, míg a Typescript a JavaScript szuperkészlete, amelyet le kell fordítani.

Sóhaj… és a Flow?

-Ez egy statikus típusellenőrző, amit néhány srác készítette a Facebookon. OCaml-ben kódolták, mert a funkcionális programozás fantasztikus.

OCaml? Funkcionális programozás?

-Ezt használják a menő gyerekek manapság, tudod, 2016? Funkcionális programozás? Magasrendű funkciók? Curry? Tiszta funkciók?

Fogalmam sincs, mit mondtál.

-Az elején senki sem csinálja. Nézd, csak tudnod kell, hogy a funkcionális programozás jobb, mint az OOP, és ezt kell használnunk 2016-ban.

Várj, az OOP-t tanultam az egyetemen, azt hittem, ez jó?

-A Java is, mielőtt az Oracle megvette volna. Úgy értem, az OOP jó volt régen, és ma is megvan a haszna, de most már mindenki rájön, hogy az állapotok módosítása egyenértékű a babák rugdosásával, így most mindenki a megváltoztathatatlan tárgyakra és a funkcionális programozásra tér át. A Haskell srácok már évek óta hívták – és ne értsenek az Elm srácokkal –, de szerencsére a weben mostanra vannak olyan könyvtáraink, mint a Ramda, amelyek lehetővé teszik számunkra, hogy sima JavaScriptben használjunk funkcionális programozást.

Csak a kedvéért ejtesz neveket? Mi a franc az a Ramnda?

-Nem. Ramda. Mint a Lambda. Tudod, hogy David Chambers könyvtára?

David ki?

-David Chambers. Menő srác. Aljas puccsjátékot játszik. A Ramda egyik közreműködője. Érdemes megnézni Erik Meijert is, ha komolyan akarod tanulni a funkcionális programozást.

És Erik Meijer…?

-Funkcionális programozó srác is. Csodálatos srác. Van egy csomó prezentációja, ahol Agile-t szemétkedik, miközben ezt a furcsa színű inget használja. Érdemes még megnézned Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani cuccait is.

Rendben. Ott meg foglak állítani. Minden jó és jó, de szerintem mindez annyira bonyolult és felesleges az adatok lekéréséhez és megjelenítéséhez. Biztos vagyok benne, hogy nem kell ismernem ezeket az embereket, vagy nem kell megtanulnom mindezt ahhoz, hogy dinamikus adatokat tartalmazó táblázatot készítsek. Térjünk vissza a Reacthoz. Hogyan kérhetem le az adatokat a szerverről a React segítségével?

-Nos, valójában nem a React-tal kéri le az adatokat, hanem csak megjeleníti az adatokat a React-tal.

Ó, a fenébe. Szóval mit használsz az adatok lekérésére?

- A Fetch segítségével kéri le az adatokat a szerverről.

sajnálom? A Lekérést használja az adatok lekéréséhez? Aki ezeket a dolgokat megnevezi, annak tezauruszra van szüksége.

-Tudom igaz? Lekérni, hogy ez a natív implementáció neve az XMLHttpRequests kiszolgálón történő végrehajtásához.

Ó, szóval AJAX.

-Az AJAX csak az XMLHttpRequests használata. De biztos. A Fetch lehetővé teszi az AJAX-ot az ígéretek alapján, amelyet aztán megoldhat, hogy elkerülje a visszahívási poklot.

Visszahívás a pokolba?

-Igen. Minden alkalommal, amikor aszinkron kérést hajt végre a kiszolgálóval szemben, meg kell várnia a válaszát, amely ezután arra készteti, hogy hozzáadjon egy függvényt egy függvényen belül, amelyet a pokolból származó visszahívási piramisnak neveznek.

Ó, oké. És ez az ígéret megoldja?

-Valóban. A visszahívások ígéretekkel történő manipulálásával könnyebben érthető kódot írhat, kigúnyolhatja és tesztelheti őket, valamint egyszerre hajthat végre egyidejű kéréseket, és várja meg, amíg mindegyik betöltődik.

És ezt meg lehet tenni a Fetch-el?

-Igen, de csak abban az esetben, ha a felhasználó örökzöld böngészőt használ, ellenkező esetben be kell illesztenie egy Fetch polyfill-t, vagy használja a Request, Bluebird vagy Axios alkalmazást.

Hány könyvtárat kell tudnom az isten szerelmére? Hányan vannak?

- Ez JavaScript. Több ezer könyvtárnak kell lennie, amelyek mindegyike ugyanazt csinálja. Ismerjük a könyvtárakat, sőt, nekünk vannak a legjobb könyvtáraink. A könyvtáraink hatalmasak, és néha Guy Fieri képeit is belehelyezzük.

Azt mondtad, Guy Fieri? Végezzük el ezt. Mit csinálnak ezek a Bluebird, Request, Axios könyvtárak?

- Ezek olyan könyvtárak, amelyek XMLHttpRequest-eket hajtanak végre, amelyek ígéreteket adnak vissza.

Nem kezdett a jQuery AJAX metódusa is ígéreteket adni?

- 2016-ban már nem használjuk a „J” szót. Csak használja a Fetch-et, és töltse ki többször is, ha nincs böngészőben, vagy használja helyette a Bluebird, a Request vagy az Axios alkalmazást. Ezután kezelje az ígéretet az await funkcióval egy aszinkron funkción belül, és boom, megfelelő vezérlési folyamat áll rendelkezésére.

Már harmadszor említed, hogy várj, de fogalmam sincs, mi az.

A -Await lehetővé teszi az aszinkron hívások blokkolását, így jobban ellenőrizheti, hogy mikor kerül sor az adatok lekérésére, és általánosságban javítja a kód olvashatóságát. Ez fantasztikus, csak meg kell győződnie arról, hogy hozzáadta a 3. szakasz előbeállítását a Babelben, vagy használja a szintaxis-async-függvényeket és a transzformáció-async-to-generator beépülő modult.

Ez őrültség.

- Nem, őrültség az a tény, hogy előre le kell fordítania a Typescript kódot, majd át kell fordítania a Babellel a várakozáshoz.

Mi van? Nincs benne a Typescriptben?

-A következő verzióban megteszi, de az 1.7-es verziótól csak az ES6-ot célozza meg, tehát ha a await-t szeretné használni a böngészőben, először le kell fordítania az ES6-ot célzó Typescript-kódot, majd az ES5-öt célzó Babelt.

Ezen a ponton nem tudom, mit mondjak.

-Nézd, könnyű. Mindent kódoljon Typescriptben. A Fetchet használó összes modul lefordítja őket az ES6 céljára, átülteti őket a Babel segítségével a 3. szakaszban, és betölti őket a SystemJS segítségével. Ha nincs Fetch, töltse ki többször, vagy használja a Bluebird, Request vagy Axios alkalmazást, és kezelje minden ígéretét várakozással.

Nagyon eltérő definícióink vannak a könnyűre. Tehát ezzel a rituáléval végre lekértem az adatokat, és most már meg tudom jeleníteni a React segítségével, igaz?

- Az alkalmazásod kezelni fog bármilyen állapotváltozást?

Err, nem hiszem. Csak meg kell jelenítenem az adatokat.

- Ó, hála istennek. Ellenkező esetben el kellett magyaráznom a Flux-ot és az olyan implementációkat, mint a Flummox, Alt, Fluxible. Bár őszintén szólva Reduxot kellene használnod.

Csak átrepülök ezeken a neveken. Megint csak adatokat kell megjelenítenem.

-Ó, ha csak azokat az adatokat jeleníti meg, amelyekre nem volt szüksége, reagáljon. Jól jártál volna egy sablonmotorral.

viccelsz velem? Szerinted ez vicces? Te így bánsz a szeretteiddel?

-Csak elmagyaráztam, hogy mire használhatod.

Stop. Csak állj meg.

-Úgy értem, még ha csak sablonmotort használ is, akkor is a Typescript + SystemJS + Babel kombinációt használnám a helyedben.

Adatokat kell megjelenítenem egy oldalon, nem pedig a Sub Zero eredeti MK-halálát. Csak mondd meg, hogy milyen sablonmotort használjak, és onnan veszem át.

-Sok van, melyiket ismered?

Jaj, nem emlékszem a névre. Nagyon régen volt.

-jSablonok? jQote? TISZTA?

Err, nem csenget. Még egyet?

- Átláthatóság? JSRender? MarkupJS? KnockoutJS? Ennek kétirányú kötése volt.

Még egyet?

-TányérokJS? jQuery-tmpl? Kormány? Vannak, akik még mindig használják.

Talán. Vannak hasonlók az utolsóhoz?

-Bajusz, aláhúzás? Azt hiszem, most még a lodash-nak is van egy, hogy őszinte legyek, de ezek a 2014-esek.

Err.. talán újabb volt.

- Jade? DustJS?

Nem.

-DotJS? EJS?

Nem.

-Nunjucks? ECT?

Nem.

-Mah, amúgy senki sem szereti a Coffeescript szintaxist. Jade?

Nem, már mondtad Jade-et.

-Mopszra értettem. Jade-re gondoltam. Úgy értem, Jade most Mopsz.

Sóhaj. Nem. Nem emlékszem. Te melyiket használnád?

- Valószínűleg csak az ES6 natív sablon karakterláncai.

Hadd találjam ki. És ehhez ES6 kell.

-Helyes.

Amelynek, attól függően, hogy milyen böngészőt használok, szüksége van a Babelre.

-Helyes.

Amit ha be akarok venni anélkül, hogy hozzáadnám a teljes alapkönyvtárat, akkor modulként kell betöltenem az npm-ről.

-Helyes.

Amihez Browserify vagy Wepback szükséges, vagy valószínűleg a SystemJS nevű másik dolog.

-Helyes.

Amit, hacsak nem Webpackről van szó, ideális esetben egy feladatfutónak kellene kezelnie.

-Helyes.

De mivel funkcionális programozást és gépelt nyelveket kellene használnom, először előre le kell fordítanom a Typescriptet, vagy hozzá kell adni ezt a Flow-t.

-Helyes.

És akkor küldje el a Babelnek, ha használni akarom, várja meg.

-Helyes.

Így aztán használhatom a Fetch-et, az ígéreteket, és irányíthatom az áramlást és mindezt a varázslatot.

-Csak ne felejtsd el többször kitölteni a Fetchet, ha nem támogatott, a Safari még mindig nem tudja kezelni.

Tudod mit. Azt hiszem, itt végeztünk. Valójában azt hiszem, befejeztem. Kész vagyok a webtel, a JavaScripttel teljesen.

- Rendben van, néhány éven belül mindannyian Elm-ben vagy WebAssembly-ben fogunk kódolni.

Visszatérek a háttérbe. Egyszerűen nem tudom kezelni ezt a sok változtatást és verziót és kiadást, fordítót és transzpilátort. A JavaScript közösség őrült, ha azt hiszi, hogy bárki lépést tud tartani ezzel.

- Hallom. Akkor próbáld ki a Python közösséget.

Miért?

- Hallottál már a Python 3-ról?

Frissítés: Köszönöm a helyesírási hibákat, frissítem a cikket a leírtak szerint. Vita a HackerNewsban és a Redditben .