lapusta

* Manual Maintenance: Returning to the pre-Stainless era.

* Agentic Coding: Works to an extent, but you lose the deterministic, review-free output required to keep an SDK perfectly structured and coherent.

* Open-source Generators: Helpful for basic use cases, but they lack Stainless's full-stack features like multi-language generation and publishing, MCPs, and documentation.

Stainless: The standout for maturity and idiomatic code generation. While method signatures across products may look the same, Stainless shines during developing & debugging - making their codebase easier to navigate. They have a practical separation of SDK configuration from OpenAPI specification, setting it apart from others reliant on OpenAPI overlays. The Stainless Studio also proved invaluable for refining our OpenAPI specs during our exploration phase.

Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs and documentation to Postman collections. Fern uses an internal "Fern Definition" language (~ think Smithy), it's optional and enables capabilities like merging multiple specs, but is adding another layer to navigate in our view.

Speakeasy: Moves at a fast pace, which could be a double-edged sword. Rapid iterations may lead to frequent, potentially disruptive updates for customers. A minor gripe was the inclusion of "Speakeasy" in class names, which felt overly branded.

Liblab: Initially limited in language support, they've expanded but still lag behind in establishing a strong customer base, which might be a red flag for some adopters.

BTW all folks are very approachable and collaborative!

- Google Meet (~Zoom)

- Google Chat (~Slack)

- Google Currents (~Yammer)

For consumers:

- Google Duo (~Facetime, but cross-platform)

- Google Messages (~iMessage, but non proprietary: SMS, MMS > RCS)

Everything else is on the retirement schedule.

The scenario is typically the following. After the EU Commission approves the directive, each country has to transform it into the national law and define the authority/approach/timelines. In the case of the UK, it's indeed the way you've described.

> As AFAICT this would be explicitly disallowed unless all the users of said APIs are themselves accredited.

In UK Plaid would have to follow the OpenBanking regulation indeed and provide access according to the consent of the account owner. In the US they are just storing your password and using it according to their privacy policy.

1) Regulation. What you heard as "PSD2" - is essentially a directive by European Commission and EBA demanding banks to open up access to accounts data and payment initiation. Neither it defines by what means this access should be provided, nor when it should be available - each European country Central Bank can decide on its own.

2) Technical Specification. Examples are OpenBanking UK specification or The Berlin Group - would be groups of banks or local regulators trying to define common standards. Think of interface definition that describes both APIs as well as journeys/workflows.

3) Compliance. In the EU some of the banks (mostly large ones) are now required to be PSD2 compliant, which means they would need to expose their APIs through the standards described above. In the US, where there is no such requirement - the only way to access the bank account is to emulate a browser.

4) Third-Party Providers or Aggregators (Plaid, Teller, Tink, SaltEdge, Bud...) - would essentially provide access to the accounts of multiple banks via APIs. If you look at Plaid in the US - their codebase is probably 50%+ screenscraping/user emulation scripts in order to retrieve your accounts from e.g. Bank of America. For the EU fin-techs its a bit better, but still depends per country (remember Berlin Group vs UK OpenBanking?).

We are currently looking on what to do with our quite massive GWT app. Already in the process of RPC to REST switch, with Angular, AngularDart and GWT3 (depending what it would end up to be) as options.

Just wanted to check if we are missing an alternative

Are you planning to go more native with something like Atom's Electron platform?