Published: 2021-12-23

Why I switched from Angular to Next.js

For this blog I chose my stack to be Next.js. I've slowly been transitioning from Angular (version 8 or 9 when making the switch) to Next.js.

Framework

The thing I like the most about Angular is that it is a complete framework. You dont have to go outside of the Angular-box if you don't want to. There are many positive aspects with that. It is easier to jump into someone elses code due to the fact that Angular almost always has one way of doing things.

Thats why I've waited to go full time with React, the lack of standardized routing is one reason, and decision overload when choosing libraries for data fetching, animations and so on.

A negative aspect of full frameworks like Angular is that you never try other things that might be better and easier to use due to the fact that is more convenient to choose from Angulars own libraries. And sometimes it requires too much work to get some external libraries to work with Angular.

I think Next.js is a competent light framework that doesn't tell you how to do everything but had standardized utilities for common tasks like routing and API integration. If you use SWR for data fetching you also have a pretty standardized way of getting your data as well. As of version 12 Next.js has middlewares. Just like Express, and it is awesome! Perfect for authentication and protected routes.

Boilerplate hell

The boilerplate code for Angular is one of the reasons I chose to go to React instead. The Angular CLI certainly helped with creating all the boilerplate code but it gets a bit tedious to traverse to the correct folder and write "ng g c component-name" every time I needed to create a component. In Next i just create a functional component with a snippet.

Angular uses the class syntax which has been used in TypeScript all along. React used to do this, and still allows you to. But it has evolved to be more function oriented. The introduction of React Hooks has changed the playing field. Less boilerplate and less lines of code makes every file more readable.

SEO and Performance

The performance of Angular is alright, but there is not many things that beats statically pre-rendered pages. You can indeed use Angular Universal for this but It's not as seamless an experience as it is in Next.

The ability to opt-in or out of static rendering in Next is easy to read and to understand and requires no additional setup for me as a developer. I also like the approach of "build as you go", meaning that Next can statically build pages when the first user requests it (incremental static generation). After that it is ready to be served statically to the next user. And it's fast!

Since Next has the server-first approach you don't have to think about bots or SoMe not being able to parse/crawl the site. Many crawlers, including Google, are now rendering Single Page Applications before crawling them but not all bots can do this. I had some issues with social sharing to Facebook using a Angular SPA and had to use an ugly PHP workaround since the site was not hosted on Node.

Routing made easy

Not having to set upp routing in Next is a relief and the outcome is predictable. It's just based on the folder structure of the "pages" folder. Subfolder = sub-route, very easy to read and to understand.

Routing in Angular is a bit complicated. You have to create an array of objects that explains what route and what component should be loaded.

const APP_ROUTES: Routes = [
  {
    path: '',
    component: StartComponent,
    pathMatch: 'full',
  },
  // Loads the supplements route with its children
  {
    path: 'supplements',
    loadChildren: () =>
      import('./product/product.module').then((m) => m.ProductModule),
  },
  // Loads the lists route with its children
  {
    path: 'lists',
    loadChildren: () =>
      import('./lists/lists.module').then((m) => m.ListsModule),
  },
  {
    path: 'news',
    component: NewsComponent,
  },
];

In Next.js we just put our files in a folder named "pages" and it just routes based on the folder structure and file name. Simple, easy to understand and requires no setup from the developer.

Easy deployment

Thanks to Vercel we have a fully autonomous integration to deploy our Next applications. I'm personally using Render.com for my hosting due to their generous pricing. As of writing this Render has a $7 fee for a tier that will suit most applications that is small to medium scale.

That's one of the things I love about Next.js. It can really be deployed anywhere. You can even serve it as static files on an old web-server if you don't need SSR or server processing.

I've not had this simple deployment process ever before. Anything that requires more effort in the future must really be worth it.

Why not Gatsby 4?

I chose Next.js a while ago when Gatsby was still just a static page generator. It didn't suit my needs then, but if I had to do it all over again maybe I'd consider Gatsby now that it has mist of Next.js features.

Maybe I should do a comparison one day. That will be another blog post.

Final thoughts

I choose Next.js due to convenience. A standardized enough framework that deals with much of the boilerplate while not taking away the freedom to choose libraries for animation, fetching and more.

With Next.js 12 we got a new renderer built in Rust, and it is really fast. I encourage you to try it.