Hur det känns att lära sig JavaScript 2016

Inga JavaScript- ramverk skapades när den här artikeln skrevs.

Följande är inspirerat av artikeln "It's the future" från Circle CI. Du kan läsa originalet här . Det här stycket är bara en åsikt, och som alla JavaScript-ramverk bör den inte tas på alltför stort allvar.

Hej, jag fick det här nya webbprojektet, men för att vara ärlig har jag inte kodat mycket webb på några år och jag har hört att landskapet förändrats lite. Du är den mest uppdaterade webbutvecklaren här, eller hur?

-Den faktiska termen är Front End-ingenjör, men ja, jag är rätt kille. Jag gör webben 2016. Visualiseringar, musikspelare, flygande drönare som spelar fotboll, you name it. Jag kom precis tillbaka från JsConf och ReactConf, så jag känner till den senaste tekniken för att skapa webbappar.

Sval. Jag behöver skapa en sida som visar den senaste aktiviteten från användarna, så jag behöver bara hämta data från REST-slutpunkten och visa den i någon sorts filtrerbar tabell, och uppdatera den om något ändras på servern. Jag tänkte kanske använda jQuery för att hämta och visa data?

-Herregud nej, ingen använder jQuery längre. Du borde prova att lära dig React, det är 2016.

Åh, okej. Vad är React?

-Det är ett supercoolt bibliotek gjort av några killar på Facebook, det ger verkligen kontroll och prestanda till din applikation, genom att du kan hantera alla vyändringar väldigt enkelt.

Det låter snyggt. Kan jag använda React för att visa data från servern?

-Ja, men först måste du lägga till React och React DOM som ett bibliotek på din webbsida.

Vänta, varför två bibliotek?

-Så det ena är själva biblioteket och det andra är för att manipulera DOM, som du nu kan beskriva i JSX.

JSX? Vad är JSX?

-JSX är bara ett JavaScript-syntaxtillägg som ser ut ungefär som XML. Det är ett annat sätt att beskriva DOM, se det som en bättre HTML.

Vad är det för fel på HTML?

-Det är 2016. Ingen kodar HTML direkt längre.

Rätt. Hur som helst, om jag lägger till dessa två bibliotek kan jag använda React?

-Inte helt. Du måste lägga till Babel och sedan kan du använda React.

Ett annat bibliotek? Vad är Babel?

-Åh, Babel är en transpilerare som låter dig rikta in dig på specifika versioner av JavaScript, medan du kodar i valfri version av JavaScript. Du MÅSTE inte inkludera Babel för att använda ReactJS, men om du inte gör det har du fastnat för att använda ES5, och låt oss vara verkliga, det är 2016, du borde koda i ES2016+ som resten av de coola barnen gör.

ES5? ES2016+? Jag går vilse här borta. Vad är ES5 och ES2016+?

-ES5 står för ECMAScript 5. Det är den utgåva som de flesta har riktat in sig på eftersom den har implementerats av de flesta webbläsare nuförtiden.

ECMAScript?

-Ja, du vet, skriptstandarden JavaScript baserades på 1999 efter den första releasen 1995, då JavaScript fick namnet Livescript och bara kördes i Netscape Navigator. Det var väldigt rörigt då, men tack och lov är saker och ting väldigt tydliga och vi har, typ, 7 upplagor av den här implementeringen.

7 upplagor. På riktigt. Och ES5 och ES2016+ är det?

-Den femte och sjunde upplagan.

Vänta, vad hände med den sjätte?

-Du menar ES6? Ja, jag menar, varje utgåva är en superset av den tidigare, så om du använder ES2016+ använder du alla funktioner i de tidigare versionerna.

Rätt. Och varför använda ES2016+ över ES6 då?

-Tja, du KAN använda ES6, men för att använda coola funktioner som asynkron och vänta måste du använda ES2016+. Annars har du fastnat med ES6-generatorer med koroutiner för att blockera asynkrona samtal för korrekt kontrollflöde.

Jag har ingen aning om vad du just sa, och alla dessa namn är förvirrande. Titta, jag laddar bara in en massa data från en server, jag brukade bara inkludera jQuery från ett CDN och bara hämta data med AJAX-anrop, varför kan jag inte bara göra det?

-Det är 2016 man, ingen använder jQuery längre, det hamnar i en massa spagettikod. Det vet alla.

Rätt. Så mitt alternativ är att ladda tre bibliotek för att hämta data och visa en HTML-tabell.

-Tja, du inkluderar de tre biblioteken men kombinerar dem med en modulhanterare för att bara ladda en fil.

Jag förstår. Och vad är en modulhanterare?

-Definitionen beror på miljön, men på webben menar vi oftast allt som stödjer AMD- eller CommonJS-moduler.

Riiight. Och AMD och CommonJS är...?

-Definitioner. Det finns sätt att beskriva hur flera JavaScript-bibliotek och klasser ska interagera. Du vet, exporterar och kräver? Du kan skriva flera JavaScript-filer som definierar AMD eller CommonJS API och du kan använda något som Browserify för att bunta ihop dem.

OK, det är vettigt... tror jag. Vad är Browserify?

-Det är ett verktyg som låter dig bunta ihop CommonJS-beskrivna beroenden till filer som kan köras i webbläsaren. Det skapades eftersom de flesta människor publicerar dessa beroenden i npm-registret.

npm-registret?

-Det är ett väldigt stort offentligt arkiv där smarta människor lägger kod och beroenden som moduler.

Som ett CDN?

- Inte riktigt. Det är mer som en centraliserad databas där vem som helst kan publicera och ladda ner bibliotek, så att du kan använda dem lokalt för utveckling och sedan ladda upp dem till ett CDN om du vill.

Åh, som Bower!

-Ja, men det är 2016 nu, ingen använder Bower längre.

Åh, jag förstår... så jag måste ladda ner biblioteken från npm då?

-Ja. Så om du till exempel vill använda React laddar du ner React-modulen och importerar den i din kod. Du kan göra det för nästan alla populära JavaScript-bibliotek.

Åh, som Angular!

-Angular är så 2015. Men ja. Angular skulle finnas där, tillsammans med VueJS eller RxJS och andra coola 2016-bibliotek. Vill du lära dig om dessa?

Låt oss hålla fast vid React, jag lär mig redan för många saker nu. Så om jag behöver använda React hämtar jag den från denna npm och använder sedan den här Browserify-grejen?

-Ja.

Det verkar överdrivet komplicerat att bara ta tag i en massa beroenden och knyta ihop dem.

-Det är därför du använder en uppgiftshanterare som Grunt eller Gulp eller Broccoli för att automatisera att köra Browserify. Heck, du kan till och med använda Mimosa.

Grymta? Klunk? Broccoli? Mimosa? Va fan pratar vi om nu?

-Insatsansvariga. Men de är inte coola längre. Vi använde dem ungefär 2015, sedan använde vi Makefiles, men nu slår vi in allt med Webpack.

Göra filer? Jag trodde att det mestadels användes i C- eller C++-projekt.

-Ja, men tydligen på webben älskar vi att göra saker komplicerade och sedan gå tillbaka till grunderna. Det gör vi varje år eller så, vänta bara på det, vi ska göra montering på webben om ett eller två år.

Suck. Du nämnde något som heter Webpack?

-Det är en annan modulhanterare för webbläsaren samtidigt som den är en slags uppgiftslöpare också. Det är som en bättre version av Browserify.

Åh, okej. Varför är det bättre?

-Nja, kanske inte bättre, det är bara mer åsiktsfullt om hur dina beroenden ska knytas. Webpack låter dig använda olika modulhanterare, och inte bara CommonJS sådana, så till exempel inbyggda ES6-stödda moduler.

Jag är extremt förvirrad över hela den här CommonJS/ES6-grejen.

-Alla är det, men du borde inte bry dig längre med SystemJS.

Jesus Kristus, ett annat substantiv-js. Ok, och vad är detta SystemJS?

-Tja, till skillnad från Browserify och Webpack 1.x är SystemJS en dynamisk modulladdare som låter dig knyta ihop flera moduler i flera filer istället för att bunta ihop dem i en stor fil.

Vänta, men jag trodde att vi ville bygga våra bibliotek i en stor fil och ladda den!

-Ja, men eftersom HTTP/2 kommer nu är flera HTTP-förfrågningar faktiskt bättre.

Vänta, så kan vi inte bara lägga till de tre originalbiblioteken för React??

- Inte riktigt. Jag menar, du kan lägga till dem som externa skript från ett CDN, men du skulle fortfarande behöva inkludera Babel då.

Suck. Och det är väl dåligt?

-Ja, du skulle ta med hela babel-kärnan, och det skulle inte vara effektivt för produktionen. Vid produktion måste du utföra en rad förarbeten för att förbereda ditt projekt som får ritualen att kalla Satan att se ut som ett recept på kokta ägg. Du måste förminska tillgångar, fula dem, infoga css ovanför mitten, skjuta upp skript, samt-

Jag har det, jag har det. Så om du inte skulle inkludera biblioteken direkt i ett CDN, hur skulle du göra det?

-Jag skulle transpilera det från Typescript med en Webpack + SystemJS + Babel-kombo.

Typskrift? Jag trodde att vi kodade i JavaScript!

-Typescript ÄR JavaScript, eller bättre uttryckt, en superset av JavaScript, mer specifikt JavaScript på version ES6. Du vet, den sjätte versionen vi pratade om tidigare?

Jag trodde att ES2016+ redan var en superset av ES6! VARFÖR behöver vi nu den här saken som heter Typescript?

-Åh, eftersom det tillåter oss att använda JavaScript som ett maskinskrivet språk och minska körtidsfel. Det är 2016, du bör lägga till några typer i din JavaScript-kod.

Och Typescript gör uppenbarligen det.

-Flow också, även om det bara letar efter att skriva medan Typescript är en superset av JavaScript som måste kompileras.

Suck... och Flow är?

-Det är en statisk typkontroll gjord av några killar på Facebook. De kodade det i OCaml, eftersom funktionell programmering är fantastisk.

OKaml? Funktionell programmering?

-Det är vad de coola barnen använder nuförtiden man, du vet, 2016? Funktionell programmering? Högre funktioner? Curry? Rena funktioner?

Jag har ingen aning om vad du just sa.

-Ingen gör det i början. Titta, du behöver bara veta att funktionell programmering är bättre än OOP och det är vad vi borde använda 2016.

Vänta, jag lärde mig OOP på college, jag tyckte det var bra?

-Så var Java innan det köptes av Oracle. Jag menar, OOP var bra förr i tiden, och det har fortfarande sina användningsområden idag, men nu inser alla att modifiera tillstånd motsvarar att sparka bebisar, så nu går alla över till oföränderliga objekt och funktionell programmering. Haskell-killar hade kallat det i flera år, -och kom inte igång med Elm-killarna- men som tur är på webben har vi nu bibliotek som Ramda som tillåter oss att använda funktionell programmering i vanlig JavaScript.

Släpper du bara namn för sakens skull? Vad fan är Ramnda?

-Inga. Ramda. Som Lambda. Du vet, det där David Chambers bibliotek?

David vem?

-David Chambers. Cool kille. Spelar ett elak kupspel. En av bidragsgivarna till Ramda. Du bör också kolla in Erik Meijer om du menar allvar med att lära dig funktionell programmering.

Och Erik Meijer är...?

-Funktionell programmeringskille också. Fantastisk kille. Han har ett gäng presentationer där han slänger Agile medan han använder den här konstiga färgade skjortan. Du bör också kolla lite av grejerna från Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani-

Ok. Jag ska stoppa dig där. Allt det där är bra och bra, men jag tror att allt det där är bara så komplicerat och onödigt för att bara hämta data och visa det. Jag är ganska säker på att jag inte behöver känna dessa människor eller lära mig alla dessa saker för att skapa en tabell med dynamisk data. Låt oss gå tillbaka till React. Hur kan jag hämta data från servern med React?

-Nja, du hämtar faktiskt inte datan med React, du visar bara datan med React.

Åh, för helvete. Så vad använder du för att hämta data?

-Du använder Fetch för att hämta data från servern.

Jag är ledsen? Använder du Fetch för att hämta data? Den som namnger dessa saker behöver en synonymordbok.

-Jag vet va? Hämta det är namnet på den inbyggda implementeringen för att utföra XMLHttpRequests mot en server.

Åh, alltså AJAX.

-AJAX är bara användningen av XMLHttpRequests. Men visst. Fetch låter dig göra AJAX baserat på löften, som du sedan kan lösa för att undvika återuppringningshelvetet.

Återuppringning helvete?

-Ja. Varje gång du utför en asynkron förfrågan mot servern måste du vänta på dess svar, vilket sedan får dig att lägga till en funktion i en funktion, som kallas callbackpyramiden från helvetet.

Åh, okej. Och det här med löften löser det?

-Verkligen. Genom att manipulera dina återuppringningar genom löften kan du skriva lättare att förstå kod, håna och testa dem, samt utföra samtidiga förfrågningar på en gång och vänta tills alla är laddade.

Och det kan man göra med Fetch?

-Ja, men bara om din användare använder en vintergrön webbläsare, annars måste du inkludera en Fetch polyfill eller använda Request, Bluebird eller Axios.

Hur många bibliotek behöver jag veta för guds skull? Hur många är av dem?

-Det är JavaScript. Det måste finnas tusentals bibliotek som alla gör samma sak. Vi vet bibliotek, faktiskt, vi har de bästa biblioteken. Våra bibliotek är enorma, och ibland inkluderar vi bilder på Guy Fieri i dem.

Sa du precis Guy Fieri? Låt oss få det här över. Vad gör dessa Bluebird, Request, Axios-bibliotek?

-De är bibliotek för att utföra XMLHttpRequests som returnerar löften.

Började inte jQuerys AJAX-metod ge löften också?

-Vi använder inte ordet "J" 2016 längre. Använd bara Fetch och polyfill det när det inte finns i en webbläsare eller använd Bluebird, Request eller Axios istället. Hantera sedan löftet med avvakta inom en asynkronfunktion och bom, du har rätt kontrollflöde.

Det är tredje gången du nämner vänta men jag har ingen aning om vad det är.

-Await låter dig blockera ett asynkront samtal, vilket gör att du kan ha bättre kontroll över när data hämtas och överlag öka kodläsbarheten. Det är fantastiskt, du behöver bara se till att du lägger till förinställningen för steg-3 i Babel, eller använder syntax-async-funktioner och transform-async-to-generator plugin.

Det här är vansinnigt.

-Nej, galet är det faktum att du behöver förkompilera Typescript-kod och sedan transpilera den med Babel för att kunna använda den.

Vad? Det ingår inte i Typescript?

-Det gör den i nästa version, men från och med version 1.7 riktar den sig bara mot ES6, så om du vill använda await i webbläsaren måste du först kompilera din Typescript-kod som riktar sig till ES6 och sedan Babel som skiter till målet ES5.

Vid det här laget vet jag inte vad jag ska säga.

- Titta, det är lätt. Koda allt i Typescript. Alla moduler som använder Fetch kompilerar dem till ES6, transpilerar dem med Babel på en förinställning för steg 3 och laddar dem med SystemJS. Om du inte har Fetch, polyfill det, eller använd Bluebird, Request eller Axios, och hantera alla dina löften med vänta.

Vi har väldigt olika definitioner av lätt. Så med den ritualen hämtade jag äntligen data och nu kan jag visa den med React eller hur?

- Kommer din ansökan att hantera några tillståndsförändringar?

Err, jag tror inte det. Jag behöver bara visa data.

- Tack gode gud. Annars skulle jag behöva förklara dig Flux och implementeringar som Flummox, Alt, Fluxible. Även om du ska vara ärlig bör du använda Redux.

Jag ska bara flyga över de namnen. Återigen, jag behöver bara visa data.

-Åh, om du bara visar data så behövde du inte React till att börja med. Du skulle ha varit bra med en mallmotor.

Skämtar du med mig? Tycker du att det här är roligt? Är det så du behandlar dina nära och kära?

-Jag förklarade bara vad du kunde använda.

Stopp. Sluta bara.

-Jag menar, även om det bara är att använda mallmotor, skulle jag fortfarande använda en Typescript + SystemJS + Babel-kombo om jag var du.

Jag behöver visa data på en sida, inte utföra Sub Zeros ursprungliga MK-dödsfall. Berätta bara för mig vilken mallmotor jag ska använda så tar jag det därifrån.

-Det finns mycket, vilken känner du till?

Usch, kommer inte ihåg namnet. Det var länge sedan.

-jMallar? jQote? REN?

Eh, ringer inte en klocka. En till?

-Genomskinlighet? JSRender? MarkupJS? KnockoutJS? Den hade tvåvägsbindning.

En till?

-PlatesJS? jQuery-tmpl? Styre? Vissa människor använder det fortfarande.

Kanske. Finns det liknande den sista?

-Mustasch, understrykning? Jag tror nu till och med lodash har en om jag ska vara ärlig, men de är typ 2014.

Err.. den kanske var nyare.

-Jade? DustJS?

Inga.

-DotJS? EJS?

Inga.

-Nunjucks? ECT?

Inga.

-Mah, ingen gillar Coffeescript-syntax ändå. Jade?

Nej, du har redan sagt Jade.

-Jag menade Mops. Jag menade Jade. Jag menar, Jade är nu Pug.

Suck. Nej. Kommer inte ihåg. Vilken skulle du använda?

-Förmodligen bara ES6 inbyggda mallsträngar.

Låt mig gissa. Och det kräver ES6.

-Rätta.

Vilket, beroende på vilken webbläsare jag använder, behöver Babel.

-Rätta.

Som, om jag vill inkludera utan att lägga till hela kärnbiblioteket, måste jag ladda det som en modul från npm.

-Rätta.

Vilket kräver Browserify, eller Wepback, eller troligen det där annat som heter SystemJS.

-Rätta.

Som, såvida det inte är Webpack, helst bör hanteras av en uppgiftslöpare.

-Rätta.

Men eftersom jag borde använda funktionell programmering och maskinskrivna språk måste jag först förkompilera Typescript eller lägga till den här Flow-grejen.

-Rätta.

Och sedan skicka det till Babel om jag vill använda vänta.

-Rätta.

Så jag kan sedan använda Hämta, löften och kontrollera flödet och all den där magin.

-Glöm bara inte att polyfill Hämta om det inte stöds, Safari kan fortfarande inte hantera det.

Vet du vad. Jag tror att vi är klara här. Jag tror faktiskt att jag är klar. Jag är klar med webben, jag är klar med JavaScript helt och hållet.

-Det är bra, om några år kommer vi alla att koda i Elm eller WebAssembly.

Jag ska bara gå tillbaka till backend. Jag kan bara inte hantera dessa många ändringar och versioner och upplagor och kompilatorer och transpilerare. JavaScript-gemenskapen är galen om den tror att någon kan hänga med i detta.

-Jag hör dig. Du borde prova Python-communityt då.

Varför?

-Hört talas om Python 3?

Uppdatering: Tack för att du pekade på stavfel och fel, jag kommer att uppdatera artikeln som nämnts. Diskussion i HackerNews och Reddit .