Converted site to Astro

A reader looking at dates on posts might note this site and the observatory have been inactive for a couple of years. I hope to resume operations in the next few months, starting with some much-needed cleaning and maintenance.

Meanwhile, the web site has been sitting here, consuming a surprising amount of resources on its hosting service. I converted to WordPress a few years ago, and appreciated the content management features and the ability to work on the web site from anywhere via the browser interface.

There’s a price for that, though. Since the pages are rendered on the server when fetched, it puts a substantial load on the server. The web hosting service I’ve used for many years isn’t really set up for this, and I was constantly getting “excessive resource consumption” warnings. To combat this, I was installing increasingly complex workarounds: WordPress caching, external DNS caching, WordPress cron-tab and heartbeat reduction, etc.

I decided it wasn’t worth the effort for the modest benefit I was getting from WordPress. (I did look into dedicated WordPress hosting services, but they are expensive at the small scale.)

Looking for alternate approaches, I got the general impression that the “shared hosting” services like the one I used, and php-oriented content management systems, are a generation obsolete.

Looking at alternatives, I decided to give Astro a try, and I’m quite pleased with it. It trades server-side rendering – with the computing cost that accompanies every page fetch – for a “build” phase that renders on the development machine. There is a rich set of JavaScript functionality and “macro-like” capabilities called Layouts and Components the give a lot of expressive power. But, from the point of view of the web server, it is a completely static web site.

And, of course, the name. What could be a better name for the web framework for an astronomical observatory web site than “Astro”?

Astro isn’t for everyone. You need to be willing to author in HTML and CSS if you want full formatting control. Or, you can author in Markdown for simplicity at the cost of losing some control of formatting.

I’m using html and CSS, with the JetBrains Webstorm IDE. (You could use the free VSCode easily, but the JetBrains suite is excellent and I already use it for other things.) Version control is Git and when the site is submitted to GitHub a build process runs automatically and the changed files are uploaded to my old host. It’s working like a charm, and the access cost of pages on the site has dropped to near zero. I’ve lost the “edit from anywhere” feature, but I have a computer with me anywhere that I might want to do an update, and with the site in GitHub I can make changes from anywhere.

Being static, I did lose the ability to support page comments that was built in to WordPress. However, I found an inexpensive hosted comment service (Hyvor) that integrates well into the site, and I’m using that. The yearly cost of Hyvor is less than I was spending on various WordPress plugins and auxiliary services.