We are yet living in an age of the AI slop avalanche, which we're under constant pressure since 2025 and release of ChatGPT. You may wonder, why to even bother about creating a new blog page in 2026? Moreover, event to mention of building a webpage using yet some another fancy frontend framework. In most cases, this sounds completely irrational and click bait, because in 2026 many says the AI chat-bots can build anything in few seconds, right? I really hate this argument, mostly because it is partly true and partly false - let me explain.Yes, AI can help you build a lot of things very rapidly, especially in the pace you will never be able to keep up as a human being. But the LLM are not an intelligent thing, yet. This is just a fancy statistical engine that can accurately predict next new word. They train the software based on scraping whole internet - websites, books, video and repositories to mechanically teach LLM to get better answers.Looking from an engineering perspective, maintenance of that and rapidly built "thing" will eventually come with a cost - every reasonable engineer knows this! This cost will be eventually the time of people that will have to be paid by the business to maintain it. Also, any reasonable person knows that time == money1, and furthermore also every good engineer knows that code is liability - it does not come for free. LLMs can produce lot of code, but they do not care or feel responsible for anything.Well, to answer the question: yes, you can build very rapidly, but also no, you cannot fully rely on it yet, if you want to your system (or product) to sustain for a longer period of time, and not suddenly crash, you'll still need someone, who may care about "how you do, what you do".I've built and maintain my blog across many years. I tried many different technologies to help me achieving my weekly writings easier, and moreover making this content better accessible to you, my audience. In years, I've tried many different ways from building websites. Starting from simple static HTML pages, through multiple technologies server-side like PHP (WordPress, Drupal), Ruby (), Python (Django), Nodejs (), Go (), and client-side: Angular, React, even Flash. At this point in time there could be probably many, many more different technologies I could have tried, but I don't remember them now.
For everyone, there is a different set of cases and needs to build a blog. Some people prefer speed and simplicity, like Hugo, some prefer convenience & free deployment like with Jekyll on GitHub. I think the technologies that I liked the most for blogging were exactly those, Jekyll and Hugo. Jekyll is really good as simple blog engine that can by default run as a static page from a GitHub (No need for compilation if you use GitHub, you just push code to a repository and the code automatically updates on your GitHub page <myname>.github.io).
Hugo on the other side is amazingly quick for building blogs with lot of content. Literally, you can compile a blog with thousand of pages in milliseconds. Simple blog structure, and you can add new posts with ease. Sounds great!
The thing is, I tried many technologies and approaches, and what I noticed is when you build simple website like personal blog, especially from a software engineer perspective, you most likely don't care about all the convenience. For example opening an admin panel like in Wordpress (or Django) to add a new post is fine, but maintaining the content you produce there is a hell. Beautiful admin panels are irrelevant for me, although they are relevant for your end-customers, or people who build their products to run their business fast, because it makes their every day actions easier!
I am a humble developer, not yet in the need to rush with releases for my products in order to deliver them to my customers asap. At the moment, I enjoy to see what I am writing. Simply by opening a file, and to have a control over what I am building. I am currently happy, when I am able to easily maintain my software by editing a source file, and if the winds of technologies will change (aka new industrial era will come) I will be ready for it. Experimenting with is another thing that is essential for me because this is also the way how I learn new things - by doing them myself.
This is great question. I think the huge selling point for me was the ability to have multiple rendering methods in one framework (SSR, SSG, and traditional client-side render). This is very appealing, especially when there is a need, you can choose a rendering strategy you need, and go further with that - or change it if there is a reason to do so. Another plus which talked to me more vividly (especially for nice blogging experience) is utilizing MDX and able to enhance the content with dedicated components, to make the site much more appealing and user-friendly. Maybe some business people, or public figures, may not find this as great solution4, but that is totally fine. Their needs may be much different, and focused in the direction of pure content creation. Therefore they use CMS, which hold their content produced over the years, but also allow to quickly refactor or push further with new content they produce each week. I didn't reach yet the point where I'm producing content every week, so in my case, the amount of new fresh content isn't so important as its quality. Therefore, I still value a manual creation of blog posts within the code editor, while still utilizing markdown files, as much more preferable way to formalize my thoughts.
At this point, the decision is simple: MDX or CMS (or server-side generation). I think, I am not yet ready for CMS. I know, I might be mistaken again, to continue building my blog posts solidly within the text files committed to the repo. I also already experience a lot of problems from a writer perspective, especially while creating new posts and selecting new tags - some were duplicated, or mistyped and need to fix them again. But, hey, there is no perfect solution, some always have some good and bad sites. I think, I will try with MDX even in order to harvest my personal option on building long term pages with this technology, and will try to share this experiance with you later.
Next.js in past and currently
I'm looking at the next.js framework for a while, and I've already built few small to medium websites with it. My biggest drawback to this framework are the turbulence in the last few versions - something around v12 until v15. In this period nextjs showed me, that this framework has really unstable for development process, especially in the area of long-term development. In this time, the nextjs team constantly changed the way how they want to develop the framework in the future and I feel this is not a solid foundation to build anything complex.
For example, I remember if you wanted to upgrade your project from v12 to v13 you had to invest huge amount of time in the migration process, just because at the time nextjs team wasn't sure about the direction of their future plans and regular releases1. In my opinion this is sad, because if you plan to build some project, and later, in order to maintain this application, in newer version you have to do a lot of additional maintenance without significant benefit to the business - the only reason is just to be able to say you run within the latest version of nextjs.
Of course, the maintenance may be critically important for the big players and their products, which has a lot of customers: like shops, maybe enterprise products, or companies' websites, where they can afford for fat development budgets. Although for small projects or personal websites, I find the solid foundation that can evolve over the years as something essential.
Well, I think that's the best question so far, and the answer is dead simple - curiosity. I am very excited and curious in same time how a new technology of mixing different type of renderings in same project and how this may evolve in real long term project. Until recent times, you had decision server side (PHP, Django, Rails, etc.) or client side (Angular, React, Vue, etc.). On the other side, if you do some side project, pick new shiny technology, and build something new with it for a few weeks, only then you may release if it's good or bad. You didn't you basically miss the chance to gain the experience of maintaining the technology over the time. And this is what I plan to gain from this decision - to build my page with some nice features of server-side generation, server-side rendering and some interactive client-side components, and then, I'll see how it evolve in the future.
Note
To be honest, I was hesitating to build my blog simply with Go/Hugo. If I would not be curious so much about current state of nextjs, most likely I would pick Hugo, as the building blog-like app within Hugo is really simple and awesome experience. In my opinion Go is literally the best technology for the web programmers at the moment, which value the boring stability of Go code releases, and speed of delivery new things. Hugo is also compelling alternative, because someone who build with it can only focus purely on content and developer experience taken from the framework itself. No decisions, no discussion, almost everything you may need is documented in nice way in their official docs.
Closing
Ok, let's wraps up and see what future will bring. If, this will be something worth to write in a blog, you can be sure, I'll do it. So far, thanks for reading, and until next time.
In one of Syntax FM podcasts (btw great podcast I can recommend) I've heard how they manage their website. They use CMS, as the simple markdown files are not efficient for them - and this is very healthy and very good! Everyone have a different needs, and I am so happy they share these kind of observations with their audience. ↩
Why I decided to actually give next.js another try (this time with my blog)?
Okay, so why I'm deciding to build my personal blog within the Next.js, despite that I complain on nextjs and think it may be unstable?