Why am I building a personal website in 2023‽
2023-11-11 | Estimated reading time: 4 minutes
Building and running a personal website, let alone a static one without (much) JavaScript code, feels a bit anachronistic in 2023. But at the same time, recent events in the social media world – especially Twitter becoming X and Reddit effectively shutting out 3rd party clients – may be a gentle push towards sharing more content in a more decentralised way.
For me personally, it also is an attempt and a reason to catch up on frontend development topics. A lot has changed since I last did extensive frontend work ca. 2014 and I am cautiously optimistic that the web can move away from some of the IMO bad practices it has picked up over the years.
“Replacing” social media
For content creators, social media is full of benefits. Content is much more discoverable, especially once you factor in categorising features like hashtags. Your consumers sharing your content in their social circles with just one click and The Algorithm™ of course helps a lot, as well.
Even though Twitter and Reddit have undergone unpopular changes this year, they are still here to stay, it seems. But quite a few of their users have packed it up and I am amongst them.
Unfortunately, they are not headed for the same destination. Some call Bluesky their new Twitter replacement, some have settled on Mastodon, and some have seized the opportunity to excise microblogging from their lives entirely.
Where have Reddit users gone to? I actually don’t know, because the end of 3rd party Reddit clients also put an end to my Reddit doomscrolling and I’m not missing it, at all.
Decentralised content
I have never thought of it this way, but during all these years, I have been consuming decentralised content on a regular basis: podcasts. Content creators can host their podcasts wherever they want to and I can consume them in the same app without having to care about where they can be found. If a creator is not happy with their hosting service, they can go somewhere else and their audience (ideally) does not have to take any action to follow them.
“Normal” websites are capable of those conveniences, as well: A domain name stays the same even if you change the actual hosting service and RSS feeds provide a convenient, simple way for your audience to essentially subscribe to your content.
Frontend development, its woes, and progress
My career focus shift to backend development came when server-side HTML rendering turned into backends providing APIs and frontends consuming those APIs to modify the DOM. When we were exploring React at work ca. 2014, some of my colleagues were much more interested in it than me, so our team of full-stack developers started to split into two cohorts: backend developers and frontend developers.
Looking back, I am still not convinced that additional complexity was justified for what we were doing. Our project manager’s vision was to create a user experience similar to that of a local application, especially with regard to managing local state.
This vision however made us “forget” that we were still building an application running in a browser with buttons like “back”, “forward”, or “refresh”. These oversights of course were our mistakes and not necessarily those of the React ecosystem, but I found myself frequently wondering whether we have considered “unexpected” input coming from the user using browser-native functionality.
React et al probably are wonderful, given the right use cases and implemented correctly, but was the added complexity really worth it for us?
This is disregarding recent developments like server-side rendering the frontend and then client-side hydration.
Before client-side JavaScript frameworks/libraries took over, CSS was primarily for styling and JavaScript was mostly used for animating frontend elements as well as making asynchronous HTTP calls.
We still need JavaScript for the latter, but CSS animations and transitions have become so powerful that they often can replace JavaScript today.
The biggest problem for adapting CSS animations and transitions probably is the lack of real incentive to use them. Instead of learning how to use them, you can just write (or use) more JavaScript to get the same result.
As long as employers are actually looking for “[JavaScript frontend framework/library here] developer” when they post a job for a frontend developer, problems are more likely to be solved using JavaScript instead of CSS.
Why am I doing this?
I am not an evangelist for either technology. If anything, I am an evangelist for using the most appropriate tools for a given problem. But in order for me to be able to identify the best tool for a problem, I need to understand a good number of the tools that are available. As a (somewhat) practical learner, putting those tools to use is the best way for me to build that understanding.
Additional benefits may include relying less on (centralised) social media to get my thoughts, ideas, and rants out, as well as a hopefully better user experience for those who want to follow me.
Huy Dinh
Senior Software Engineer
at Solaris SE