## Ultra quick setup
Many of the people I speak to regarding [React.js](https://reactjs.org/) use [Create React App](https://github.com/facebook/create-react-app) (CRA) to quickly bootstrap applications. It would be great if [Next.js](https://nextjs.org/) had something similar. Let's call it Create Next App (CNA). Well, it exists! [Vercel](https://vercel.com/), the company behind Next.js has created [CNA](https://nextjs.org/docs/api-reference/create-next-app). Let's have a look.

![yarn create next-app](/img/articles/create-next-app-command.png)

You will be guided to an interactive setup that will just ask you for a project name. After that, all the required node modules will be installed and a very basic Next.js app will be bootstrapped. You could opt-in for a TypeScript variant as well. The output should look something like this:

![Outputted Create Next App folders](/img/articles/create-next-app-folders.jpg)*Outputted Create Next App folders*

Note: you can ignore the `pages/api` folder for now. If you are interested in the feature you can have a read at my article ["Next.js API routes"](https://www.davebitter.com/articles/next-js-api-routes).

For those who are familiar with CRA, this will look very familiar. Besides all the build tools, CNA outputs a simple home page with an image and some styling. As you can see, by default CSS modules are used. If you want to add something like SCSS you can easily do so by installing SCSS. Next.js will just work. Next to all of this, CNA comes with the development tools that you'd expect it to like, for instance, hot-module reloading. In my experience, the way you alter your CRA project for things like linting and rules is very similar in CNA. Please refer to the documentation if you want more details. That's it, you are now ready to start developing!

![yarn dev](/img/articles/create-next-app-dev.png)

![Create Next App default page](/img/articles/create-next-app-boilerplate-page.jpg)*Create Next App default page*

## Building your first page
Naturally, Next.js documented all you need to know very well. Let's have a quick look however how we can build our first page.
### Standard route
The `pages` folder is a special folder by Next.js. Basically, every file in this folder translates to a route. For example, by default, you see an `index.js` file. This gets build into `/index.html`.  So what if we want to create an about page. Well, we make a file called `about.js` and return a React.js component. In this case a functional component:

![Created "about" page](/img/articles/create-next-app-about-page.png)*Created "about" page*

If you go to `/about` in your browser you will see that you now have an about page. This is all you need to do to create pages. Creating folders works as you expect it to. `pages/contact/socials.js` will translate to `/contact/socials.html`.

From here on out you can write all the same React.js code you are familiar with for every page. As you might have guessed, you can use [Next links](https://nextjs.org/docs/api-reference/next/link) to take care of your client-side routing.
### Dynamic routes
So what if we need to use dynamic routes. In the case of my blog, I have various articles under `/articles/... .html`. It wouldn't make sense to create a separate file for each new article. This is where dynamic routes come in. You can use the special bracket notation to indicate to Next.js that a part of the route is dynamic. In the case of the example of the articles, we can create a file under `pages/articles/[slug].js`. Whatever you put as a slug now in the URL will be mapped to this file. There is one small addition you need to make that we'll cover in the next chapter.
### Special page files
As you may have noticed, there is a file called `pages/_app.js`. Next.js has a couple of special files which are prefixed with a `_`. This specific file is exactly the same as the file you might have worked with in a CRA React.js app. It is a sort of "wrapper component" around your page. Here, you could for instance load a header, navigation and footer component that will be loaded for each page. Next to this file, there are a few more. `pages/_error.js` is a page that will be loaded if there is a critical error. You can create a bit of a nicer page than the default one if you want. Finally, there is a `pages/_document.js` page which is a "wrapper-page" around the `pages/_app.js` where you can load for instance some external scripts or set meta-information in the `head`. Please refer to the documentation for these pages to learn more.
## You can stop here
Great, that's the basics. We now have React.js pages build with Next.js that will be rendered server-side. Next.js takes care of the development environment and build process with things like automatic code-splitting, minifying and post-processing. You can stop here for now or take it up one notch and really get the benefits of Next.js.
## A short introduction to server-side functions
By far, having server-side functions is one of Next.js's biggest features. It may sound a bit daunting at first, but let's look at some practical examples of how to use it.
In essence, these functions run on the server, or during build time, before the page gets loaded in the client. These functions can, for instance, fetch some needed data on the server, return the data as a React.js prop to the page and be rendered on the server based on the value.
### getInitialProps
Let's keep using the blog as an example. When the user navigates to `/articles/the-meaning-of-life` we want to fetch the articles from a CMS and return it as a React.js prop to the page. This is done through by exporting a special Next.js function. This could look something like this:

![Code example getInitialProps](/img/articles/create-next-app-get-initial-props.png)*Code example getInitialProps*

As you can see, we retrieve the dynamic slug from the request object, fetch the article and return the article. We now receive it as a React.js prop for the page itself. You can now use the data to render the page (server-side).

There is however a small addition to this. Next.js needs to know what all the possible slugs are in order to build a page for every article. We can do this by exporting another special Next.js function like this:

![Code example getStaticPaths](/img/articles/create-next-app-get-static-paths.png)*Code example getStaticPaths*

Based on this array of slugs, Next.js will now build pages during the build process.
### getInitialProps
The previous example is used when you want to fetch some data on the serving during build time, but what if you want to fetch during run time? You can export an other special Next.js function like this:

![Code example getInitialPaths](/img/articles/create-next-app-get-initial-paths.png)*Code example getInitialPaths*

The vital difference in this function, compared to the previous one, is that this will only run on run time. This page will therefore no longer be statically generated but requires either a Node.js server or serverless function. The question is how you want to host your site. A statically generated site is easier to deploy as it is just some static files, a Node.js server or serverless environment will allow you to retrieve data on demand. The cool thing about Next.js is that you can use both these techniques on different pages. If you want to dive a bit more into this part of Next.js I suggest you to read my article ["Next.js page generation"](https://www.davebitter.com/articles/next-js-page-generation).
## Deploying your Next.js app
The deployment of your Next.js app depends on a variety of factors. Let's take a statically generated site for the purpose of keeping it simple. You can run the following command to create a fresh build of your app:

![yarn build](/img/articles/create-next-app-build.png)

You then have to add a new NPM script called `export` that runs the command `next export`. Once you run that you will have the following output:

![yarn export](/img/articles/create-next-app-export.png)

![Outputted Create Next App export](/img/articles/create-next-app-export.jpg)*Outputted Create Next App export*

You're now free to host these static files wherever you want. In the case of going for serverless, you might want to check out my article [Implementing the latest web technologies to boost the Mirabeau blog](https://www.davebitter.com/articles/mirabeau-blog-latest-web-technologies).
## C'est tout!
That's it, in my opinion, you should be able to do most of what you want with these basic principles. I often write about Next.js. Please refer to [my Next.js articles](https://www.davebitter.com/tags/next-js) as well as the [Next.js documentation](https://nextjs.org/docs) if you are interested in going a bit deeper in the matter.

Finally, you can have a look at [my personal Next.js boilerplate](https://github.com/DaveBitter/next-boilerplate) based on this which includes all the things you might want to add like unit tests with [Jest](https://jestjs.io/) and [Enzyme](https://github.com/enzymejs/enzyme), [Storybook](https://storybook.js.org/), linting and more.

A simple, yet detailed introduction to Next.js

As a heads-up, I won't be going over how to build things like pages in [Next.js](https://nextjs.org/), but rather focus on the generation techniques. If you're unfamiliar with Next.js, please refer to their documentation.
## SSR/SSG versus CSR
We need to have a look at server-side rendering (SSR) and static site generation (SSG) versus client-side rendering In order to understand what Next.js offers. If you are up to speed with this, you can skip over this section and go straight over to "Generating pages with Next.js".
### SSR
SSR is a technique where a request comes in, the server builds the HTML and responds with the final page. The great thing about SSR is that it's fast. The usually means great performance as more the server is most likely more powerful than your browser. An added upside is servers can cache these pages to serve to multiple users at the same time.
The downside is that the user has to make this roundtrip for every page which can end up with slower user experience. More on this later.
### SSG
Similar to SSR, SSG serves a build HTML page. The difference, however, is when this page is built. With SSR the page gets to build upon a request by a user. An SSG page is pre-build and deployed to a server. The server will always respond with the same page for every user. This makes it easy to cache and very performant.
### Dynamic routes
The downside comes when you have dynamic routes. For example, a blog might have hundreds of articles. The URL can be `/blog/article-1.html`, `/blog/article-2.html`, ` /blog/article-3.html` etcetera. Here you have two options; either go with SSR or build every page out during build time.
### CSR
Lastly, we can leverage the use of CSR. This type of rendering is what you see with default [React.js](https://reactjs.org/) applications. In essence, you serve an (empty) HTML page, the JavaScript bundle builds the page in the browser and updates the page when navigating without going to the server. These pages can be dynamic, as the SSG example as well.
The downside of doing this is having to wait on the JavaScript bundle, that can be rather large, to load, then to parse and finally to build the HTML for the page. The initial loading time is quite long, uses much data on the user's network and demands processing power from the user's potentially low-end device.
## Generating pages with Next.js
So which of these does Next.js leverage? Well, all of them. Next.js optimizes how pages are loaded with just a little help from the front-end developer. They allow you to mix and match based on your requirements. This makes page generation incredibly powerful, easy and quick. Let's have look at the tools at your disposal.
### SSR
Firstly, let's have a look at SSR ([docs]([https://nextjs.org/docs/api-reference/data-fetching/getInitialProps](https://nextjs.org/docs/api-reference/data-fetching/getInitialProps))). Next.js lets you export a special function from your page file called `getInitialProps`. In essence, this function:
* runs on the server and lets the developer get for instance data
* passes the returned object as a prop for the page
* renders the initial render on the server
* serves that HTML
* finally hydrates the front-end as soon as the React.js/Next.ts is loaded in the front-end.
```jsx
// Example of getInitialProps
...
ArticlePage.getInitialProps = (async { req, res }) => {
    const article = await fetchArticle(req.query.slug);

    return {
        article
    };
};
...
```
After that, every page navigation by the user will update the page through CSR. This combination is highly performant and offers the best of SSR and CSR.
### Serverless architecture
Shortly, I'd like to mention how you can host this server. Next.js allows you to either host a [Node.js](https://[nodejs.org](http://nodejs.org/) server where Next.js runs or make use of serverless functions for all the pages. The latter being more performant. You can read more about this in my blog [Implementing the latest web technologies to boost our blog](/articles/mirabeau-blog-latest-web-technologies).
### SSG
Even though using the Next.js SSR technique works great, there is another step we can take. Some pages might not change. The HTML will always be the same. This sounds like a better job for SSG. Luckily, Next.js detects whether you export a `getInitialProps`. If not, it will use SSG ([docs](https://nextjs.org/docs/api-reference/data-fetching/getInitialProps)) to generate your page during build time. This works out of the box.
You can still run a function before generating the page, but this only happens the one time during the build. Here, you fetch for instance some data and pass it as a prop for the page. To do this, you can export a function called `getStaticProps`.
```jsx
// Example of getStaticProps
...
export const getStaticProps: GetStaticProps = async context => {
    const article = await fetchArticle(req.query.slug);

    return {
        props: {
            article
        }
    };
}
...
```
### Dynamic routes
Sometimes though, pages might not change, but the URL is dynamic as with the blog example previously mentioned. So how do we generate all these pages during the build? Next.js thought about this. You can export a final function called `getStaticPaths` ([docs]([https://nextjs.org/docs/basic-features/data-fetching#getstaticpaths-static-generation](https://nextjs.org/docs/basic-features/data-fetching#getstaticpaths-static-generation)))this function allows you to return an object with paths. This is where you tell Next.js all the dynamic routes that it needs to build. For the blog example, here you would pass a list of all the articles that exist. Next.js then takes that list and generates an HTML page for every item.
```jsx
// Example of getStaticPaths
...
export const getStaticPaths = async () => {
    const articleSlugs = await fetchArticleSlugs();

    return {
        paths: articleSlugs
    };
}
...
```
## Joining forces
The combination of these different ways of generating pages is where Next.js shines. As shown, you can use these techniques for the use case you have. By being able to mix and match you always have the opportunity to choose the best way. Welcome to the future of Single Page Application development!

Next.js page generation

![Every great concept starts with a sketch](/img/articles/firebase-sketch.jpg)*Every great concept starts with a sketch*
## Weapons of choice
Usually, these ideas need two parts to be realised. Let's have a look at how I like to handle both front- and back-end to build a fully functioning and rapidly built prototype.
### Building the Front-end part
I've worked with [React.js](https://reactjs.org/) for years to build interactive applications. Although not needed for every project, it allows me to rapidly build prototypes or even production-level applications due to its [reactive behaviour](https://www.freecodecamp.org/news/how-to-bring-reactivity-into-react-with-states-exclude-redux-solution-4827d293dfc4/). Next (pun incoming) to that, [Next.js](https://nextjs.org/) takes away many of the downsides I used to find with React.js. You can read more about that in my article about [how I rebuild the Mirabeau blog from the ground up using Next.js, serverless and more](https://www.davebitter.com/articles/mirabeau-blog-latest-web-technologies).
### 'Building' the Back-end part
The back-end part is usually where the prototyping stops as it feels like a chore in the creative process. Sure, you can mock this part for the sake of prototyping, but getting across your idea works, in my opinion, best if a user can actually do all the things they want with as little mocked parts as possible.

In my search for an easy way to deal with authentication and databases, I came across [Firebase](https://firebase.google.com/) by Google. Firebase is a mobile and web application development platform developed by Firebase, Inc. in 2011, then acquired by Google in 2014.

So why Firebase? The platform offers many [features](https://firebase.google.com/products) for free to help you build whatever you want. I usually don't need all these features, but it allows me to pick just the parts I need.
#### Letting the users log in
Authentication is a ubiquitous part of any application nowadays. It allows me to store your preferences, data and more. Authentication is more than just logging in. I want to offer users to create, delete and update their account. Next to that, they should be able to recover their password, log in through social accounts, keep a session and more.

![Firebase login options](/img/articles/firebase-login.png)*Firebase login options*

This is quite a lot when you just want to build your community cat food recipe tinder-based prototype. Luckily, Firebase offers this and more to you straight out of the box. Setting it up is as easy as flipping a few switches in the Firebase dashboard, as seen above, and implementing the logic in your prototype with the easy-to-use [Firebase SDK](https://firebase.google.com/docs/reference).
#### Storing data
Let's say you are building the community cat food recipe tinder-based prototype and the user has created an account and logged in. They might want to store recipes, upload pictures and look at other peoples recipes. Firebase has two types of databases in store. There is a more traditional [REST](https://restfulapi.net/) based database and a reactive 'real-time' database. The difference being the 'real-time' database allowing me to listen for any changes in the database and update the user interface accordingly.

![Firebase database](/img/articles/firebase-database.png)*Firebase database*

Finally, I might want to store pictures to go with my recipes. Firebase offers [storing of media files](https://firebase.google.com/products/storage) as well. As all mentioned features, there is a limit in the free version, but it is high enough for your prototypes sake.
### Tying it all together
Cool, we have a React.js front-end and a Firebase back-end. Now it's time to tie it together into a fully functioning prototype. I usually tend to go for the 'real-time' database since React.js is a perfect match due to its reactive nature. Below you can see how I implemented data fetching between React.js and Firebase using the Firebase SDK.

![React.js and Firebase data flow](/img/articles/firebase-react-flow.png)*React.js and Firebase data flow*

The upside of handling your data fetching this way is having only one version of your data. Normally, I send an update to the database and update my user interface when the update went through successfully. I don't have to do this with this way of updating. I listen to the database for changes. Whenever I need to update something I send the update to the database and my listener will automatically get the updated document from Firebase.
## Practice what you preach
I know this might sound like a paid advertisement by Firebase. I promise you it's not. I've built several prototypes or small applications doing this. Some examples are the internal tool I build to to see all presentations for [the Mirabeau weekly inspiration session event](https://blog.mirabeau.nl/en/articles/The_Best_Is_Yet_To_Come_one_year_of_love_and_pride/5soiFSn4y5HzO3J3nHhtmq) and the Mirabeau ski event signup application. A colleague used it to build a visitor registration tool after showing him what Firebase can do for you.

![The Best Is Yet To Come application built with Firebase](/img/articles/firebase-tbiytc.jpg)*The Best Is Yet To Come application built with Firebase*

![Company ski event application built with Firebase](/img/articles/firebase-apres-business.jpg)*Company ski event application built with Firebase*

## Break through limitations
I've often limited my creativity by stopping at the concept phase due to technical requirements. Using the previously mentioned tools helped me to break through these limitations and start creating. I'm now able to quickly setup a new project with all the requirements I might have. Let's keep creating, we've got the tools available!

How to take an idea from sketch to a fully functioning and rapidly built prototype?

## Disclaimer: I love native apps
This is not an "I develop for the web, so the web is the best" type of article. I love native apps. The user experience is often better than their web counterparts. This becomes apparent in, for instance, eCommerce websites. Often, they feel bloated, sluggish and don't provide the same 'feel' and functionalities as the native variant.
## So, why go for web apps?
I strongly believe that web counter-parts can be equally as good, if not better. The reason why I love the web so much is due to its accessibility. If developed well, the web is accessible on every device with a web browser.
I have a top-of-the-line tablet that's about 3 years old. It's well performant, receives frequent updates and runs very well. You'd say I'll be able to run new apps. Well, no. I quite often am not able to download or view an app because of three possible reasons:
### "This item isn't available in your country"
I live in the Netherlands. Generally, we are on pretty much good terms with any country of legislation. Sure, web apps can be blocked as well in certain countries for several reasons, but generally, it is accessible. Why can't native apps be?
### "This app is not optimized for your device"
Why? The hardware is capable, the OS is up to date. This is a problem that the web inherently doesn't have. If built well, the web apps scale to every resolution and offer a working solution through 'progressive enhancement'.
### "Only for iOS"
This one gets me more than anything. Often, new applications are just available for one OS and sometimes even starting from a specific version. This excludes a large number of potential users just because they don't have the specific OS and version you support.

![This item isn't available in your country.](/img/articles/app-unavailable.jpg)*This item isn't available in your country.*

## Can it provide the same features of native apps?
So, the web has these upsides, but can it provide the same features of native apps? If not, though luck. Well, it will surprise you how much the web can do and provide. Let's go over a few.
### Performance
One of the big issues I have with web apps that drive me to their native counter-parts is performance. This is the responsibility of the developers. For the sake of the argument, let's take two types of applications.
#### eCommerce
There is no, and I repeat, NO excuse for sluggish eCommerce web apps in this day and age. There is a wide variety of tools for developers to build highly performant web apps. For example, a big issue with web apps is the use of front-end SPA frameworks like [React.js](https://reactjs.org/). Although build for fast web apps, it contributes to one of the biggest factors of sluggish websites which are resources. The bundle that needs to be loaded can be quite big. This issue is however solved with frameworks like [Next.js](https://nextjs.org/). You can read more in my article on [Implementing the latest web technologies to boost the Mirabeau blog](https://www.davebitter.com/articles/mirabeau-blog-latest-web-technologies). Combine this with caching of data and you go a long way in building a performance eCommerce web app.
#### Intensive games
This is where native apps are better suited on first sight. The native app can make use of all the hardware possibilities of the device and ensure great performance. The web is getting better at this through techniques like [WebAssembly](https://webassembly.org/) can solve many issues.
### Offline support
[Progressive Web Apps](https://web.dev/progressive-web-apps/) (PWA) and more explicitly [WebWorkers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers). bring offline support to the web. This ensures that, like native apps, PWas can always be loaded, cache resources and offer functionality even without an active internet connection.
![Twitter PWA](/img/articles/twitter-pwa.jpg)*Twitter PWA*
### Home screen presence
The great thing about native apps is the presence on the home screen. It is easy for users to come back to the application when they need to. It takes a bit more effort to open a browser and then go to the web app. PWAs solve this problem. One of the core functionalities is to allow the user to add the PWA to their home screen.
A great bonus is to be able to install the PWA to desktops as well to run as a destop app.
### Omni-platform by default
Native and web apps run into the same issues regarding OS (and browser). There is no way around this, but the web has a big advantage over native. Even though the user might use a different OS or browser than others, it will still be able to use the code you wrote. This is possible for native apps by using something like React Native or by wrapping a web app in a shell for native. Being able to have a Omni-platform app out of the box is a great way to ensure accessibility for every user.
### iOS App Store/Google Play store/Windows store presence
One of the lesser know features of PWAs is the ability to add your app to the iOS App Store/Google Play store/Windows store. This opens up a whole way to be discovered by potential users. For a more detailed look head over to [this](https://www.freecodecamp.org/news/i-built-a-pwa-and-published-it-in-3-app-stores-heres-what-i-learned-7cb3f56daf9b/) article explaining the possibilities and experience.
![Twitter PWA in Google Play Store](/img/articles/twitter-google-play-store.jpeg)*Twitter PWA in Google Play Store*
### Version updates
One of the downsides I see with native apps is the requirement to first install and then keeping the app up to date. Again, this is inherently not an issue with the web. Releasing an update will always be immediately available to the user.
### Notifications
Another great possibility of native apps is notifications. This feature is immensely valuable to trigger users to use your app. This, again, is supported when using PWAs. Obviously, like native apps, this should be used unobtrusively.
### And more
You get the picture by now. The web offers many of the functionalities that native does and brings more upsides to the table. Things like splash screens, BlueTooth support, webcam access and more are available in the browser. The web is one mighty machine.
## Successful web apps are not just about technological possibilities
That was a lot of technical information, but let's step back a bit and look at the 'look and feel'. Often, web apps are turned into PWAs on a technical level. Although this is a good start, there is a big part we aren't covering yet. The look and feel of a native app versus a web app are immense. Besides platform-specific styles and interaction patterns, there is a fundamentally different design pattern.
Native apps don't scroll. Well, they do, but very specific. On the web, it is custom to have multiple sections on a page. You might have a header, latest posts, a contact form and end with a footer. Native apps do have this sometimes, but mostly 'tuck away' sections. Generally, lists and content are scrollable. Forms and other standalone sections are often available after a user interaction on, for instance, a button.
![Load flow with app shell](/img/articles/appshell.png)*Load flow with app shell*
Next to this, native apps often have a shell with a top- and bottom bar with a place for the content in the middle. This 'shell' is always available and loaded first. Content will be loaded second.
Naturally, there is way more that goes into designing an app versus a website, but this exemplifies how crucial the design is when building a PWA.
## Which companys use PWAs?
A lot actually. Here are some of the examples companies that use PWAs:
* Starbucks
* Housing.com
* Digikala
* Flipboard
* Soundslice
* 2048 Game
* MakeMyTrip
* Uber
* Padpiper
* Pinterest
* Yummly
* Spotify
## Which one should I choose and don't say "it depends"?
It depends. If the functionalities are available for the web, definitely! As I just mentioned, the web offers many advantages over native apps while offering many of the same functionalities. If you need that native app, go for that.
My goals are not to push web apps over native apps in some 'platform war'. Be open-minded for both and be up to speed with the possibilities. In the end, our goals should be to offer the user with the best product. Personal preference or other peoples opinion matter, but are not leading. With both platforms, there is only one question you should ask yourself.
> How can I help the person using this in the best way?

You might not need a native app

## The issue with SEO in SPAs
The issue with SEO in SPAs has to do with where the page gets built or rendered. The rise of client-side SPA frameworks like [React.js](https://reactjs.org/), [Vue.js](https://vuejs.org/) and others caused an issue I didn't encounter before with server-side frameworks.
In short, there are two ways of rendering a page. Traditionally, the page gets rendered on the server. As a result, bots like [GoogleBot](https://yoast.com/what-is-googlebot/) will visit your page, read the content and [meta tags](https://www.webpresencesolutions.net/metadata-meta-tags-web-page-titles-page-descriptions-explained/) of the page and use that information for Googles search engine. SPA frameworks work a little different. Normally, a blank page is loaded. The framework will build the entire page client-side as soon as the JavaScript bundle is loaded. Besides potential performance issues, this raised a new problem. Bots will visit a page, find a blank page and return that information.
## So is Google just ignoring this?
Nope, they are trying their best to deal with this issue. As you can read [here](https://webmasters.googleblog.com/2014/05/understanding-web-pages-better.html), Google can execute JavaScript to build the page and then get the content and metadata. So, problem fixed? Well, not entirely. They mention that _sometimes things don't go perfectly during rendering, which may negatively impact search results for your site_. Google is providing tools for you to debug and see what causes issues.
> Building applications for the web is hard enough.
## Do I want to deal with this?
Well, no. Building applications for the web is hard enough. At the start, I mentioned that I wanted to solve this issue with modern tools and techniques I love to use. Let's pick React.js as the SPA framework. I love to use React.js in combination with [Next.js](https://nextjs.org/) to solve many of the issues with SPA frameworks. You can read up on that in my article on [Implementing the latest web technologies to boost the Mirabeau blog](/articles/mirabeau-blog-latest-web-technologies).
![React.js and Next.js](//images.ctfassets.net/w4dg3cjf42ew/5JdNrYGW2SBKmIoT38kqz0/80b019ca3d6e00871b3603f842814b0c/CDFEF415-123A-4D0E-85AD-BB3B32A0B3A1-min.png)*React.js and Next.js working together*

I will leverage the solution that Next.js offers regarding server-side rendering. This solves the issue in the old fashioned way. The page will be rendered on the server, GoogleBot will get the content and metadata and I will have solved my problem.
## Taking it a bit further
I can call it a day now, but let's look at how I took it a bit further when building the  the [Mirabeau blog](blog.mirabeau.nl). The content, [semantically written](https://html.com/semantic-markup/), is received by the GoogleBot. The metadata implementation needs to be done by me. In theory, it is simple. I have a set of [basic meta tags](https://support.google.com/webmasters/answer/79812?hl=en) that I update for every page. An article page may use the title and description of the article while the home page uses the name of the blog and the tagline.
In the case of Next.js, I load a component called `SiteMeta` the head element of the page using the Next.js `head` component like so:
![Simplified code snippet of loading SiteMeta component](//images.ctfassets.net/w4dg3cjf42ew/1ux4A6clBzDNpDdqYdoc7I/a8cd4433d13cb83b6e822f057bd2a968/meta-tags.png)*Simplified code snippet of loading SiteMeta component*
For an article, for instance, I set the title tag to the title of the article. I then load the `SiteMeta` component that sets a couple more tags. This is already starting to look more like it. The meta tags are being added dynamically based on the article and locale. Here you can see a simplified version:
![Simplified code snippet of SiteMeta component](//images.ctfassets.net/w4dg3cjf42ew/4RkWDgVEekZ7QlDK2CxE6A/7a00962575163a0ebadabbbdcf3418f1/site-meta.png)*Simplified code snippet of SiteMeta component*
## Taking it even further by taking social media into account
Social media is vital for the reach of your blog. Naturally, we need to spend some time here to have the best chance of getting people to click the link to the article.
### OpenGraph
I can specify the page even further by using standards with [Open Graph](https://ogp.me/). It’s a protocol that is widely supported by all major social media websites and crawlers. I use Open Graph to create semantical tags for SEO and sharing. For example, I can provide a title, image and summary for an article page specifically aimed towards social media sites. I now load a second component called `SiteOpenGraphTags` in the head element.
![Simplified code snippet of loading OpenGraphTags component](//images.ctfassets.net/w4dg3cjf42ew/7b71NBLQBlK5VK9x0nPcEn/36b05ab8de8b8ed3b10078f091bd2e87/open-graph-tags.png)*Simplified code snippet of loading OpenGraphTags component*
Here we can set additional tags according to the Open Graph specification. Below you find a simplified version that for instance sets tags specific for [Twitter cards](https://developer.twitter.com/en/docs/tweets/optimize-with-cards/guides/getting-started).
![Simplified code snippet of OpenGraphTags component](//images.ctfassets.net/w4dg3cjf42ew/6RHSmvijxYUhoyYCaBMysX/9bf84bed3b1183bb029536532b786bf2/site-open-graph.png)*Simplified code snippet of OpenGraphTags component*
## The result
When I share an article to social media I can now see that it shows a custom title, description and image that I can set in the CMS used. A social media card might look something like:
![Mirabeau blog social card example](//images.ctfassets.net/w4dg3cjf42ew/6tAjqUcClkipkwktwCRzhY/3252230919b7c43d4070cf55adccea10/mira-blog-seo.jpg)*Mirabeau blog social card example*
## Case: Lely Used
Sure, a blog is relatively simple. Often, we need to put in a bit more work. [Lely used](https://used.lely.com/en/why-used) is a platform I build similarly. The platform consists of 'content pages', a product search page and product detail pages. The goal is to sell products. As a result, detail pages are often shared on social media platforms. The implementation for many of the pages is the same, but as an article page on a blog, there is a product page on an e-commerce platform. I looked into setting dynamic tags specific to a product. Below you can see the response of a product detail page.
![Lely Used social card example](//images.ctfassets.net/w4dg3cjf42ew/2SsaB4tQB3QXMmenbqmonb/9249a5987f901dbe43df60740484307d/lely-used-seo.jpg)*Lely Used social card example*
I've added quite a bit of information in this card. You can see the:
- platform
- model
- location
- build-year
- localised currency and amount (price)
- specifications
- image of product
- content localised based on locale in link
These tags are being used both for sharing the product and by bots like GoogleBot.
## Looking back
SPA frameworks have an impact on SEO. Although Google is working hard an this, there are still several issues. I can solve all issues by using server-side rendering with a framework like Next.js. I can use React.js to dynamically load regular meta tags and Open Graph tags in the head element of the page. I can then fully customise the tags based on the what kind of page it is. This is my current way of handling SEO with SPA frameworks. What is yours?

How can I handle SEO in my Single-page application?

I am a Senior Front-end Consultant, Developer Advocate, and Google Developer Expert for Web. Here, you can find my resume, a collection of my articles covering a wide range of topics and get in contact.

Going for React.js can introduce quite a few new challenges like server-side render support, performance, SEO and more. In this talk, I go over how I solve those challenges by using Next.js, "The React Framework for Production" to progressively enhance your SPA.

SPA

Articles

A simple, yet detailed introduction to Next.js

Next.js page generation

How to take an idea from sketch to a fully functioning and rapidly built prototype?

You might not need a native app

How can I handle SEO in my Single-page application?

Talks

Building SPA the responsible way