Before anything I want to say that I am not a web developer. In my IT life and experiments I always tried to stay as far as possible to anything that would be running with Node.js. Now, I am aiming to post more on this blog, and hopefully I will, if I take the time to do so and do things that are worth sharing. This post describes my discovery of Next.js and the Node environment (and it is disappointing).
So as it happens once in a while I was thinking that the current way my blog was built was not satisfying to me. Indeed, I first had a homemade solution to generate HTML from Markdown files, that I then switched to the Zola static site engine, in hope of easing the process. But still, I felt like Zola forced me to do things I didn't agree with, and I still had to hack my way around to do what I wanted. So, what technologies should I use for my new blog? Probably I should reinvent the wheel and make my own solution using Python. And if I ever need my blog not to be static I can add some Flask to it. No, let's take this as an opportunity to try the modern web technologies. According to internet research, job offers and social medias, the true web developer should use modern technologies such as React, Vue.js, Svelte, or what else. But the true cool kid should use Next.js, there is apparently no debate on that. Indeed, many well known big companies use it, as you can see on their showcase page: https://nextjs.org/showcase.
For those not aware, Next.js is a React framework which eases web application development process. Some of its selling points are speed, scalability, SEO-friendliness, Server Side Rendering (SSR) and/or Static Site Generation (SSG).
First impressions
After a few hours of development and reading documentation and looking up for weird errors, my blog generation was rewritten properly. Regarding the development process I have to say that React components makes it really easy to reuse code around. Of course I would use TailwindCSS to style my website because that's what modern people do, no questions asked, and likewise it eases the process of fighting with CSS. If you just use the classes exposed to you (and of course have a basic understanding of CSS) it seems like things could not go wrong, and makes the development process faster. Put all of that in Next.js and I now have a website that I can either serve using Next.js server, or even just export as a static website. However, since I am more of a "low level" programmer, I was wondering about the impact of these technologies on the size and speed of websites. Since everybody uses it, it must be fine, right? Right? (Anakin and Padme meme) While I used to have no JavaScript on my previous blog, now you will have to download hundreds of KBytes of JavaScript.
Google PageSpeed Insights
To measure the efficiency of my new website, I will use Google's https://pagespeed.web.dev/ which will crawl my website and provide information regarding the rendering process of it. Here is the first result I got:
Results of PageSpeed for the initial version of this blog
Including this advice:
Avoid serving legacy JavaScript to modern browsers (Est savings of 12 KiB) Polyfills and transforms enable legacy browsers to use new JavaScript features. However, many aren't necessary for modern browsers. Consider modifying your JavaScript build process to not transpile Baseline features, unless you know you must support legacy browsers. Learn why most sites can deploy ES6+ code without transpiling
If my understanding is right, Next.js provides a way for old browsers to handle new browsers API. But apparently while it should provide it only to old browsers, it seems even modern browsers download this useless extra JavaScript. I did not dig too much into it.
But wait a minute, what is a typical Next.js website result on PageSpeed? Let's take a look at the official Next.js website, and the company working on it Vercel:
Results of PageSpeed for vercel.com
Results of PageSpeed for nextjs.org
You can take a look at the results yourself:
- https://pagespeed.web.dev/analysis/https-nextjs-org/16zo3xdaa4?form_factor=mobile
- https://pagespeed.web.dev/analysis/https-vercel-com/u748nusk00?form_factor=mobile
Frankly, this is quite hilarious. I wish I had checked this first before switching my blog to it, although nextjs.org has a better "Speed Index" than me and I have no clue why.
To be completely honest, the results are likely bad because of the first load. Once all the JS is downloaded the whole website should be much faster. But still, it hurts my heart a bit. However if you have tips or knowledge to share regarding that topic, feel free to educate me, that's appreciated!
Next.js, is it that good?
Random caching issues
Next.js comes in with a development server that you can run using npm run dev. That's pretty cool because it will inject a hot-reload script to your pages, and display server and client stack traces in your browser, so that helps with development. But sometimes you will bump into an error that quite doesn't make sense regarding your current changes, but restarting the dev server fixes it. You could spend hours trying to understand the bug until you realise it is just a stupid caching issue. Not so great.
Debugging hell
This is not related to Next.js only, more to the whole Node.js ecosystem I think, but around half of the time the stack traces are useless due to the bundling of things. You will get stacktraces full of compressed JavaScript which are in no way helpful, because all functions and variables names are modified, good luck with that. It has happened to me with the development server, and I could not find a way to have a clean stacktrace, I just revert my changes until it works.
Dependencies hell (1)
Of course when starting a Next.js project, it prompts you if you want to use TypeScript over JavaScript, and as a sane person you would of course agree to this because typing is good. But sooner or later, you have to fight with the TypeScript compiler. But the worst kind of fight, is when your dependencies are not written in TypeScript and make the compiler unhappy themselves. Here is an example where I try to use the negotiator module, but there is no type definition for it.
Type error: Could not find a declaration file for module 'negotiator'. '/work/xark.es/node_modules/negotiator/index.js' implicitly has an 'any' type.
Try `npm i --save-dev @types/negotiator` if it exists or add a new declaration (.d.ts) file containing `declare module 'negotiator';`
1 | import { match } from '@formatjs/intl-localematcher'
> 2 | import Negotiator from 'negotiator'
| ^
So what, do I have to read this module code and guess the type myself, add an explicit cast to any? Should I just ditch TypeScript and move all my project to JavaScript again? Surely none of this, I will just add a // @ts-ignore comment above the line, as I would add an unsafe {} block to my Rust code, and everybody's happy.
Dependencies hell (2)
If you add a dependency to your project that depends on a different version of React as your current version of Next.js, I noticed various things could go wrong.
- It will not warn you about it (I never ever got any warning from npm stating versions mismatch)
- It may ship the whole out-of-date module (here React), resulting in a 1MB bundle for your new 200 LoC dependency (I don't know if this is a general thing or if it is an issue with the package itself)
- It will yield runtime errors
Finally, all errors are fixed. Of course bleeding edge modern web technologies never fail to disappoint and greet you with a NaN somewhere. Peak state of the art.
The aftermath
Do I regret switching my website to Next.js? Yes because now it is bloated and I hate bloat. No because I learned things along the way, and still managed to complete my initial task which was getting a better control of my blog. So I:
- Learned more about Node.js environment
- Learned how to use React and how it helps frontend development
- Learned how to use TailwindCSS
- Learned how to deploy a Node.js app (although cool kids don't really do that, they just use a hosting provider like Vercel and let the magic happen)
- Got rid of the limitations of my previous blog generator
- Downloaded almost 300 Node modules to… generate a static website (
du -h node_modules | tail -n1returns403M node_modules) - Added some hundreds of KB of more or less useful Javascript to my website (mostly useless if you want my opinion)
- Got the ability to handle a conversation about web technologies with the cool kids
I am not disappointed in this journey, I am still convinced the web is really a mess. For sure there are tradeoffs to be made between ease of development and performance. But it seems to me the latter has really been neglected.