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 🤯
Just finished recording a new demo for @ReflameApp that includes our new component testing product!
Now the demo on https://t.co/47Gi4IQkdn 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).
@gunta85 Ah that's perfect! Take a look at the example here for how to configure those:
https://t.co/TkTV7XH5Z9
Just add another item in the array with the @ replaced with ~ to support both!
@gunta85 And then configure the same aliases on the Reflame side by adding something like this:
specifierTransforms: [
{ from: "/", to: "@/" }
]
Which would allow us to import anything in the source folder with "@/path/to/file".
@gunta85 And then configure the same aliases on the Reflame side by adding something like this:
specifierTransforms: [
{ from: "/", to: "@/" }
]
Which would allow us to import anything in the source folder with "@/path/to/file".
@gunta85 We do actually support absolute paths for imports, in the form of `import url from "/icons.png"` (relative to the src folder, not public), but Vite doesn't.
One way to set up a form of absolute imports could be to use something like https://t.co/xyJrjW5PoC on the Vite side...
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: https://t.co/r3X7KISWdM
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.
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. :)
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 (https://t.co/9dhyLp3x33).
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.
@gunta85 Right now, installing and bundling NPM packages is by far the slowest part of the system, so we don't want it happening randomly when you import new subpaths in your app code.
This makes sure it only happens predictably when you update your config/package.json.