Når vi ønsker at opbygge et statisk websted, der er hurtigt, SEO-venligt og er i stand til at levere en fantastisk brugeroplevelse, vælger vi en af de to mest anvendte React-rammer: Next.js k Gatsby.
Mens Next.js gengives dynamisk, genereres Gatsby statisk og gengives på forhånd. Hvis du vil opbygge et React-websted eller -applikation uden at skulle beskæftige sig med routing, konfiguration eller gengivelse på serversiden, skal du se på forskellene mellem Next.js k Gatsby, dens applikationer, og hvornår man skal bruge hvilken.
Som vi allerede har dækket i tidligere blogindlæg, Next.js er en React-baseret ramme, der bygger gengivne apps på serversiden og gør det muligt for søgemaskiner nemt at optimere React-apps med nul konfiguration. Det bruges generelt til at implementere destinationssider, SEO-venlige websteder, e-handelsbutikker og alle slags webapplikationer, der kræver højtydende indlæsningstider.
Valg af den bedste ramme til at udvikle en webapp
afhænger normalt af produktionskravene og mellemlangsigtede mål for dit projekt. Disse er dog nogle af de vigtigste fordele ved at bruge Next.js:
Læs også:
Ligesom Next.js, Gatsby er også baseret på React og er en statisk webstedsgenerator, hvilket betyder, at hvad Gatsby vil producere for os er statiske HTML-filer, som vi indlæser på en server. Dette fungerer anderledes end hvordan mange websteder fungerer, hvor du besøger et websted, og det skal forespørge en database eller lave noget programmering på selve serveren for at betjene dine websider. Gatsby vil bryde denne konvention, have alle tingene forudkonfigureret på forhånd, og servere det op.
Det bliver vigtigt at nævne, at Statiske websteder betyder ikke interaktive eller ikke dynamiske. Vi kan for eksempel indlæse JavaScript i de HTML-filer, som Gatsby betjener, samt foretage API-opkald, udføre interaktioner og opbygge usædvanligt rige og fordybende websteder, selvom de er statiske i deres natur.
En af de gode ting ved Gatsby er, at den bruger GraphQL, et forespørgselssprog, for at få data hvor som helst, hvilket er en udvikling af, hvordan man gør API-opkald enklere og mere effektive - denne funktion kaldes datalag.
Gatsby bruger også React og CSS. Mens React vil blive brugt til alle skabelonerne, vil CSS blive brugt til stylingen.
I en simpel sætning bruger du Gatsby til hastighed, sikkerhed og forbedret udvikleroplevelse.
Formentlig er en af de største gevinster, du får med Gatsby, da det genererer et statisk websted, hastighed. Du vil se, at det bliver langt hurtigere end mange af alternativerne, såsom endda cachelagrede websteder, der bruger WordPress, fordi den statiske er virkelig svær at slå. Dette skyldes, at Gatsby er baseret på justerbare plugins og temaer, som vi vil se nedenfor, hvilket gør processen med at udvikle en webapp eller software meget hurtigere end i Next.js.
På grund af den statiske karakter og bare forsendelse af HTML-filer vil dette også være iboende mere sikkert. Der er ikke en database at hacke eller få adgang til, ingen brugerdata, der vil blive gemt på serveren med Gatsby-webstedet, så selvom nogen skulle være i stand til at hacke selve serveren, vil de kun få adgang til HTML-filer og vil være i stand til langt mindre skade, end de kunne, hvis de fik adgang, for eksempel, til brugerdata, køb, kreditkortnumre og så videre.
Endelig kan det være virkelig drænende for udviklere at arbejde i forældede stakke, og det moderne udviklingsmiljø er en stor fordel ved at arbejde med Gatsby. Værktøjet er enkelt og robust, sprogene er moderne og rene, og generelt er det et virkelig problemfrit miljø at arbejde i.
Gatsby er bygget med en plugin-arkitektur, og det har et enormt økosystem af plugins, såvel som Gatsby temaer.
Plugins sidder mellem den kode, der skrives, og koden, der bliver udsendt, og som vi har sagt tidligere, går alt gennem Gatsby, hvilket gør det muligt for det at træde ind mellem alt og bare komprimere det - uanset om det er et billede eller en CSS-kode, der skal kompileres osv.
Det enkle svar er, at Gatsby faktisk understøtter begge dele SSR (Rendering på serversiden) og CSR (Rendering på klientsiden).
SSR er den mest almindelige metode til at vise indhold på en skærm, og det fungerer ved at omdanne HTML-filer på serveren til browservenlige data. Kort sagt giver det dig mulighed for at forhåndsgengive en side med data, der hentes, når en bruger besøger en side. Gatsby understøtter SSR gennem asynkrone funktioner, som du kan se her.
På den anden side CSR er relativt ny inden for webstedsgengivelse. Du kan oprette regelmæssige sider gennem det, hvilket gør webstedet eller appen meget mere responsiv og problemfri. Brug af CSR giver dig mulighed for at gengive websteder i browseren ved hjælp af JavaScript, hvilket betyder, at i stedet for at have en forskellig HTML-side pr. rute, er du i stand til at opbygge hver rute dynamisk i browseren.
Hvis du har meget indhold, eller hvis du forventer, at dit indhold vokser over tid, er et statisk genereret websted muligvis ikke den bedste løsning for dig, fordi det vil tage meget længere tid at opbygge dit webstedsprojekt på grund af mængden af indhold.
Når du opretter et meget stort websted eller en app med tusindvis af sider, kan det være virkelig langsomt at genopbygge. Og hvis du skal vente 20 minutter, når du trykker på udgiv, før det går live, er det ikke en særlig god løsning.
Kort sagt, Hvis du har et websted med indhold, som du forventer at vokse over tid, så skalerer Gatsby ikke for dig. Og du skal ikke kun tænke på, hvor meget indhold du har nu, men hvor meget du forventer i fremtiden, dvs. have i tankerne hvor mange sider du forventer at have i fremtiden, når du vælger mellem Next.js vs Gatsby.
En af vigtigste kontraster mellem Next.js vs Gatsby er, at Next.js oprindeligt er et gengivelsesværktøj på serversiden. Med andre ord understøtter det kun Static Site Generation (SSG) siden 9.3-versionen. På den anden side er Gatsby en statisk webstedsgenerator, så der er mange out-of-the-box-løsninger til det, som Gatsby Themes, et ret rigt plug-in-økosystem osv. Lad os se på de vigtigste forskelle mellem de to, hvilket er, hvordan de håndterer data og routing, og hvordan de implementeres.
En anden forskel er den måde, de håndtere data. Mens Gatsbys datahentning går gennem GraphQL som standard, er det i Next.js lidt mere fleksibelt, og du kan stort set beslutte, hvordan du selv skal nærme dig datahentning. Lad os tage et bedre kig:
GetInitialProps hvilket er en asynkron metode, der skal løses, før dataene kan sendes fra serveren til klienten. I sidste ende, i stedet for GetInitialProps, dokumentationen anbefaler at bruge GetStaticProps eller GetServerSideProps da disse hentningsmetoder altid kører på serveren (aldrig på klienten) giver dig mulighed for at have et granulært valg mellem statisk generation og SSR.Opret side API til dynamisk oprettelse af siderne. Her kan du angive, hvad slugen er, hvilken komponent der skal gengives. Lad os sige, at du har en liste med 10.000 blogindlæg, du kan bare gå gennem dem og dynamisk oprette sider til hver enkelt.
Ligegyldigt hvad, både Next.js vs Gatsby er virkelig gode værktøjer til at opbygge statiske sider, og beslutningen om, hvilken man skal vælge, er virkelig et spørgsmål om projektkrav. En af de vigtigste ting at overveje er dog, hvor mange opdateringer dit websted vil have i løbet af dagen. Som allerede forklaret før, er Next.js et gengivelsesværktøj på serversiden, og alle opdateringer sker stort set dynamisk, mens med Gatsby betyder hver opdatering, at du skal bygge dit websted igen og igen, undtagen hvis du bruger SSR API der gør det muligt at gengive en side ved kørsel med data, der hentes, når en bruger besøger siden.
Men generelt er det lettere at opbygge et websted med Gatsby, fordi det leveres med mange plugins og brugsklare løsninger, så Hvis du vil bygge et simpelt websted, der ikke kræver for mange daglige opdateringer, kan du vælge Gatsby. Disse websteder kan være virksomhedswebsteder, destinationssider til dit produkt eller endda en personlig blog. På den anden side Next.js er et rigtig godt værktøj til at opbygge fremragende og tilpassede brugeroplevelser, og det bruges mest til at opbygge store e-handelsbutikker, når du har mange daglige opdateringer på dit websted, eller når du vil bygge en rigtig stor webportal, hvor du har mange brugere. Next.js er en god mulighed, når dit projekt kræver gengivelse på serversiden mere end statisk webstedsgenerering.
Mere end 500.000 mennesker læser vores blog hvert år, og vi er rangeret øverst på Google for emner som Next og Gatsby. Hvis du kunne lide dette blogindlæg og ville elske at læse alle vores blogindlæg, tag et kig her.
Alsidig og datadrevet vækstmarkedsfører med dybdegående forretningskendskab, opdateret med den seneste udvikling i det digitale marketinglandskab.
En udvikler, der er fascineret af verdens kulturer, teknologiske fremskridt, og menneskers potentiale.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
