Explicit Control Flow
Requests, state changes, and rendering paths stay visible.
We can trace behavior without crossing multiple hidden framework layers.
Explicit Native Systems
Agentic programming works best when readable software helps both humans and LLMs understand, change, verify, and hand over a system. Modern browsers and modern Java already provide strong native primitives. We prefer to use them directly.
Frameworks solved many problems, but they also introduced hidden behavior, convention layers, and abstraction depth. For many applications, modern platforms already provide enough native capability.
Single Source Of Truth
State and contracts live in one clear place.
That reduces drift and makes reactive updates easier to reason about.
Native Before Framework
We prefer what the platform already does well.
The real system stays visible in our own source files.
Native Browser Components
The browser already provides a native component model. Custom Elements, Shadow DOM, JavaScript modules, and related native tools such as template literals and HTML templates give us reusable UI building blocks without adding a large framework runtime.
- Custom Elements provide reusable UI units through the browser’s built-in
window.customElementsregistry. - Shadow DOM gives native encapsulation for DOM and CSS.
- JavaScript modules make dependencies explicit through imports and exports.
- Template literals and the HTML
<template>element support direct and readable view construction. - Type-safe JavaScript with JSDoc gives plain
.jsfiles clearer API contracts and lightweight type checking. - Single source of truth keeps state centralized and avoids scattered UI drift.
- Reactive programming through subscriptions, state changes, and JavaScript
Proxykeeps rendering aligned with the model.
Native Java Systems
The Java platform already offers a strong base for web applications. For this style of project, JDK
HttpServer, plain JDBC, and virtual threads already provide a strong native base. When outbound
HTTP calls are needed, java.net.http.HttpClient is available as a native platform option.
- JDK HttpServer keeps HTTP entrypoints local and visible.
- java.net.http.HttpClient is a modern native HTTP client available without introducing another framework runtime.
- Manual routing makes URL handling and request flow explicit in project code.
- Plain JDBC keeps database access close to the actual SQL and schema.
- Virtual threads are handled by the Java runtime itself.
- Structured concurrency is the preferred native choice when coordinated concurrent work is needed.
Why This Works Well With LLM-Assisted Development
More Real Code Fits Into Context
Important logic lives in local source files.
The implementation is not hidden behind framework lifecycles and generated layers.
Dependencies Are Visible
The system graph is easier to inspect.
JavaScript modules, manual routing, and direct configuration show what the system depends on.
Patches Stay Local
Changes touch fewer files with clearer side effects.
Explicit architecture makes small, reviewable edits more likely.
Debugging Is Easier
Errors can usually be traced through project code.
There are fewer framework-specific abstraction layers between cause and effect.
What We Accept In Return
- We write more infrastructure ourselves.
- We rely less on batteries-included ecosystems.
- We need discipline in folder structure, state design, and code organization.
- The starter template absorbs much of that one-time setup cost so future projects can still move quickly.
Small Reading List
- HttpServer API
- HttpClient API
- JEP 444: Virtual Threads
- JEP 525: Structured Concurrency
- OpenJDK Project Loom
- Networking I/O with Virtual Threads - Under the hood
- MDN: Using custom elements
- MDN: Using shadow DOM
- MDN: JavaScript modules
- MDN: Template literals
- MDN: Using templates and slots
- MDN: Proxy
- MDN: CSSStyleSheet
- @use JSDoc