Rewriting the Site

This more-or-less started when I discovered that most browsers accepted the CSS nesting selector, which allowed for SASS-like stylesheets natively.

I had been dissatisfied with the CSS architecture for two categories of projects. One was the previous site, which used SASS + CSS modules. The SASS was for organizing CSS and the CSS modules were for ensuring there was no styling collision. The other category was for component packages, which used CSS modules also to prevent styling collision.

For the latter category, this was a nightmare. It was very useful for developing out-of-the-box components where the client didn't have to download any stylesheets, but that itself became a problem: 1) it required a "style-inject" hack to make it work and 2) the client probably prefers to have a say in the download of stylesheets. Breaking down that number 2 into two more arguments: 1) the client has a right to control when and where they download certain styles and 2) CSS modules made it very difficult to have the components follow theming. The airtightness of CSS modules was far too constraining.

In fact, the theming of the previous site was always busted. It required a series of hacks to make it work, when in reality it should've been bonehead simple. CSS really isn't that hard to figure out!

Then there was just the reality that my sites were never complex enough to protect against style collision. I didn't write an analytics dashboard or anything. With these little projects, my way of thinking is that I, the author, am the primary consumer of them and therefore the use case I have to most cater to is logically mine. If I get emails, great, that's a happy problem to have; over time I have learned how easy it is to overthink in software development.

The other big feature of CSS that helped me change my mind was CSS layers. With full control over the importation of stylesheets, you can, in theory, prevent styling collisions.

As I thought more and more on this, it struck me how much work would be required and that this was essentially a rewrite. And so I made the choice to rewrite the site, for a number of reasons which I will declare later. But one reason I found the rewrite encouraging was, the filesystem for the old system was crazy mangled. Again, in a fit of overthinking, I put a bunch of interrelated files in different folder paths thinking it would keep everything neat. It did not. For this site I got lazy and put one-off components in the same folder path as their page file. If I want to reuse them, I can figure out how to reuse them in the future. Software development: figuring out the path of least resistance.

Usually rewrites are accompanied by the giddy sensation of, "Yippee! Time to learn a new software development tool!" I looked into Vue, SvelteKit, Astro, all sorts of static-site generators I could pad out my resume with and acquire all sorts of fancy FE tricks.

And then I just went back to Next.

I had need for a Node server and I just never had any complaints about Next, neither in terms of site performance or development speed. I believe fundamentally in clean site design and would hopefully never bombard my visitors with the data clusterfuck that is the NYT page. Furthermore, who in their right mind, with all things being equal, downgrade from a large, well-supported ecosystem to a smaller one?

I did think about going totally vanilla but then it was just like, eh.

Oh and some of my packages are in React. I could've figured out how to isolate them, but, again, there was no obvious gain to doing so.

But hey, I was able to upgrade to the App Router stuff which, and I understand why people bitch about it, is pretty neat. I definitely don't use all of its features, but maybe some day.

The other choice I made while rewriting the site was to not port over the unit tests. I do think unit tests are essential for a professional app, but two circumstances belie that word "professional": 1. the app is actually useful to someone and 2. you have to know what specifically the app is trying to accomplish, and pretty much all of my projects, so far, fulfill neither criteria. I'm still kinda figuring out how my own personal interests interact with programming, though the Author Map is definitely bridging the distance between those subjects.

And...I think that's it. After all that decision-making, the rest of the task was to code, and coding is the easy part. I don't have the exact timeframe for how long this rewrite took, but it took maybe three weeks, while working on other stuff as well. Three weeks isn't really that much time for development, but a bean counter probably thinks differently.

There are a number of downsides to this new system:

The upsides were:

The rewrite also gave me an excuse to cancel Random-of-the-Day. Basically, I had procured lists of random things, like poems or facts, some sourced from other APIs, some I manually added, then ran an AWS Lambda to draw a random item from the lists and updated a fast-to-access resource the client could pull from. This cost me, like, 15 bucks a month. It was ridiculously expensive. But I also learned that, whatever app you build, its quality depends on the data you have, and I wasn't really willing to pull / pay for a bunch of data for something as trivial as Random-of-the-Day, at least in the iteration it was. At that point, it might've even been cheaper to just give the client data on-demand from a Mongo database, if I could figure out how to properly rate-limit requests. So, good bye Random-of-the-Day, perhaps you will come back when I have data that is both 1) robust and 2) reliable and when I think of a more cost-effective way to keep you running.

I hope this encourages me to write me code instead of doing lots of talking, though I, evidently, love talking. The lack of MD processing isn't that big of an issue but for this site it'd be nice to 1) think of much smaller coding projects going forward into the future and 2) letting the coding do all the talking for me. Which reveals a tenet I'm a big proponent of: project architecture is a major component for creativity, which is why architecture needs to be as clean as possible.