1.0.0

Unless I think of more stuff to add, this is probably my last devlog before shipping.

Lume Theme Registry

A few hours ago, the PR that I created last devlog was merged into the official Lume theme registry, so you can now install my theme with a single command using Lume init, and it now has its own dedicated page on the official Lume website: https://lume.land/theme/tufte/.

README

• I added a How it Works section that explains how the Lume theme architecture works behind-the-scenes (spoiler: it’s just remote files) and explains what each of the 18 included plugins do.
• I updated the quickstart to use the Lume init command.
• I added a Showcase section that lists the sites that use this theme. It seemed kind of weird to exclusively list the Tufte theme site itself, so I also switched one of my documentation sites to use the Tufte theme.
• I added a shields.io badge to the top of the README that links to the theme’s page on the Lume website. shields.io relies on simple-icons for its logos, but simple-icons doesn’t have the Lume logo for some reason, so had to Base64-encode an SVG of the Lume logo in order to get the badge to work.

Next steps

I’m not going to ship this project juuuuust yet in case I think of any missing features that I ought to add, but I probably will soon.

Theme Registry PR

I just created a PR to add my theme to the official theme registry for Lume: https://github.com/lumeland/themes/pull/10.

Why

If my theme isn’t in the official registry, the best way for users install it is to clone my entire repo, which is silly, bad for separation of concerns, and just generally worse for UX.

git clone https://github.com/ethmarks/lume_tufte.git
cd lume_tufte
deno task serve

But if I get my theme into the theme registry, users can install it using the official Lume init command, which is much better in every way:

deno run -A https://lume.land/init.ts --theme=tufte

Conclusion

From my interactions with him in the past, the Lume maintainer (Oscar) seems like an extremely nice dude who seems to respond fairly quickly, so I shouldn’t have to wait too long before he either accepts my PR or suggests changes that I can go implement. Meanwhile, I’ll probably continue working on the README.

README, optimizations, and more

Since my last devlog:

1. I wrote the README.
2. I optimized the theme until it earned perfect 100s in every category on Lighthouse on every page.
3. I added a light mode.
4. I added support for tables of contents.
5. I added RSS feed generation.
6. I rewrote one of the demo blog posts.
7. I added styles for HTML tables

Link to the diff between last devlog and this one

Optimization

Most of the work I did today is pretty self-explanatory from my little summary, but the optimization work probably merits elaboration.

So while I was writing the README, I had the idea to include the Lighthouse scores. When I checked, they were 100/100/100/92 on mobile and 92/100/100/92 on desktop.

“100s on Lighthouse in some fields” doesn’t sound nearly as nice as “100s on Lighthouse in every field”, so I decided to start optimizing. Lighthouse told me that the SEO problem was a lack of descriptions, and the desktop performance problem was excessive network requests and chained network requests.

SEO problem

I fixed the lack of descriptions by adding descriptions. Simple as that. I wrote descriptions for all of the existing pages, added a description field to the CMS config, and added a mention of it in the usage guide. The network requests and chained requests were a bit trickier to solve.

Performance problems

The cause of the excessive network requests was that, even though the homepage didn’t use the KaTeX or Nueglow styles, they were still being imported. I solved that with a per-page check that runs at build time. Each page only imports the Nueglow stylesheet if it contains code blocks, and it only imports the KaTeX stylesheet if the page contains math blocks. Here’s a link to the relevant section of code. I think that it’s a pretty clever solution because it selectively removes the unnecessary CSS requests without using client-side JS or anything like that.

I used a similar approach to solve the chained requests. What was happening is that in order to download the woff2 files, the browser first had to download the CSS files, so it took twice as long because they couldn’t be downloaded in parallel. Font preloads are the way to solve this. The only problem is that if I preload too many font files, the browser will have download font files even if they aren’t used on the page. But if I preload too few, then the network requests are still chained. My solution was to have it check which font files each page needs and selectively preload only those font files. Here’s the relevant code if you want to see my implementation. Again, this solves the problem of unnecessary requests and chained requests without adding any client-side JS.

I’m glad that Lume and Vento are such powerful tools that I can easily do programmatic optimizations like this.

Next Steps

I think that the next thing I should do is submit my theme to the official Lume theme repo. That way I can simplify the installation process down to one command.

Hi there! This is a project I’ve been working on for the past week. It’s a theme for Lume SSG based on Tufte CSS.

Btw, I did the majority of the work before I started using Hackatime, so I’ve been working on it for a lot longer than 5 hours.

I’m just going to briefly tell you about everything that I did before I started tracking with Hackatime.

1. I looked through the Lume source code to figure out how the poorly-documented theme APIs work.
2. I copied the tufte.css file into the project. Then I downloaded the font .tff files, compressed them into .woff2 files, and wrote css font-face rules for them.
3. I made some Vento layouts.
4. I created, styled, and wrote the logic for the site header.
5. I wrote the blog post and blog index layouts and created the BlogList component.
6. I started installing Lume plugins like KaTeX and Nueglow.
7. I started writing the “Using this theme” post.
8. I created the tufte-sections and tufte-notes plugins for markdown-it.
9. I began heavily tweaking and customizing tufte.css.
10. I transcribed every word of the TufteCSS homepage from HTML to Markdown.
11. I started configuring LumeCMS.

Most of what I’ve done since then (what’s reflected in the 5 hours I’ve logged with this devlog) has been a lot of writing, mainly in the Using this theme post. I’ve also been adjusting the LumeCMS config a lot.

I think that the next thing that I’ll do is write the README.

Thanks for reading!