[HN Gopher] Show HN: Reflame - Deploy your React web apps in mil...
___________________________________________________________________
Show HN: Reflame - Deploy your React web apps in milliseconds
Hi HN! I've been working on Reflame since I quit my job at Brex
last year, excited to finally open it up for everybody to try out!
Here's a demo: https://www.youtube.com/watch?v=SohUnrjiIxk Reflame
deploys client-rendered React web apps instantly, to previews and
to production. In concrete wall-clock terms, deploys generally
take: - ~50-500ms from our VSCode extension - ~500-3000ms from
our GitHub app (Jump to this comment
(https://news.ycombinator.com/item?id=33134082) for what makes
Reflame so fast) The Reflame GitHub App automatically deploys
default branches to production, and other branches to previews. If
you've used Netlify/Vercel's GitHub apps, you should feel right at
home. The difference is it's multiple orders of magnitudes faster.
Fast enough that _you 'll probably never see an in-progress deploy
on GitHub ever again_, only ready-to-go preview/production links.
No more having to babysit builds or having to context switch to and
from other tasks before being able to see our changes deployed in
previews or production. Previewing, sharing, and even shipping, can
now become part of the so-called inner loop, giving us the
superpower to stay in flow state for much longer. The Reflame
VSCode extension is yet another order of magnitude faster than even
the GitHub App. It was designed to offer an experience that can
rival local development workflows in both speed and ergonomics,
while addressing many of local dev's limitations around
collaboration and production-parity. Every time we make a change
(e.g. by saving a file), the extension will deploy that change (in
~50-500ms) to a "Live Preview", and will immediately update the app
in our browsers to reflect that change. Live Previews can operate
in one of two modes: - Development mode delivers updates through
React Fast Refresh, offering the familiar state-preserving instant
feedback loop we know and love from local development workflows. -
Production mode delivers updates by triggering a full browser
reload on every change, and in exchange for this extra bit of
friction, we get to develop against a byte-identical version of the
fully optimized production deployment that customers will see once
we ship, with a tighter feedback loop than was ever possible
before. Live Previews deliver updates over the internet, meaning
we can effortlessly test out our changes on multiple devices
simultaneously, and show our changes to anyone in the world, just
by sharing a Live Preview link, all while having our updates
reflected automatically across all connected devices in real-time
(with live reload or React Fast Refresh _over the internet_ ).
Being able to ship quickly is valuable on its own, but Reflame's
true north star has always been to enable customers to ship quickly
_with confidence_. One way Reflame helps customers ship with more
confidence today is by making previews with full production-parity
available at every step of the development process. Previews in
Reflame are accessible at the exact same URL customers will use to
access the production deployment, instead of at a different
subdomain for each preview (i.e. every preview is accessed through
https://reflame.app instead of at https://some-branch-of-
reflamedotapp.reflame-previews.dev). Behind the scenes, this is
implemented using session cookies that our CDN will check to
determine which version of the app to serve. This is only the tip
of the iceberg. We have some really exciting prototypes around
testing and typechecking that we've been exploring that could allow
us to ship with even more confidence _without ever slowing us
down_. If any of this sounds interesting for the apps you're
building or planning to build (taking into account this comment
(https://news.ycombinator.com/item?id=33134092) below describing
what Reflame is not well suited for), please sign up and give it a
try! I can't wait to see what you'll build with it! :)
Author : lewisl9029
Score : 78 points
Date : 2022-10-08 17:10 UTC (5 hours ago)
(HTM) web link (reflame.app)
(TXT) w3m dump (reflame.app)
| lewisl9029 wrote:
| (posting some extras as comments since the original post is
| already way too long)
|
| 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.
| lewisl9029 wrote:
| (posting some extras as comments since the original post is
| already way too long)
|
| 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.
| tomg wrote:
| Very impressive!
|
| I am curious about who your intended user is. I'm just thinking
| about how most FE build pipelines I've used have a bunch of
| "checks" like linters, running various tests, maybe reaching out
| to some other services when the build passes or fails.
|
| Is the idea with this that the developer would do these steps
| locally? I also might just be misunderstanding this tool.
|
| Thanks for sharing this :)
| lewisl9029 wrote:
| Really appreciate the kind words!
|
| 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).
| tomg wrote:
| > Reflame will eventually try to build versions of, with a
| focus on speed similar to what we've done with deployment
|
| Nice! The time I wait during builds tend to break my mental
| flow.
|
| Best of luck!
| lewisl9029 wrote:
| (posting some extras as comments since the original post is
| already way too long)
|
| 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.
| solardev wrote:
| This sounds really interesting and is a problem we were trying to
| solve just this week with Vercel!
|
| However, I am having a hard time following what it's actually
| doing under the hood. Aside from a single video, might you be
| willing to share some more details on the product page about how
| it works? I can't tell what it's doing, and I'm not inclined to
| randomly sign up for something without even having a high-level
| understanding...
|
| Like when I push to Github, I understand that Vercel pulls the
| repo and does a yarn install and yarn build or whatever -- the
| same buildchain I use locally, just on their servers. Same with
| CircleCI.
|
| Is that also what Reflame is doing? If so, what's it doing
| differently that makes it faster? If not, how does it deal with
| node_modules installation and are there are any caveats there,
| like how does it deal with resolutions, lockfiles, private repos,
| etc.?
|
| Or am I completely misunderstanding...? Is this some sort of
| content diffing engine / hot reloader instead of a faster build
| pipeline? I'm not really sure I'm following, sorry :(
|
| Just trying to understand what your product actually is and how
| it works :)
| lewisl9029 wrote:
| Happy to explain in a bit more detail how it works:
|
| 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!
| solardev wrote:
| Thanks for the explanation! I hope you add that sort of
| writeup on the product page itself too.
|
| > 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. [...]
|
| If I'm understanding you right, you've created a new lower-
| level buildchain and caching mechanism. The first time I
| deploy an app to your servers it will take a while, but
| subsequent ones will be a lot faster.
|
| If so, there's nothing wrong with that and in fact it's a
| great way to speed up subsequent builds (which are what
| really matter anyway). The first push of any given repo is
| just going to be a test anyway, it's the day-to-day speed
| that makes a big difference.
|
| > 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!
|
| It totally depends on the scale of the repo/app that we're
| talking about. For simpler hobbyist projects those probably
| won't be needed, but then again for those projects Vercel is
| already fast enough, especially with incremental static
| regeneration. On bigger projects, speed would be GREAT (ours
| is sooooo slow, taking minutes to build), BUT basically it
| has to out-of-the-box be reproducible with what we have
| locally or any other buildchain (i.e. our repo, deployed
| anywhere, has to work the same, no matter how it's built and
| bundled). Package locking and private npm packages are not
| something I would ever WANT to add to a project, but
| sometimes they are the realities of legacy codebases that we
| have no choice but to keep using... this is why we couldn't
| switch to bun, for example, and probably Deno for that
| matter. 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?
|
| -------
|
| Anyhow, it is still really exciting to see development in
| this space. Thanks for tackling a long-standing pain point
| for us, and hope to this evolve further! I signed up and will
| check it out at work :)
| lewisl9029 wrote:
| > If I'm understanding you right, you've created a new
| lower-level buildchain and caching mechanism. The first
| time I deploy an app to your servers it will take a while,
| but subsequent ones will be a lot faster.
|
| 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!
| gervwyk wrote:
| This is really impressive stuff! Congrats on the launch! Does
| this work for next.js apps?
| lewisl9029 wrote:
| Thanks for the kind works! Unfortunately, if you're using Next
| for SSR, and your use case requires SSR, the answer is going to
| be an unambiguous no (at least today). See
| https://news.ycombinator.com/item?id=33134092 for more on this.
|
| 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.
| bradhilton wrote:
| Very cool, I may use this for my next React project :)
| iLoveOncall wrote:
| I'm sorry but I honestly can't think of a single real-life use
| case.
|
| I do NOT want to instantly deploy to preview on a file save, and
| certainly not to production. And let's not even talk about
| working as a team.
|
| The only situation where I can think this is useful is if you
| write code locally but run your "local" version on a cloud
| machine. But in that case it's already covered by rsync.
|
| What am I missing?
|
| > Previews in Reflame are accessible at the exact same URL
| customers will use to access the production deployment, instead
| of at a different subdomain for each preview (i.e. every preview
| is accessed through https://reflame.app instead of at
| https://some-branch-of-reflamedotapp.reflame-previews.dev).
| Behind the scenes, this is implemented using session cookies that
| our CDN will check to determine which version of the app to
| serve.
|
| Also this sounds like the worst idea of the century for many
| reasons, including security, convenience, reliability, and much
| more.
| morelisp wrote:
| > Every JS/TS module deployed through Reflame is transformed and
| shipped as independent ES modules
|
| This means it's impossible to do any cross-module type checking,
| correct?
| lewisl9029 wrote:
| Depends on what you mean by cross-module type-checking!
| TypeScript would still be running locally because Reflame
| doesn't run your typechecking for you yet (though we'll be
| working on it!), either on your laptop or in a CI server
| somewhere, so everything supported by your local TypeScript
| version should still work the same.
|
| 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...
| morelisp wrote:
| What I'm asking is, even if you support type checking how can
| it fit usefully into your compilation model, given you can't
| do any cross-module analysis?
|
| Or more pithily: a fast linker isn't impressive if it has no
| error handling.
| tuukkah wrote:
| Sounds this could be quicker than local development.
|
| Something to check: When I click the button _" Let's create your
| first app"_, I get _" Oh no, something went horribly wrong!"_
| lewisl9029 wrote:
| Oh no, that's terrible! Looking into it now.
|
| 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!
| iLoveOncall wrote:
| > Something to check: When I click the button "Let's create
| your first app", I get "Oh no, something went horribly wrong!"
|
| That's what deploying to prod every time you save in VS Code
| will do to your website.
| dewey wrote:
| I just watched the video and I'm wondering about the fact that
| you don't have preview URLs but instead have a cookie based way
| to differentiate a preview from the real production version.
|
| Is that really something that makes it easier? Debugging which
| cookies are used, deleting specific cookies or sharing a specific
| preview version seems to be a lot harder that way? Or am I
| missing something?
| tylerchurch wrote:
| Having worked on a similar system in the past - it's a trade-
| off.
|
| On one hand, all your domains match across all
| environments/deployments and you can set a cookie and refresh
| to switch versions fast. Only 1 HTTPS cert and no subdomains to
| manage. You could invisibly do a slow rollout of deployments by
| slowly changing cookies. Fun stuff like that.
|
| On the other hand, you have to have special links to set the
| cookies, and you end up building some kind of
| environment/version indicator somewhere or else you'll lose
| your mind when debugging. And buckle up for when you
| accidentally switch versions in a different tab instead of
| using Incognito and screw up some debugging. Or try explaining
| to a confused marketing person that they're looking at the
| wrong version of your landing page because a cookie they don't
| know about is set wrong.
|
| It's all trade-offs. Personally having used both approaches I
| think the cookie method sounds better than it ends up being in
| practice. Different domains is uglier, but more clear.
| dewey wrote:
| Thanks for the explanation, that makes sense. I think I
| prefer the more explicit version over the seemingly more
| elegant version.
| lewisl9029 wrote:
| Yep, definitely a tradeoff. Really awesome to hear others
| have explored this in the past!
|
| 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.
| tylerchurch wrote:
| Love the widget!
|
| Assuming an app handles it correctly, unique domains-per-
| deployment give me the warm fuzzies when debugging. When
| tracking down a problem, I want there to be no doubt I'm
| looking at the correct version. Vercel's approach here is
| nice.
| lewisl9029 wrote:
| That's a really fair concern, in fact it's one that's bitten me
| quite a few times. Can't count the times I stared at a page
| waiting for an update, only to realize I'm looking at
| production, or vice versa.
|
| 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...
| cantSpellSober wrote:
| They are ersatz feature flags
| ianbutler wrote:
| That's really great, I could see your smirk when you said the
| bottleneck was how quickly you could create the PR because the
| deploy was already finished and you definitely deserve to be
| smiling :D
| tylerchurch wrote:
| This looks super cool, very impressive!
|
| How flexible is this?
|
| I get the impression from the video that this will work for a
| blessed React configuration that you support.
|
| But if I have a legacy React app with a complicated build setup -
| am I screwed?
|
| Or if I want to deploy a Vue/Vite app, would that require a huge
| engineering lift on your side since it's not React?
| lewisl9029 wrote:
| Thank you for the kind words!
|
| 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.
| MatthiasPortzel wrote:
| I think this is really your big downside. You're
| inadvertently competing with Vite and Webpack right now. I
| don't know if there's a good way around that, though, seeing
| as your magic is that you've written a faster bundler.
|
| I hate to be the Hacker News commenter who is like "are you
| going to open source it?" But I am curious, do you think you
| think you could release your toolchain in a way that people
| can run it locally and get the same benefits that you're
| advertising?
|
| (I say this as someone who currently uses esbuild and Preact.
| Your service looks really cool, but you would have to convert
| me to react-create-app if that's all you support.)
| lewisl9029 wrote:
| So supporting Vite-based React apps is _very_ high on my
| list of priorities at the moment, precisely because I don't
| really want to be pushing people to create-react-app just
| to use Reflame, since it offers a strictly inferior
| experience compared to Vite today. :)
|
| 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.
| jensneuse wrote:
| What about SSR?
| lewisl9029 wrote:
| Unfortunately only client-rendered React apps are supported. So
| if your use case requires SSR, Reflame is probably not a good
| fit. For more on this, see:
| https://news.ycombinator.com/item?id=33134092
| vaughan wrote:
| Great idea. I usually run a dev server on a cloud instance and
| rsync to it and run pnpm install. In the future I want to do this
| for an entire monorepo. It's amazing the waiting tax you pay for
| modern ci and paas stuff for non-prod stuff.
| lewisl9029 wrote:
| Haha that's awesome. In fact, part of Reflame was inspired by
| the good old days of webdev where we could just ship changes by
| editing PHP files sitting on the production server.
|
| 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.
___________________________________________________________________
(page generated 2022-10-08 23:00 UTC)