Why did I migrate to jekyll?

The beginning

Since I was a kid, I’ve loved writing code. Coding is a hobby of mine, and I enjoy spending time on new and interesting projects, exploring new technologies, or simply reimplementing an elegant algorithm.

To share my experiences with a wider audience, I’ve decided to start a blog about my small projects, funny stories, and little findings. When I decided to create a blog, I turned to my closest friend: the frontend framework ReactJS. When I start a new project, I usually choose React because it’s flexible, has a large community and ecosystem, and, last but not least, it’s the framework I’m most familiar with.

Great start

Here’s the text with some corrections and improvements:

Everything was going great at the beginning – I started creating the blog prototype quickly thanks to my familiarity with the tools. I already had a project written in plain JavaScript that I wanted to incorporate into the site. I decided to convert it to TypeScript and present it as a separate page within my React application. However, I soon realized that following this approach would make my application unnecessarily large, leading to slower initial loading times. Remember, React, as a client-side framework, bundles everything into one massive JavaScript file.

To tackle this issue, I decided to split the application into smaller chunks. This enables lazy loading of individual blog posts, effectively resolving the problem of the bloated JavaScript file.

I’ve used the following approach:

const MyPost = lazy(() =>
  import("./components/pages/mypost").then((module) => ({
    default: module.MyPost,
  }))
);

…

<Routes>
    <Route path="/mypost" element={<MyPost/>}>
    </Route>
<Routes>

The realization

When I launched the site, I hoped users searching for my name could easily find it on Google. Recognizing the impact of loading time on search engine ranking, I prioritized improving my site’s SEO. Luckily, the fantastic Core Web Vitals metrics on [pagespeed.web.dev] helped me identify areas for improvement. While I managed to address some issues within a few hours, persistent mobile performance hurdles made me realize ReactJS wasn’t the ideal tool for this project. A simple, static website would ultimately better suit my needs.

Jekyll

I looked for a static stite generator. I narrowed it down to my choice to two options. Hugo or Jekyll. There are plenty of good reasons to use one or the other but I’ve choosen Jekyll at the end cause it gaved me a fully functional website by default. With its plugin system its ready for most of the challenges for a blog. I had to spend a couple of hours again to recreate the website desing and the posts but it worth the effort. I’ve reached much better scores on core web vitals. The application became blazing fast and writing a post is even more convinient.

Summary

To the end I can tell it was a nice jurney from React to Jekyll. This is a good example that choosing the right tool is benefitial and make our life easier. I will keep this in mind when I start a new projet next time.