LTheme already existed for Pelican and Hugo before this port. Both are solid static site generators, so the honest question is why bother with a third implementation on VitePress at all.
Markdown-it is a real extension point
Pelican and Hugo both have plugin systems, but they sit at arm's length from the renderer — you're configuring a black box, not extending it. VitePress hands you the actual markdown-it instance in markdown.config(md). LTheme's Tufte-style sidenotes (^[...]) and the :::writing container aren't config flags bolted onto the theme — they're a couple dozen lines each, registered as ordinary markdown-it rules. Anyone who's written a markdown-it plugin before can read them in five minutes.
The theme is just Vue
A VitePress theme is a Vue app: Layout.vue, some composables, some .vue components. There's no templating DSL to learn on top of the framework, and no separate build pipeline for theme assets versus content — one Vite config handles both. That's the whole reason this theme's CSS bugs have been fixable by reading actual computed styles instead of guessing at a static-site generator's internal layout conventions.
Dev server speed changes how you work on layout
Vite's dev server does instant HMR on both content and theme CSS. Every mobile breakpoint fix on this site so far — the padding bug, the sidenote toggle, the sidebar stacking — went through dozens of resize-and-reload cycles. On Pelican or Hugo's built-in servers that loop is seconds slower each time; over a session of layout work that adds up to real friction.
What you give up
VitePress is Vue-only — if you're more comfortable in React, or you need Hugo's content-heavy taxonomy features out of the box, this isn't the pragmatic choice. It's also younger and smaller than Hugo, so fewer existing themes and plugins to lean on. LTheme on VitePress trades that ecosystem breadth for a tighter loop between "I want to change how this renders" and "I can see it."