With the recent release of my updated website. I’ve decided to reflect on the growth and changes to my website over the time it’s been around.
At first the website was very simple. It was a static site hosted on GitHub Pages written in pure HTML and CSS. The basics. Nothing more, nothing less. It did what it needed to: serve as an aggregate collection of links to my online presence, mainly YouTube and GitHub at the time. For any changes I simply updated the HTML and pushed the changes and they would become live. The domain was the default mxtt-mmxix.github.io. However, I started to run into some problems.
I began to realize that I was frequently reusing certain chunks of HTML code. Furthermore these chunks were being reused across multiple pages and the pages in of themselves grew ever more longer and more complicated. I needed a way to manage the growing complexity of my website. Then, I came across React, a JavaScript library for building user interfaces. At the time I thought it was amazing (and still is). I could organize my markup into components and then reuse those components! These components can then be composed to form entire pages. Multiple pages can reuse the same components and then pass properties to the components to alter the behavior. JSX allowed to mix HTML and JS allowing HTML elements to be stored by variables, returned by functions, passed as arguments and so much more. It was a dream come true. The JSX could then be compiled to standard JavaScript and uploaded to GitHub pages.
That last part however, proved to be a problem in of itself. At the time, GitHub pages simply served whatever was in the root or docs folder. What this meant for my simple React application was that the actual source code was stored in a separate repository, and whenever I wanted to make a change, I’d have to do a build, then copy the build output files to the GitHub Pages repo, then push it. This became quite tedious, especially since I was new to web development at the time and constantly made changes as a learned new things.
I came across, Next.JS, a framework for building React applications. It supported file-based routing, APIs (without the need for an external project based on something like Express), and it supported building and serving the files with a built-in server from the same folder. Overall, it was a much nicer developer experience. I migrated my website to Next.JS and overall was happy with it for the time. However GitHub pages, only supported static content, and while Next.JS did support static builds, I wanted to avoid the whole copying build output to a another repository workflow. I wanted something where I could simple have a server rebuild the Next project and serve the new output. Furthermore, I began integrating GitHub REST API functionality and needed a backend server to proxy the requests to avoid exposing my personal access token to the client.
Enter Heroku, a platform that allowed me to upload my Node.JS project, build on push, and serve. For a while this worked. Anytime I made a change, I pushed the updated source files, Heroku would pull it and rebuild it for me. However, there was one issue. Heroku is would occasionally put the server to sleep. This meant that loading the page after a while would take a noticeable long time which would make the website feel slow even though it never was. GitHub Pages used to be fast and snappy I wanted that back.
At that point, I turned to Vercel. Vercel had deep integration with Next.JS. I was able to take advance of server-side generation to pre-render the HTML to my website. This was a major speed improvement as no longer was the entire UI being generated by JavaScript anymore. However this sparked a thought that would later lead to this post: Plain hypertext documents are ultimately faster, and the way to achieve a faster website was to use less JavaScript.
At this point, I was satisfied with the current framework and platform. Now it was time to focus more on the website itself. At the time I moved to Vercel. The website was a plain white background with text on it, and a listing of my GitHub projects. It was flat and simple. However it got boring. With the macOS Big Sur and Windows 11 design updates, I wanted to redesign my website to reflect the changing design trends, particularly: the acrylic/glass effect. So I spent sometime redesigning the website. Instead of a white background I would now have a wallpaper fetched from Unsplash. The semi transparent buttons and card elements featured a background blur that made for a nice frosted effect. Soft shadows distinguished those glass elements while a parallax effect from scrolling blocks of texts aided with the sense of depth. I pushed this and it decided to leave it alone for a while.
Except I wasn’t too happy with it. While there was nothing wrong with the website. It simply didn’t capture that modern design aesthetic I was envisioning. Also, the new website did not offer more than the old website did. It was merely a listing of all my projects on GitHub. While yes, there were new additions such as Education, and my Minecraft plugins, it didn’t feel new enough. Also, I became more security and performance conscious and wanted to ship less JavaScript to the client than before.
Then I learned about Astro.JS. A JavaScript framework that aims to pre-render everything only ship JavaScript to the client as needed. Further it integrated when any JavaScript library including React. So decided to rewrite my website using Astro.JS. I decided to go back the minimal, black text on white background approach from before. However, instead of a navigation bar, I opted for a full height side bar following modern design trends. I also chose to forgo the automatic listing of my GitHub repositories. Instead, favoring quality over quantity, I chose to only list the two projects that mean that the most to me right now. At this point the GitHub REST API requests were being made during build time as part of server side generation since the Next.JS days and that was also replicated here.
For a while now, the the blog has been hosted on a separate platform, Blogger. At this point I was unsatisfied with the visual inconsistency between my website and the blog website. So with the new rebuild, I decided to move the blog in house. Astro supports rendering of Markdown pages so I can simply write my new blogs (such as this one) in Markdown and Astro will render it inside the same sidebar layout with the rest of the site. (Now if I could only somehow integrate the generated Doxygen pages)
At this point I’ve realized that I have come full circle. From static HTML pages to JavaScript generating the entire page, to JavaScript generating some of the page in advance then hydrating the rest later, to JavaScript generating the entire HTML page in advance. As far as the client is concerned, they’re just getting pure HTML and CSS, just like the first versions of the website! Furthermore, no backend server is needed anymore since the REST API calls are made at build time.
However, over the years I’ve learnt a lot about web development. Along the way I’ve picked up Bootstrap, learnt how to use REST APIs, would with CI/CD workflows, migrated to TypeScript, and so much more. Now, mmccall.dev spans across two domains, loads in mere milliseconds, hosts my blog, my portfolio, and documentation for my projects. It serves as a hub for other content on GitHub, YouTube, Twitter, LinkedIn, and more. Right now, I am satisfied with the site. But who knows? In a couple months I might rewrite the whatever the next trendy JavaScript framework is. (I’m eyeing Deno frameworks, WASM, or even my own Silicon Engine)
With the recent release of my updated website. I’ve decided to reflect on the growth and changes to my website over the time it’s been around.
At first the website was very simple. It was a static site hosted on GitHub Pages written in pure HTML and CSS. The basics. Nothing more, nothing less. It did what it needed to: serve as an aggregate collection of links to my online presence, mainly YouTube and GitHub at the time. For any changes I simply updated the HTML and pushed the changes and they would become live. The domain was the default mxtt-mmxix.github.io. However, I started to run into some problems.
I began to realize that I was frequently reusing certain chunks of HTML code. Furthermore these chunks were being reused across multiple pages and the pages in of themselves grew ever more longer and more complicated. I needed a way to manage the growing complexity of my website. Then, I came across React, a JavaScript library for building user interfaces. At the time I thought it was amazing (and still is). I could organize my markup into components and then reuse those components! These components can then be composed to form entire pages. Multiple pages can reuse the same components and then pass properties to the components to alter the behavior. JSX allowed to mix HTML and JS allowing HTML elements to be stored by variables, returned by functions, passed as arguments and so much more. It was a dream come true. The JSX could then be compiled to standard JavaScript and uploaded to GitHub pages.
That last part however, proved to be a problem in of itself. At the time, GitHub pages simply served whatever was in the root or docs folder. What this meant for my simple React application was that the actual source code was stored in a separate repository, and whenever I wanted to make a change, I’d have to do a build, then copy the build output files to the GitHub Pages repo, then push it. This became quite tedious, especially since I was new to web development at the time and constantly made changes as a learned new things.
I came across, Next.JS, a framework for building React applications. It supported file-based routing, APIs (without the need for an external project based on something like Express), and it supported building and serving the files with a built-in server from the same folder. Overall, it was a much nicer developer experience. I migrated my website to Next.JS and overall was happy with it for the time. However GitHub pages, only supported static content, and while Next.JS did support static builds, I wanted to avoid the whole copying build output to a another repository workflow. I wanted something where I could simple have a server rebuild the Next project and serve the new output. Furthermore, I began integrating GitHub REST API functionality and needed a backend server to proxy the requests to avoid exposing my personal access token to the client.
Enter Heroku, a platform that allowed me to upload my Node.JS project, build on push, and serve. For a while this worked. Anytime I made a change, I pushed the updated source files, Heroku would pull it and rebuild it for me. However, there was one issue. Heroku is would occasionally put the server to sleep. This meant that loading the page after a while would take a noticeable long time which would make the website feel slow even though it never was. GitHub Pages used to be fast and snappy I wanted that back.
At that point, I turned to Vercel. Vercel had deep integration with Next.JS. I was able to take advance of server-side generation to pre-render the HTML to my website. This was a major speed improvement as no longer was the entire UI being generated by JavaScript anymore. However this sparked a thought that would later lead to this post: Plain hypertext documents are ultimately faster, and the way to achieve a faster website was to use less JavaScript.
At this point, I was satisfied with the current framework and platform. Now it was time to focus more on the website itself. At the time I moved to Vercel. The website was a plain white background with text on it, and a listing of my GitHub projects. It was flat and simple. However it got boring. With the macOS Big Sur and Windows 11 design updates, I wanted to redesign my website to reflect the changing design trends, particularly: the acrylic/glass effect. So I spent sometime redesigning the website. Instead of a white background I would now have a wallpaper fetched from Unsplash. The semi transparent buttons and card elements featured a background blur that made for a nice frosted effect. Soft shadows distinguished those glass elements while a parallax effect from scrolling blocks of texts aided with the sense of depth. I pushed this and it decided to leave it alone for a while.
Except I wasn’t too happy with it. While there was nothing wrong with the website. It simply didn’t capture that modern design aesthetic I was envisioning. Also, the new website did not offer more than the old website did. It was merely a listing of all my projects on GitHub. While yes, there were new additions such as Education, and my Minecraft plugins, it didn’t feel new enough. Also, I became more security and performance conscious and wanted to ship less JavaScript to the client than before.
Then I learned about Astro.JS. A JavaScript framework that aims to pre-render everything only ship JavaScript to the client as needed. Further it integrated when any JavaScript library including React. So decided to rewrite my website using Astro.JS. I decided to go back the minimal, black text on white background approach from before. However, instead of a navigation bar, I opted for a full height side bar following modern design trends. I also chose to forgo the automatic listing of my GitHub repositories. Instead, favoring quality over quantity, I chose to only list the two projects that mean that the most to me right now. At this point the GitHub REST API requests were being made during build time as part of server side generation since the Next.JS days and that was also replicated here.
For a while now, the the blog has been hosted on a separate platform, Blogger. At this point I was unsatisfied with the visual inconsistency between my website and the blog website. So with the new rebuild, I decided to move the blog in house. Astro supports rendering of Markdown pages so I can simply write my new blogs (such as this one) in Markdown and Astro will render it inside the same sidebar layout with the rest of the site. (Now if I could only somehow integrate the generated Doxygen pages)
At this point I’ve realized that I have come full circle. From static HTML pages to JavaScript generating the entire page, to JavaScript generating some of the page in advance then hydrating the rest later, to JavaScript generating the entire HTML page in advance. As far as the client is concerned, they’re just getting pure HTML and CSS, just like the first versions of the website! Furthermore, no backend server is needed anymore since the REST API calls are made at build time.
However, over the years I’ve learnt a lot about web development. Along the way I’ve picked up Bootstrap, learnt how to use REST APIs, would with CI/CD workflows, migrated to TypeScript, and so much more. Now, mmccall.dev spans across two domains, loads in mere milliseconds, hosts my blog, my portfolio, and documentation for my projects. It serves as a hub for other content on GitHub, YouTube, Twitter, LinkedIn, and more. Right now, I am satisfied with the site. But who knows? In a couple months I might rewrite the whatever the next trendy JavaScript framework is. (I’m eyeing Deno frameworks, WASM, or even my own Silicon Engine)