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

[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