[littlecranky67]

> We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this

To be fair, chosing Svelte over React explicitly means that - if the React installed/userbase is 10-50x as big, you will be frustrated with this a lot. But in the end I don't get the frustration, in the end react is not a framework and you can render any component into a single HTML node that is part of your Svelte system. If the external library is encapsulated well, you shouldn't even notice that is react based.

[port11]

Of course this means importing a ton of new libs and frontend code just to render billing. It's the same with the dependency on, say, Next. It's too many moving parts, could've been done without tying yourselves down to specific ‘cultures’. That said, it's a great endeavour and my hat is off.

[agreeahmed]

Appreciate the feedback. This work happens in all frontend "cultures" (a phrase I will be lovingly borrowing, thank you). But a payment provider can't really take this work off a developer's plate unless it provides an SDK that works inside of that culture. So yeah, we hope to ship the best payments experience for React. But eventually also for Svelte and Vue. Because that's what you'd have to do to solve this problem.

And the problem goes substantially beyond billing UI. There's all the unseen tedium that devs need to implement in order to derive proper app behavior based on their customers' billing state. Most of this work is transposing billing state (and its derivatives) and then lugging it to the client where it will be used to show upgrade buttons, gate feature access, show outstanding usage balances, etc.