And it's up! Thanks for waiting!
3,792 karma · joined November 22, 2014
Reflame came out of the frustration I continue to experience with the current state of frontend dev tooling and infrastructure. I've worked with some of the most amazingly talented frontend teams I could ever hope to work with, and we were always able to ship great software to customers at a breakneck pace when it truly mattered.
But looking back, this was in spite of the tooling and workflows that were available to us. At almost every step past local development, the tools and workflows we used ended up removing our ability to iterate with an tight and effective feedback loop, which I firmly believe is _the_ key to developer productivity.
The feedback loop is why many of us fell in love with local frontend dev tooling when we first started working with frontend, and why we keep pushing the envelope to tighten the feedback loop further and further, starting from manual reloading that took on the order of seconds, to live reloading that automatically reloaded as we saved, to hot reloading that preserved app state with sub-second latencies, and most recently to fast refresh that can achieve latencies in the double digit miliseconds.
Reflame is an reimagining of the end to end frontend development workflow that will empower us to _ship_ software with the instantaneous feedback loop that we love, not just develop with it locally.
If that sounds interesting to you, please head over to https://reflame.app/ and add yourself to the waiting list. Or feel free to shoot over an email to hi @ the same domain or a DM to https://twitter.com/lewisl9029 if you want to learn more, or just want to geek out about frontend dev. :)
Shipping a fix now, should be up in a couple of minutes (if only I could use Reflame to build the backend of Reflame... maybe one day...).
If you could open up a support chat so I can grab the user ID and get back to you when I have a fix, that would be super helpful!
I ended up having to start with create-react-app support, mostly because that's what one of my ideal early customers was using, and I wanted to make it as easy as possible for them to make the switch.
So hopefully once Vite support is ready, that could unblock your use case? (though I guess you'd also need to be willing to switch to React from Preact, which I realize is not a small ask)
Re: open source. I do actually intend to open source pieces of it. The VSCode extension is an especially great candidate since it's relatively well contained and doesn't require any specific infra to run.
Open sourcing the backend pieces probably won't happen anytime soon though, because it is very tightly coupled to very specific infrastructure (fly.io, NGS, FaunaDB, Dynamo, just to name a few), and there's a ton of moving pieces that all need to be configured to precisely to work together in order for even basic functionality to work as expected (especially in a geo-agnostic setup, like the one I'm current operating).
The support overhead for a self-deployed setup would be absolutely massive, and I'd have to think really hard about taking it on even for a lucrative contract for a large enterprise client (and the answer in the end would probably still be no). There's no way I can possibly offer that for free while making any progress on improving the service.
What Reflame does require is turning on the `isolatedModules` compiler flag in your TypeScript config, so it can help you avoid features that would block isolated module compilation (that would similarly block things like Babel/SWC that only transpile individual modules as well).
Luckily those features are rarely used to begin with, here's the relevant bit in the example TypeScript repo with more about this: https://github.com/reflame/example-typescript/blob/main/tsco...
There are obviously very good reasons why we mostly don't do that anymore, but you can't deny how great of a feedback loop that was for shipping to production. We've lost that for the longest time with this new generation of development workflows that take latencies of minutes for granted.
With Reflame I want to restore that awesome feedback loop for shipping we used to have, but this time with all the modern niceties with source control for collaboration and different preview environments to test changes in, so we can have the best of both worlds.
If you're using Next as mostly a static renderer for an app that doesn't absolutely need SSR, then it could work as long as you're willing to fiddle with configuration a bit and change some code. If this becomes a popular migration path, we'll definitely look into automating the process like we've done with create-react-app.
To answer your question, the system is definitely not as flexible as I'd like it to be today. The eventual goal is for Reflame to support many of the most popular development toolchains out of the box, enough to make it possible to run alongside them in the same codebase, across many frameworks.
But we have to start somewhere, and create-react-app is where we've focused our attention so far. I want to work on supporting Vite-based React apps next, and where we go from there is pretty much entirely up to community demand.
There's also no technical limitation stopping Reflame from supporting frameworks outside of React. In fact, I'm pretty sure if you stuck with production mode live previews that do full browser refreshes on every change, you could just swap out the React initialization code in the entry point with a Vue/Solid/Angular version and it should work just fine (hit me up if you end up trying this and running into blockers, happy to look into what it'd take to unblock this use case). However, there's just a ton of work that needs to go into building a first-class HMR-style, state-preserving workflow for each framework, and until then I wouldn't be comfortable with advertising first-class support for them.
Unfortunately, I don't think we'll ever be able to support a fully custom webpack config that's not based on a popular preset like create-react-app. The surface area to cover is just too gigantic there.
The things in build pipelines today that you mentioned (linting, testing, events/webhooks), are all things that Reflame will eventually try to build versions of, with a focus on speed similar to what we've done with deployment, but they're definitely not there today.
This means if you want those things (and most reasonable people probably do), you do still need to install and run them locally and in whatever existing CI pipeline you're currently running them in.
The difference Reflame makes even in this context is that your deploys, both to preview and to production, are no longer blocked behind all of those frustratingly slow processes that break your flow every time you hit them:
If you want to share a work in progress with someone else, you no longer have to wait minutes for a preview to go up. It will be up the moment you made your changes.
If you have a production issue where you need to ship new code to fix, you no longer have to wait minutes for a build pipeline to run, during which your product will remain broken. It can go live as soon as you're done coding the fix.
Most importantly, having instant deploys unblocks a ton of opportunities around running tests and checks against the live production deployment, either as sanity checks that run after shipping with notifications on failure, allowing you a chance to revert (also instantly) if you broke something, in order to maximize the efficiency of the feedback loop (this is the approach I'd recommend and build first), or as a blocking safety net that can prevent broken changes from reaching customers in exchange for adding more friction to deploy every other good changeset (I'll probably build this eventually given enough demand, but would recommend that it be used very sparingly).
Yep, but one important thing to note is this "slow the first time" behavior is limited to npm package installs only. Deploying a ton of source code changes at the same time is still going to be a bit slower than a single module due to sheer network and compute constraints, but the cache is fully granular here, and the processing pipeline is pretty well parallelized so should still take well under a second in most cases. Basically, the only time you should see a slow deploy in Reflame is when you update npm packages (and I hope to change this soon).
And understood re: your desire for reproducible builds, I hope to to add some level of lockfile support in the near future, will let you know through product update emails since you're already signed up! :)
> And if I were starting a greenfield project using Reflame from the get-go, I'd still worry about broader ecosystem compatibility... like if Reflame goes under (god forbid), will my repo still be portable to other buildchains and hosts?
This is a really valid, and probably super common, concern that I can totally empathize with. The best solution I've been able to think of is to make Reflame work seamlessly with existing toolchains, to the point you can have both Reflame and a local toolchain (and possibly another deployment provider that deploys using that toolchain) running on the same codebase simultaneously. This way there ends up being 0 risk to trying out Reflame, since you can run it side-by-side with your existing toolchain to compare, and can always swap back to the local toolchain + deployment provider by just removing Reflame if it doesn't work out.
We're not there yet for the vast majority of toolchains out there (there's a lot of them haha...), but we have built in some preliminary support for create-react-app, so if you have an existing create-react-app project, you can connect Reflame to the repo and it will detect you're using create-react-app, make the necessary config customizations to support it, and will start deploying it without requiring any major code or config changes afterwards. Give that a shot if that would alleviate your concerns around longevity and lock-in!
The next toolchain I'm hoping to do the same for is Vite-based React apps, but definitely open to changing that based on demand!
I wanted to err on the side of _enabling_ an identical-to-production development workflow, because AFAIK nothing else really offered this. So the cookies approach is what I ended up starting with, and I also built a UI to help make the difference abundantly obvious: https://reflame.app/~r/start-preview/?mode=production&varian...
Even still, subdomains are definitely less confusing though, and doesn't lead to the same kind of strange behaviors that you could only make sense of if you understood exactly how cookies work and how Reflame makes use of them (a tall order, I'm not even sure if I do 100% today). I may eventually also offer a subdomain version of these previews, for those who might be collaborating with less technical folks who are more likely to be confused by the cookie-based implementation.
This why I ended up building a small UI overlay to show the current preview and allow exiting the preview and switching between prod/dev modes (in fact I just shipped this yesterday in preparation for the launch since I knew it would make a huge difference to developer experience).
This is not in the demo because it was recorded a while ago, but take a look at this Live Preview I just created to see what it looks like: https://reflame.app/~r/start-preview/?mode=development&varia...
So Reflame does not use any of the exact same high-level, user-facing tools you might be using locally, like vite, webpack, npm, yarn, etc. Those tools are designed to be ran locally, and so if we wanted to run them on a server in a shared environment (e.g. in CI), we'd need to spin up a VM, install those tools, git clone the repo, before even starting to do any real work. This makes it impossible to offer the kinds of latencies Reflame is targetting.
To answer your question on what Reflame actually does: it composes a bunch of the low-level primitives behind the tools we run locally (along with a boatload of custom code), and runs them in a server, against every single module that gets sent in through our GitHub app and VSCode extension, and then deploys the result.
For npm packages specifically, instead of running npm install, it currently makes use of the lower level arborist library that npm is built on top of, to run package installations server side, then transforms, caches, and deploys the results. This was done to get an MVP out quickly and is not an ideal setup at the moment, because the caching behind it is not very granular. The first time you install a set of packages our servers have never seen before, it can take a while, but subsequent times it becomes instant.
This is really the achilles heel in our instant deployment story, and something I want to work on soon is a custom package resolution system using content addressing, similar to pnpm, that's more amenable to space-efficient, shared granular caching.
Package locking and private npm packages (private github repos are already supported, in case that's what you were referring to?) are not yet supported, but should be simple to add on top of the existing system if there is demand. Let me know if these are blockers for you!
What's the pricing going to be like?
Pricing is still very much a work in progress. Feedback from early customers will play a major factor here. Here's my current thinking:
Reflame should be free to use for individuals deploying apps that live on the default *.reflame.dev subdomains. Deploying apps to custom domains will probably require a monthly fee, which will enable custom domains on all apps of the user (i.e. there won't be an additional fee for having more than 1 app with custom domains). For organizations, there will be a simple monthly fee per member, for any number of apps with custom domains in that org.
I'm planning to avoid usage-based pricing for the deployment side of Reflame if at all possible, because I don’t think it leads to a good alignment of incentives. I don't want to financially disincentivize customers from deploying as often as they want (within reasonable limits to protect against DoS), and I really don't want to be financially disincentivized to make customers' deploys faster over time. Every usage-based CI platform out there benefits financially from our builds getting slower, so have no financial incentive to build anything to make them faster. I believe usage-based pricing for CI and the diametrically opposed incentives it introduced has been a huge driver of stagnation in the industry.
What kinds of things should I not build with Reflame?
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.
Reflame is hyper-focused on the use case of iterating as quickly as possible on product dashboard apps (like https://dashboard.brex.com) 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.
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:
- Truly instant deploys, measured in milliseconds, regardless of how large your app becomes.
- Maximally efficient cache invalidation on updates, i.e. only modules that are updated (and the entry point html) are ever invalidated.
- Ability to preview changes as customers would see them exactly, down to the URL.
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.
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.
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.
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.
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.
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.
How does Reflame deploy so quickly?
Some major contributors:
- Reflame never does more work than absolutely necessary for any change. Every JS/TS module deployed through Reflame is transformed and shipped as independent ES modules. Only modules that have never been seen before are transformed and deployed (taking advantage of content-addressing to simplify caching). This means Reflame isn't just fast when our projects are small. It will stay just as fast as we scale to hundreds or thousands of modules. Because it will continue to do the minimum amount of work possible for every change.
- Reflame always deploys via the most direct possible path. A typical deploy of a trivial hello world project using a traditional CI service consists of: a git commit & push from our laptops, waiting for a webhook from github, spinning up a VM or container, cloning the git repo, installing npm dependencies, transforming and bundling source code, and finally uploading the output. Each of these steps has a latency floor measured in seconds, adding up to 10s of seconds of latency to deploy even the smallest change. Compare that to a deploy with Reflame's VSCode extension: we get a file change event, we upload the file, our server transforms it and stores the output for serving. Done.
- Reflame is completely region-agnostic. We haven't yet figured out how to make light move faster in fiber optics, but we can lower the effective latency floor it imposes by having servers close to our users. Reflame lives in 3 regions today: 1 in western US, 1 in eastern US, 1 in central EU, and we'll be adding more based on customer demand. Each region is a first class citizen. Updates in each region are visible immediately to users in that region, and replicated asynchronously to all others. We also have some magic in our CDN to ensure previews get routed to the originating region so customers can collaborate using previews across the world without dealing with replication delays.
Haven't found myself needing much else from a DB.
Really looking forward to Cockroach's serverless options too. More competition in this space is very welcome.
But the architecture itself has been used successfully in a bunch of apps, most notable of which is probably Linear (https://linear.app/docs/offline-mode, I remember watching an early video of their founder explaining the architecture in more detail but I can't seem to find it anymore (edit: found it! https://youtu.be/WxK11RsLqp4?t=2175)).
Basically the way authorization works is you define specific mutations that are supported (no arbitrary writes to client state, so write semantics are constrained for ease of authorization and conflict handling), with a client-side and server-side implementation for each mutation. The client side gets applied optimistically and then sync'ed and ran on the server eventually, which applies authorization rules and detects and handles conflicts, which can result in client state getting rolled back if authorization rules are violated or if unresolvable conflicts are present. Replicache has a good writeup here: https://doc.replicache.dev/how-it-works#the-big-picture
1. A strongly consistent globally replicated DB for most data that needs fast reads (<100ms) but not necessarily fast writes (>200ms). I've been using Fauna, but there are other options too such as CockroachDB and Spanner, and more in the works.
2. An eventually consistent globally replicated DB for the subset of data that does also need fast writes. I eventually settled on Dynamo for this, but there are even more options here.
I think for all but the most latency-sensitive products, 1. will be all they need. IMHO the strongly consistently replicated database is a strictly superior product compared to databases that are single-region by default and only support replication through read-replicas.
In a read-replica system, we have to account for stale reads due to replication delays, and redirect writes to the primary, resulting in inconsistent latencies across regions. This is an extremely expensive complexity tax that will significantly increase the cognitive load on every engineer, lead to a ton of bugs around stale reads, and cause edge case handling code to seep into every corner of our codebase.
Strongly consistently replicated databases on the other hand, offer the exact same mental model as a database that lives in a single region with a single source of truth, while offering consistent, fast, up-to-date reads everywhere, at the cost of consistently slower writes everywhere. I actually consider the consistently slower writes also a benefit since it doesn't allow us to fool ourselves into thinking our app is fast for everybody, when it's only fast for us because we placed the primary db right next to us, and forces us to actually solve for the higher write latency using other technologies if our use case truly requires it (see 2.).
In the super long term, I don't think the future is on what's currently referred to as "the edge", as this "edge" doesn't extend nearly far enough. The true edge is client devices: reading from and writing to client devices is the only way to truly eliminate speed-of-light induced latency.
For a long time, most truly client-first apps have been relegated to single-user experiences due to how most popular client-first architectures have not had an answer for collaboration and authorization, but with this new wave of client-first architectures solving for collaboration and authorization with client-side reads and optimistic client-side writes with server-side validation (see Replicache), I've never been more optimistic about the future (an open source alternative to Replicache would do wonders to accelerate us to this future. clientdb looks promising).
On one hand, the distribution power makes it extremely easy for new products to get lots and lots of users really quickly. On the other hand, it can give a false sense of security when it comes to product-market fit.
The only real solution I can think of is deliberately launching new products without the Google branding and without relying on the built-in distribution channels, working towards product market fit the hard way, and only after that should they consider taking advantage of Google's distribution power to accelerate growth.
In fact, the incentives are diametrically opposed in that almost every one of them makes more money when our builds take longer to run, regardless of the reason. So they are financially disincentivized to build anything that could make them faster, or even make it easier to limit the duration, as is the case here. When it does happen, it's a rare triumph of some combination of people with genuinely good intentions, customer demand, and competitive pressure, over the demand for financial returns that every company has to eventually come to terms with, and not sustainable over the super long term.
The ones that let us host our own runners at least offer us an escape hatch where we can opt out of the diametrically opposed incentive structure and back into a still-not-aligned but neutral one, but then we give up much of the benefits of CI as a SaaS and have to spend engineering hours building and maintaining our own build infrastructure at a significant cost.
Let's not forget that traditional CI in itself is already a commodity where providers sell us dumb CI minutes that we have to spend our own eng hours engineering deployment and testing solutions on top of, and eventually have to sink entire full-time engineering teams' worth of hours into fighting against the natural tendency for these systems to get slower as we add more code and people.
I believe the solution is deployment & testing platforms tailored to specific technologies, meticulously engineered to be so ridiculously fast that they can reasonably be offered as an all-you-can-eat plan for a fixed monthly price per seat, instead of the industry standard usage-based pricing of traditional CI providers. This aligns incentives much better in that slow builds hurt the provider's bottom line as much as they hurt customers' engineering productivity, and on the flip side it financially incentivizes constant investments into making the system even faster from the provider side since faster builds means they can serve more customers on the same hardware and pocket the difference as profit.
Shameless plug: I've been building one of these platforms at https://reflame.app. Reflame can deploy client-rendered React web apps in milliseconds, fast enough to make deploying to the internet feel like local dev.
If not, is anyone doing anything to improve this situation?
Sending packets over the internet across the farthest ends of the earth takes about 300ms roundtrip. What's preventing email from approaching this?
Latency is the biggest UX issue facing email IMHO, and a huge part of why it is continuing to lose ground vs alternative messaging systems, most of which are proprietary, but offer sub-second latency delivery. The world will become a worse place if the trend continues to its logical conclusion and proprietary silos eventually fully supplants email's remaining use cases.
The high average latency and even higher variance leads to people second guessing if an email they sent will ever arrive, and if an email they're expecting has ever been sent, resulting in crude workarounds like resend buttons becoming commonplace and seen as necessary, perpetuating the uncertainty around deliverability, and even further eroding trust in the system.
But most importantly, the latency problem makes email unsuitable for the most compelling use case for messaging platforms: real-time conversation.
Holding a spontaneous real-time conversation over email is painful, as anyone who has tried can probably attest. Both sides are constantly left wondering if the other side is simply taking their sweet time to reply, or if the email is just taking even longer than email usually takes to get delivered. Conversations that could have taken mere seconds end up taking minutes as a result.
This is why email has been consistently losing to messaging apps for fun conversations between friends where email's latency would suck much of the fun out of them, to Slack for mission critical work conversations where wasting time means literally wasting money, to live chat widgets for businesses looking to provide a customer support experience that delights, whereas conversations over email frequently tends to frustrate, the list goes on...
Solving the latency problem for email I believe is the key to slowing and possibly reversing the trend of email's slow but steady decline, and society will benefit massively from the continued prosperity of this rare miracle of an open system that managed to survive for so long despite all its shortcomings.
At first glance this seems to be mostly targeted towards single-user apps where each user would have their own database that can be sync'ed to a remote server, but still isolated from data for other users, similar to the CouchDB+PouchDB model?
At least it looks that way since I couldn't see anything around authorization and conflict resolution. Not that there's anything wrong with focusing on this use case, a lot of apps can function perfectly fine this way.
A few other interesting new players that use an optimistic local update + server validated mutation model to support collaboration:
Phone inputs are especially painful to mask since you have to deal with a mind-boggling number of format variations.
This video goes into some of the design and tradeoffs: https://www.youtube.com/watch?v=Jc_L6UffFOs
TL;DW: they optimized for fast creation/destruction of low-footprint VMs with no JIT or garbage collection.