Since I started converting parts of my website to use 11ty as a static site generator, I’ve been able to automatically generate tag and category pages that are *just there* as plain html files. And since they’re plain HTML, the old local site search engine I have on there still finds all the Eleventy-generated pages. And again since it’s all static, it doesn’t go down when the database does (which has been happening on an annoyingly frequent basis lately).

And this would be perfect if I was using a single Eleventy instance to build the entire site, but I’m not. I’ve got separate instances building the Les Misérables blog, the reviews, the tech tips, the creative writing collection, and so on, plus I have this WordPress blog and a bunch of hand-coded HTML from the old days.

Which leads to a few problems:

  1. Tags are per-section, not universal.
  2. The site search, which indexes html files on the server, sees everything except the WordPress posts, and the WordPress search *only* sees the WordPress posts.

Some ideas I’ve had to combine the tag pages:

  • Rebuild everything in a single Eleventy instance with a deeper hierarchy. Upside: Still static pages for everything except WordPress. Downside: Time-consuming, still leaves the main blog separate.
  • Write a post-build script that combines all the the tag pages from each subsite. Upside: Same. Downside: Need to either run on the server or make sure my local copies of the *other* subsites are current.
  • Write a server-side page that combines the backend HTML pages into a dynamic frontend for only the tag being viewed. Upside: simple. Downside: tag pages now depend on PHP.
  • Write some client-side JavaScript for the tag pages that will check whether other subsites have tag pages, and add those to the end of the list in a “See also…” section. Upside: simple, and the “local” tag pages are still usable as long as I make sure the script doesn’t block anything. I could even have it check the other static subsites first and then check the blog, so if the blog times out I still display everything else. Downside: requires JavaScript and additional network requests. But as long as I stick to vanilla JS, I can make it pretty small.

And for unifying the search:

  • Write a post-site-indexing script that adds the WordPress posts to the index. Could be done with direct DB access.
  • Write a pre-site-indexing script that generates a bunch of files for it to index. Seems like overkill.
  • Update the search code to send the same search terms to WordPress and combine the results.
  • Use a new search engine that indexes the served pages instead of the files on the server.
  • Point the search box at a remote search engine like Googl…yeah, never mind.

I haven’t settled on anything. I’m just kind of writing down ideas in public. If you have any suggestions, please let me know!

I’ve been meaning to write a post about email newsletters that still assume you’re reading on a desktop and send out layouts that rely on a wide screen size and end up with tiny 2-point type on a mobile phone — you know, where most people read their email these days.

Then I stumbled on this usability article by Jakob Nielsen.

From 2012.

It pretty much covers what I would have said, and more. But a decade on, I still get email I can’t read without moving to a bigger screen.

The Time Before Tables

The funny thing is that HTML, by design, already adjusts to different sized displays, windows and terminals. In the very early days, you couldn’t make it not be responsive unless you added a block of pre-formatted text.

Once HTML picked up a little more rendering capability (tables, images and image maps), you had people designing websites who were accustomed to fixed-size media, and the paradigm stuck.

— Build your layout in Photoshop at 800×600, then slice it up into clickable pieces and reassemble the whole thing on a page!
— Wait, now we can aim for 1024×168!
— Oh, hey, we have widescreen now!
— Huh? What do you mean the window isn’t always fullscreen?
— Phones now? Ugh, I’ve gotta make a totally different website!

And so on.

Responsive Styling

These days you can apply relative sizes to everything, and tweak the layout based on the logical screen size instead of physical pixels. (Shout-out to high-definition displays here!) Modern HTML+CSS is amazingly improved in flexibility, and if you plan it right, you can often just rearrange the same page for screens from small cell phone size up to those widescreen monitors. Obviously this depends on what kind of site or application you’re building.

But for email, especially for newsletters, where reading the text is the main point, it should be an obvious choice!

Expanded from this thread on Wandering.shop.

WP Tavern summarizes the conversation around WordPress losing CMS marketshare for the first time in ages, and what various people have cited as likely causes.

Personally, I’m finding its increasing complexity to be a major frustration.

  • Writing on WordPress has gotten somewhat more complicated.
  • Maintaining a WordPress site has gotten more complicated.
  • Developing for WordPress has gotten more complicated.
  • The resulting page code (including CSS and Javascript) has gotten a lot more complicated. As I’ve noted before, there’s no good reason to require 450K of data to display a 500-word post. Or a single link with a one-sentence comment.

The move towards Gutenberg blocks and full-site editing complicates things on several levels, and feels like an attempt at lock-in as well.

Ironically, I’ve been moving toward Eleventy, which has also been very frustrating…but only in building the layout I want.

On one hand…

  • I have to develop a lot of the components I want from scratch. More than would have thought. Though I suspect there are enough pre-built layouts out there for most people’s use cases.
  • The documentation is sorely lacking. (Eventually I’ll get around to helping with that.)
  • Dynamic features like comments need to be handled by another program.

But on the other…

  • I can fine tune things a lot more easily than fine tuning a WordPress theme.
  • Once I’m done building the layout, adding a new post is almost as easy as it is on WordPress.
  • My actual post content is portable.
  • There’s essentially no attack surface, so if I have a site that’s “done” I can just build it one last time and leave it as-is — and not worry about spam, maintenance or security (beyond general webserver security).
  • I don’t have to send extra JavaScript libraries along with every page, so it can use a tenth of the bandwidth and load faster on slow connections.

With Eleventy, setting up the layout and features has been super complicated…but once it’s set up, it’s smooth, easy to deal with, and does the job well. It’s kind of like running Linux back in the 1990s.

But with WordPress, there’s complexity in every layer.

Sometimes it’s worth it.

Sometimes it’s not.

I’m not ready to give up on the flexibility of WordPress for my main blog yet, but holy crap are these pages heavy. Even with compression. There’s no reason it should take 450K (before compression) and 20 requests to display a 500-word post.

And I don’t even do ads, popups, social sharing buttons or anything else like that.

By contrast, my Les Mis blog, where I post about once a year, is currently generated by Eleventy using a custom minimal theme that only takes around 10K of HTML, 3K CSS, and a third request for the icon. And another 40K for the header font, which I recently set up locally so it no longer has to call out to Google Fonts.

One domain, just four requests, and only 50K for the first hit and 10K for each subsequent page.

Never mind the Gemini version of the blog which is around 2-5K per page and a single request per page!

Compression cuts down on those 500Kb WordPress pages — all the text and code compresses really well so only around 200K bandwidth is needed. But it’s still got multiple JavaScript and CSS requests going on.

I was able to cut it down significantly by switching to a lighter theme and turning on the minimize/combine feature in WP-Optimize so it’s making fewer script calls. But it’s still way bigger than the minimalist setup I have with 11ty.

Some of it is images, though. I still have my latest Flickr posts in the sidebar, and I’m using Jetpack’s related posts feature which includes thumbnails. I could cut out a big chunk by removing those, but I kind of still like the idea of having them in there.

I think I need to take a look at how much extra stuff I really want on this site and rip some of it out. Eventually I’d like to replace all the JetPack features because they just seem to keep adding more scripts. Plus I want an entirely local stats package instead of one that’s offloaded to a third party even if they’re less awful than, say, Google or Facebook.

On the other hand, I want to keep Gravatar on the comments sections (on the older posts where people actually commented) because that’s actually useful to readers as an aid for following a conversation better. But that’s all on top of the base page size.

Originally posted at Wandering.shop