De laatste tijd krijg ik steeds meer de vraag waarom ik in veel gevallen Remix kies boven Next.js. Met dit artikel wil ik laten zien in welke situatie en om welke redenen ik Remix boven Next.js verkies.
Casus
Stel, je bouwt een Enterprise Search toepassing 😛. De data die de gebruiker ontvangt is dynamisch en afhankelijk van de rechten en zoekopdrachten van die gebruiker. Dit artikel laat zien waarom ik in zo’n geval Remix verkies boven Next.js.
Gebruikerservaring en Performance
Bij een dynamische applicatie is het essentieel om een snelle en soepele gebruikerservaring te bieden. Als front-end ontwikkelaar zie ik het als mijn taak om ervoor te zorgen dat gebruikers minimale laadtijden ervaren, en als het even kan met zo min mogelijk client-side JavaScript 😬. Remix is hiervoor perfect, omdat het framework uit zichzelf de mogelijkheid biedt om de meeste data- en mutatielogica aan de serverkant af te handelen, wat leidt tot een betere performance.
Remix: Server-side Data Mutaties met Actions
Op het web zou je eigenlijk kunnen stellen dat elke vorm van data mutaties via een form kan gaan (ja, ook een simpele button) Binnen Remix kunnen alle data mutaties (zoals zoekopdrachten) afhandelen via server-side actions. Dit voorkomt dat je onnodig client-side JavaScript moet schrijven om data mutaties af te handelen.
Doormiddel van actions en useActionData hook kunnen we de response van een action opvangen om de resultaten weer te geven. Om een fancy experience te bieden kunnen we gebruik maken van de useNavigation hook om de status van de zoekopdracht bij te houden (loading states, etc.)
Deze aanpak zorgt ervoor dat je de volledige zoeklogica server-side kunt verwerken, zonder de noodzaak voor extra client-side fetches.
Had ik trouwens al iets gezegd over nested routes? Binnen Remix kun je ditzelfde principe toepassen voor child routes. Elke child route kan zijn eigen loader en action hebben, die onafhankelijk van de parent route werken. Dit betekent dat je dynamisch data kunt laden en mutaties kunt afhandelen op elke geneste route, zonder dat je veel extra client-side logica nodig hebt.
Hoe Next.js Data Mutaties Behandelt
In Next.js kun je gebruikmaken van getServerSideProps om data server-side te laden, maar voor het muteren van data heb je vaak een extra API-route nodig. Dit kan de complexiteit van je applicatie verhogen, omdat je zowel server- als client-side logica moet beheren.
Hier is een voorbeeld van hoe je in Next.js een API-route kunt maken voor het verwerken van zoekopdrachten.
Deze route accepteert een POST-aanvraag, verwerkt de zoekopdracht en retourneert de resultaten. Vervolgens zouden we een client-side een fetch request kunnen versturen naar deze API.
Dit vereist best wat handmatige logica voor het beheren van laadtoestanden en foutafhandeling. En natuurlijk kan je in deze situatie kiezen voor een oplossing als react-query om je state management iets te versimpelen.
Het punt dat ik wil maken is dat Remix in deze situatie, react-query niet eens nodig heeft.
Het kan behoorlijk complex worden als je veel endpoints hebt, wat één van de redenen is waarom Remix met zijn ingebouwde ondersteuning voor forms en server-side data handling aantrekkelijker kan zijn.
Hoewel Next.js krachtig is en vaak de beste keuze is voor toepassingen met bijvoorbeeld Static Site Generation of Client Side Rendering, blinkt Remix uit in situaties waarin dynamische content en server-side rendering centraal staan. Voor complexe toepassingen zoals onze Enterprise Search toepassing, biedt Remix een efficiënte aanpak die server-side logica beter beheert en client-side JavaScript minimaliseert.
Kortom, Remix maakt het bouwen van dynamische applicaties eenvoudiger, met minder client-side code, meer focus op performance en progressive enhancements voor key-functionaliteit van je applicatie.
Ik ben benieuwd naar jouw mening! Heb je suggesties of ervaringen die je wilt delen? Laat het me weten!