The Story of Next.js

Share

Every decade or so, technology comes along, that changes how we write software.

Is Next.js that technology? or is it just another framework that’ll be obsolete by next year, to better answer that we need to go back, way back to the beginning of the web.

In the early days of the web, there were just documents with links between them when a browser made a request to a server for a particular page the server would find the HTML file stored on its hard disk and send it back to the browser.

It was a simple relatively fast process primarily because everything was static. every user no matter what received the exact same static experience. Not long after instead of serving up static files, servers started pre-processing the HTML before it was sent to the client.

Every time a browser would request a page based on the user’s cookies or authentication headers, the server would generate the HTML on the fly for that specific user. This allowed you to create sites that were more than just for reading static documents.

Now you could create unique experiences for each individual user but there was still something missing. Yes, pages were being dynamically created on the server but the end result, the user, got was still a static experience. For the web, to take a step towards being a real application platform it needed a way to make static pages more interactive.

#Early days JavaScript

In the summer of 1995, one man on a lot of caffeine did just that:

Brenden Eich – Creator of JavaScript

Javascript was a step in the right direction but its initial release was rushed underfunded and it was treated as sort of a toy sidekick to java not only that but the way it was initially used was not ideal.

Javascript had enough good at the beginning to survive now if you think back through to the mid-90s, javascript was cursed because it was mainly used for annoyances like little scrolling messages in the status bar at the bottom of your browser or flashing images or things that popped up windows massively.

The good news was that even though it was rushed javascript was malleable enough to encourage user innovation. it just needed something to push it over the edge.

#Game Change

Then, in 1999 that something came in the form of an ugly but powerful API. AJAX changed the game because it allowed browsers to send and receive data from the server without needing to reload the page. This one change ushered in the next era of rich dynamically generated web apps in fact believe it or not. AJAX was so powerful that apple’s original developer strategy for the iPhone was centered on it.

we’ve got an innovative new way to create applications for mobile devices, really innovative. And it’s all based on the fact that iPhone has the full safari inside it. you can write amazing web 2.0 and AJAX apps that look exactly and behave exactly like apps on the iphone.

Steve Jobs

STEVE JOBS

So at this point with the addition of AJAX and additional improvements to the javascript language, the web started to look like a viable application platform. this ushered in the years of the web the era where you could build real applications before any of us knew what we were actually doing.

#Evolution

Misko goes on to describe that there are three ways to build web apps treating the browser as a dumb terminal with a round trip to the server abstracting away HTML and javascript and DOM manipulators each coming with their own set of opinions and trade-offs none of which were ideal.

The DOM scripting era of vanilla javascript and jquery eventually led to the lawless period of AngularJS which eventually led to the creation of a library called react.js.

#ReactJS in Game

one of the core innovations of React was that they made the view a function of your application state. all you had to do is worry about how the state in your application changed and react would handle the rest.

But this was only really half the picture. the real innovation happened when you encapsulated this idea into a proper component-based API. By doing so, the same intuition you have about creating and composing together, functions can directly apply to creating and composing components to truly embrace a component-based API.

React needed a way to allow you to describe what the UI effort component would look like from inside the component itself. To do this, they created JSX.

JSX combined the power and expressiveness of javascript with the readability and accessibility of HTML. if you were already comfortable with both javascript and HTML which you probably were if you were building web apps, then you could get up to speed with JSX in a matter of minutes. not only that but by embracing both JSX and react’s component-based API. this not only enabled a better developer experience, but also a vibrant ecosystem of third-party components.

Later on, create-react-app was created by a team of Facebook to make getting up and running with a react app as easy as possible. with one command you’d get a production-ready react app. The problem that angularjs ushered in and create react app embraced was that both were optimized for creating a Single Page Application (SPA).

#Single Page Application (SPA)

With SPAs instead of making a request to the server, every time a user visited a new page, your application would load all the necessary HTML, CSS, and javascript for your app on the initial request.

SPAs create a brilliant user experience that feels snappy and app-like done anything less than well and SPAs leave a lot to be desired by their nature. SPAs tend to encourage large bundle sizes if you’re not careful, this is especially problematic for users on slow internet connections or mobile devices.

second, with SPAs, your data is typically loaded on an as-needed basis, again if you’re not careful this leads to an experience where every route transition is met with a barrage of loading spinners.

finally, if you care about SEO creating a SPA is less than ideal because you’re relying on google’s ability to execute your javascript before it’s able to figure out the content of your page.

#Rise of NEXT.JS

Next.js is the combination of everything we’ve learned from the last 20 years of building for the web. with next.js you get

  • The simplicity of the Document era
  • The power of the server-rendered era
  • The composition of the react era
  • the UX of the SPA era

Next.js is a framework built on top of React. This lets Next embrace react for what it is– a UI framework and ignore it for what it isn’t anything else like create react app.

You can get up and running with the Next.js app with a single command. To create a new page in your app with Next.js, you just add a file in the pages directory.

It exports a react component describing the UI for that page. By default, next.js will statically generate the page of build time and like websites of old serve up the HTML for every request allowing it to be cached by CDNs.

unlike websites of old if that page needs external data that can be fetched at build time you just export a getStaticProps() function that fetches and returns the data which will then be passed as props to the component.

Features:

There’s a feature called incremental static regeneration which allows you to statically generate your site at build time, then on a per-page basis regenerate a page on-demand with new data.

Next.js comes with code splitting out of the box which means that each file inside of your page’s directory will be split into their own bundles during build time so users only download the assets they need

Another feature is image optimization. Next.js comes with an image component that’s like if the HTML image element had been built for the modern web out of the box you get improved performance by always serving correctly sized images for each device. using modern image formats you get visual stability by preventing cumulative layout shift automatically. you get faster page loads because images are only loaded when they enter the viewport and you get on-demand image resizing even for images stored on remote servers.

Since Next.js is more than just a front-end framework, you can create API routes without having to spin up your own server meaning you can literally build out an entire API with Next.js by simply creating a file.

Next.js isn’t the only framework of its kind. however, it was the first that combined decades of innovation into a single package which is why as of today I believe Next.js is one of the best ways to create web applications.

Share
Sudeep Mishra

Sudeep Mishra

Healing

%d bloggers like this: