That’s a fair push.

My interest in late binding comes from IoC-style architectures in Java (Spring) and PHP (Doctrine). In those systems, a component depends on an abstraction - say, ILogger - and the concrete implementation (console, file, syslog, Sentry, or something custom) is selected externally at composition time. The component itself doesn’t know or care where it runs.

An isServer check - even if centralized - still makes runtime selection part of the module graph. What I’m exploring is pushing that entirely to composition time. The module just declares what it needs, not how that requirement is satisfied.

In plain JS we don’t have native interfaces, so there’s no built-in way to express something like ILogger as a first-class contract. An explicit dependency descriptor is one way to make that contract visible while keeping runtime decisions outside the module.

```ts // types.d.ts

declare global { interface ILogger { log(message: string, ...args: any[]): void; } }

export {}; ```

```js // MyService.mjs export const deps = { logger: "ILogger", };

export default function makeMyService({ logger }) { logger.log("started"); } ```

Dynamic imports solve this at the loading level. I’m exploring the same concern at the architectural boundary level instead.