Over the past year we’ve been working on WNode Cloud, an experiment in simplifying the modern web stack.
The idea is to see whether a web app can be developed and deployed without a build system — no Webpack, no Babel, no bundlers — just standard JavaScript executed as-is.
Some core design choices:
- True component architecture (model, view, controller, and styling encapsulated and colocated in one file)
- Views written in plain JavaScript (no template language)
- Zero-config cloud deployment tied directly to your codebase
Demo
We recorded a 45-second demo showing a functional app deployed in under 15 seconds: Watch demo
Technical Trade-Offs
- Dependency Management: Client-side code works with native ES modules or classic <script>-based libraries.
- Production Optimization: No minification or tree-shaking is performed. Instead, WNode only delivers the components required for the current page, rather than sending the entire application bundle.
- Browser Support: modern browsers only; no IE/legacy support.
- Performance for Large Apps: For each page, WNode maintains a context window containing only the components required for that page, rather than the entire application. This approach helps improve performance for large apps by keeping dependency graphs small and focused.
I’d love to hear thoughts from the community.
Top comments (2)
Really interesting approach! I'm curious about the “context window” you mention: how is it actually defined and managed at runtime? For example, how does WNode decide which components belong in the window for a given page, and how does it handle shared components used across multiple routes without reloading or duplicating them?
Great question!
In WNode, the “context window” is essentially a runtime LRU cache of palets (our term for self-contained HTML components, short for “page-lets”). Each palet is a self-contained, miniature HTML page, implemented as a Node.js module.
Because palets are loaded using
require()—just like Node modules—WNode can inspect and track the dependency graph for the current page. We extend the standard require() so the runtime knows:With that information, WNode maintains a “hot set” of active palets. Recently used palets stay in memory; unused ones fall out of the window based on LRU rules.
Shared components used across multiple routes naturally stay hot because they are accessed frequently. And because the runtime understands the dependency graph, components are not duplicated or redundantly loaded.
The result: each page only keeps the subset of the app it truly needs, and large applications stay efficient without bundling or tree-shaking.