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.