Du behøver muligvis ikke transpilere din JavaScript

Populære guider som YouMightNotNeedJQuery.com og du behøver ikke Lodash / Underscore har udfordret almindelig branchepraksis.

Dette indlæg er ikke så vildt som for eksempel YouMightNotNeedJS.com, men det uddyber transpilation og forklarer, hvorfor det måske ikke er så nødvendigt i den nærmeste fremtid.

StatCounter indsamler data om 15+ milliarder sidevisninger hver måned fra 2,5 millioner websteder over hele kloden. Fra maj 2017 er dette status quo:

Det, der gør dette diagram interessant, er at de 3 bedste browsere (Chrome, Safari og FireFox) er stedsegrønne,hvilket betyder, at 74% af brugerne automatisk får den nyeste version af deres browser.

Lad os se, om denne antagelse er korrekt.

Her er de bedste browserversioner på markedet:

Chrome 58 blev frigivet for mindre end en måned siden, og dens desktopversion har 12,77% af den globale browsermarkedsandel. Chrome 57 blev frigivet kun 42 dage før det, og dens desktopversion besidder 9,96% af det globale browsermarked. Desværre skelner StatCounter ikke mellem kromversioner på mobile platforme, men forudsætter det samme forhold som desktop, som vi ender med:

Hvad betyder det for min kode?

Ifølge ES Compatibility Table har den nyeste version af alle større browsere en meget god understøttelse af ES6-funktioner:

Med andre ord, hvis du transponderer din JavaScript til ES5, gør du din kode unødigt stor og langsom til at understøtte et mindretal af de brugere, der sandsynligvis vil opgradere deres system, når du formår at konfigurere din Webpack og Babel! ?

Hvorfor ville du stadig transponere?

Det kan være, at du stadig ønsker at transponere din kode, men forhåbentlig efter at have vejet ulemper og fordele eller mulige alternativer:

  • Du bruger React JSX (hvilket er ret populært i øjeblikket, så jeg antager, at mange udviklere passer ind i denne kategori). JSX er i sin kerne en transformation af XHTML til JS-kode og har ikke brug for en fuldspiller som Babel. Desuden, hvis alt hvad du har brug for er VirtualDom, skal du bruge det i stedet.
  • Du vil prøve de nyeste funktioner på sproget. Medmindre du er en del af TC39 eller har et brændende ønske om at injicere ustabile sprogfunktioner i din produktionskode, har du sandsynligvis det godt med ES6. I dag har vi et anstændigt sprog, hvor størstedelen af ​​browserne er, og behovet for at transpilere forsvinder.
  • Du bruger TypeScript og forhåbentlig vejede ulemper og fordele. TypeScript-kompilator, når man målretter mod en moderne version af ES6, fjerner for det meste typeoplysningerne i stedet for at transformere syntaksen.
  • Du vil reducere kodestørrelsen ved hjælp af trærystning (her gør du det i webpack og rollup). Du vil tilsløre din kode eller reducere dens størrelse ved minifikation. Du vil ekskludere en del af koden betinget. Dette kræver analyse af statisk kode. Du kan bruge en smart bundler til størrelsesfølsomme produktionstjenester som mobile enheder, men vi vil se mere omhyggelige omkostningsvurderinger, når vi opretter sådanne alternative implementeringer. Disse former for statisk kodeanalyse vil fortsat være nyttige som "avancerede optimeringsteknikker" til produktionskode.Du behøver ikke at minificere dine filer. UglifyJS kan ikke minify ES6 i øjeblikket (selvom der findes en harmoney-gren), men Babili kan håndtere det. Kompressionsalgoritmerne gør et ret anstændigt job (ikke når filerne er for små), og medmindre du sender et operativsystem i hver sideindlæsning, skal det klare sig uden komprimering. Disse dage tager billeder og multimedieindhold meget mere båndbredde end koden.
  • Du vil have elefanten i rummet:

NPM er den største pakkehåndtering på planeten. De fleste ikke-trivielle webapplikationer bruger noget kode fra NPM, og det indebærer at bruge en modulbundler. Det vil snart ændre sig! Chrome understøtter allerede ES6-moduler på Canary (Chrome 60 sender officielt denne funktion i august), og Safari er også tæt på at sende det, mens Firefox og Edge arbejder på det.

Udover HTTP / 2 tillader det frivilligt at skubbe ressourcer til browseren. Det betyder, at hvis a.js importerer b.js og c.js , kan serveren skubbe b.js og c.js hver gang a.js hentes, hvilket minimerer tiden mellem anmodninger. Dette er selvfølgelig en forenklet visning, fordi browseren i praksis muligvis allerede har b.js og c.js i sin cache. HTTP / 2 understøttes i de fleste browsere.

Fremtiden uden Transpilation

I betragtning af ovenstående statistik betyder det, at 2018 vil være det år, hvor størstedelen af ​​webapps kan slippe af med modulbundlerne eller transpilerne.

Transpilation er en løsning. Vi har muligvis gjort det for længe, ​​at vi blev vant til det, men tænk over det. Vi "sammensætter" et "fortolket" sprog til et "fortolket" sprog! Udover:

  • Konfiguration af Webpack / Browserify er i mange tilfælde en unødvendig skat
  • Fejlfinding ved hjælp af sourcemaps er altid sværere end debugging af det faktiske script, der køres (nogen havde det sjovt med at prøve at debugge thiseller variabler, når sourcemaps ikke fungerer korrekt?)
  • Det dræber DX, når du skal vente et par sekunder (nogle gange et halvt minut) efter hver redigering for at se den nyeste kode. Hot Module Reloading (HMR) er et svar på det, men det er ikke altid glat og hurtigt at konfigurere. Uden transpilation er alt hvad du skal gøre, at opdatere siden, og på mindre end et sekund er din seneste side der!

I august, når ES6-moduler sendes, bruger nogle typer applikationer slet ikke transpilation:

  • Chrome-udvidelser
  • Elektron desktop applikationer
  • B2B webapps, der er lavet til at blive drevet af forretningsbrugere, der allerede har gode gear leveret af virksomheden

Når transpilering hører fortiden til, vil biblioteker med Hyperscript-syntaks bringe idéerne fra React til POJS (Almindelig gammel JavaScript, der ikke transpileres og let kan debugges på konsollen).

Transpiler ikke, men kompilér rigtigt!

WASM er det nye barn i byen, og det er det officielle kompileringsmål, der lover hurtigere eksekveringshastighed og mindre kodestørrelse. I øjeblikket understøtter Chrome og Firefox WASM, men der er god enighed blandt de store browserudbydere om, at WASM bliver fremtidens almindelige kørselstid. Hvis du har Chrome, kan du prøve det.

Hvis du er den slags udvikler, der klager efter noget nyt, skal du kigge på Rust. Det kompileres til WASM, men er ikke begrænset til internettet. Folk bruger det faktisk til at skrive operativsystem eller browsermotor. Udover gammel tid godkender C / C ++ udviklere og kan lide det, og det har et meget imødekommende samfund.

Et par noter

  • Ifølge den tidligere Mozilla CTO vandt Chrome, og det er usandsynligt, at der vil være endnu en browser-krig. Det interessante er, at Chrome vandt det med meritokrati . Det er open source, og Google har klart defineret, hvilke oplysninger de indsamler fra brugerne. Chrome vinder selv de forretningsbrugere, der traditionelt bruger Windows. Ikke desto mindre, mens slutbrugerne vælger Chrome på grund af dets hastighed, sikkerhed og enkelhed, elsker programmører dets udviklerværktøjer. Google har en aktiv rolle i TC39, der driver fremtiden for JavaScript og er generelt den stærkeste tilhænger af webplatformen, selvom den måske konkurrerer med sit eget mobile OS. Ikke kun det, men Google hjælper også sine konkurrenter. Google har været en af ​​de største økonomiske tilhængere af Mozilla, og dets gengivelsesmotor bruges af Opera.
  • Microsoft droppede officielt support til IE for omkring 17 måneder siden. IE 11 vil fortsat modtage sikkerhedsopdateringer indtil 2025, men det er op til dig at beslutte at bruge betydelige ressourcer på at understøtte en browser, som kun 3,24% af markedet bruger. Husk også på, at Edge er standardbrowseren i Windows 10. Hvis nogen ikke vil opgradere deres Windows til den nyeste version, giver det nylige WannaCrypt-angreb dem sandsynligvis en grund til at genoverveje! Jeg er personligt interesseret i enhver markedsundersøgelse af indtægterne fra netop dette kundesegment.
  • Apple satte et sæt urimelige begrænsninger for at holde de andre browserudbydere ude af deres iOS-platform. Så for eksempel er Chrome på iOS teknisk begrænset til dele af Safari-motoren! Safari plejede at være den nye IE, indtil tilbage i 2016 gjorde de et godt stykke arbejde og blev browseren med den bedste ES6-support:

Samlet set er den globale andel af iOS / Safari mindre end Android / Chrome. Det varierer efter land, for eksempel i rigere lande har iOS lidt højere penetration, mens Android i den udviklende verden er den absolutte vinder, men her er statistikken globalt:

Opfordring til handling!

Hvis du er gammel nok, kan du sandsynligvis huske de irriterende dage, hvor nogle websteder tvang (eller høfligt foreslået) deres valgte browser (for det meste IE):

Vi vil ikke gøre det! Uanset hvor begejstret vi er over Chrome, vil vi ikke ignorere 46% af webtrafikken, der ikke gengives af Chrome.

Bare fordi vi snart har understøttelse af ES6-moduler i browsere, betyder det ikke, at vi kan slippe af med en byggeproces og en ordentlig "bundle-strategi". - Stefan Judis

Vi har altid folk, der sidder fast med en gammel browser i deres TV-firmware eller bilinfotainment-system. Vi har altid den stædige bedstefar, der ikke ser behovet for at investere i at opgradere sin maskine kun for at lade den være en arv. Børn vil fortsætte med at bruge deres forældres gamle iPhone eller tablet, og 1 bærbar computer pr. Barn får ikke noget processorkraft om natten. Vi ønsker ikke at låse nogen ude.

Dette er dog ikke et nyt problem. På trods af at ES6 er en af ​​de største ændringer på nettet, kan yndefuld nedbrydning stadig give noget brug for mindretallet, samtidig med at udviklingsomkostningerne holdes under kontrol for flertallet.

I et fremtidigt indlæg vil jeg diskutere den praktiske side af, hvordan man sender moderne kode, mens jeg har en backupplan for yndefuld nedbrydning. Du kan følge mig på Twitter eller Medium for at holde dig opdateret.

BONUS: Se på JS Codeshift. Det er en CLI til konvertering af gammel javascript-kode til ny javascript-kode, der opdaterer selv gamle javascript-biblioteksopkald til deres seneste API. Det forsøger at bevare så meget som den originale styling som muligt. Workflow: Efter at have foretaget dine ændringer til versionskontrol, skal du køre dette og foretage en grundig sammenligning og køre de automatiserede og manuelle tests. Færdig!

Opdatering 1 (2017–09–8): Chrome 61 landede for et par dage siden med fuld understøttelse af ES6-modulet. Det har 54% af det globale browsermarked. Safari (14% af det globale marked) har understøttet ES6-moduler i et stykke tid.

Opdatering 2 (2017–09–10): du kan stadig understøtte browsere, der ikke understøtter ES6-moduler takket være dette trick pt nomodule src = ”compiled.js”> < ; / scri pt>. Nomodule-attributten fortæller browsere med ES6-modulstøtte ikke at indlæse scriptet. På Safari er der nogle advarsler, som du kan læse på siden, der taler om tricket. Læs spec.

Opdatering 3 (2017–09–12): ES6-moduler understøtter lande i browsere: er det tid til at genoverveje bundling?

Update 4 (2017/09/12): modul er Udskyd rød som standard. Hvis du vil omgå det, skal du tilføje en async- attribut til script-tagget for at forhindre SPOF (Single Point Of Failure).

Opdatering 5 (2017–09–13): Node LTS 8.5 understøtter ES6-moduler (kaldet ESM) bag et flag, når filen har en * .msj- udvidelse. Her er en god introduktion til, hvordan de bruges.

Opdatering 6 (2017-09-22): her er nogle gode praktiske råd til understøttelse af både nye og gamle browsere. Båndbreddebesparelserne for at undgå transpilation er store!

Opdatering 7 (2018–01–15): Lebab (bagsiden af ​​Babel) har en CLI til modernisering af gammeldags Javascript. Dette svarer lidt til Facebooks CodeShift, fordi de begge moderniserer den gamle kode.

Den mest udbredte fejl i computerhistorien åbnede en stor mulighed for os! Læs Hvorfor skal vi overbevise vores brugere om at opdatere deres browsere?