This site just migrated from Gatsby to NextJS. If every coder today leans toward NextJs versus Gatsby, now I don't feel this so obvious.
<hr>
<h2>Gatsby and its plugins</h2>
I want to write more premium content on this site, so I was motivated to upgrade a few items,
when appeared at my first <code>gatsby develop</code> :
<img src="./images/gatsby-plugin-bug.png" alt="Bug du plugin gatsby">
...last bug I wanted to see. Not on my code, but a bug about a plugin and the wrong version of
one of its dependencies.
<h2>Gatsby versus NextJS ?</h2>
The site you are reading now just migrated from Gatsby toward NextJS.
Those two technologies embrace the JAM stack and are static sites generators, which allow
to display very fastly web pages with a maximum of security. Wordpress killers.
But does it allow fast improvements ?
<h2>DX: Developer Experience</h2>
This capability of improving fastly and nicely an application is named Developer Experience. Now
that developers are more valuated than users, it has its importance.
DX relies on development speed, but even more on the pleasure of coding. This is impacted by many
factors that won't be described there, but you can understand that pleasure is important for
such a not monetized web site.
And, in terms of pleasure, Gatsby and and GraphQL are terrible. My opinion, and opinions of many.
Every type of page is affected by a huge, unpleasant, partly copy/pasted GraphQL query.
<img src="./images/graph-ql-blog.png" alt="graphql query">
That is not very readable, and moreover the tooling is far from excellent.
Even worst, you must add many plugins, where each plugin wrap a lib adapted to Gatsby structure and GraphQL
queries. The bug I had above appeared on one of this plugin, not updated quickly enough. Classic and predictable.
<h2>Programming language</h2>
Both Gatsby and NextJS use React JS, but only one command line argument quickly adds Typescript to NextJS.
Typescript is now a must for most developers.
You can still use typescript with Gatsby. I used an <a href="https://github.com/antoinerousseau/gatsby-starter-antoine/">unofficial starter kit</a>
proposed by <a href="https://antoine.rousseau.im">Antoine Rousseau</a> for Gatsby.
<h2>CSS Framework</h2>
NextJS proposes by default CSS Modules. Nothing is proposed by Gatsby, which is not that bad.
Both work well with Sass.
I used very easily Styled Components with Gatsby, and it would be that easy also with NextJS.
CSS Modules didn't bring me more, it's a question of taste and coder experience.
<h2>Deployment ease</h2>
Vercel, which is an Heroku competitor, is the NextJS editor and proposes in its documentation
a path to deploy in a few steps the website on Vercel servers.
The JAM stack also contains api capabilities. Your website is not read-only, and can create actions.
Vercel proposes an api from React JS front to Vercel servers.
However pricing from Vercel is not obvious to catch. Also I don't think it's always a good idea to be tied
to an editor. If the code gets slowly locked, I would have more awareness on quitting NextJS being outside
Vercel cocoon. I needed around 20 hours to move from Gatsby to NextJS, so I may reverse it quickly as long
as I don't call too much proprietary Vercel apis.
<h3>Strange build for NextJS</h3>
It took 10 seconds to my new edge computer to build NextJS website, and 16 seconds with Gatsby. As this
site is very small, those are not representative figures.
I expected both technologies to create basic html. It happens that structures were different. Here is the one generated by Gatsby.
<img src="./images/structure-gatsby.png" alt="Generation Gatsby">
A browser going to <code>/page/2/</code> will load <code>/page/2/index.html</code> file with a basic server.
Generation is significantly different with NextJS:
<img src="./images/structure-next.png" alt="Generation NextJS">
So after the command <code>next build &#x26;&#x26; next export</code>, I deployed the site with a local server (<code>php -S localhost:8888</code>), and going directly
to the second page (<code>/page/2</code>), we have an awful 404 error. I should call <code>/page/2.html</code> which is not a sexy url.
If I first go to the homepage, then on the second page, it will work as the React application will display content loaded from
some Json.
<img src="./images/404.png" alt="404 sur NextJS">
Thought I followed the documentation with nothing fancy, it may be a configuration problem, but it's worrying if it's not the case.
Nevertheless, like my old Gatsby site, I used Netlify who deployed everything without any problem,
nor any 404 error page.
<h2>Site publication</h2>
The change of DNS was done quickly. The roadmap is written and next items are:
<ul>
<li>The page to present the trainings</li>
<li>SEO: some headers and the sitemap</li>
<li>An API to record the emails of a newsletter</li>
</ul>
The point of the sitemap is interesting for the comparison between Gatsby versus NextJS. It is about transforming all the pages
and articles to generate an XML. Using Gatsby, you would have to start from some sort of plugin or graphQL query.
With NextJS, I already have access to a <code>Post</code> type object array representing the pages that will need to be mapped to XML.
It's not done, but I have a clear idea of where to start.
In conclusion, Gatsby is missing an official version with typescript and without GraphQL to compete.
Since the migration, the site is just as fast, the updates are more regular, the articles more frequents,
which was the desired goal.

Why I made the migration from Gatsby toward NextJS

Le bug de trop de Gatsby et ses plugins, un mois plus tard, je migre ce site en NextJS... Si aujourd'hui chaque codeur semble préférer NextJs à Gatsby, le choix n'est
rétrospectivement pas si évident.
<hr>
<h2>Gatsby et ses plugins</h2>
Je veux maintenant écrire bien plus de contenu à haute valeur sur ce site,
et j'étais donc décidé à améliorer deux-trois éléments, quand apparu à mon premier <code>gatsby develop</code> :
<img src="./images/gatsby-plugin-bug.png" alt="Bug du plugin gatsby">
...le bug de trop. Non pas sur mon code, mais un bug qui parle de plugin
et de mauvaise version de l'une de ses dépendances.
<h2>Gatsby ou NextJS ?</h2>
Le site que vous lisez actuellement vient de migrer de Gatsby vers NextJS.
Ces deux technologies embrassant la JAM Stack sont des Static site generators, ce qui permet
d'afficher très rapidement des pages web, avec un maximum de sécurité. L'opposé de Wordpress.
Mais est-ce que cela permet de coder rapidement ?
<h2>DX: Experience de développement</h2>
Cette capacité à faire progresser rapidement et sympathiquement une application a son petit anglicisme
barbare : la Developer Experience, aka DX. Maintenant que les développeurs sont plus précieux
que les utilisateurs, la DX a son importance.
La DX joue sur la rapidité de développement, mais aussi sur le
plaisir à coder, ce qui est en fait essentiel pour un projet non monétisé comme celui-là.
Et pour moi comme beaucoup d'autre, Gatsby et GraphQL sont catastrophiques. Chaque type de page
se retrouve affublée d'une requête GraphQL plus ou moins longue et qui se ressemblent.
<img src="./images/graph-ql-blog.png" alt="graphql query">
Non seulement, c'est peu lisible, mais en plus l'outillage associé n'est pas excellent.
De plus il faut enchaîner plugins sur plugins. Et donc l'utilisation d'une bibliothèque adaptée à Gatsby et
,problème parfois superposé, requêtable en GraphQL. Le problème qui m'est survenu était qu'un de ces plugin n'était pas mis
à jour assez vite. Classique et prévisible.
<h2>Langage de programmation</h2>
Les deux technologies utilisent React JS, mais il suffit d'un argument simple pour initialiser NextJS avec Typescript.
Avec un peu d'habitude, Typescript est un must pour la plupart des dévelopeurs.
Typescript est toutefois utilisable avec Gatsby. J'ai utilisé
un <a href="https://github.com/antoinerousseau/gatsby-starter-antoine/">starter kit non officiel</a> proposé
par <a href="https://antoine.rousseau.im">Antoine Rousseau</a> pour Gatsby.
<h2>Framework CSS</h2>
NextJS propose les CSS Modules par défaut. Rien n'est proposé par Gatsby, ce qui n'est pas plus mal.
Les deux frameworks fonctionnent bien avec Sass.
J'avais utilisé facilement les Styled Components avec Gatsby, et ce serait aussi simple à mettre en place avec NextJS.
En comparaison, les CSS Modules ne m'ont rien apporté, c'est vraiment une question de goût et d'expérience.
<h2>Simplicité de déploiement</h2>
Vercel, que l'on peut classer comme un concurrent de Heroku, est l'éditeur de NextJS.
La documentation propose donc logiquement de déployer en quelques instants
le site sur les serveurs de Vercel.
Mais d'une part le pricing de Vercel n'est pas clair, d'autre part je pense qu'il n'est pas bon de trop se nouer avec un éditeur.
Si le code se verouille doucement, je serai plus alerte pour sortir de Next JS en étant hors du cocon de Vercel.
<h3>Build étrange pour Next JS</h3>
Il me faut 10 secondes pour builder NextJS, où Gatsby prend 16 secondes. Ce n'est pas représentatif vu la petite taille du site.
En théorie, ces deux build doivent créer un site avec du html basique. Or les structures sont différentes. Voici celle générée par
Gatsby
<img src="./images/structure-gatsby.png" alt="Génération Gatsby">
Pour Gatsby, il faut se rendre sur <code>/page/2/</code> pour qu'un serveur très standard va charger le fichier <code>/page/2/index.html</code>
La génération est différente pour Next JS :
<img src="./images/structure-next.png" alt="Génération NextJS">
Si bien qu'après avoir fait la commande <code>next build &#x26;&#x26; next export</code>, j'ai deployé le site avec un serveur local
(<code>php -S localhost:8888</code>), et
si l'on se rend immédiatement à la seconde page <code>/page/2</code>, nous avons un affreux 404. Il faudrait charger
<code>/page/2.html</code>, ce qui n'est pas une url sexy.
Si je passe par le homepage, puis navigue vers la 2e page,
je n'ai pas de problème car l'application affiche le contenu issu d'un Json chargé via Ajax.
<img src="./images/404.png" alt="404 sur NextJS">
Peut-être un problème de configuration, mais c'est inquiétant si ce n'est pas le cas.
Le déploiement sous Netlify se fait pourtant sans soucis et le probleme de 404 n'est pas rencontré.
<h2>Publication du site</h2>
Le changement des DNS s'est fait rapidement. La roadmap est écrite et les prochains objectifs sont :
<ul>
<li>La page pour presenter les formations</li>
<li>SEO : quelques headers et le sitemap</li>
<li>Une api pour enregister les emails d'une newsletter</li>
</ul>
Le point du sitemap est intéressant pour la comparaison entre Gatsby ou NextJS. Il s'agit de transformer l'ensemble des pages
et articles pour générer un XML. En utilisant Gatsby, il faudrait partir de je ne sais quel plugin ou requête graphQL.
Avec NextJS j'ai déjà accès un tableau d'objet de type <code>Post</code> représentant les pages qu'il faudra mapper vers du XML.
Ce n'est pas fait, mais j'ai une vision claire de par où commencer.
En conclusion, il manque à Gatsby de proposer une version officielle avec typescript et sans graphQl pour rivaliser.
Depuis la migration, le site est tout aussi rapide, les mises à jour sont plus régulières, les articles plus fréquents,
ce qui était bien le but recherché.

Why I made the migration from Gatsby toward NextJS

Pourquoi j'ai migré de Gatsby vers NextJS