Template vs. Framework: Why a Boilerplate You Own Beats One You Depend On

“Boilerplate” and “framework” get used interchangeably, but they’re opposites in the way that matters most: a framework is something you build inside and depend on; a template is code you own outright and are free to change. cdkbase is deliberately the second kind — and that choice shapes everything about how it feels to work in.

The distinction, precisely

A framework inserts itself between you and the platform. It brings its own abstractions, its own lifecycle, its own conventions and magic, and you write code the way it wants you to. That can be a great deal — when the framework’s opinions match your needs, you move fast. But you’re building on top of an API someone else controls.

A template is just a working starting point — real, unabstracted code that happens to already be wired together. There’s no layer between you and the platform; the template is the code, and from the first commit it’s yours to read, edit, or delete. The value is the head start, not an ongoing dependency.

The hidden cost of a framework

Frameworks are wonderful right up until your needs diverge from theirs, and then the costs surface:

• The version treadmill. A framework is a dependency you have to keep current — breaking changes, deprecations, and migrations land on your schedule whether or not they help you.
• Leaky abstractions. The moment something behaves unexpectedly, you have to understand both your code and the framework’s internals — often harder than if the underlying calls were right there in front of you.
• Escape hatches and ceilings. When you need something the framework didn’t anticipate, you either contort your design to fit, drop into an awkward escape hatch, or wait for a release. You’ve outgrown the abstraction but you’re still carrying it.

Case study: Cognito via the AWS SDK, not Amplify

Auth is the clearest place this choice shows up. AWS offers Amplify, a higher-level framework that wraps Cognito (and more) in its own auth abstraction — convenient, but it’s another layer with its own API, conventions, and version cadence sitting between your app and the service.

cdkbase skips it. Authentication talks to Cognito directly through the AWS SDK for JavaScript (v3) Cognito client — plain, documented API calls like InitiateAuthCommand and SignUpCommand. The entire auth package has a single runtime dependency, and the code does exactly what it appears to: no framework lifecycle to learn, nothing hidden, every call traceable straight to the AWS API it makes. If you need to change how sign-in works, you edit the function — there’s no abstraction to fight.

Minimal dependencies as a feature

Keeping the dependency list short isn’t austerity for its own sake — it’s a property worth protecting. Every dependency is surface area: something that can break, ship a vulnerability, force a migration, or simply need understanding. Fewer of them means a smaller supply-chain footprint, fewer surprise upgrades, and a codebase a person can hold in their head. The AWS SDK is going to be in your project regardless; building on it directly means you’re not also carrying a framework on top.

Why this matters more in the AI era

There’s a newer reason thin, direct code wins: an AI agent reasons far better about a plain SDK call than about framework magic it has to infer. When behavior lives in an explicit function the agent can read top to bottom, it can follow any thread straight down to the AWS API and change it confidently. Framework abstractions hide exactly the details an agent needs to reason correctly. A template you own is, not coincidentally, the most legible substrate for an agent to build on.

When a framework is the right call

None of this means abstractions are bad — the opposite. A good framework earns its keep when its abstraction is genuinely valuable, stable, and shared by a large community: you wouldn’t hand-roll a web router or a UI rendering layer to avoid a dependency. The test is whether the abstraction saves you more than it costs over the life of the project. For a web framework, usually yes. For wrapping a handful of Cognito calls you’ll want full control over, usually no. cdkbase uses real frameworks where they pay off — React Router, Hono — and skips them for the glue you’re better off owning.

The bottom line

A template you own gives you the head start of a framework without the dependency: real code, minimal abstractions, the AWS primitives in plain sight. You can read all of it, change any of it, and never outgrow it — and so can your agent. That’s the deliberate design behind cdkbase: thin, legible, and yours.