This post is meant for very senior devs, people who have been writing code at least as long as I have, meaning at least decades.
You know well that after about 20 years of writing your own software, you get to a point where it's just infeasible to maintain your own projects, so you hand them over to the community, or you encourage competing projects to create the features you need.
I'm at that point with the static site generator I developed within my blog over the past 3 years and eventually extracted into a framework in the hopes that it would catch on and be polished up by the community.
Since that didn't happen, I'd rather that the features I need be replicated in another framework, so that I can migrate to that and move on. But until then, here are the features that are still uniquely in my own framework.
Every framework assumes I want to use React or something similar. I don't. I want to use JSX to compose and produce strings for the static files, and to compose and produce DOM elements in the browser. That's it.
And because JSX is now just syntactic sugar for nested objects, code can be shared between front-end and back-end, as long as they don't rasterize the JSX within that file. This makes shared components natural.
JSX is maybe the only good thing to come out of React, and experience has proven that it's perfection compatible with JavaScript. Eventually it will be standardized. But babel and deno and bun closed my proposal.
My framework implements that proposal as a babel plugin, so that I get all the benefits of JSX but without magical imports or bloated frameworks.
It's natural to use JSX for the view of HTML when generating files, and it's therefore natural to use TypeScript to generate HTML files. So when a file ends with .<ext>.ts|tsx, its code is run and its default export becomes the file(s) at .<ext>, such as about.html.tsx becoming about.html.
This also ties in well with the idea that data files are just dirs I can import, and pushes the model concept entirely out of the framework.
At some point, I stumbled on the idea of naming a file [article].html.tsx to indicate to the framework that it doesn't produce a single file, but an array of files, where the [article] portion is replaced by a string in each item in the file's default-exported array.
Combined with the idea of importing entire directories as an array of file-like objects, it became the obvious way to produce folders full of articles. The syntax for this is literally just import blogFiles from '../blog/data/'