Over in Front-End-Land at Kyan, 2020 kind of feels like the year of Next.js. We’ve kicked off a number of internal and external projects using the framework now, and it feels very much like we’re in love with one another.
But what is Next.js, and why do we love it so much?
It’s a JAM sandwich!
Next.js is a React framework for building sites using the JAM stack architecture. The acronym JAM stands for Javascript, APIs and Markup. Effectively, it is building sites with Javascript, with data from APIs, which all ends up as simple markup.
The JAM stack does away with the traditional server and database architecture, giving us plain old-school HTML, CSS and Javascript to host wherever we please.
What’s that you ask? Why is that so good?
-
Better performance – Because we’re serving pre-built files (probably from a CDN), we cut out network waiting times which we might have normally associated with websites (such as, for example, database calls).
-
Security – Removing the need for servers and databases, and pre-building your pages on deployment reduces the possible avenues for malicious souls to attack your website.
-
Scalability – You can serve your files from anywhere, and if you do so via a CDN, you can deliver as demand dictates.
What more could you ask for?!
There are a number of products out there that offer you the benefits of the JAM stack though, for example, maybe Gatsby or Hugo. So what specifically makes us so keen on Next.js?
You don’t have to be clever
Webpack has undoubtedly become central to the front-end workflow at Kyan, but it is not without its issues. What I mean of course, is that it is sometimes black magic of the most incomprehensible kind.
Next.js comes with Webpack set up for you, more or less invisible, and all the while offering all of the goodies that you would want. Asset compilation (Sass), hot reloading, optimisation (code-splitting) and code transformation (for backwards compatibility) are all set up by default.
That’s a whole lot of cleverness before you’ve even written a single line of code!
...but sometimes it helps
That is not to say that Next.js ties you to particular ways of working. The Webpack configuration is editable through a configuration file.
This has come in particularly helpful for us when we’re dealing with assets.
Before the built-in Sass support that Next.js now enjoys, you would have to use the next-sass plugin. This meant diving into the Next config to update Webpack. Some really solid docs helped make the whole process trivial.
Importing SVGs into our components was one of the smaller configuration changes.
Optimise Prime
I mentioned optimisation briefly, but it’s probably worth going into a bit more detail. Performance is one of those JAM-y benefits which make Next.js such a good choice, but the framework does not sit on its laurels.
As already mentioned, code-splitting comes as standard, avoiding that monolithic bundle that might slow down your user’s experience.
Next.js also pre-fetches content when it sees links to that content in the viewport. What’s more, it will only look to fetch prematurely if you have a decent connection.
‘Automatic static optimisation’ is a rather fancy way of saying that, if possible, Next.js will pre-render static HTML on the server, and deliver that to the user. Which, in case you didn’t realise, is super fast.
All aboard!
Bringing Next.js into our collective toolbox has been relatively straightforward for the front-end team. You are still building your component-based React sites in much the same way as you would with Create React App, or any other framework.
I’d be lying if I said Next.js hadn’t forced some significant changes on builds, particularly in the data layer, if you’re not used to talking to APIs.
Routing (especially when its dynamic) also requires a specific Next.js way of doing things; having said that, the concepts are not altogether complicated, and the documentation. Well, actually that leads me on quite nicely...
What’s up, Doc?
One feature of Next.js that is particularly close to my heart, and probably not spoken about enough, is its documentation. It’s very rare that I’ve come across a problem (or indeed a solution) that wasn’t clearly and concisely explained in the docs.
On top of that, the community around the framework is excellent, with lots of tutorials and tips to pick up. The problems that you are likely to come up against have been solved for the most part, and a quick Google will find those solutions.
A constant stream of new features
In the course of my last two builds with Next.js, they have released two minor versions of the framework, both of which have demonstrably improved the development experience. Just to name a few, in the last three months, support has been added for:
-
Built-in Sass for global stylesheets and CSS Modules
-
Absolute imports
-
Environment variables
Some of these are quite large, some relatively small, but it’s been a pleasure to see these releases come so quickly and consistently, and that they add so much value to the development experience.
Show me the money!
I mentioned that we’re using Next.js in production, if you’re interested in where, you might want to take a little look at these two beauties. Beat the Covid Lockdown and support Save the Children with the Beano-themed Lockdown Birthday Bash Party Pack: Save the Children: Lockdown Birthdays. And WXG, our long-running annual tech conference: wxg.co.uk
Summing up
I’ve barely scratched the surface here really... there are so many more nice things to say about Next.js.
There have undoubtedly been issues along the way, though I would say a lot of those are a result of learning how to use the framework effectively. The benefits have most definitely outweighed any problems that we’ve encountered.
If you want to find out more about Next.js, I’d highly recommend having a look through those sterling docs that I spoke about.
For our part, we’ll be keeping up with Next.js for the foreseeable.
Previously from our Engineering Team:
Dev Talks: End-to-end testing with Cypress by Damian Boni
Things I wish I’d known before I started with React Native by Carmen Lopez Guerra
How Ruby if statements can help you write better code by Dave Cocks
How do you solve a problem like caching in Progressive Web Apps? by Dave Quilter
Rails 6: Seeing Action Text in... action by Stephen Giles
A Quick Comment on Git Stash by Karen Fielding
Avoiding N+1 queries in Rails GraphQL APIs by Andy West
