Preface
There are many controversial opinions about Next.js 13 App Router, some of them say that this routing method is slow and created a lot of unnecessary weight in the project, but in the other side, many people says that managing your routes using the App Router is the best way to improve productivity while building with Vercel's very own Next.js
Why Next was created?
In one of Lucas Montano's videos — this particular one featured Mario Souto they did a retrospective moment talking about the purpose of Next.js's existence.
When Guillermo Rauch, CEO of Vercel, first launched Next.js back in 2017, he mentioned that Next was created in a try to make an framework that would build application as PHP was merged with JavaScript.
Think about how webapps are created with PHP. You create some files, write PHP code, then simply deploy it. We don't have to worry about routing much, and the app is rendered on the server by default.
Watch the video here
Comparing AppRouter to PHP router
Starting with PHP, where the idea of Next came from.
In PHP, there are many ways to route your application, just as it works at React, you can install some routing library and work with a custom routes.php
file or you can choose for building a folder structure that will be responsible for routing your entire application
As you can see, each one of the files inside this source directory is assigned to a route, so 404.php
would be the /404
route, the same way home.php
would be the /
route.
Pretty simple, right? Next uses an almost identical folder structure to route applications.
Above there is Next.js original routing, that was based in the pages
folder. A pages
folder needed to exist in the app in order to create routes.
The structure consisted on a page inside the pages folder and a index.tsx
file inside of the subfolder.
For example: the directory pages/users/duca.tsx
would create the route users/duca
.
New routing method: AppRouter
In order to make Next route even more succinct, Vercel developed the App Router.
Now the routes look like this:
The app does not need anymore the folder pages
to work. Now, it follows this structure: app/users/duca/page.tsx
to generate the /users/duca
route. In this example, the routing seems to be static, once always will exist just one /duca
route and you can not change the user without creating or renaming the existent folder.
But, let's try a new perspective: If you want to create a dynamic route that reads the name of a user by its url and then display it on screen, you can do something like this:
Final considerations
Guillermo had successfully created a file-based routing system that I am afraid to say that works better than the one from PHP.
Now it is up to you. Based on your application, which routing system would serve you better? Page routing (the deprecated one) or the newer App Router?
Would you be affected by a system that is more needed of folders but has a succinct nomenclature or would you prefer keep using the pages
folder on exchange of using fewer folders to route your app?
Sig Coding
Sig is a community-first DAO startup that produces SaaS applications powered by its own community. We spend time thinking on how to make things better and how to make tech be more environment-friendly.
Top comments (0)