Hvordan det føles at lære JavaScript i 2016

Der blev ikke oprettet nogen JavaScript -rammer under skrivningen af denne artikel.

Det følgende er inspireret af artiklen "It's the future" fra Circle CI. Du kan læse originalen her . Dette stykke er kun en mening, og ligesom enhver JavaScript-ramme, bør den ikke tages for seriøst.

Hej, jeg har fået dette nye webprojekt, men for at være ærlig har jeg ikke kodet meget web i et par år, og jeg har hørt, at landskabet har ændret sig en smule. Du er den mest opdaterede web-udvikler her omkring ikke?

-Den faktiske betegnelse er Front End-ingeniør, men ja, jeg er den rigtige. Jeg laver web i 2016. Visualiseringer, musikafspillere, flyvende droner, der spiller fodbold, you name it. Jeg er lige kommet tilbage fra JsConf og ReactConf, så jeg kender de nyeste teknologier til at skabe webapps.

Afkøle. Jeg skal oprette en side, der viser den seneste aktivitet fra brugerne, så jeg skal bare hente dataene fra REST-slutpunktet og vise dem i en form for filtrerbar tabel og opdatere den, hvis noget ændrer sig på serveren. Jeg tænkte måske at bruge jQuery til at hente og vise dataene?

-Åh min gud nej, ingen bruger jQuery længere. Du bør prøve at lære React, det er 2016.

Åh, okay. Hvad er React?

-Det er et super fedt bibliotek lavet af nogle fyre på Facebook, det bringer virkelig kontrol og ydeevne til din applikation, ved at tillade dig at håndtere alle visningsændringer meget nemt.

Det lyder pænt. Kan jeg bruge React til at vise data fra serveren?

-Ja, men først skal du tilføje React og React DOM som et bibliotek på din webside.

Vent, hvorfor to biblioteker?

-Så det ene er det faktiske bibliotek, og det andet er til at manipulere DOM, som du nu kan beskrive i JSX.

JSX? Hvad er JSX?

-JSX er bare en JavaScript-syntaksudvidelse, der ligner XML stort set. Det er en anden måde at beskrive DOM på, tænk på det som en bedre HTML.

Hvad er der galt med HTML?

-Det er 2016. Ingen koder HTML direkte længere.

Højre. Anyway, hvis jeg tilføjer disse to biblioteker, kan jeg bruge React?

- Ikke helt. Du skal tilføje Babel, og så kan du bruge React.

Et andet bibliotek? Hvad er Babel?

-Åh, Babel er en transpiler, der giver dig mulighed for at målrette mod specifikke versioner af JavaScript, mens du koder i enhver version af JavaScript. Du behøver ikke at inkludere Babel for at bruge ReactJS, men medmindre du gør det, sidder du fast med at bruge ES5, og lad os være rigtige, det er 2016, du burde kode i ES2016+ ligesom resten af de seje børn gør.

ES5? ES2016+? Jeg er ved at fare vild herovre. Hvad er ES5 og ES2016+?

-ES5 står for ECMAScript 5. Det er den udgave, der har flest mål, da den er blevet implementeret af de fleste browsere i dag.

ECMAScript?

-Ja, du ved, scriptstandarden JavaScript var baseret på i 1999 efter dens første udgivelse i 1995, dengang da JavaScript hed Livescript og kun kørte i Netscape Navigator. Det var meget rodet dengang, men nu er tingene heldigvis meget klare, og vi har ligesom 7 udgaver af denne implementering.

7 udgaver. For rigtigt. Og ES5 og ES2016+ er?

-Hhv. femte og syvende udgave.

Vent, hvad skete der med den sjette?

- Du mener ES6? Ja, jeg mener, hver udgave er et supersæt af den forrige, så hvis du bruger ES2016+, bruger du alle funktionerne i de tidligere versioner.

Højre. Og hvorfor så bruge ES2016+ over ES6?

-Nå, du KUNNE bruge ES6, men for at bruge fede funktioner som async og afvent, skal du bruge ES2016+. Ellers sidder du fast med ES6-generatorer med coroutiner til at blokere asynkrone opkald til korrekt kontrolflow.

Jeg aner ikke, hvad du lige sagde, og alle disse navne er forvirrende. Se, jeg indlæser bare en masse data fra en server, jeg plejede at være i stand til bare at inkludere jQuery fra en CDN og bare hente dataene med AJAX-kald, hvorfor kan jeg ikke bare gøre det?

-Det er 2016 mand, ingen bruger jQuery længere, det ender i en masse spaghettikode. Det ved alle.

Højre. Så mit alternativ er at indlæse tre biblioteker for at hente data og vise en HTML-tabel.

-Nå, du inkluderer de tre biblioteker, men samler dem med en moduladministrator for kun at indlæse én fil.

Jeg kan se. Og hvad er en modulmanager?

-Definitionen afhænger af miljøet, men på nettet mener vi normalt alt, der understøtter AMD- eller CommonJS-moduler.

Riiight. Og AMD og CommonJS er...?

-Definitioner. Der er måder at beskrive, hvordan flere JavaScript-biblioteker og -klasser skal interagere. Du ved, eksporterer og kræver? Du kan skrive flere JavaScript-filer, der definerer AMD eller CommonJS API, og du kan bruge noget som Browserify til at samle dem.

OK, det giver mening... tror jeg. Hvad er Browserify?

-Det er et værktøj, der giver dig mulighed for at samle CommonJS beskrevne afhængigheder til filer, der kan køres i browseren. Det blev oprettet, fordi de fleste mennesker udgiver disse afhængigheder i npm-registret.

npm registreringsdatabasen?

-Det er et meget stort offentligt lager, hvor smarte mennesker lægger kode og afhængigheder som moduler.

Ligesom en CDN?

- Ikke rigtig. Det er mere som en centraliseret database, hvor alle kan publicere og downloade biblioteker, så du kan bruge dem lokalt til udvikling og derefter uploade dem til et CDN, hvis du vil.

Åh, ligesom Bower!

-Ja, men det er 2016 nu, ingen bruger Bower længere.

Åh, jeg forstår... så jeg er nødt til at downloade bibliotekerne fra npm?

-Ja. Så hvis du for eksempel vil bruge React, downloader du React-modulet og importerer det i din kode. Du kan gøre det for næsten alle populære JavaScript-biblioteker.

Åh, ligesom Angular!

-Angular er så 2015. Men ja. Angular ville være der sammen med VueJS eller RxJS og andre seje 2016-biblioteker. Vil du lære om dem?

Lad os holde os til React, jeg lærer allerede for mange ting nu. Så hvis jeg skal bruge React, henter jeg det fra denne npm og bruger derefter denne Browserify-ting?

-Ja.

Det virker alt for kompliceret at bare få fat i en masse afhængigheder og binde dem sammen.

-Det er derfor, du bruger en task manager som Grunt eller Gulp eller Broccoli til at automatisere at køre Browserify. For pokker, du kan endda bruge Mimosa.

Grynte? Gulp? Broccoli? Mimosa? For pokker taler vi om nu?

-Task managers. Men de er ikke seje længere. Vi brugte dem i 2015, så brugte vi Makefiles, men nu pakker vi alt ind med Webpack.

lave filer? Jeg troede, at det mest blev brugt på C- eller C++-projekter.

-Ja, men på nettet elsker vi åbenbart at gøre tingene komplicerede og så gå tilbage til det grundlæggende. Det gør vi hvert år eller deromkring, bare vent på det, vi skal lave samling på nettet om et år eller to.

Suk. Du nævnte noget, der hedder Webpack?

-Det er en anden modulmanager til browseren, mens den også er en slags opgaveløber. Det er ligesom en bedre version af Browserify.

Åh, ok. Hvorfor er det bedre?

-Nå, måske ikke bedre, det er bare mere meningsfuldt om, hvordan dine afhængigheder skal bindes. Webpack giver dig mulighed for at bruge forskellige moduladministratorer, og ikke kun CommonJS dem, så for eksempel native ES6-understøttede moduler.

Jeg er ekstremt forvirret over hele denne CommonJS/ES6-ting.

-Det er alle, men du burde ikke være ligeglad mere med SystemJS.

Jesus christ, et andet navneord-js. Ok, og hvad er dette SystemJS?

-Tja, i modsætning til Browserify og Webpack 1.x er SystemJS en dynamisk modulindlæser, der giver dig mulighed for at binde flere moduler i flere filer i stedet for at samle dem i én stor fil.

Vent, men jeg troede, vi ville bygge vores biblioteker i én stor fil og indlæse den!

-Ja, men fordi HTTP/2 kommer nu er flere HTTP-anmodninger faktisk bedre.

Vent, så kan vi ikke bare tilføje de tre originale biblioteker til React??

- Ikke rigtig. Jeg mener, du kan tilføje dem som eksterne scripts fra et CDN, men du skal stadig inkludere Babel derefter.

Suk. Og det er dårligt ikke?

-Ja, du ville inkludere hele babel-kernen, og det ville ikke være effektivt til produktion. I produktionen skal du udføre en række forhåndsopgaver for at gøre dit projekt klar, der får ritualet til at tilkalde Satan til at ligne en opskrift på kogte æg. Du skal formindske aktiver, hæmme dem, inline css over skillelinjen, udskyde scripts, samt-

Jeg fik det, jeg fik det. Så hvis du ikke ville inkludere bibliotekerne direkte i et CDN, hvordan ville du så gøre det?

-Jeg ville transpilere det fra Typescript ved hjælp af en Webpack + SystemJS + Babel combo.

Typeskrift? Jeg troede, vi kodede i JavaScript!

-Typescript ER JavaScript, eller bedre sagt, et supersæt af JavaScript, mere specifikt JavaScript på version ES6. Du ved, den sjette version, vi talte om før?

Jeg troede, at ES2016+ allerede var et supersæt af ES6! HVORFOR har vi nu brug for denne ting, der hedder Typescript?

-Åh, fordi det giver os mulighed for at bruge JavaScript som et maskinskrevet sprog og reducere runtime fejl. Det er 2016, du burde tilføje nogle typer til din JavaScript-kode.

Og det gør Typescript åbenbart.

-Flow også, selvom det kun tjekker for at skrive, mens Typescript er et supersæt af JavaScript, som skal kompileres.

Suk... og Flow er?

-Det er en statisk type checker lavet af nogle fyre på Facebook. De kodede det i OKaml, fordi funktionel programmering er fantastisk.

OKaml? Funktionel programmering?

-Det er, hvad de seje børn bruger i dag mand, du ved, 2016? Funktionel programmering? Høj ordens funktioner? Currying? Rene funktioner?

Jeg aner ikke, hvad du lige sagde.

- Det er der ingen, der gør i begyndelsen. Se, du skal bare vide, at funktionel programmering er bedre end OOP, og det er det, vi skal bruge i 2016.

Vent, jeg lærte OOP på college, jeg troede det var godt?

-Det samme var Java, før det blev købt af Oracle. Jeg mener, OOP var godt dengang, og det har stadig sine anvendelser i dag, men nu indser alle, at ændring af tilstande svarer til at sparke babyer, så nu flytter alle til uforanderlige objekter og funktionel programmering. Haskell-fyre havde kaldt det i årevis - og lad mig ikke komme i gang med Elm-fyrene - men heldigvis på nettet har vi nu biblioteker som Ramda, der giver os mulighed for at bruge funktionel programmering i almindelig JavaScript.

Dropper du bare navne for dets skyld? Hvad fanden er Ramnda?

-Ingen. Ramda. Ligesom Lambda. Ved du, David Chambers' bibliotek?

David hvem?

-David Chambers. Fed fyr. Spiller et gemytligt kupspil. En af bidragyderne til Ramda. Du bør også tjekke Erik Meijer, hvis du er seriøs med at lære funktionel programmering.

Og Erik Meijer er...?

- Også en funktionel programmeringsmand. Fantastisk fyr. Han har en masse præsentationer, hvor han kasserer Agile, mens han bruger denne mærkelige farvede skjorte. Du bør også tjekke nogle af tingene fra Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani-

Okay. Jeg vil stoppe dig der. Alt det er godt og fint, men jeg synes, at alt det er bare så kompliceret og unødvendigt for bare at hente data og vise dem. Jeg er ret sikker på, at jeg ikke behøver at kende disse mennesker eller lære alle de ting for at skabe en tabel med dynamiske data. Lad os vende tilbage til React. Hvordan kan jeg hente dataene fra serveren med React?

-Jamen, man henter faktisk ikke dataene med React, man viser blot dataene med React.

Åh, for fanden mig. Så hvad bruger du til at hente dataene?

-Du bruger Fetch til at hente dataene fra serveren.

Jeg er ked af det? Bruger du Fetch til at hente dataene? Den, der navngiver disse ting, har brug for en tesaurus.

- Jeg ved det ikke? Hent det er navnet på den oprindelige implementering til at udføre XMLHttpRequests mod en server.

Åh, altså AJAX.

-AJAX er kun brugen af XMLHttpRequests. Men sikkert. Fetch giver dig mulighed for at lave AJAX baseret på løfter, som du så kan løse for at undgå tilbagekaldshelvede.

Tilbagekaldshelvede?

- Ja. Hver gang du udfører en asynkron anmodning mod serveren, skal du vente på dens svar, som så får dig til at tilføje en funktion i en funktion, som kaldes tilbagekaldspyramiden fra helvede.

Åh, ok. Og løser denne løfteting det?

-Virkelig. Ved at manipulere dine tilbagekald gennem løfter, kan du skrive nemmere at forstå kode, håne og teste dem, samt udføre samtidige anmodninger på én gang og vente, indtil dem alle er indlæst.

Og det kan gøres med Fetch?

-Ja, men kun hvis din bruger bruger en stedsegrøn browser, ellers skal du inkludere en Fetch polyfill eller bruge Request, Bluebird eller Axios.

Hvor mange biblioteker skal jeg for guds skyld kende? Hvor mange er af dem?

-Det er JavaScript. Der skal være tusindvis af biblioteker, der alle gør det samme. Vi kender biblioteker, faktisk har vi de bedste biblioteker. Vores biblioteker er enorme, og nogle gange inkluderer vi billeder af Guy Fieri i dem.

Sagde du lige Guy Fieri? Lad os få det overstået. Hvad gør disse Bluebird, Request, Axios-biblioteker?

-De er biblioteker til at udføre XMLHttpRequests, der returnerer løfter.

Begyndte jQuerys AJAX-metode ikke også at returnere løfter?

-Vi bruger ikke ordet "J" i 2016 længere. Bare brug Fetch, og polyfill det, når det ikke er i en browser, eller brug Bluebird, Request eller Axios i stedet. Håndter derefter løftet med afvent inden for en asynkron funktion og bom, du har ordentlig kontrol flow.

Det er tredje gang, du nævner vente, men jeg aner ikke, hvad det er.

-Await giver dig mulighed for at blokere et asynkront opkald, hvilket giver dig mulighed for at have bedre kontrol over, hvornår dataene hentes og generelt øge kodelæsbarheden. Det er fantastisk, du skal bare sørge for at tilføje fase-3 forudindstillingen i Babel, eller bruge syntax-async-funktioner og transform-async-to-generator plugin.

Det her er sindssygt.

-Nej, sindssygt er det faktum, at du skal prækompilere Typescript-kode og derefter transpilere den med Babel for at bruge den.

Hvad? Er det ikke inkluderet i Typescript?

-Det gør den i den næste version, men fra og med version 1.7 er den kun målrettet mod ES6, så hvis du vil bruge afvent i browseren, skal du først kompilere din Typescript-kode målrettet ES6 og derefter Babel, der lorter op til målet ES5.

På dette tidspunkt ved jeg ikke, hvad jeg skal sige.

- Se, det er nemt. Kod alt i Typescript. Alle moduler, der bruger Fetch, kompilerer dem til at målrette ES6, transpiler dem med Babel på en fase-3 forudindstilling og indlæs dem med SystemJS. Hvis du ikke har Fetch, skal du polyfill det, eller bruge Bluebird, Request eller Axios, og håndtere alle dine løfter med afvent.

Vi har meget forskellige definitioner af let. Så med det ritual hentede jeg endelig dataene, og nu kan jeg vise dem med React ikke?

- Kommer din ansøgning til at håndtere nogen tilstandsændringer?

Årh, det tror jeg ikke. Jeg skal bare vise dataene.

- Gudskelov. Ellers skulle jeg forklare dig Flux, og implementeringer som Flummox, Alt, Fluxible. Selvom du skal være ærlig, skal du bruge Redux.

Jeg vil bare flyve over de navne. Igen skal jeg bare vise data.

-Åh, hvis du bare viser de data, du ikke havde brug for React til at begynde med. Du ville have haft det fint med en skabelonmotor.

Laver du mig? Synes du det er sjovt? Er det sådan du behandler dine kære?

-Jeg forklarede bare, hvad du kunne bruge.

Stop. Bare stop.

-Jeg mener, selvom det bare bruger skabelonmotor, ville jeg stadig bruge en Typescript + SystemJS + Babel combo, hvis jeg var dig.

Jeg skal vise data på en side, ikke udføre Sub Zero's oprindelige MK-dødsfald. Bare fortæl mig, hvilken skabelonmotor jeg skal bruge, så tager jeg den derfra.

-Der er en masse, hvilken er du bekendt med?

Uh, kan ikke huske navnet. Det var længe siden.

-jSkabeloner? jQote? REN?

Årh, ringer ikke en klokke. En anden?

- Gennemsigtighed? JSRender? MarkupJS? KnockoutJS? Den havde to-vejs binding.

En anden?

-PlatesJS? jQuery-tmpl? Styr? Nogle mennesker bruger det stadig.

Måske. Er der magen til den sidste?

- Overskæg, understregning? Jeg tror nu, at selv lodash har en for at være ærlig, men det er en slags 2014.

Arr.. måske var det nyere.

-Jade? DustJS?

Ingen.

-DotJS? EJS?

Ingen.

-Nunjucks? ECT?

Ingen.

-Mah, ingen kan lide Coffeescript-syntaks alligevel. Jade?

Nej, du har allerede sagt Jade.

-Jeg mente Pug. Jeg mente Jade. Jeg mener, Jade er nu Pug.

Suk. Nej. Kan ikke huske det. Hvilken en ville du bruge?

- Sandsynligvis kun ES6 native skabelonstrenge.

Lad mig gætte. Og det kræver ES6.

-Korrekt.

Hvilket, afhængigt af hvilken browser jeg bruger, har brug for Babel.

-Korrekt.

Som, hvis jeg vil inkludere uden at tilføje hele kernebiblioteket, skal jeg indlæse det som et modul fra npm.

-Korrekt.

Hvilket kræver Browserify eller Wepback, eller højst sandsynligt den anden ting kaldet SystemJS.

-Korrekt.

Som, medmindre det er Webpack, ideelt set bør administreres af en opgaveløber.

-Korrekt.

Men da jeg skulle bruge funktionel programmering og maskinskrevne sprog, skal jeg først prækompilere Typescript eller tilføje denne Flow-ting.

-Korrekt.

Og så send det til Babel, hvis jeg vil bruge afvente.

-Korrekt.

Så jeg kan bruge Fetch, løfter og styre flow og al den magi.

-Bare glem ikke at polyfill Fetch, hvis det ikke understøttes, Safari kan stadig ikke håndtere det.

Ved du hvad. Jeg tror, vi er færdige her. Faktisk tror jeg, jeg er færdig. Jeg er færdig med nettet, jeg er helt færdig med JavaScript.

-Det er fint, om nogle år skal vi alle sammen kode i Elm eller WebAssembly.

Jeg vil bare flytte tilbage til backend. Jeg kan bare ikke håndtere disse mange ændringer og versioner og udgaver og oversættere og transpilere. JavaScript-fællesskabet er sindssygt, hvis det tror, at nogen kan følge med dette.

-Jeg hører dig. Så skal du prøve Python-fællesskabet.

Hvorfor?

-Har du nogensinde hørt om Python 3?

Opdatering: Tak fordi du pegede på tastefejl og fejl, jeg opdaterer artiklen som nævnt. Diskussion i HackerNews og Reddit .