5 ms·

How would you know at "compile time" whether a library failed to load?

by jtvjan 5y ago

ramesh31 5y ago
>How would you know at "compile time" whether a library failed to load? Imports and Webpack. I cannot imagine externally loading a payment SDK like that in this day and age.
- pests 5y ago
  This is probably loaded from Stripe's servers so they can do their own updates without customers involvement. There is no compile check because the library is not included during compilation.
  - ramesh31 5y ago
    >This is probably loaded from Stripe's servers so they can do their own updates without customers involvement. They can make whatever updates they want to the API and publish a new NPM version. Package management exists for a reason. Including scripts on a page like this for web development is simply anachronistic and wrong in 2021. Maybe for just throwing something into a blog site, whatever fine. But it's just not an acceptable practice for application development anymore.
    - 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 ago
        The 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.

How would you know at "compile time" whether a library failed to load?

by jtvjan 5y ago

How would you know at "compile time" whether a library failed to load?

>How would you know at "compile time" whether a library failed to load? Imports and Webpack. I cannot imagine externally loading a payment SDK like that in this day and age.

pests 5y ago
This is probably loaded from Stripe's servers so they can do their own updates without customers involvement. There is no compile check because the library is not included during compilation.
- ramesh31 5y ago
  >This is probably loaded from Stripe's servers so they can do their own updates without customers involvement. They can make whatever updates they want to the API and publish a new NPM version. Package management exists for a reason. Including scripts on a page like this for web development is simply anachronistic and wrong in 2021. Maybe for just throwing something into a blog site, whatever fine. But it's just not an acceptable practice for application development anymore.
  - 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 ago
      The 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.