Is Next.js de oplossing voor jouw volgend project?

In de beginjaren van het internet bestonden web-applicaties uit verschillende documenten die met elkaar verbonden waren met links. Als je via de browser een pagina bezocht, dan stuurde de browser een verzoek naar de server om deze pagina op te halen. De server zocht dan de gepaste html-pagina op zijn harde schijf en stuurde deze terug naar de browser.

Dit was een heel eenvoudig en relatief snel proces, voornamelijk omdat alles statisch was. Elke gebruiker kreeg exact dezelfde statische pagina te zien.

Next.js probeert alle voordelen van de beschikbare webtechnologiën te bundelen. Daarom is de kans groot dat het een goede match wordt voor je volgende project.

Niet zo heel lang daarna werd alles een beetje dynamischer omdat de server de mogelijkheid had de html-pagina's eerst aan te passen (pre-processing) alvorens deze terug te sturen naar de client (de browser).

Elke keer de browser een pagina opvroeg, zou de server de html voorbereiden op basis van user-cookies of authentication headers, om daarna een pagina op maat van de gebruiker terug te sturen naar de browser. Dat zorgde ervoor dat er per gebruiker een unieke ervaring kon worden gebouwd.

Maar er ontbrak nog iets. De pagina's werden nu wel dynamisch opgebouwd op de server, maar de eindervaring van de gebruiker was nog steeds statisch.

Om een echte app-ervaring te kunnen bieden aan gebruikers, had het web iets nodig om de statische pagina's interactiever te maken. In de zomer van 1995 had Brendan Eich een idee. Onder de codenaam "Mocha" maakte hij een prototype van een scripting taal die erin slaagde de inhoud van de browser interactiever te maken. Het prototype werd gereleased onder de naam "LiveScript". Later veranderde de naam in JavaScript, omdat de originele bedoeling altijd was geweest om een side-kick taal van Java te maken.

JavaScript was in het begin goed genoeg om te overleven, maar websitebouwers maakten al snel misbruik van de technologie, waardoor het zijn doel initieel mistte. Velen zullen zich nog de ontelbare, vervelende pop-ups herinneren.

De taal bevatte echter voldoende potentieel om een innoverend effect te hebben op de gebruikerservaring.

In 1999 werd een nieuwe technologie geïntroduceerd. Een Asynchrone JavaScript API genaamd Ajax. De technologie liet de browser toe om data te versturen en ontvangen van de server, zonder de pagina te moeten herladen. Het was zo'n krachtige technologie dat zelfs het originele core-concept van de Apple Iphone gebaseerd was op Ajax.

Deze verandering maakte het mogelijk om echt interactieve applicaties te bouwen voor het web. Veel ontwikkelaars hadden daarbij echter nog maar vaag een idee van was ze aan het doen waren.

In 2011 had een ontwikkelaar genaamd "Misko Hevery" er genoeg van. De voorbije 12 jaar waren de browsers wel beter en sneller geworden, maar de manier waarop web-applicaties werden ontwikkeld, was nog steeds dezelfde Ajax-manier. Er was nog wat hulp gekomen van jQuery, een library die het ontwikkelen van Ajax-applicaties wat eenvoudiger maakte, maar meer dan dat was er niet. Misko ontwikkelde daarom Angular.js, een framework dat verandering bracht.

Html is goed in het omschrijven van statische pagina's, maar schiet tekort in het behandelen van dynamische content. Angular.js liet de ontwikkelaars toe de syntax van html uit te breiden om deze beperkingen weg te werken.

Angular.js was de voorbode voor de ontwikkeling van React. Een library die nog een stapje verder ging.

Het innoverende aan React.js is dat het de visuele laag behandeld als een functie van de "application state". Concreet betekent dit dat je je als ontwikkelaar enkel zorgen hoeft te maken over de data in je applicatie. React zorgt er dan voor dat het visuele zich daaraan aanpast. Dit kernidee werd dan in een jasje van een component-based api gegoten, wat ertoe leidt dat je als ontwikkelaar op een intuitieve manier componenten kan samenstellen.

Om dit nog eenvoudiger te maken, werd JSX geïntroduceerd. Een XML-notatie, te vergelijken met Html, die de ontwikkelaar toelaat om een JavaScript component te omschrijven zoals hij dat vroeger met Html deed.

Dit klinkt allemaal heel goed, maar toch was er nog een probleem. React is namelijk heel goed in dat waarvoor het gebouwd is, maar trekt zich niks aan van al de rest. Weinig applicaties hebben echter genoeg aan een visuele laag, er komt meer bij kijken. Als ontwikkelaar moest je al snel een doctoraat in Computer Science hebben om uit te vissen hoe je hiermee iets nuttig kon maken.

Een team bij Facebook kwam met Create-React-App op de proppen. Een tool die het opzetten van een production-ready React-applicatie herleide tot 1 commando. Geen gezeur meer met webpack configs of dingen zoals babel... Je kon je eerder focussen op het bouwen van de applicatie, in plaats van die te configureren.

Angular.js en React.js werden gebouwd met 1 reden, ze waren geoptimaliseerd voor het bouwen van SPA's (Single Page Applications). In plaats van een request te maken naar de server telkens een gebruiker een pagina bezoekt, laden SPA's alle nodige JS, CSS en Html al bij de eerste request. Elke vorm van navigatie of interactie die zich daarna afspeelt, gebeurt op de client. Dit zorgt, indien de SPA ontwikkeld wordt volgens de regels van de kunst, voor een snelle en intuitieve app-ervaring, die garant staat voor een heel goede, "snappy" gebruikerservaring. Let wel, als die regels van de kunst niet zo goed gevolgd worden, dan heeft dit echter het omgekeerde effect.

Voordelen:

Het downloaden van de volledige bundle bij de initiële request, maakt een goeie caching mogelijk. Gebruikers kunnen aan de slag met de applicatie terwijl ze offline zijn en eens de bundle gecached is, zal er minder data opgehaald moeten worden.
Tijdens het navigeren door de applicatie, zal een SPA enkel de nodige content updaten, in plaats van de volledige pagina te herladen. Dat zorgt voor een sneller en responsievere applicatie.
Voor ontwikkelaars bieden SPA's dan weer een snellere ontwikkeltijd, meer en betere debug-mogelijkheden en out-of-the box cross-platform compatibiliteit.

Nadelen:

SPA's hebben de neiging om een grotere "bundle size" (de hoeveelheid data die bij de initiële request moet gedownload worden) af te dwingen. Voor gebruikers met een tragere internetverbinding betekent dit langer wachten tot de applicatie geladen wordt.
In SPA's wordt data ook typisch on-demand opgevraagd. Dit kan leiden tot een overaanbod van loading-spinners.
Tot slot zijn SPA's ook verre van ideaal voor SEO (Zoekmachine optimalisatie). Je dwingt Google om te wachten tot de JavaScript geladen is, vooraleer de content van de applicatie kan gelezen worden. Door de on-demand werking is deze initiële content, die door bots gelezen wordt, echter vaak leeg.

SPA's hebben dus hun nut, maar het is niet altijd rozengeur en maneschijn.

Next.js probeert aan dit verhaal een oplossing te bieden, door net zoals met Create-React-App gedaan werd, de manier van apps te onwikkelen te vereenvoudigen. Niet alleen dat, maar het probeert ook de manier waarop het web oorspronkelijk werd ontwikkeld te versmelten met de nieuwe, innovatieve technologie die voorhanden is.

Next.js combineert de simpliciteit van de statische documenten waar het allemaal mee begon, de kracht van de server-side dynamiek, de compositie mogelijkheden van React.js en de gebruikerservaring die SPA's kunnen bieden. Het doet dit, terwijl het de trade-offs die elk van deze stappen in de historiek van het web met zich meebrachten, minimaliseert.

Next.js is een framework dat gebouwd werd bovenop React.js. Het waardeert React voor wat het is en negeert het voor wat het niet is.

Net zoals bij Create-React-App, kan je een Next.js applicatie opzetten met 1 commando.

Een pagina toevoegen is zo eenvoudig als een bestand aanmaken in de "pages"-directory, waarin je een component toevoegt die omschrijft hoe die pagina er moet uit zien.

Next.js zal deze pagina statisch aanmaken op de server (at build-time) en deze pagina doorsturen naar de client op elke request, zoals het vroeger gebeurde. Indien je data nodig hebt die reeds op de server bestaat (at build-time), kan Next.js op basis van deze data statische pagina's voorzien, die dan on request kunnen doorgestuurd worden naar de client.

Indien de pagina data nodig heeft, waarover de server nog niet beschikt tijdens het builden van de applicatie (data die bijvoorbeeld op het moment moet berekend of samengesteld worden), dan biedt Next.js verschillende opties. Je kan Next.js de pagina laten samenstellen op de server, wanneer de request komt, of je kan de data opvragen in de client, zoals een traditionele SPA.

Next.js biedt dus de flexibiliteit om data te injecteren in je applicatie, wanneer je die nodig hebt: at build-time, op de server, of terwijl gebruikers je applicatie gebruiken.

Als extra optie kan je ook je applicaties statisch builden, daarna on request een pagina opnieuw genereren om die vervolgens statisch aan te bieden.

Next.js zorgt ervoor dat elke pagina in je applicatie (elk bestand in de pages folder) wordt opgesplitst in zijn eigen bundle. Gebruikers downloaden dus enkel wat ze nodig hebben.

Automatische image-optimalisatie is nog een geweldige feature in Next.js. Afbeeldingen worden automatisch aangeboden op een afmeting, geschikt voor de viewport waarin ze bekeken worden. Ze worden ook pas ingeladen wanneer ze in de viewport te zien zijn.

Aangezien Next.js niet alleen een frontend-framework is, is er ook de mogelijkheid om api-routes toe te voegen. Je kan de volledige API van je applicatie bouwen in Next.js. Elk bestand in de pages/api folder wordt aanzien als API-endpoint. Het wordt een server-side bundle en heeft geen invloed op de client-side bundle-grootte.