Jeg fik endelig mening med værktøj til frontendebygning. Du kan også.

Frontend build-værktøjer kan være forvirrende selv for erfarne udviklere som mig. Løsningen er at forstå, hvordan de arbejder - og arbejder sammen - på et konceptuelt niveau.

Denne artikel præsenterer min meningsfulde tilgang til at få mening i frontend build-værktøjer. I stedet for at dykke ned i kode vil jeg lede dig gennem min mentale model for, hvordan disse værktøjer fungerer, og hvad de udfører.

Lad dig ikke skræmme af den nyeste teknologi

Node, NPM, Grunt, Gulp, Bower, Webpack, Browserify, Yeoman, Brunch ... der er så mange front-end-værktøjer derude, at det kan synes umuligt at følge med.

Nøglen er ikke skræmmende. Alle disse projekter er designet til at gøre dit liv lettere.

For at forstå hvad, hvorfor og hvordan disse værktøjer skal du bare forstå et par begreber.

Koncept nr. 1 - Kernedikotomien i buildværktøjer er "installation vs. gør"

Byg værktøjer gør to ting:

  1. Installer ting
  2. Gør ting

Det første spørgsmål, du skal stille dig selv, når du konfronterer et nyt byggeværktøj, er: "Er dette værktøj beregnet til at installere ting til mig eller gøre ting for mig?"

"Installation" -værktøjer som npm, Bower og Yeoman kan installere stort set alt. De kan installere front-end-biblioteker som Angular.js eller React.js. De kan installere servere til dit dev-miljø. De kan installere testbiblioteker. De hjælper dig endda med at installere andre frontend build-værktøjer.

Kort sagt, de installerer mest de koderelaterede ting, du kan tænke på.

De "gør" -værktøjer som Grunt, Webpack, Require.js, Brunch og Gulp er meget mere komplicerede. Målet med "gør" -værktøjerne er at automatisere alle de alvorlige og fejlbehæftede opgaver i webudvikling. De ting, de gør, kaldes undertiden "opgaver".

For at udføre disse "opgaver" bruger de ofte deres eget økosystem af pakker og plugins. Hvert værktøj skriver opgaver på forskellige måder. Disse værktøjer gør heller ikke alle de samme ting. Nogle "gør" -værktøjer prøver at håndtere enhver opgave, du kaster på den (Grunt, Gulp osv.). Andre fokuserer på en ting, såsom håndtering af Javascript-afhængigheder (Browserify, Require.js osv.).

Nogle gange ender du med at bruge flere af disse værktøjer i det samme projekt.

Her er en kort liste over "opgaver", jeg har automatiseret med disse "gør" -værktøjer:

  1. Udskiftning af en tekststreng i en fil
  2. Oprettelse af mapper og flytning af filer til disse mapper
  3. Kører mine enhedstest med en enkelt kommando
  4. Opdaterer min browser, når jeg gemmer en fil
  5. Kombinerer alle mine JavaScript-filer til en og alle mine CSS-filer i en
  6. Minifiering af mine sammenkædede JavaScript- og CSS-filer
  7. Ændring af placeringen af ​​tags på en html-side

Når du først har forstået, at værktøjer installerer ting eller gør ting, bliver det meget lettere at kategorisere dem:

Koncept # 2 - Bedsteforælderen til alle buildværktøjer er Node og npm

Node og npm installerer og kører alle disse buildværktøjer, så der er altid et spor af dem i dit projekt. På grund af dette forsøger mange udviklere at bruge disse to værktøjer så meget som muligt, før de ty til at installere et ekstra værktøj.

Node og NPM falder ind i vores "build" og "do" dikotomi. Node er "gør" -værktøjet, og npm er "installer" -værktøjet.

npm kan installere biblioteker som Angular.js eller React.js. Det kan også installere en server til at køre din app lokalt til udvikling. Det kan endda installere værktøjer til at gøre ting som at formindske din kode.

På den anden side “gør” ting noget for dig, som f.eks. At køre JavaScript-filer, servere og meget mere.

Hvis du har brug for et sted at begynde at lære, skal du starte med Node + npm og blive der et stykke tid. Når dit projekt bliver stort nok, når du grænserne for, hvad Node og npm kan automatisere for dig. På det tidspunkt kan du organisk inkorporere et andet buildværktøj.

Koncept # 3 - En build er bare en produktionsklar version af din app

Udviklere deler ofte JavaScript og CSS ud i separate filer. Separate filer giver dig mulighed for at fokusere på at skrive mere modulære stykker kode, der gør en enkelt ting. Filer, der gør en ting, mindsker din kognitive belastning. (Hvis du synes, at separate filer er mere forvirrende end en stor fil, så prøv at arbejde i en fil med 5000 linjer, og du vil hurtigt skifte mening?)

Men når det er tid til at flytte din app til produktion, er det ikke ideelt at have flere JavaScript- eller CSS-filer. Når en bruger besøger dit websted, vil hver af dine filer kræve yderligere HTTP-anmodninger, hvilket gør dit websted langsommere at indlæse.

For at afhjælpe dette kan du oprette en "build" af vores app, der fletter alle dine CSS-filer i en fil og gør det samme med din JavaScript. På denne måde minimerer du antallet og størrelsen af ​​filer, som brugeren får. For at oprette denne "build" bruger du et "build-værktøj."

Nedenfor er et screenshot af en app under udvikling. Læg mærke til, hvordan den har 5 tags og 3 tags? Hvis du ser på venstre side, bemærker, at mappen UDVIKLING har 10 filer inde i den?

Og nedenunder er den samme app, efter at et build-værktøj har arbejdet sin magi.

Læg mærke til, hvordan vi bare har et enkelt script-tag og et enkelt link-tag? Og nu har mappen PRODUCTION kun 4 filer sammenlignet med mappen DEVELOPMENT's 10.

Appen er linje for linje den samme. Vi har netop komprimeret det til en pæn lille pakke, vi kalder en "build".

Du spekulerer måske på, hvorfor en build endda er det værd, hvis alt det gør er at spare dine brugere et par millisekunder indlæsningstid. Nå, hvis du laver et websted kun for dig selv eller et par andre mennesker, behøver du ikke bekymre dig om dette. At generere et build af dit projekt er kun nødvendigt for websteder med høj trafik (eller websteder, som du håber snart vil have høj trafik?).

Hvis du bare lærer udvikling eller kun laver websteder med meget lav trafik, er det ikke værd at bruge tid på at generere en build.

Koncept # 4 - Linjerne mellem "installer" og "gør" kan være slørede

Intet værktøj gør kun det ene og ikke det andet. De laver alle en blanding af "installation" og "gør". Men generelt har et værktøj en tendens til at gøre mere af det ene end det andet.

Nogle gange kører et "installations" -værktøj filer. npm gør ofte dette. npm kan også køre kommandoer og scripts - ikke kun installere filer. Et værktøj som Yeoman installerer forudbyggede kedelplade-apps på din computer, men det genererer også dynamisk nye filer efter behov og slører linjen mellem installation og gør.

Koncept # 5 - Der er ingen rigtig kombination af værktøjer

Kombinationen af ​​værktøjer, du bruger, kan være helt op til dig.

Du kan vælge ikke at bruge noget værktøj overhovedet. Bare husk at kopiering, indsættelse, minificering, start af servere og alt andet involveret hurtigt kan blive overvældende.

Eller du kan bare bruge Node og npm sammen uden yderligere værktøjer. Dette er godt for begyndere, men efterhånden som dit projekt vokser, kan det føles som for manuelt af en proces.

Eller du kan vælge at bruge et par andre værktøjer oven på Node og npm i dit projekt. Så din app bruger Node + npm, da den er kernen, og måske måske Grunt + Bower eller Webpack eller Gulp + Bower.

Ved hjælp af en kombination af værktøjer som disse oven på Node + npm kan du automatisere mange opgaver i dit projekt. Prisen du betaler er, at disse værktøjer har en stejl indlæringskurve.

Koncept # 6 - Bygningsværktøjer har en stejl indlæringskurve, så lær kun hvad der er nødvendigt

Det er svært nok at opbygge en app. Du arbejder muligvis med et nyt sprog eller en ny ramme. Eller du har måske virkelig vanskelig forretningslogik. Så at inkorporere et build-værktøj kan tilføje et helt ekstra lag af kompleksitet til dit projekt. Dette gælder især når det er et projekt, hvor en anden skrev koden, der er knyttet til byggeværktøjet.

Mit råd er kun at lære nøjagtigt, hvad du har brug for for at gøre dit job og intet andet.

Den bedste måde at lære nye ting på er, når du har en reel verdensopgave, som du skal udføre. Lær for eksempel ikke, hvordan du kopierer filer med Grunt af hensyn til det. Vent i stedet til dit projekt rent faktisk har brug for det, og find det derefter ud.

Husk: for tidlig kompleksitet vil bremse dig.

Koncept # 7 - Alle buildværktøjer deler det samme mål: at gøre dig glad ved at automatisere mange meniale opgaver

Du bruger dit build-værktøj til sit fulde potentiale, når du når det, jeg kaldte "build tool nirvana." Det er når du gemmer en fil eller kører en enkelt kommando, og masser af opgaver sker "automatisk" for dig.

Hvis dit build-værktøj stadig kræver, at du manuelt flytter filer, ændrer værdier eller kører kommandoer for at få en ny build, har du endnu ikke nået build-værktøjet nirvana.

En af de største fordele ved buildværktøjer er, at du bare ved at gemme en fil kan udløse en ny build af din app og sende den til din browser. Dette kan dramatisk fremskynde din frontend-udviklingsworkflow.

Så hvor meget arbejde skal du lægge for at konfigurere og opsætte dit buildværktøj? Enkelt: stop, når du er tilfreds med, hvad det gør for dig.

Koncept # 8 - Det er ikke kun dig. Dokumentationen er ofte forfærdelig.

Det er ikke dig, det lover jeg. For mange af disse værktøjer mangler dokumentationen ret. Nogle gange kan det være svært at finde ud af, hvordan man udfører grundlæggende opgaver.

Husk, at der er meget få foruddefinerede opskrifter til byggeværktøjer. Du vil se folk få de samme resultater på vildt forskellige måder - nogle gange alle som svar på det samme StackOverflow-spørgsmål!

Selvom dette er irriterende, giver det dig også en mulighed for at bøje dine kodermuskler og implementere noget kreativt.

Når alt kommer til alt, er det ikke derfor, vi gør dette?

Tak fordi du læste dette! Forhåbentlig gør disse få punkter at nærme sig byggeværktøjer til en mindre forvirrende oplevelse. Hvis ikke, er jeg glad for at rydde spørgsmål (eller rette eventuelle fejl, du finder herinde), tweet mig @Roneesh!

Og selvfølgelig, hvis du kunne lide det, du læste, skal du sørge for at ❤ det nedenfor og dele med dine venner. Som forfatter betyder det verden for mig!