Implosive Build Pipelines: Concentric Chunking After Schappeller
Modern web bundlers — Webpack, Rollup, Vite, Parcel, esbuild, Turbopack — all share the same architectural assumption: the optimal artefact is a tree of small chunks delivered on demand. Karl Schappeller, designing his Raumkraft sphere in 1928, made the opposite assumption about energy: the optimal vessel is a single concentric structure that draws inward. This essay describes what happens when you build a bundler under the second assumption — and where the design choice lands for a WebAssembly-heavy browser SDK like the one anchoring the team's public engineering.
The orthodoxy of front-end bundling is well-established. Code-split aggressively. Defer non-critical JavaScript. Load each route's chunks on demand. Cache each chunk independently so an unrelated change does not invalidate the entire bundle. The assumption underneath is that latency is amortizable across many small requests provided each request is small enough.
The assumption is empirically defensible against any single page load. It is empirically more fragile against a session of page loads on a user-experienced cold network — and the fragility compounds when the SDK ships large WebAssembly modules whose initial parse cost is paid once but whose download cost is paid every time the chunk graph fragments them.
The Schappeller Vessel
Karl Schappeller's dynamic stationary sphere was an engineering object before it was a physical theory. The sphere was constructed in concentric layers — an outer ceramic shell, an intermediate stator winding, an inner rotor coil, an axial electret core — and Schappeller's claim, set down at length in the 35-page Raumkraft monograph that Wetzel and Gföllner authored on his behalf, was that the structure functioned because energy concentrates inward, not because it propagates outward. From Davson's later notes on the Bahn collection:
The dynamic stationary sphere is a vessel in which the medium is invited to localize. The concentric structure is not decorative; each shell exists to admit the medium and to refuse it egress. The result is a stable interior that is denser than its surroundings.Davson on Schappeller, c. 1955
The engineering primitive — concentric admission, refused egress, dense interior — is general. It applies wherever you can identify, in your domain, an analogue of “interior density” that you actually want.
The Bundler Analogy
The interior density of a web application, viewed from the user's perspective, is the likelihood that the next byte the browser needs is already in memory. This is the quantity that LCP, INP, and TTI all approximately measure. Modern bundlers optimize for it tangentially, by minimizing the size of the initial chunk and by lazy-loading on route change.
The implosive reading: optimize for it directly. Construct the bundle as a single concentric artefact whose innermost shell contains exactly the bytes needed for the first paint, whose next shell contains the bytes needed for first interaction, whose next shell contains the bytes needed for the second route, and so on outward. Stream the artefact from inside out over a single connection. Refuse the egress of any shell until the inner shells have arrived.
Five Departures from the Default
Five concrete departures from the Vite default that the implosive reading suggests are worth designing for, and that the team has been working through in the WebAssembly bundling pipeline that ships VRIL's browser-side post-quantum primitives:
- Single response, multipart shells. The entire application ships as one HTTP/3 response with N multipart shells. Each shell is independently parseable and independently executable. The browser begins parsing shell 1 before shell 2 has arrived. This eliminates the connection-establishment overhead of N−1 chunk requests — a cost that matters disproportionately when the chunks contain large WebAssembly modules whose handshake-to-bytes ratio is bad.
- Concentric shell ordering, not topological. The standard bundler emits chunks ordered by import graph. The implosive variant emits shells ordered by predicted user demand, computed from a per-app Markov chain of route transitions trained on the application's own analytics. The first shell contains the bytes needed for the route the user is most likely to land on; the second shell contains the bytes needed for the route they are most likely to navigate to next.
- Refused egress. The browser is not permitted to begin executing shell N+1 until shell N's execution has completed. This sounds slower; it is in fact often faster, because shell N+1's execution typically depends on shell N's exports, and parallel execution of dependent code costs more in cache misses than serial execution costs in wall time.
- Static interior. The innermost shell — the one containing the first-paint critical path — is content-addressed and effectively immutable across releases. The majority of releases do not modify it. The browser caches it under a cryptographic hash, and the cache hit rate at the innermost shell is determined by how aggressively the team carves the critical path away from feature-development churn.
- Outer shell prefetch on idle. Once the first three shells have executed, the runtime begins prefetching the outer shells during browser idle time, in the order predicted by the Markov chain. This is the only place the architecture resembles the standard model — and even here, the prefetch is over the same connection, not via separate requests.
What the Trade-Off Costs
The first-paint improvement that this design philosophy can in principle deliver is not free. It costs the ability to serve the application from a static CDN edge as N independent objects, because the multipart shell stream needs an origin that can interleave the shells correctly. It costs the ability to re-use existing CDN cache primitives that are organised around object identity, not shell position. And it costs a substantial amount of build-time complexity: the bundler must train and persist a per-app Markov chain on real session data, and the model has to be re-trained whenever route topology shifts.
For a SaaS dashboard whose hot routes account for the overwhelming majority of session time, the trade is favourable. For a documentation site whose users land on long-tail pages from search results, it is not. The standard chunk-tree and the concentric-shell artefact are not competing for the same workload; they are competing for the same default, and the right default depends on the shape of the user journey the application is built to serve.
The Schappeller Lineage
The engineering instinct of concentrating a flow inward toward a high-value core, which Schappeller documented for energy in 1928, transposes onto bundling JavaScript and WebAssembly for a browser in 2026 in a way that produces a different design than the orthodox approach — with a different set of trade-offs. The team's published browser-side work continues in the open at github.com/VRIL-LABS/web-sdk and the JavaScript bindings at github.com/VRIL-LABS/vril-js; the WebAssembly modules they ship are exactly the kind of payload that an implosive bundler is designed to carry.
The 35-page monograph that supplied the design instinct is in the public domain, as is Davson's 1955 exposition. The complete reference for the dynamic stationary sphere — including the Bahn correspondence and the Bedini reconstruction notes — is preserved at the Rex Research Schappeller archive for any reader who wants to study the source material directly.
