Introduction

I think it is interesting to share my thoughts and principles I have been following when I started building this website. The goal of this website is to have a blog part where I can write about my thoughts and share my knowledge. It also has a playground for me to experiment with web development. Lastly, it is a place where I can present myself professionally and showcase my achievements so far. These principles have developed over time and I think they are quite useful for anyone who is building a modern website. This blog post will not be too technical, but I will try to explain the principles in a way that is easy to understand.

Principle 1: As much static content as possible

For this personal website I wanted it to be as performant as possible. Performance for me is that it should be fast to load, and it should be fast to crawl. It should also be fast for visitors on their mobile devices with slow internet connections.

To achieve this, I made the following decisions:

As much static content as possible.
Optimize images.

Static Content

For the static content, I am trying to build every page during the build process and even if the amount of pages goes into the hundreds there should be a negligible impact on build times. Currently the build time is less than a minute with 64 pages, Next.js 15.0.4-canary.30, 29 unit tests (running via Playwright) and generating a sitemap. Having the static content is also great for SEO, because search engines like Google can crawl the pages very fast and the content is quickly available from the CDN. It also makes navigating the website faster almost instantly like a native app. As I am writing my content in Markdown and therefore doing a deployment every time I push new content, I am also not worried about having to update static content. Even if, Next.js has Incremental Static Regeneration (ISR) which allows me to update the content without having to rebuild the entire site.

Optimize Images

For the few images I am using Next.js Image component to optimize them through Vercel. This makes them lazy load, optimize them and also compress them as I would otherwise have to do this manually or serve the original images. The majority of them are screenshots or taken with my phone, so they are usually way too big and slow to load. It would not make any sense to serve them that way.

Principle 2: Use the latest versions of packages

Over the last years, I have seen and talked to many developers and SDET's who are still using outdated versions of libraries and frameworks. Most of the time the business or product owners do not allocate enough time or budget for updating the dependencies because it is not broken, so why fix it?

"Never change a running system." - Unknown

To avoid the pitfalls outlined below in my two examples, I have opted to use the latest versions of the packages I am using. One concern usually is that build errors may occur or that the latest versions are less proven. However, I have not experienced any of these issues so far and because I am using Vercel I am only worried about runtime errors, as build errors would result in a failed deployment and therefore not affect my production environment.

IMHO, a proper Software Development Lifecycle (SDLC) should include updating the dependencies to the latest versions and having a proper Quality Assurance (QA) strategy should ensure that the new versions work as expected and reduce the risk of encountering any issues.

Negative example 1: Java 1.8

Typically that results in a lot of security vulnerabilities, bugs and performance issues. While it is true that some offer Long-Term-Support (LTS) versions, they often lack the features and improvements introduced in the latest versions. For example, Java 1.8 is a LTS version and it was released in 2014. Newer versions that are also LTS versions like 11 and 17 would have improvements in performance and security and it is a missed opportunity to not utilize them.

Negative example 2: Appium

One of the customers I worked with was using Appium 1.x for a long time. They only started to look into Appium 2.x when more and more of their mobile app tests started to fail. They tried to keep their old tests running and fixed them or tried to apply workarounds to make them work instead of solving the underlying issues. Ultimately, the state of their tests deteriorated to the point that they had to spend a lot of time to do the migration. This was quite an undertaking as they had to rewrite a lot of tests. An incremental approach would have been better, but they did not want to change the running system.

Principle 3: Ensure a good User Experience (UX)

What is a good User Experience?

For me, a good UX is a website that works on desktop as well as it does on mobile devices. It needs to be mobile-friendly. It should also load fast and be snappy like a native app. Given the improvements in internet speeds and the ubiquitous amount of mobile devices and people using mobile devices probably more than desktops, it should be evident that websites must be mobile-friendly and fast. Looking at the demographics and continous changes any business that lacks behind in this area will lose customers or in my case lose visitors to this website.

For this website I am using Next.js and Tailwind CSS. Both make it very simple to build a mobile-friendly website. It also supports out of the box saving the website as a Progressive Web App (PWA) which makes it installable on mobile devices and also load faster because it can be cached. I may do this in the future to make it feel more native and to be able to send push notifications to users. If you are interested in this you can check out the documentation here.

Principle 4: KISS

KISS stands for Keep It Simple, Stupid. According to Wikipedia, there are different variations of the saying that changes the rude word "Stupid".

I could have used a CMS to manage my content like blog posts. However, I also chose to use Markdown for my content because I enjoy it. It has presented its own challenges especially with rendering the content in the right style and look especially when used together with Tailwind CSS, as Tailwind overrides other styles and I had to manually map tag names to components.

Another reason is that I do not want to ship too much JavaScript to the client so I limit the amount of packages used and prefer to write small codes and components myself. Although I do use shadcn/ui for the majority of the components.

Ultimately, the most simple thing to do would have been to use WordPress if I only wanted to write blog posts. However, I also wanted to have a website that I can call my own and that I can use to do whatever I want with it. It also helps that it is an actual project that is used to learn more about modern web development and to try out new things.

Principle 5: Use AI to your advantage

I think it is very difficult to always write the most optimal code. As such I like to use ChatGPT and v0 to help me double-check my code and to suggest code improvements for improving code readability, maintainability, performance and scalability. To achieve better results, it is useful to use Repomix to generate an AI-friendly file that has the entire codebase. With this as context you will in general get better results.

Conclusion

I am sure there are many more principles, tips, tricks and best practices and even more that I do not follow or are aware of. However, these are the ones that I am consciously following or at least trying to and so far they have been working well for me. And at least fwiw in the area of performance Google PageSpeed Insights and Vercel's Speed Insights score this website with a 100 points:

Screenshot of Google PageSpeed Insights tool showing a performance score of 100 for this website {caption: Google PageSpeed Insights score 100}

Screenshot of Vercel Speed Insights showing a performance score of 100 for this website {caption: Vercel Speed Insights score 100}

So far I am very happy with the results and the performance of this website by following these principles.