How is it more expensive (than Cloudinary, which the parent was talking about)?
Cloudinary uses a credit system and charges by disk space + bandwidth + transformation calls. Its free plan is metered and only good for up to a small number of monthly visitors.
Imgix charges by # of origin images, regardless of their size, and everything is included free. The free plan is up to 1000 source images and bandwidth/disk space are not charged (though fair use limits prob apply?)
It's what happens when no one group controls the "open" web, and instead you have different advertising & services giants competing for the future of human information exchange. Blame Netscape for hurriedly shimming in a shitty language in the 90s and jumpstarting a war among the digital cartels.
Microsoft wants TypeScript and abandoned .Net dominance. Google failed with AMP. On the backend, Facebook's HHVM saw limited adoption, and node.js took over, even surpassing PHP in developer mindshare. So streamlining the front & backends was inevitable. Angular 2 was so bloated that it made React seem simple, and by the time Vue et al came around, React had so much inertia and community support that it was harder for them to gain traction. Apple checked out completely, Mozilla is still fighting the good fight but losing more ground every year, so now it's really just Facebook building on top of Google...
For what it's worth, the nightmarish toolchain is slowly getting better, with ES6 modules, dynamic imports, Web Components, service workers, and the such. NPM is also slowly improving, and semver has done wonders for maintaining library compatibility. Frameworks-on-top-of-libs like Next.js bring some much-needed boilerplate and tooling to React and generally make the whole experience both quicker and far more tolerable (you rarely have to edit tooling configs, and webpack/babel are invisibly handled for you). Not to say it's ideal -- far from it -- but people are definitely working on streamlining the developer experience. And from the UX side there is a lot of optimization and tree-shaking work happening too, to try to shrink down the ultimately delivered package sizes.
That's not to say React is right for every project. It's just the most popular, so easy to hire for and easy to collaborate on. Every vendor provides React demo code or readybuilt components and hooks, vs having to write your own for every trivial API use case. It's a real time-saver, and the closest thing to a de-facto standard the web dev world has had since jQuery was pronounced dead (RIP).
But hey, the JS ecosystem at its worst now is at least still better than having to choose between Flash, ActiveX, Java, and VRML. At least it all compiles down to JS. Or at least it did until WebAssembly (cry)...
In a way, JS is a victim of its own success. Reminds me a lot of the Linux ecosystem, where there are always 10,000 ways to do something depending on your particular distro and package manager and shell and window manager, yet never a single "best practices" way. There are a million ways to do anything in JS/TS/CoffeeScript/ECMAScript/React/Vue/Svelte and none of the come close to the relative orderliness of, say, PHP or the .Net stack. I'd say it's what happens when you do design-by-committee, except it's not, because JS is more like design-by-retrospective, and only after years or decades of suffering do best practices emerge from popular use and bubble up eventually into ECMA proposals, only to be largely ignored by Apple and so require polyfills (thanks, Safari).
Which is all to say, yes, it's still hard to work with and has room for a lot of improvement. The community at large is working on a lot of those problems, slowly but surely, while being constrained by the will and pacing of the behemoths. Maybe in 20 years' time things will be better... but who are we kidding.
How is it any better or worse than Luxon? (I only ask because Moment recommends Luxon as is "spiritual successor", so I never bothered to evaluate date-fns. Should I?)
Have you considered imgix? It's like Cloudinary, but with flat pricing per # of origin images. Transformations and bandwidth don't cost extra. It's nice because you don't have to manage yet another stack, just plop in a URL and you're done.
It seems like Cloudflare wants you to predefine all the "variants" (transformations) as specific templates in their GUI, whereas Cloudinary and Imgix are much more flexible and accept specific URL parameters to create those transformations.
Even for Google logins, would you consider using a token-based authentication system (like Spotify, Postman, etc. do)... i.e., your default browser opens, Google logs you in there (or you already are), and that sends a backend auth token to your service to connect your Google and Replay accounts.
I would like to try your product, but am wary of typing in my Google credentials into an unknown, black-box browser. It's too easy to MITM, especially if someone redistributes a copy with a keylogger shimmed in.
The token-based auth means you can still log in with Google but never have to share your Google password with the proprietary Replay browser. Probably many of the multi-login vendors support something similar already if you don't want to deal with it yourself.