Web Framework Blues

I’ve written before about the tools I’ve used for building this website. To recap, I started with Jekyll, and I transitioned to Gatsby because of… reasons.

I don’t have strong opinions about Gatsby. Being a React-based framework, it felt familiar because I had been working on several other React projects. Maybe a little too familiar, as it turns out.

I started to hear about Svelte and SvelteKit early last year. Curiosity got the better of me, and I decided to port this site to SvelteKit. Recall that my primary motivation for switching to Gatsby was to allow me to use Tailwind as my styling solution, and I stuck with Tailwind for my SvelteKit rewrite.

Svelte is absolutely lovely. I love its syntax for expressing reactive UI state changes, and its use of stores for cross-component shared state. SvelteKit, though, I still have some reservations about. I won’t get into specifics here, because I acknowledge that it’s a relative newcomer (still in beta when I first picked it up), and I have faith that as it matures, it will continue to address some of the quirks that I encountered. If I were to start a web application project, I would choose SvelteKit.

However, for a non-interactive blog website like this one, I don’t think that SvelteKit is the best fit. Its default mode is full-stack server-side rendering, not static site generation¹. In particular, it doesn’t have built-in support for content management (which Jekyll and Gatsby do), and I found myself writing a lot of custom code just to read Markdown text files from the filesystem and render it as HTML.

I’ve learned that my Kryptonite is getting bogged down in coding details and missing the big picture, and after stepping back from all of the SvelteKit and Tailwind tinkering, I had a painful realization: this website was kind of ugly. Design is a skill that I need to practice, just as much as coding.

Jekyll → Gatsby → SvelteKit → Astro

This is the part of the story where I wag my finger at myself and say, “Don’t tell me you rewrote it again.” I’ve had enough corporate software experience to instinctively recoil at the idea. Refactoring or rewriting a project even once is verboten, let alone three times.

That’s right, three. I’m now building this site using Astro.

In order to describe what I’m appreciating about Astro, I need to talk about a couple of mental shifts that I’ve had in recent months.

Regarding Tailwind

I called Tailwind “CSS without CSS” and to many, that’s a good thing. I fell in love with it, too, but the longer I spent with it, the more uncomfortable I got.

The initial appeal came from the feeling of “moving fast”: there’s an almost Zen-like trance that comes from typing short, easy-to-remember nubbins in the class list of an HTML element. But as soon as I needed to change something, it became tedious to scan that same list, as it got longer and longer. Many Tailwind detractors criticize it on this front.

More importantly, I started to think that maybe it wasn’t such a good idea to try to do CSS without CSS. There’s value in accepting CSS for what it is, instead of trying to hide it behind shortcuts for the sake of “developer experience.”

Tailwind is to CSS as Coles Notes² are to Shakespeare. Why not just study Shakespeare?

Anti-JS sentiment

Recently, I read a couple of blog posts that angrily criticize the current state of web development. While their tone is too “conspiracy theory rant” for my tastes, they have a valid point. Namely, Javascript web frameworks (especially React) may have become dominant because of marketing and hype, not technical merit. And the consequence of putting Javascript first? A lot of extra load on browsers, and a lot of extra complexity in the development workflow.

I learned React by starting two projects at around the same time: one for an internal web tool at the software company where I was employed, and one for a small-business client with whom I was moonlighting as a freelancer. It didn’t feel like I had a choice. I felt pressure from my teammates at the software company to use React, probably because they hoped that their peripheral exposure to it would result in a line item on their résumé. Even my small-business client, who has little technical knowledge, wanted me to use React. It’s a brand, and it has brand recognition in the marketplace of web development.

React appears to be easy to learn. The basic idea of rendering the DOM as a function of state is cool. However, in my experience, the basic idea is not enough to create applications that perform well and are easy to maintain. There are layers and layers of extensions and techniques³ that I had to learn along the way, usually because I was reacting⁴ to a situation where something was broken or slow.

The best practices are not built in, and I feel like every project team needs to take a different journey towards making their application the best that it can be.

Back to basics

The web started with HTML and CSS, and I have been feeling a desire to go back to basics, and really grasp the fundamentals again.

For the longest time, I’ve held onto the presumption that CSS doesn’t have the concept of variables. That’s why, in order to make your code reusable, you needed to use a preprocessor, or one of many CSS-in-JS solutions. But in fact, browsers have supported CSS custom properties for several years now. Heavy reliance on Javascript frameworks has obfuscated my knowledge of these changes, and my understanding of web development became filtered through framework-specific concepts.

Astro, then, is a breath of fresh air. Being focussed on static HTML generation first, it is most similar to Jekyll and Hugo (which I touched briefly to build a small site). Astro is friendlier than either of these for developers who are already used to Javascript and JSX, since it doesn’t require picking up another language (Ruby and Go, respectively).

In my experience so far, Astro provides the best of all worlds:

• content management and Markdown support, like Jekyll and Gatsby
• single file components with scoped CSS, similar to Svelte
• if you need some interactive UI, you can plug in a framework component as an “island” - this can be created with React, Svelte, Vue, whatever. E.g., this site is largely Javascript-free, but I imported the interactive search functionality from my previous Svelte incarnation.

Most importantly, Astro forces me to think mainly in HTML and CSS, and consequently, to keep visual design decisions in the front of my mind, not buried underneath layers of Javascript libraries and optimizations.

It’s ironic that I started with an HTML-first static site generator and came all the way back around. The anti-JS sentiment that I’ve been seeing online might be a sign that the web community at large is taking a similar cyclical journey. Everything old is new again, it seems.