(posting some extras as comments since the original post is already way too long)<p>What kinds of things should I not build with Reflame?<p>Reflame in its current state can only deploy client-rendered React apps. So it comes with the usual caveats with client-rendered React apps around poor SEO, requiring JS to render anything at all, and offering non-ideal first visit performance. Some examples of the kinds of things you probably shouldn't use it for: marketing sites, ecommerce stores, social media sites, discussion forums, etc.<p>Reflame is hyper-focused on the use case of iterating as quickly as possible on product dashboard apps (like <a href="https://dashboard.brex.com" rel="nofollow">https://dashboard.brex.com</a>) that are usually locked behind a login that can't be crawled by search engines, where most visits are repeat visits from existing users with a primed cache.<p>For this very specific (but still fairly common) use case, it has several rather unique value props that I've never seen offered anywhere else:<p>- Truly instant deploys, measured in milliseconds, regardless of how large your app becomes.<p>- Maximally efficient cache invalidation on updates, i.e. only modules that are updated (and the entry point html) are ever invalidated.<p>- Ability to preview changes as customers would see them exactly, down to the URL.<p>The second point is key to why apps built with Reflame will be fast in practice. Instead of cargo-culting lighthouse scores that emphasize empty-cache first visit performance which are few and far in between for this class of apps, Reflame focuses on what actually matters for this use case: maximizing cache granularity and minimizing cache invalidation in the face of frequent updates.<p>Every JS/TS module deployed through Reflame is transformed and shipped as independent ES modules, served using content-addressed url references, with immutable, far-future cache headers, and loaded with maximum parallelism with HTTP/2 through modulepreload links to flatten the module loading waterfall.<p>The content-addressed url references are translated using import maps instead of with url rewrites. This further minimizes write-amplification such that only the import map and the specific updated modules need to be updated, instead of having to update the updated modules and every dependent module recursively to the root (due to the content addressing), which would result in a potentially unbounded update latency ceiling and invalidation blast radius. We also create proxy modules for non-js resources such that they can be imported as string URLs, instead of rewriting the import statement, also in service of minimizing write-amplification.<p>All of this means that a user loading an app with built with Reflame a second time will only have to download the new html and specific, independent modules that have been updated since the first time, instead of a gigantic bundle of hundreds of KBs of JS every time any single module is updated.<p>However, the unfortunate reality today is, even with a fully flattened and parallelized module loading waterfall with HTTP/2, there is still a tangible overhead to loading 100s of independent modules at once vs a handful of large bundled modules. I'm hopeful that dynamic server-side bundling with WebBundles might be able to offer the best of both worlds someday in the future, but today this is an unavoidable tradeoff.<p>So, fundamentally, an app built using Reflame trades off some efficiency of the initial empty-cache visit for the best possible efficiency of subsequent primed-cache visits, even in the face of frequent updates. As I mentioned in the first paragraph, this is not a great tradeoff for many common use cases (so you shouldn't use Reflame for those use cases), but I do believe it is the ideal tradeoff we have available today for the kinds of apps I'm hoping to target with Reflame.