So, couple facts about this SSG's design that nobody will ever read:<p>1. It's hyper-efficient with how it reloads modules, to do the absolutely least amount of work necessary. If a file hasn't changed, it's not touched. If a .ts/.tsx file hasn't changed and nothing depends on it, its exports aren't touched. If it hasn't changed but something has that depend son it, it's function isn't recompiled, only its exports are re-exported by re-running it.<p>2. Everything in src/ is normal, but everything under site/ is loaded by src/ and compiled via sucrase, and run in its own runtime. This is what allows the psuedo module system above to be so efficient. It's also what makes the JSX feature so simple and yet fast.<p>3. The JSX syntax essentially compiles down to an object like {tag:string, attrs:object, children:any[]}, which can be manipulated at runtime. This allows for script/style/link hoisting and de-duplicating, which means you can put a css link in a component that's used multiple times in the site, but only loaded in the HTML once, and pulled up into the head element. It's turned into a string by walking the tree and adding to an array and joining it when done. I think it can be improved. For a while it was in the site/ runtime but I saw no benefit to that.<p>4. Import just uses require under the hood, and importing any file claims a dependency on it which reloads your file whenever the depended-upon file changes, whether the one you're importing is a normal ts/tsx module or a resource file (css, js, jpg, etc).<p>5. Importing a file tree returns a list of every file under that tree recursively, including future dependencies. So if you `import files from './images/';` then it will reload the file containing this import not only when a file changes in ./images/foo/bar/ but also when one is added or removed from it. This is really helpful in reloading when e.g. new data files are added. And the fact that it returns a flat list of "absolute" file paths (relative to site/) makes it easy to operate on and filter through.<p>6. When you import a static resource (jpg, css, etc), it returns {path:string, content:Buffer} as well as claiming a dependency on it, so that you can e.g. use the path in a href, or examine its buffer and do something with it, etc. Eventually I want to reintroduce the concept of dynamically generated routes, e.g. given a font dir, you can currently use the Font component, but it genereates a script tag; it'd be better if it introduced a link tag that can be cached by the browser.<p>7. Components with this are super cool and easy to use, but there's a lot of low-hanging fruit. I'm in no rush to see what kind of things I can do with it, but it's already picking up speed in the past few weeks. One of my next challenges for myself is figuring out how to use the dynamic static resource concept in point 6 to generate unique IDs for pseudo-scoped-css, similar to what react styled-components and all them did.