Thomas Cannon

Right now I’m running Practical Computer’s apps on Heroku, based on the following criteria:

• Crunchy Bridge is, IMO, the best Managed Postgres option out there. Their platform offerings mean I’m locked into being in AWS’s network to avoid latency hits. I learned that one the hard way with the performance hit of crossing datacenters between Hetzner + AWS when self-hosting via Dokku ( microblog.thomascannon.me/2024/05/1… )
• As other folks have said, my time is valuable, so I want minimal babysitting of servers
• Heroku’s developer experience is still really solid given those constraints
• Render has real “Ambulance Chaser” vibes that put me off

However, given those constraints, I’ve still done a bunch of research into what self-hosting would look like, especially for the extremely tiny apps that aren’t self-sustaining. The criteria I have for self-hosting are:

• Container-first (which disqualifies Hatchbox). You can’t beat the portability & isolation of container images
• Sustainable & wide community support outside of the Ruby/Rails ecosystem. This disqualifies ONCE/Kamal, which are “Not Invented Here” projects
• Have strong Infrastructure As Code foundations, notably Terraform/OpenTofu support. Terraform/OpenTofu support is critical in my eyes because if I’m giving up the developer experience of a platform like Heroku, I want to make up those time savings elsewhere in the administrivia of provisioning and maintenance

Right now the current candidate is Portainer (www.portainer.io, registry.terraform.io/providers… ). And even then, it’s an annoying lift that I’m not making anytime soon.

For a more managed alternative to Portainer, I’ve also been looking at Northflank, but am not biting the bullet there yet: northflank.com

www.rubyforum.org/t/paas-is…

If you’re using puma-dev (having .test domains and automatic HTTPS is super nice!) but want HTTP2+ support + all the benefits of caddy, I’ve started work on a small script/setup that provides a puma-dev like experience, but using caddy!

And best of all, there are no intermediary steps/tools, it’s just a setup that strings together 2 out-of-the-box programs.

https://github.com/practical-computer/caddy-dev

This is a super quick post, as I’m mired in a few projects. But! The web is a living document, and I want to get these thoughts out there; I can always update this later.

I’ve spent a fair bit of time over the past 3 weeks trying to chase down how to get a good Lighthouse performance score, particularly as I refine Little CRM and hone in my Web Awesome usage. Lighthouse was constantly dropping the score to the ~80s, leading me to:

• Build a whole static site in 11ty that was just the markup + asset compilation
• Figure out a Caddy setup that would give me HTTP/2 with full compression locally
• Burn even more time after that spamming the “analyze page” button.

Ultimately, the lessons I’ve learned are:

• The Lighthouse tab is finicky; particularly the Cumulative Layout Shift. The other stuff it checks is good, though!
• What Lighthouse reports for Simulated Throttling might not actually reflect real-world loading. Switch to DevTools throttling to check those results as well
• For layout shifting and overall loading details, check the “Performance” tab, it’s much more insightful.
• Make sure to throttle CPU & Network to get reasonable information when testing locally
• Building a good Web Awesome bundle (or really, any framework-layer bundle) is really important for first load performance. a Cloak can work, but for slow network connections it can make things unnecessarily worse. General rule for building the Web Awesome bundle: page, callout, card, icon, avatar, divider, tab-group. Then, pick the things you really really want to be available ASAP. But everything else (eg: tooltips) should be autoloaded
• Break up your applicaton bundles from your framework bundles. Combined with preload directives on Font Awesome’s CDN, that improves caching and load performance thanks to HTTP/2.
• Most importantly: with a slow network connection, there is always going to be some rearranging until SSR gets to be stable. So, aim for getting content on the page for users ASAP. They already know they’re on a bad network

These have been a long time in the making; and they’re barely the initial alphas, but the Practical Framework is officially open-sourced.

They’re 3.0 releases because they’ve gone through 2 internal revisions. Next up is:

• Updating existing apps to use 3.0
• Refinements from there
• Tons of documentation, because the framework takes a very different approach than others on the market

If you’re curious:

• The Ruby repo
• The JS repo

After months of research and development, a new guide about how to build maintainable view layers in Rails (and overhaul an existing UI without stopping feature development) is live.

thomascannon.me/guides/th…

This is the largest thing I’ve ever seriously published, clocking in at about 8.2K words, with an open-source snapshot to boot

After a short break, I’m going to extract the framework-level code into libraries, then start the process of migrating Little CRM 💪

I’m currently in the middle of re-tackling the view layer for Practical Computer. Now that there are 2 apps + a framework, the complexity is high enough to actually tackle the problem comprehensively

So, from my view of the Rails View Layer landscape, you have the following paths:

• continue as-is, as we have for 15 years
• get partway there with ViewComponent, having to make concessions & hacks. This is a glaring flaw; table-stakes: viewcomponent.org/known_iss…
• go with Phlex all-in, acting as a clean-room replacement. Basically; nothing aside from Form Builders & explicit helper uses, no ERB files
• roll something on your own, like Garett proposes in some of his musings: garrettdimon.com/journal/p…

Am I correct here? Am I missing something?

A new mini-tool from the Practical Computer labs: an Extism plugin to process Mustachio templates: github.com/practical…

Overall, I’m impressed with how Extism is structured. Being able to use WASM to deal with a thorny issue (running Mustachio’s official C# library in a Ruby codebase) with a small, cross-platform binary that can be embedded into the repo itself, dramatically simplifies the problem at hand.

The goal is to hand this off to Postmark directly, since this gives their entire ecosystem a huge boost in usability.