Hoe het voelt om JavaScript te leren in 2016

Er zijn geen JavaScript- frameworks gemaakt tijdens het schrijven van dit artikel.

Het volgende is geïnspireerd door het artikel "It's the future" van Circle CI. U kunt het origineel hier lezen . Dit stuk is slechts een mening en zoals elk JavaScript-framework moet het niet te serieus worden genomen.

Hey, ik heb dit nieuwe webproject, maar om eerlijk te zijn heb ik de afgelopen jaren niet veel web gecodeerd en ik heb gehoord dat het landschap een beetje is veranderd. Jij bent de meest up-to-date webdev hier, toch?

-De echte term is Front End engineer, maar ja, ik ben de juiste persoon. Ik doe web in 2016. Visualisaties, muziekspelers, vliegende drones die voetbal spelen, noem maar op. Ik kom net terug van JsConf en ReactConf, dus ik ken de nieuwste technologieën om webapps te maken.

Cool. Ik moet een pagina maken die de laatste activiteit van de gebruikers weergeeft, dus ik hoef alleen de gegevens van het REST-eindpunt te halen en deze in een soort filterbare tabel weer te geven, en deze bij te werken als er iets verandert op de server. Ik dacht eraan om misschien jQuery te gebruiken om de gegevens op te halen en weer te geven?

-Oh mijn god nee, niemand gebruikt jQuery meer. Je zou React moeten leren, het is 2016.

Oh, oké. Wat is React?

-Het is een supercoole bibliotheek die is gemaakt door een paar jongens van Facebook. Het geeft je applicatie echt meer controle en prestaties, omdat je er heel eenvoudig weergavewijzigingen mee kunt verwerken.

Dat klinkt goed. Kan ik React gebruiken om data van de server weer te geven?

-Ja, maar eerst moet je React en React DOM als bibliotheek aan je webpagina toevoegen.

Wacht eens, waarom twee bibliotheken?

-De eerste is de daadwerkelijke bibliotheek en de tweede is voor het manipuleren van de DOM, die je nu in JSX kunt beschrijven.

JSX? Wat is JSX?

-JSX is gewoon een JavaScript-syntaxisextensie die er ongeveer hetzelfde uitziet als XML. Het is een andere manier om de DOM te beschrijven, zie het als een betere HTML.

Wat is er mis met HTML?

-Het is 2016. Niemand codeert HTML meer rechtstreeks.

Klopt. Hoe dan ook, als ik deze twee bibliotheken toevoeg, kan ik dan React gebruiken?

-Niet helemaal. Je moet Babel toevoegen, en dan kun je React gebruiken.

Nog een bibliotheek? Wat is Babel?

-Oh, Babel is een transpiler waarmee je specifieke versies van JavaScript kunt targeten, terwijl je codeert in elke versie van JavaScript. Je hoeft Babel niet te gebruiken om ReactJS te gebruiken, maar als je dat niet doet, zit je vast aan ES5, en laten we eerlijk zijn, het is 2016, je zou moeten coderen in ES2016+, net als de rest van de coole kids.

ES5? ES2016+? Ik raak hier de weg kwijt. Wat is ES5 en ES2016+?

-ES5 staat voor ECMAScript 5. Dit is de editie waar de meeste mensen op mikken, omdat deze tegenwoordig door de meeste browsers wordt geïmplementeerd.

ECMAScript?

-Ja, weet je, de scripting standaard JavaScript was gebaseerd op in 1999 na de eerste release in 1995, toen JavaScript nog Livescript heette en alleen in de Netscape Navigator draaide. Dat was toen erg rommelig, maar gelukkig zijn de zaken nu heel duidelijk en hebben we, zeg maar, 7 edities van deze implementatie.

7 edities. Echt waar. En ES5 en ES2016+ zijn?

-Respectievelijk de vijfde en zevende editie.

Wacht, wat is er met de zesde gebeurd?

-Je bedoelt ES6? Ja, ik bedoel, elke editie is een superset van de vorige, dus als je ES2016+ gebruikt, gebruik je alle functies van de vorige versies.

Klopt. En waarom zou je dan ES2016+ gebruiken in plaats van ES6?

-Nou, je KAN ES6 gebruiken, maar om coole features als async en await te gebruiken, moet je ES2016+ gebruiken. Anders zit je vast aan ES6 generators met coroutines om asynchrone calls te blokkeren voor een goede control flow.

Ik heb geen idee wat je net zei, en al die namen zijn verwarrend. Kijk, ik laad gewoon een hoop data van een server, ik kon vroeger gewoon jQuery opnemen van een CDN en de data ophalen met AJAX calls, waarom kan ik dat niet gewoon doen?

-Het is 2016 man, niemand gebruikt jQuery meer, het eindigt in een hoop spaghetticode. Dat weet iedereen.

Klopt. Mijn alternatief is dus om drie bibliotheken te laden om data op te halen en een HTML-tabel weer te geven.

-Nou, je neemt die drie bibliotheken op, maar bundelt ze met een modulebeheerder om slechts één bestand te laden.

Ik snap het. En wat is een modulemanager?

-De definitie is afhankelijk van de omgeving, maar op het web bedoelen we meestal alles wat AMD- of CommonJS-modules ondersteunt.

Klopt. En AMD en CommonJS zijn…?

-Definities. Er zijn manieren om te beschrijven hoe meerdere JavaScript-bibliotheken en -klassen met elkaar moeten interacteren. U weet wel, exports en requires? U kunt meerdere JavaScript-bestanden schrijven die de AMD of CommonJS API definiëren en u kunt iets als Browserify gebruiken om ze te bundelen.

Oké, dat klinkt logisch... denk ik. Wat is Browserify?

-Het is een tool waarmee u CommonJS-beschreven afhankelijkheden kunt bundelen naar bestanden die in de browser kunnen worden uitgevoerd. Het is gemaakt omdat de meeste mensen die afhankelijkheden publiceren in het npm-register.

npm-register?

-Het is een hele grote openbare opslagplaats waar slimme mensen code en afhankelijkheden als modules plaatsen.

Zoals een CDN?

-Niet echt. Het is meer een gecentraliseerde database waar iedereen bibliotheken kan publiceren en downloaden, zodat je ze lokaal kunt gebruiken voor ontwikkeling en ze vervolgens kunt uploaden naar een CDN als je dat wilt.

Oh, net als Bower!

-Ja, maar het is inmiddels 2016 en niemand gebruikt Bower meer.

Oh, ik snap het... dus ik moet de bibliotheken van npm downloaden?

-Ja. Dus als u bijvoorbeeld React wilt gebruiken, downloadt u de React-module en importeert u deze in uw code. U kunt dat voor bijna elke populaire JavaScript-bibliotheek doen.

Oh, net als Angular!

-Angular is zó 2015. Maar ja. Angular zou er zijn, naast VueJS of RxJS en andere coole 2016-bibliotheken. Wil je daar meer over weten?

Laten we bij React blijven, ik leer nu al te veel dingen. Dus als ik React moet gebruiken, haal ik het dan op van deze npm en gebruik ik dan dit Browserify-ding?

-Ja.

Het lijkt me te ingewikkeld om zomaar een aantal afhankelijkheden te pakken en aan elkaar te koppelen.

-Dat is het, daarom gebruik je een task manager zoals Grunt of Gulp of Broccoli om het draaien van Browserify te automatiseren. Je kunt zelfs Mimosa gebruiken.

Grunt? Slok? Broccoli? Mimosa? Waar hebben we het nu over?

-Taakmanagers. Maar die zijn niet meer cool. We gebruikten ze in 2015, toen gebruikten we Makefiles, maar nu verpakken we alles met Webpack.

Makefiles? Ik dacht dat dat vooral gebruikt werd in C of C++ projecten.

-Ja, maar blijkbaar houden we er op het web van om dingen ingewikkeld te maken en dan terug te gaan naar de basis. Dat doen we ongeveer elk jaar, wacht maar, we gaan over een jaar of twee assembly doen op het web.

Zucht. Je had het over iets dat Webpack heet?

-Het is een andere modulemanager voor de browser en tegelijkertijd een soort taskrunner. Het is een betere versie van Browserify.

Oh, oké. Waarom is het beter?

-Nou, misschien niet beter, het is gewoon meer eigenzinnig over hoe je afhankelijkheden moeten worden gekoppeld. Webpack stelt je in staat om verschillende modulemanagers te gebruiken, en niet alleen CommonJS-managers, dus bijvoorbeeld native ES6-ondersteunde modules.

Ik ben enorm in de war door dat hele CommonJS/ES6 gedoe.

-Dat is bij iedereen het geval, maar met SystemJS hoeft dat geen probleem meer te zijn.

Jezus Christus, nog een zelfstandig naamwoord-js. Oké, en wat is dit SystemJS?

- Nou, in tegenstelling tot Browserify en Webpack 1.x is SystemJS een dynamische modulelader waarmee u meerdere modules in meerdere bestanden kunt samenvoegen in plaats van ze in één groot bestand te bundelen.

Wacht, ik dacht dat we onze bibliotheken in één groot bestand wilden bouwen en dat wilden laden!

-Ja, maar omdat HTTP/2 er nu aankomt, zijn meerdere HTTP-verzoeken eigenlijk beter.

Wacht, kunnen we niet gewoon de drie originele bibliotheken voor React toevoegen?

-Niet echt. Ik bedoel, je zou ze kunnen toevoegen als externe scripts van een CDN, maar dan zou je nog steeds Babel moeten toevoegen.

Zucht. En dat is toch erg?

-Ja, je zou de hele babel-core opnemen, en het zou niet efficiënt zijn voor productie. In productie moet je een reeks pre-taken uitvoeren om je project gereed te maken, waardoor het ritueel om Satan op te roepen eruitziet als een recept voor gekookte eieren. Je moet assets minimaliseren, lelijk maken, css boven de vouw inline zetten, scripts uitstellen, en-

Ik snap het, ik snap het. Dus als je de bibliotheken niet direct in een CDN zou opnemen, hoe zou je dat dan doen?

-Ik zou het transpileren van Typescript met behulp van een Webpack + SystemJS + Babel-combinatie.

Typescript? Ik dacht dat we in JavaScript codeerden!

-Typescript IS JavaScript, of beter gezegd, een superset van JavaScript, specifieker JavaScript op versie ES6. Weet je nog, die zesde versie waar we het eerder over hadden?

Ik dacht dat ES2016+ al een superset was van ES6! WAAROM hebben we nu dit ding genaamd Typescript nodig?

-Oh, omdat het ons in staat stelt om JavaScript te gebruiken als een getypte taal, en runtime-fouten te verminderen. Het is 2016, je zou wat typen aan je JavaScript-code moeten toevoegen.

En Typescript doet dat uiteraard.

-Flow ook, hoewel het alleen op typen controleert, terwijl Typescript een superset van JavaScript is die gecompileerd moet worden.

Zucht… en Flow is?

-Het is een statische type checker gemaakt door een paar gasten bij Facebook. Ze hebben het gecodeerd in OCaml, omdat functioneel programmeren geweldig is.

OCaml? Functioneel programmeren?

-Dat is wat de coole kids tegenwoordig gebruiken man, weet je, 2016? Functioneel programmeren? Hogere orde functies? Currying? Zuivere functies?

Ik heb geen idee wat je net zei.

-Niemand doet dat in het begin. Kijk, je moet gewoon weten dat functioneel programmeren beter is dan OOP en dat is wat we in 2016 zouden moeten gebruiken.

Wacht, ik heb OOP op de universiteit geleerd. Ik dacht dat dat goed was?

-Dat was Java ook voordat het door Oracle werd gekocht. Ik bedoel, OOP was vroeger goed en het heeft nog steeds zijn nut, maar nu realiseert iedereen zich dat het wijzigen van toestanden gelijk staat aan het schoppen van baby's, dus nu stapt iedereen over op onveranderlijke objecten en functioneel programmeren. Haskell-jongens noemden het al jaren, -en laat me niet beginnen over de Elm-jongens- maar gelukkig hebben we nu op het web bibliotheken als Ramda waarmee we functioneel programmeren in gewoon JavaScript kunnen gebruiken.

Noem je nou gewoon namen voor de lol? Wat is Ramnda in hemelsnaam?

-Nee. Ramda. Zoals Lambda. Weet je wel, die bibliotheek van David Chambers?

David wie?

-David Chambers. Coole gast. Speelt een geweldig Coup-spel. Een van de bijdragers aan Ramda. Je zou ook Erik Meijer moeten checken als je serieus bent over het leren van functioneel programmeren.

En Erik Meijer is…?

- Ook een functionele programmeur. Geweldige gast. Hij heeft een hoop presentaties waarin hij Agile afkraakt terwijl hij dit vreemd gekleurde shirt draagt. Je zou ook wat van de spullen van Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani moeten bekijken-

Oké. Ik ga je hier stoppen. Dat is allemaal goed en aardig, maar ik denk dat dat allemaal zo ingewikkeld en onnodig is om alleen maar data op te halen en weer te geven. Ik weet vrijwel zeker dat ik deze mensen niet hoef te kennen of al die dingen hoef te leren om een tabel met dynamische data te maken. Laten we teruggaan naar React. Hoe kan ik de data van de server halen met React?

-Nou, eigenlijk haal je de gegevens niet op met React, je geeft ze alleen weer met React.

Oh, verdomme. Wat gebruik je dan om de data op te halen?

- U gebruikt Fetch om de gegevens van de server op te halen.

Sorry? Je gebruikt Fetch om de data op te halen? Degene die die dingen een naam geeft, heeft een thesaurus nodig.

-Dat weet ik toch? Fetch is de naam van de native implementatie voor het uitvoeren van XMLHttpRequests tegen een server.

O ja, AJAX dus.

-AJAX is gewoon het gebruik van XMLHttpRequests. Maar goed. Fetch laat je AJAX doen op basis van promises, die je dan kunt oplossen om de callback-hel te vermijden.

Terugbelhel?

-Ja. Elke keer dat je een asynchrone aanvraag uitvoert tegen de server, moet je wachten op de reactie, wat je vervolgens dwingt om een functie binnen een functie toe te voegen, wat de callback-piramide uit de hel wordt genoemd.

Oh, oké. En dit belofte-gedoe lost het op?

- Inderdaad. Door uw callbacks te manipuleren via promises, kunt u gemakkelijker te begrijpen code schrijven, ze mocken en testen, en gelijktijdige verzoeken tegelijk uitvoeren en wachten tot ze allemaal zijn geladen.

En dat kan met Fetch?

-Ja, maar alleen als uw gebruiker een 'evergreen' browser gebruikt. Anders moet u een Fetch polyfill opnemen of Request, Bluebird of Axios gebruiken.

Hoeveel bibliotheken moet ik in godsnaam kennen? Hoeveel zijn het er?

-Het is JavaScript. Er moeten duizenden bibliotheken zijn die allemaal hetzelfde doen. We kennen bibliotheken, sterker nog, we hebben de beste bibliotheken. Onze bibliotheken zijn enorm, en soms voegen we er foto's van Guy Fieri aan toe.

Zei je net Guy Fieri? Laten we dit maar snel afhandelen. Wat doen deze Bluebird, Request, Axios bibliotheken?

-Het zijn bibliotheken om XMLHttpRequests uit te voeren die promises retourneren.

Retourneerde de AJAX-methode van jQuery niet ook promises?

-We gebruiken het woord "J" niet meer in 2016. Gebruik gewoon Fetch en polyfill het wanneer het niet in een browser staat of gebruik in plaats daarvan Bluebird, Request of Axios. Beheer vervolgens de promise met await binnen een async-functie en boem, je hebt een goede controleflow.

Het is de derde keer dat je het woord 'wachten' noemt, maar ik heb geen idee wat het is.

-Await laat je een asynchrone call blokkeren, waardoor je meer controle hebt over wanneer de data wordt opgehaald en de leesbaarheid van de code toeneemt. Het is geweldig, je moet er alleen voor zorgen dat je de stage-3 preset in Babel toevoegt, of syntax-async-functions en transform-async-to-generator plugin gebruikt.

Dit is waanzin.

-Nee, het is waanzin dat je Typescript-code moet precompileren en deze vervolgens moet transpileren met Babel om await te kunnen gebruiken.

Wat? Het staat niet in Typescript?

-Dat gebeurt wel in de volgende versie, maar vanaf versie 1.7 is het alleen nog maar gericht op ES6. Als je await in de browser wilt gebruiken, moet je dus eerst je Typescript-code compileren die gericht is op ES6. Vervolgens moet je die code via Babel upzetten zodat deze gericht is op ES5.

Op dit punt weet ik niet wat ik moet zeggen.

- Kijk, het is makkelijk. Codeer alles in Typescript. Alle modules die Fetch gebruiken compileren ze om ES6 te targeten, transpileren ze met Babel op een stage-3 preset en laden ze met SystemJS. Als je Fetch niet hebt, polyfill het dan, of gebruik Bluebird, Request of Axios, en handel al je promises af met await.

We hebben heel verschillende definities van makkelijk. Dus met dat ritueel heb ik eindelijk de data opgehaald en nu kan ik het weergeven met React toch?

- Zal uw applicatie statuswijzigingen verwerken?

Eh, ik denk het niet. Ik moet gewoon de data weergeven.

-Oh, godzijdank. Anders had ik je Flux moeten uitleggen, en implementaties als Flummox, Alt, Fluxible. Hoewel je eerlijk gezegd Redux zou moeten gebruiken.

Ik ga even over die namen heen vliegen. Nogmaals, ik hoef alleen maar data weer te geven.

-Oh, als je alleen de data weergeeft, had je React niet nodig. Je zou prima af zijn geweest met een template engine.

Maak je een grapje? Vind je dit grappig? Is dit hoe je met je geliefden omgaat?

-Ik legde alleen uit wat je kunt gebruiken.

Stop. Stop gewoon.

-Ik bedoel, zelfs als ik alleen de template engine zou gebruiken, zou ik nog steeds een combinatie van Typescript + SystemJS + Babel gebruiken als ik jou was.

Ik moet data op een pagina weergeven, niet Sub Zero's originele MK fatality uitvoeren. Vertel me gewoon welke template engine ik moet gebruiken en ik neem het van daaruit over.

-Er zijn er veel. Welke ken je?

Ugh, ik kan de naam niet meer herinneren. Het is lang geleden.

-jSjablonen? jQote? PUUR?

Eh, dat zegt me niks. Nog eentje?

-Transparantie? JSRender? MarkupJS? KnockoutJS? Die had tweerichtingsbinding.

Nog eentje?

-PlatesJS? jQuery-tmpl? Stuur? Sommige mensen gebruiken het nog steeds.

Misschien. Zijn er soortgelijke als de laatste?

-Mustache, underscore? Ik denk dat zelfs Lodash er nu een heeft, eerlijk gezegd, maar die zijn een beetje 2014.

Eh... misschien was het nieuwer.

-Jade? DustJS?

Nee.

-DotJS?

Nee.

-Nunjucks? ECT?

Nee.

-Mah, niemand houdt toch van de syntaxis van Coffeescript. Jade?

Nee, je zei al Jade.

-Ik bedoelde Pug. Ik bedoelde Jade. Ik bedoel, Jade is nu Pug.

Zucht. Nee. Kan me niet herinneren. Welke zou jij gebruiken?

-Waarschijnlijk gewoon ES6-sjabloonstrings.

Laat me raden. En daarvoor is ES6 nodig.

-Juist.

Afhankelijk van welke browser ik gebruik, heb ik Babel nodig.

-Juist.

Als ik deze wil opnemen zonder de volledige kernbibliotheek toe te voegen, moet ik deze als een module vanuit npm laden.

-Juist.

Hiervoor heb je Browserify, Wepback of waarschijnlijk ook SystemJS nodig.

-Juist.

Tenzij het Webpack is, zou dit idealiter beheerd moeten worden door een taskrunner.

-Juist.

Maar omdat ik functioneel programmeren en getypeerde talen zou moeten gebruiken, moet ik eerst Typescript pre-compileren of dit Flow-dingetje toevoegen.

-Juist.

En stuur dat dan naar Babel als ik await wil gebruiken.

-Juist.

Dan kan ik Fetch, promises, control flow en al die magie gebruiken.

- Vergeet niet om polyfill Fetch te gebruiken als dit niet wordt ondersteund, Safari kan dit nog steeds niet verwerken.

Weet je wat? Ik denk dat we hier klaar zijn. Eigenlijk denk ik dat ik klaar ben. Ik ben klaar met het web, ik ben helemaal klaar met JavaScript.

-Dat is prima, over een paar jaar coderen we allemaal in Elm of WebAssembly.

Ik ga gewoon terug naar de backend. Ik kan deze vele veranderingen en versies en edities en compilers en transpilers gewoon niet aan. De JavaScript-community is gek als ze denken dat iemand dit kan bijhouden.

-Ik hoor je. Dan zou je de Python community eens moeten proberen.

Waarom?

-Heb je ooit gehoord van Python 3?

Update: Bedankt voor het aanwijzen van typfouten en fouten, ik zal het artikel updaten zoals aangegeven. Discussie in HackerNews en Reddit .