Articles for #webdev

I’ve been working on a plugin for Obsidian called Obsidian Full Calendar on-and-off for the past 10 months or so. For most of that time the plugin has had no unit tests, and I finally got around to adding some test coverage during a big refactor.

Tests are easiest when code doesn’t have side effects since filesystems and network calls often aren’t available in the environment the tests are running in. Obsidian’s core code is closed-source and can only be run from inside the Electron app, so plugin developers who want test coverage aren’t left with many options but to test their plugins completely outside of Obsidian. Unfortunately for me, my plugin is mostly a pile of glue sitting between FullCalendar as the view layer and the Obsidian filesystem APIs for persistence. I would need to mock out the relevant APIs from Obsidian if I wanted to have any meaningful test coverage of my own code.

There isn’t yet any comprehensive mock Obsidian API for use in a testing environment that I could reach for, so I went ahead writing my own!

I started a new project a few days ago built with Django. Heroku is killing their free tier, and I’ve read that Fly.io is the cool new thing, so I decided to try it out.

Overall, Fly has great documentation. Their Language and Framework Guides are pretty comprehensive, but in a list that includes popular frameworks like Rails and Laravel alongside less boring options like RedwoodJS and Remix, I couldn’t help but notice Django’s conspicuous absence.

I was able to get everything working great with Django and Fly.io after some trial and error, so I wanted to write up my process to make it easier for people going forward.

Hello World, again! I’ve rewritten this website using the Astro web framework. Astro’s very new — it had its 1.0 release just under two months ago. There’s three things that got me excited enough about it to rewrite my whole site.

1. JSX. JSX is best known as the templating syntax that powers React. While Astro can integrate with React, Vue, Svelte, or any other framework from a growing list , .astro templates are written with a mix of TypeScript and JSX and are rendered directly to vanilla HTML with no JavaScript at runtime. TypeScript is written in a preamble section that looks similar to Markdown frontmatter and sets up the scope for the rest of the template. I found Hugo’s templating system that is built directly on Go’s templating library to be very limiting by contrast. At this point, I definitely believe the adage that “any powerful templating language eventually grows into an awkward programming language” — I’d much rather use a full programming language as my templating language.
2. Scoped CSS. CSS written in .astro templates are scoped to that template only. I’m not a fan of dogmatic separation of concerns in CSS. I also don’t have much experience with Tailwind, and I enjoy writing SCSS. So scoped styles in all my templates is a happy medium where my styles live close to my templates while I can write in a familiar syntax.
3. Lightweight. With everything from archetypes to taxonomies, Hugo is really a static CMS more than a blog generator. It’s a much more general system than I need. Astro is a bit “closer to the metal” in that respect. When I’ve had to write some helpers that I took for granted in Hugo, writing custom helpers is much easier since it can be accomplished in a few lines of Typescript.

Hotwire, which seems to be short for (H)tml (O)ver (T)he (Wire), is a collection of frameworks just announced by Basecamp that work together to help build “traditional” server-rendered web applications that look and feel to users like modern, Single-Page Applications (SPAs) built in React, Angular, Vue or other frontend frameworks. Basecamp’s CTO put out a blog post on why he believes in Hotwire, but most of the justification seems to be handwavy claims that JavaScript is inherently “complex,” never mind that Ruby’s syntax and dynamic type system can be just as head-scratching to a newcomer. I think that Basecamp’s built a really interesting tool, and a better argument for Hotwire can be made by fully engaging with the benefits that SPA “thick clients” bring to the table, their specific shortcomings, and all the different ways framework developers are trying to address those shortcomings today.