New customer trying out the @ReflameApp component testing product for the first time. 🙂

Wow, this is insane! If you don't know @lewisl9029, he is one of the few 10x engineers I've met in my career. He quit Brex to build @ReflameApp and solve issues we faced on a daily basis. Check out his latest demo 🤯

Yoooo! @highlightio made their deploys 100x faster using @ReflameApp 🤯🔥

Just finished recording a new demo for @ReflameApp that includes our new component testing product! Now the demo on reflame.app is no longer 2 years out of date haha... And it's 2 minutes shorter! And hopefully at least as compelling. Let me know what you think!

Automatic PR/commit previews was definitely a game changer when I first encountered it on Netlify! @ReflameApp's previews introduce a few interesting twists that I believe can make the preview experience even better: - All previews use the same origin as production, routed using cookies. This means previews behave completely identically to production by default, hitting the same APIs, using the same local storage, with no need for special configuration in third party redirects, CORS, etc. If our changes work in a preview, they're guaranteed to work the same way once deployed to production. - In addition to commit/branch previews, we also introduce the concept of a "personal preview", that gets deployed every time we make changes to our apps locally using the VSCode extension. Changes get reflected within milliseconds in our browsers and are applied using React Fast Refresh. It's a similar experience as a traditional local dev environment, except we get much better production parity (uses the same origin as production, has https/http2, can flip to production mode to preview/benchmark/debug with fully optimized output, etc), and we can share it with anyone in the world just by sending a link (and they'll see our changes in real time with React Fast Refresh over the internet).

While forcing teams of 11 people into opaquely priced (starting at ~$2k/month) "Enterprise" plans still feels pretty ridiculous to me, it's just another pricing lever that they have every right to tweak with. It's the way it's hidden that feels rather questionable ethically.

Down to a much more reasonable 7s for 250 screenshots now. It could be <5s if these screenshots weren't gigantic to the point they take whole seconds just to capture. Got some ideas to try out. Here's the live results page: github.com/lewisl9029/radix-… And yep, it's Radix UI! 🙂

Started onboarding a project with a lot more stories. 250 screenshot diffs in 18 seconds. Needs a lot of work, but better than their current setup (~5m). Playwright's screenshot capture speed is starting to become a bottleneck. Takes more than 2s for some larger screenshots.

5 seconds flat. LFG.

Discovered and knocked out a bunch more screenshot flake sources from video loading/playback and font loading for @ReflameApp component tests. I'm sure there's more to find, but at least from the projects I've onboarded so far, the diffs are starting to look pretty solid. :)

Just got this down to single digits by handling a few more error conditions properly instead of letting tests time out.

Interesting implication of the @ReflameApp testing product I've been working on: Every test suite run is basically a mini DOS on our serving infrastructure! 😱

💯 @ReflameApp actually evolved from my early experiments with buildless dev workflows (github.com/lewisl9029/buildl…). I eventually had to come to terms with how there just wasn't enough intrinsic value to buildless to justify all the incredibly compelling capabilities we'd lose compared to having a build system. The biggest extrinsic advantage to buildless was the speed of the feedback loop, which does make a huge, tangible difference to DX. This led to a new hypothesis: that it's possible to create workflows with build systems that are so fast they'd feel indistinguishable from buildless workflows. That's when @ReflameApp was born.

Getting _really_ close to launching the next big piece in @ReflameApp's vision. 🤐 Just updated the welcome email, and I actually plan to put the waitlist back up before launch, so sign up now if you want a sneak peak. 🙂

Sounds like OP uses CF Pages. Curious if this happens for Vite apps on Vercel/Netlify at all? I consider never having to worry about breaking resource links on deploy one of the killer features for client-rendered apps. Would be a shame to not be able to take advantage of that.

You all are missing out on @ReflameApp 🔥⚡ Saw a React App deploying SO FAST, that the deploy is done before the github action UI Element even loads on a PR 🤣 Thread talks about a parallel flow to support monorepos that is 10x slower... its still 15 seconds. 15 Like WTF 🤯.

Been building a 10x slower version of @ReflameApp. Takes almost 15s to deploy. Downright painful to watch. 🤦 Why? 👇🧵

Another @ReflameApp feature I snuck in over the last few weeks was SVG components support! 🥳 This means we can import SVGs as React components, like we could with SVGR, but with a twist: We bundle all SVGs into a single sprite, and components just point to ids in the sprite!

Missed a few updates for @ReflameApp in the past few weeks since I was heads down working on product, so will be doing a bit of catch up over the next few days Starting with first-class environments: We can now create envs and update env vars on reflame.app! 🎉

Just shipped automatic NPM package entry point updates for @ReflameApp! 🎉 This should make onboarding new apps a lot less painful, since we'll now detect entry points to NPM packages based on usage, and we can even add them for you in a new commit through our GitHub App!