4 ms·
Eh, there is pros and cons. When Stripe updates it's ask it's immediately deployed to _every_ user immediately. Yes it's possible with npm and semver but it's a
by pests 5y ago
Eh, there is pros and cons. When Stripe updates it's ask it's immediately deployed to _every_ user immediately. Yes it's possible with npm and semver but it's also possible people pin specific versions or get stuck on a certain minor version.
While I think that's fine for normal software Stripe lives in the world of financial regulation and compliance with laws around the world. They might not be able to even allow their users to use an older SDK (regulation changed, new regulatory steps, etc) in a graceful manner.
Sticking to live loaded sdk and the technical debt that comes with to not break clients and end users might just be the best option for something as risky as payments online.
- ramesh31 5y agoThe thought of a critical revenue impacting API changing dynamically without warning is absolutely terrifying to me. The thing is, no other software in existence works like this. Payment systems are ubiquitous across an incredible array of devices outside the context of a web browser and they are perfectly fine with using normal software engineering techniques like package management and static linking. Dynamic script imports are fraught with hangups like http errors and slow user hardware causing race conditions. And you're then always tied to using some kind of loading function. Remember having to write entire applications within a jQuery onLoad? It's a vestigial pattern from the early days of the web. We're better than that on the front end now.