Disclaimer: I work at Speakeasy but not the author.
It probably needs better wording because it's sort of the wrong complexity metric. Many customers have gigantic OpenAPI documents with large numbers of deep and wide JSON Schemas that contain things like allOf/oneOf/anyOf sub-schemas, all of which need to be parsed into an object model for use by downstream tooling (e.g. code generation). For those customers, we want generation time to be super speedy and since this is a core aspect of Speakeasy, it made a ton of sense to us to take full control of OpenAPI parsing and optimize it.
> Some were fast but modeled the spec loosely, making it hard to build correct tooling on top. Others were closer to the spec but used untyped maps everywhere, which made large refactors and static analysis painful.
It probably needs better wording because it's sort of the wrong complexity metric. Many customers have gigantic OpenAPI documents with large numbers of deep and wide JSON Schemas that contain things like allOf/oneOf/anyOf sub-schemas, all of which need to be parsed into an object model for use by downstream tooling (e.g. code generation). For those customers, we want generation time to be super speedy and since this is a core aspect of Speakeasy, it made a ton of sense to us to take full control of OpenAPI parsing and optimize it.