Tämän artikkelin kirjoittamisen aikana ei luotu JavaScript- kehyksiä.
Seuraava on saanut inspiraationsa Circle CI:n artikkelista "Se on tulevaisuus". Voit lukea alkuperäisen täältä . Tämä kappale on vain mielipide, ja kuten mitä tahansa JavaScript-kehystä, sitä ei pidä ottaa liian vakavasti.
Hei, sain tämän uuden web-projektin, mutta rehellisesti sanottuna en ole koodannut paljon verkkoa muutamaan vuoteen ja olen kuullut maiseman muuttuneen hieman. Oletko ajantasaisin verkkokehittäjä täällä?
- Varsinainen termi on Front End Engineer, mutta kyllä, olen oikea kaveri. Teen nettiä vuonna 2016. Visualisaatiot, musiikkisoittimet, lentävät droonit, jotka pelaavat jalkapalloa, mitä vain. Palasin juuri JsConfista ja ReactConfista, joten tiedän uusimmat tekniikat verkkosovellusten luomiseen.
Viileä. Minun on luotava sivu, joka näyttää käyttäjien viimeisimmät toiminnot, joten minun tarvitsee vain saada tiedot REST-päätepisteestä ja näyttää ne jonkinlaisessa suodatettavissa olevassa taulukossa ja päivittää se, jos palvelimessa tapahtuu muutoksia. Ajattelin, että voisinko käyttää jQueryä tietojen hakemiseen ja näyttämiseen?
- Voi luoja ei, kukaan ei käytä enää jQueryä. Sinun pitäisi yrittää oppia React, se on 2016.
Okei. Mikä React?
-Se on joidenkin Facebookin kaverien tekemä superhieno kirjasto, joka todella tuo hallinnan ja suorituskyvyn sovellukseesi, koska voit käsitellä näkymän muutoksia erittäin helposti.
Se kuulostaa siistiltä. Voinko käyttää Reactia palvelimen tietojen näyttämiseen?
-Joo, mutta ensin sinun on lisättävä React ja React DOM kirjastona verkkosivullesi.
Odota, miksi kaksi kirjastoa?
-Joten yksi on varsinainen kirjasto ja toinen on DOM: n manipulointia varten, jota nyt voit kuvata JSX: ssä.
JSX? Mikä on JSX?
-JSX on vain JavaScript-syntaksilaajennus, joka näyttää melko paljon XML:ltä. Se on eräänlainen tapa kuvata DOM:ia, ajattele sitä parempana HTML-koodina.
Mikä HTML:ssä on vikana?
-On vuosi 2016. Kukaan ei enää koodaa HTML:ää suoraan.
Oikein. Joka tapauksessa, jos lisään nämä kaksi kirjastoa, voin käyttää Reactia?
- Ei aivan. Sinun on lisättävä Babel, ja sitten voit käyttää Reactia.
Toinen kirjasto? Mikä on Babel?
-Oh, Babel on siirtosovellus, jonka avulla voit kohdistaa tiettyihin JavaScript-versioihin, kun koodaat millä tahansa JavaScript-versiolla. Sinun EI TÄYTYY sisällyttää Babelia käyttääksesi ReactJS:ää, mutta ellet tee niin, olet jumissa ES5:n käytössä, ja olkaamme totta, nyt on 2016, sinun pitäisi koodata ES2016+:ssa kuten muutkin siistit lapset tekevät.
ES5? ES2016+? Olen eksymässä tänne. Mikä on ES5 ja ES2016+?
-ES5 on lyhenne sanoista ECMAScript 5. Se on versio, johon useimmat ihmiset kohdistavat, koska se on otettu käyttöön useimmissa selaimissa nykyään.
ECMAScript?
-Kyllä, tiedäthän, komentosarjastandardi JavaScript perustui vuonna 1999 sen ensimmäisen julkaisun jälkeen vuonna 1995, silloin, kun JavaScript nimettiin Livescriptiksi ja se toimi vain Netscape Navigatorissa. Se oli hyvin sotkuinen tuolloin, mutta onneksi nyt asiat ovat hyvin selkeitä ja meillä on esimerkiksi 7 versiota tästä toteutuksesta.
7 painosta. Ihan oikeasti. Ja ES5 ja ES2016+ ovat?
- Viides ja seitsemäs painos.
Odota, mitä tapahtui kuudennelle?
-Tarkoitatko ES6:ta? Joo, tarkoitan, että jokainen versio on edellisen versio, joten jos käytät ES2016+:aa, käytät kaikkia aiempien versioiden ominaisuuksia.
Oikein. Ja miksi sitten käyttää ES2016+:aa ES6:n sijaan?
-No, voit käyttää ES6:ta, mutta käyttääksesi upeita ominaisuuksia, kuten async and await, sinun on käytettävä ES2016+:aa. Muuten olet jumissa ES6-generaattoreissa, joissa on korutiinit estämään asynkroniset kutsut oikeaa ohjausvirtaa varten.
En tiedä mitä juuri sanoit, ja kaikki nämä nimet ovat hämmentäviä. Katsos, lataan vain joukon tietoja palvelimelta. Ennen pystyin vain sisällyttämään jQueryn CDN:stä ja vain saamaan tiedot AJAX-kutsuilla, miksi en voi tehdä sitä?
-On vuosi 2016, kukaan ei käytä enää jQueryä, se päätyy spagettikoodiin. Kaikki tietävät sen.
Oikein. Joten vaihtoehtoni on ladata kolme kirjastoa tietojen hakemiseksi ja HTML-taulukon näyttämiseksi.
- No, sisällytät nämä kolme kirjastoa, mutta yhdistät ne moduulien hallintaan ladataksesi vain yhden tiedoston.
Minä näen. Ja mikä on moduulin hallinta?
-Määritelmä riippuu ympäristöstä, mutta verkossa tarkoitamme yleensä kaikkea, mikä tukee AMD- tai CommonJS-moduuleja.
Riiight. Ja AMD ja CommonJS ovat…?
- Määritelmät. On olemassa tapoja kuvata, kuinka useiden JavaScript-kirjastojen ja -luokkien tulee toimia vuorovaikutuksessa. Tiedätkö, vienti ja vaatii? Voit kirjoittaa useita JavaScript-tiedostoja, jotka määrittelevät AMD- tai CommonJS-sovellusliittymän, ja voit käyttää jotakin Browserifyn kaltaista niiden niputtamiseksi.
OK, siinä on järkeä… Mielestäni. Mikä on Browserify?
-Se on työkalu, jonka avulla voit niputtaa CommonJS-kuvattuja riippuvuuksia tiedostoihin, joita voidaan ajaa selaimessa. Se luotiin, koska useimmat ihmiset julkaisevat nämä riippuvuudet npm-rekisterissä.
npm rekisteri?
-Se on erittäin suuri julkinen arkisto, johon älykkäät ihmiset laittavat koodia ja riippuvuuksia moduuleiksi.
Kuten CDN?
-Ei oikeastaan. Se on enemmän kuin keskitetty tietokanta, jossa kuka tahansa voi julkaista ja ladata kirjastoja, joten voit käyttää niitä paikallisesti kehittämiseen ja ladata ne sitten CDN-verkkoon, jos haluat.
Voi, kuten Bower!
-Kyllä, mutta nyt on vuosi 2016, kukaan ei käytä enää Boweria.
Ymmärränkö… joten minun täytyy sitten ladata kirjastot npm:stä?
-Kyllä. Jos siis esimerkiksi haluat käyttää Reactia, lataa React-moduuli ja tuo se koodiisi. Voit tehdä sen melkein jokaiselle suositulle JavaScript-kirjastolle.
Voi, kuten Angular!
-Angular on niin 2015. Mutta kyllä. Angular olisi siellä VueJS:n tai RxJS:n ja muiden hienojen 2016-kirjastojen rinnalla. Haluatko oppia niistä?
Pysytään Reactissa, opin jo nyt liian monia asioita. Joten jos minun on käytettävä Reactia, haen sen tästä npm:stä ja käytän sitten tätä Browserify-toimintoa?
-Kyllä.
Vaikuttaa liian monimutkaiselta tarttua joukkoon riippuvuuksia ja sitoa ne yhteen.
-Se on, siksi käytät tehtävänhallintaa, kuten Grunt, Gulp tai Broccoli, automatisoidaksesi Browserifyn suorittamisen. Hitto, voit jopa käyttää Mimosaa.
Grunt? Kulaus? Parsakaali? Mimosa? Mistä ihmeestä me nyt puhumme?
- Tehtäväpäälliköt. Mutta ne eivät ole enää siistejä. Käytimme niitä vuonna 2015, sitten käytimme Makefileja, mutta nyt käärimme kaiken Webpackilla.
Tee tiedostot? Luulin, että sitä käytettiin enimmäkseen C- tai C++-projekteissa.
-Joo, mutta ilmeisesti verkossa rakastamme tehdä asioista monimutkaisia ja sitten palata perusasioihin. Teemme sen joka vuosi, odota vain, aiomme tehdä kokoonpanon verkossa vuoden tai kahden kuluttua.
Huokaus. Mainitsitko jotain nimeltä Webpack?
-Se on toinen selaimen moduulien hallinta, samalla kun se on myös eräänlainen tehtävien suorittaja. Se on kuin parempi versio Browserifysta.
Okei. Miksi se on parempi?
-No, ei ehkä parempi, se on vain enemmän mielipiteitä siitä, kuinka riippuvuutesi pitäisi sitoa. Webpackin avulla voit käyttää erilaisia moduulien hallintaohjelmia, ei vain CommonJS-ohjelmia, joten esimerkiksi alkuperäisiä ES6-tuettuja moduuleja.
Olen erittäin hämmentynyt tästä CommonJS/ES6-jutusta.
-Kaikki ovat, mutta sinun ei pitäisi enää välittää SystemJS:stä.
Jeesus Kristus, toinen substantiivi-js. Ok, ja mikä tämä SystemJS on?
- No, toisin kuin Browserify ja Webpack 1.x, SystemJS on dynaaminen moduulilataaja, jonka avulla voit sitoa useita moduuleja useisiin tiedostoihin sen sijaan, että niputat ne yhteen suureen tiedostoon.
Odota, mutta ajattelin, että haluamme rakentaa kirjastomme yhdeksi suureksi tiedostoksi ja ladata sen!
-Kyllä, mutta koska HTTP/2 on tulossa nyt, useat HTTP-pyynnöt ovat itse asiassa parempia.
Odota, emmekö voisi vain lisätä kolme alkuperäistä kirjastoa Reactille?
-Ei oikeastaan. Tarkoitan, että voit lisätä ne ulkoisiksi komentosarjoiksi CDN:stä, mutta sinun on silti sisällytettävä Babel.
Huokaus. Ja se on huono, eikö?
-Kyllä, ottaisit mukaan koko babel-ytimen, eikä se olisi tehokasta tuotannossa. Tuotannossa sinun on suoritettava sarja esitehtäviä saadaksesi projektisi valmiiksi, jolloin Saatanan kutsumisrituaali näyttää keitetyn munan reseptiltä. Sinun on pienennettävä resursseja, ilmiselvä ne, upotettava css sivun yläpuolelle, lykättävä komentosarjoja sekä
Sain sen, sain sen. Joten jos et sisällyttäisi kirjastoja suoraan CDN:ään, miten tekisit sen?
- Siirsin sen Typescriptistä Webpack + SystemJS + Babel -yhdistelmällä.
konekirjoitus? Luulin, että koodaamme JavaScriptillä!
-Typescript ON JavaScript, tai paremmin sanottuna, JavaScriptin superjoukko, tarkemmin sanottuna JavaScript versiossa ES6. Tiedätkö sen kuudennen version, josta puhuimme aiemmin?
Luulin, että ES2016+ oli jo ES6:n supersetti! MIKSI tarvitsemme nyt tätä Typescript-nimistä asiaa?
-Voi, koska sen avulla voimme käyttää JavaScriptiä kirjoitettuna kielenä ja vähentää ajonaikaisia virheitä. On vuosi 2016, sinun pitäisi lisätä joitain tyyppejä JavaScript-koodiisi.
Ja Typescript selvästi tekee sen.
- Myös Flow, vaikka se tarkistaa vain kirjoittamisen, kun Typescript on JavaScriptin pääjoukko, joka on käännettävä.
Sigh… ja Flow on?
-Se on joidenkin Facebookin kaverien tekemä staattinen tyyppitarkistus. He koodasivat sen OCamlissa, koska toiminnallinen ohjelmointi on mahtavaa.
OCaml? Toimiva ohjelmointi?
-Se on mitä coolit lapset käyttävät nykyään, tiedätkö, 2016? Toimiva ohjelmointi? Korkealuokkaiset toiminnot? Currying? Puhtaita toimintoja?
Minulla ei ole aavistustakaan, mitä juuri sanoit.
- Kukaan ei tee sitä alussa. Katso, sinun tarvitsee vain tietää, että toiminnallinen ohjelmointi on parempi kuin OOP ja sitä meidän pitäisi käyttää vuonna 2016.
Odota, opin OOP yliopistossa, ajattelin, että se oli hyvä?
- Samoin Java oli ennen kuin Oracle osti sen. Tarkoitan, että OOP oli hyvä aikoinaan, ja sillä on käyttöä edelleenkin, mutta nyt kaikki ymmärtävät, että tilojen muokkaaminen vastaa vauvojen potkimista, joten nyt kaikki ovat siirtymässä muuttumattomiin esineisiin ja toiminnalliseen ohjelmointiin. Haskell-kaverit olivat kutsuneet sitä vuosia, - älkääkä saako minua alkuun Elm-kavereiden kanssa - mutta onneksi verkossa on nyt Ramdan kaltaisia kirjastoja, joiden avulla voimme käyttää toiminnallista ohjelmointia tavallisella JavaScriptillä.
Pudotatko nimiä vain sen takia? Mikä helvetti on Ramnda?
-Ei. Ramda. Kuten lambda. Tiedätkö sen David Chambersin kirjaston?
David kuka?
-David Chambers. Siisti kaveri. Pelaa ilkeää vallankaappauspeliä. Yksi Ramdan avustajista. Kannattaa myös tarkistaa Erik Meijer, jos olet tosissaan oppimassa toiminnallista ohjelmointia.
Ja Erik Meijer on…?
-Myös toiminnallinen ohjelmoija. Mahtava kaveri. Hänellä on joukko esityksiä, joissa hän roskaa Agilea käyttäessään tätä outoa värillistä paitaa. Kannattaa myös tsekata Tj:n, Jash Kenasin, Sindre Sorhusin, Paul Irishin, Addy Osmanin juttuja.
Ok. Aion pysäyttää sinut siellä. Kaikki tämä on hyvää ja hienoa, mutta mielestäni kaikki tämä on vain niin monimutkaista ja tarpeetonta vain tietojen hakemiseen ja näyttämiseen. Olen melko varma, että minun ei tarvitse tuntea näitä ihmisiä tai oppia kaikkia näitä asioita luodakseni taulukon dynaamisilla tiedoilla. Palataan Reactiin. Kuinka voin noutaa tiedot palvelimelta Reactin avulla?
-No, et itse asiassa nouta dataa Reactilla, vaan näytät tiedot Reactilla.
Voi vittu minua. Mitä käytät tietojen hakemiseen?
- Käytät Fetchiä tietojen hakemiseen palvelimelta.
Olen pahoillani? Käytätkö Fetchiä tietojen hakemiseen? Se, joka nimeää näitä asioita, tarvitsee tesaurusten.
- Tiedänkö oikein? Hae se on alkuperäisen toteutuksen nimi XMLHttp-pyyntöjen suorittamiseksi palvelinta vastaan.
Siis AJAX.
-AJAX on vain XMLHttpRequestsin käyttö. Mutta varmasti. Fetch antaa sinun tehdä AJAXin lupauksiin perustuen, minkä jälkeen voit ratkaista takaisinsoittohelvetin välttämiseksi.
Takaisinsoitto helvetti?
-Joo. Joka kerta kun suoritat asynkronisen pyynnön palvelinta vastaan, sinun on odotettava sen vastausta, mikä saa sinut lisäämään funktion funktioon, jota kutsutaan takaisinsoittopyramidiksi helvetistä.
Okei. Ja tämä lupaus ratkaisee sen?
-Todellakin. Käsittelemällä takaisinsoittojasi lupausten avulla voit kirjoittaa helpommin ymmärrettävää koodia, pilkata ja testata niitä sekä suorittaa samanaikaisia pyyntöjä kerralla ja odottaa, kunnes ne kaikki ladataan.
Ja se voidaan tehdä Fetchillä?
-Kyllä, mutta vain jos käyttäjäsi käyttää ikivihreää selainta, muuten sinun on sisällytettävä Fetch polyfill tai käytettävä Request, Bluebird tai Axios.
Kuinka monta kirjastoa minun täytyy tietää, jumalan tähden? Kuinka monta niitä on?
-Se on JavaScript. Täytyy olla tuhansia kirjastoja, jotka kaikki tekevät saman asian. Tunnemme kirjastot, itse asiassa meillä on parhaat kirjastot. Kirjastomme ovat valtavat, ja joskus laitamme niihin kuvia Guy Fieristä.
Sanoitko juuri Guy Fieri? Tehdään tämä ohi. Mitä nämä Bluebird-, Request- ja Axios-kirjastot tekevät?
-Ne ovat kirjastoja, jotka suorittavat lupauksia palauttavia XMLHttp-pyyntöjä.
Eikö jQueryn AJAX-menetelmä alkanut myös antaa lupauksia?
- Emme käytä enää J-sanaa vuonna 2016. Käytä vain Fetchiä ja täytä se moninkertaisesti, kun se ei ole selaimessa, tai käytä sen sijaan Bluebird-, Request- tai Axios-toimintoa. Hallitse sitten lupausta awaitilla async-toiminnolla ja puomilla, sinulla on oikea ohjausvirta.
Tämä on kolmas kerta, kun mainitset odotuksen, mutta minulla ei ole aavistustakaan, mikä se on.
-Awaitin avulla voit estää asynkronisen puhelun, jolloin voit hallita paremmin, milloin tietoja haetaan, ja parantaa koodin luettavuutta yleisesti. Se on mahtavaa, sinun täytyy vain varmistaa, että lisäät vaiheen 3 esiasetuksen Babeliin tai käytä syntaksi-asynkronointitoimintoja ja muunnos-asynkronointi-generaattoriin -laajennusta.
Tämä on hullua.
-Ei, järjetöntä on se, että joudut esikääntämään Typescript-koodin ja siirtämään sen sitten Babelin avulla odottamaan.
Mitä? Eikö se sisälly konekirjoitukseen?
-Se toimii seuraavassa versiossa, mutta versiosta 1.7 lähtien se on kohdistettu vain ES6:een, joten jos haluat käyttää await-toimintoa selaimessa, sinun on ensin käännettävä ES6:een kohdistuva Typescript-koodisi ja sitten ES5:een kohdistettu Babel.
Tässä vaiheessa en tiedä mitä sanoa.
- Katso, se on helppoa. Koodaa kaikki Typescriptissä. Kaikki Fetchiä käyttävät moduulit kääntävät ne kohdistamaan ES6:een, siirtävät ne Babelin avulla vaiheen 3 esiasetukseen ja lataavat ne SystemJS:llä. Jos sinulla ei ole Fetchiä, täytä se tai käytä Bluebird-, Request- tai Axios-sovellusta ja hoida kaikki lupauksesi odotuksella.
Meillä on hyvin erilaiset helpon määritelmät. Joten tuon rituaalin avulla hain vihdoin tiedot ja nyt voin näyttää ne Reactilla, eikö?
- Käsitteleekö sovelluksesi tilamuutoksia?
Äh, en usko. Minun täytyy vain näyttää tiedot.
- Voi luojan kiitos. Muuten minun täytyisi selittää sinulle Fluxia ja toteutuksia, kuten Flummox, Alt, Fluxible. Vaikka ollakseni rehellinen, sinun pitäisi käyttää Reduxia.
Aion vain lentää noiden nimien yli. Jälleen, minun täytyy vain näyttää tiedot.
-Voi, jos näytät vain tietoja, joita et tarvinnut reagoida aluksi. Olisit pärjännyt mallimoottorilla.
Pilailetko minua? Onko tämä mielestäsi hauskaa? Näinkö sinä kohtelet läheisiäsi?
- Selitin vain, mitä voisit käyttää.
Stop. Lopeta vain.
-Tarkoitan, että vaikka se käyttäisikin vain mallimoottoria, käyttäisin silti Typescript + SystemJS + Babel -yhdistelmää sinuna.
Minun täytyy näyttää tiedot sivulla, en suorittaa Sub Zeron alkuperäistä MK-kuolemaa. Kerro vain mitä mallimoottoria käyttää, niin otan sen sieltä.
-On paljon, mikä niistä on sinulle tuttu?
Äh, en muista nimeä. Se oli kauan sitten.
-jTemplates? jQote? PUHDAS?
Äh, ei soita kelloa. Toinen?
- Avoimuus? JSRender? MarkupJS? KnockoutJS? Siinä oli kaksisuuntainen sidonta.
Toinen?
-PlatesJS? jQuery-tmpl? Ohjaustanko? Jotkut käyttävät sitä edelleen.
Ehkä. Onko olemassa samanlaisia kuin viimeinen?
-Vikset, alaviiva? Luulen, että nyt jopa lodashilla on sellainen, ollakseni rehellinen, mutta ne ovat tavallaan 2014.
Err... ehkä se oli uudempaa.
-Jade? DustJS?
Ei.
-DotJS? EJS?
Ei.
-Nunjucks? ECT?
Ei.
-Mah, kukaan ei kuitenkaan pidä Coffeescript-syntaksista. Jade?
Ei, sanoit jo Jade.
- Tarkoitin Mopsia. Tarkoitin Jadea. Tarkoitan, Jade on nyt Mopsi.
Huokaus. Ei. En muista. Kumpaa käyttäisit?
- Luultavasti vain ES6:n alkuperäisiä mallijonoja.
Anna minun arvata. Ja se vaatii ES6:n.
-Korjata.
Joka, riippuen käyttämästäni selaimesta, tarvitsee Babelia.
-Korjata.
Joka, jos haluan sisällyttää lisäämättä koko ydinkirjastoa, minun on ladattava se moduulina npm:stä.
-Korjata.
Mikä vaatii Browserifyn tai Wepbackin tai todennäköisesti sen muun SystemJS:n.
-Korjata.
Jollei, ellei se ole Webpack, ihannetapauksessa tehtävän suorittajan pitäisi hallita.
-Korjata.
Mutta koska minun pitäisi käyttää toiminnallista ohjelmointia ja kirjoitettuja kieliä, minun on ensin esikäännettävä Typescript tai lisättävä tämä Flow-juttu.
-Korjata.
Ja sitten lähetä se Babeliin, jos haluan käyttää, odota.
-Korjata.
Voin sitten käyttää Fetchiä, lupauksia ja ohjata virtausta ja kaikkea sitä taikuutta.
- Älä vain unohda monitäyttöä Hae, jos sitä ei tueta, Safari ei silti pysty käsittelemään sitä.
Tiedätkö mitä. Luulen, että olemme täällä valmiita. Itse asiassa luulen, että olen valmis. Olen valmis webin kanssa, JavaScriptin kanssa kokonaan.
-Se on hyvä, muutaman vuoden kuluttua aiomme kaikki koodata Elmillä tai WebAssemblylla.
Aion vain siirtyä takaisin takaosaan. En vain voi käsitellä näitä monia muutoksia ja versioita ja painotuksia ja kääntäjiä ja käännösohjelmia. JavaScript-yhteisö on hullu, jos se luulee, että kuka tahansa voi pysyä tämän mukana.
- Kuulen sinua. Sinun pitäisi sitten kokeilla Python-yhteisöä.
Miksi?
- Oletko koskaan kuullut Python 3:sta?
Päivitys: Kiitos kirjoitusvirheistä ja -virheistä, päivitän artikkelin toteamallani tavalla. Keskustelua HackerNewsissa ja Redditissä .