[CuriousRose]

Congratulations on the beta launch, an impressive product we will consider integrating.

As a relatively new developer, I'm curious why the dependancy on React?

Was there no way to get the UI you wanted without implementing a framework like React?

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

[agreeahmed]

That’s a great point.

We started with React because that’s what we knew best and the community we were most embedded in.

We have no dogmatic attachment to React. We hope to support Svelte and Vue soon. We’ll start on that once we feel that our data model and flow are sufficiently nailed down that we feel comfortable committing to porting our SDK to other frontend frameworks.

[littlecranky67]

You should look at using Preact (4kb alternative) and supply your frontend code as fully encapsulated with embedded preact. That way you client would only have to render your widget/app into an existing DOM element:

> customPreactRootRenderFunction(document.getElementById("outlet"))

[CuriousRose]

Appreciate the response. I suppose the follow up is, why not make the library framework agnostic initially or work towards that, rather than have to maintain support for x number of frameworks into the future?

[agreeahmed]

That’s a devilish engineering question. If you are truly framework agnostic you limit how much work you can do for your users, because a lot of the work happens inside of the framework. We decided we’d commit to doing the work so our customers didn’t have to.

E.g. most web apps have some endpoint that the client calls to initiate a checkout session by calling their payment processor’s server SDK.

How many times has the following code been implemented because no payment processor ships a route handler and a React hook (pardon my React-brainedness)?

Someone has to do the work to get that checkout request from your frontend to your payment provider and then back so you can redirect. In a just world, that your processor’s SDK would handle that work. Otherwise it falls on your plate.

[hombre_fatal]

Yeah, I've run into this many times.

If you can assume the framework someone is using, you can deliver a powerful, comprehensive integration.

If you instead try to build a generic one that anyone can use, then it's both hard for you to build it, and hard for everyone to integrate with it because it's generalized.

[agreeahmed]

Exactly. If you’re too committed to framework agnosticism you end up leaving your users a bunch of last mile work that they have to do with every integration, and maintain through every pricing model change.

[skrebbel]

May I suggest web components? For all their warts, they are perfect for a use case like this. Even React, the IE of frameworks, supports them properly in v19.

[anentropic]

amen

[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.