Why I chose next.js for frontend development

Published on
post image


Over the past couple of years, I have been working on a few projects with the goal of learning more about frontend development process and web development in general. I have built some small apps and websites for myself and a couple of friends. For some of them I used Wordpress, for some I used Vue.js, for others I used React.js. In the beginning I even did a website only with pure PHP, HTML and CSS.So by now I think I have a decent understanding of how at least the frontend part of web development works. In this post I will share with you the 4 main things i discovered while working on my first project with next.js. and why I gut stuck on it and you should too:

Frontend frameworks in general

The web doesn't work without frameworks anymore. Its basically impossible to build a website without using a framework by now. Although you technically can use plain HTML and CSS, it is just not something that is very useful for most of today's websites. When you start looking into web development, especially if you look at some big, well known sites from the past like google, yahoo or ebay, you will see that they are all built with frameworks today. Some of them even built their own frameworks like Angular.js which is developed by google, or React.js which is developed by Facebook.

Why PHP is the predecessor of modern frameworks


As programmers we really hate to repeat ourselves. And I'm not sure, but its probably something that is in our genes. Everyone who developed even the smallest function once and has felt that inner resistance against copy and pasting code to a new project or another function knows what I'm talking about. In the past PHP allowed you to write parts of your websites in plain HTML and CSS and in the end magically combine them into a working website. And while this works great technically it always required you to learn two languages at once. PHP to generate the server side of your website and then JS for everything dynamic that your website should do. This doesn't sound like much, but as an entry barrier to the web, this is huge. Not to mention that the mix of JS and PHP in your documents can get really confusing really quickly. But despite all that PHP generated websites already had a huge advantage over JS generated ones and that is Server side generation of content. This is the reason why a website framework like Wordpress still uses PHP today. Because a lot of sites simply require server side generated content for the site to be as SEO friendly as possible. Because you want the site to look the same no matter if you look at it or google does.

Evolution of frontend frameworks

The principle is very simple. For a website's content to reach your phone or your computer, you need to make a request to a server. The server will then create a package of what it was told to ship when a request comes in. This package will then be sent to the client. The client will parse the package and display the content.

Sounds simple right?

The interesting part lies in the package that the server sends. Because the contents can differ a lot depending on how your server and website is built.

Level 1: Static content - HTML

The simplest form of sending the package to the client. Just send the HTML file and you're done. While this is fast, easy to set up and easy to use, it is not very scalable. If you have one site and it never changes, then this is the way to go, but for basically everything other than that it's a nightmare to maintain.


Level 2: Dynamic content - PHP

This is where PHP comes into play. With PHP its possible to generate the HTML files that the package contains on request. So the files do not exist when the client requests them, instead they are generated whenever needed. This is cool, because now we can build parts of our website like Footer or Header once and only add them to each of our sites. The good thing: Its very SEO friendly as the content is always there for google to index it. The downside is that it takes time, and capacity from the server to generate the content. Which, depending on the time that it takes can also be counterproductive.


Level 3: Dynamic content - JS frameworks

The next level of evolution was to ship the content in a JS framework to the client and the client will parse the content and generate the website he requested to see. The simplest form of doing this is to just use the framework on your machine where you develop the website and then use the build function of the framework to build the package that the server should send to the client. This is great because now we dropped the need to learn PHP, because we can simply build our entire site using JS. Which allows for very dynamic and rapidly changing websites, like chat or messenger, or sites like Facebook and Twitter. But on the other hand, we lost the SEO benefits of the PHP generated websites, which is not a big deal for companies like Facebook or Google as they are established brands but for personal websites and blogs it's a big deal.

Level 4: Server side rendering

So the idea is now to move the dynamic part of the content creation back to the server right? Well, this is where the next level of evolution comes in. Why not just transfer the framework and its contents to the server and generate the content there like we did with the PHP generated websites? That would be a good idea in theory, but to do that for all of our contents the generation times would be very long, the more complex our site gets, so sites with lots of functionality would be a nightmare to load. And still we would render the content for every client. Of course we could cache the content on the server and keep it for a while but the loading times could still differ drastically depending on the update frequency and the amount of content.

Level 5: Static site generation with next.js

To tackle all the issues that we learned above this is where next.js comes into play. It is a framework based on React that allows you to build a static site generator that lives on your server. So whenever a client makes a request to your server he will just get a package with the content that basically looks like a plain HTML website. What this means is that you can build your entire website with a very flexible framework and don't have to worry about loading times or SEO. So you can focus on building a customer focused app or a blog and you can still use a framework to build the rest of your website's functionality.

Final thoughts

Thanks for following me along through this article until now. I hope you enjoyed it. I hope you found it useful. If you have any questions or comments feel free to contact me.

Affiliate Disclaimer
Links on the site might be affiliate links, so if you click them I might earn a small commission.