I have a confession to make, I'm absolutely obsessed with building my own in-house solutions to already existing matured software. Whether it's custom components, CSS utilities, login management, content management systems, static server directory viewer, or a whatever I want next, I've always preferred the precision of an in-house tool over the convenience of a third-party library. For a long time now, Astro was the exception and go to for building projects and websites with the elegant islands architecture and stellar performance that were enough to keep my builder's itch at bay - well, up until now.

Eventfully, every developer hits a wall of where the abstraction feels like a constraint than a superpower. I didn't just want to use a fast framework to build; I wanted to start understanding the mechanics of the engine itself and take a deeper peek behind the curtain. This led to a radical decision, that was a long time coming: I'm going to be transitioning away from Astro to build my own web framework from scratch that'll be built on top of Deno.

No more complex builds or hidden configurations - by building it in-house, I get to decide exactly how routing is handled, how components will be rendered, and how the server communicates with the client. It's the ultimate pursuit of "less is more". Swapping out a feature-heavy framework for a lean, custom-tailored architecture that I have complete control over.

This also means, another big change to all SudoVanilla projects that already built on Astro. As this transition isn't just a weekend experiment, it is a commitment to a new foundation. I've reach a point where I want more control over my code, and how they behave. Every existing project I've built on top of Astro is slated for a complete overhaul. One by one, I'll be migrating my current portfolio over to this all new engine, battle-testing the framework in real-world scenarios until it's just not a hobby project, but the backbone of SudoVanilla's ecosystem.

Philosophy

The name Marrow represents the "barebones" nature of this project. In any complex system, the marrow is the hidden, internal source of vitality, protected by a ridge structure. By stripping away the layers of modern bloat, I'm focusing on more of the essential core. This engine isn't meant to be flashy, feature-heavy suite; it is designed to be the skeletal framework to support the needs for my current and future projects without the extra fat of unnecessary dependencies or complex build pipelines.

My primary goals is to align Marrow Engine entirely with native web standards. By utilizing the Fetch API, Web Streams, and ES Modules as they exist in the Deno runtime, I am ensuring that the engine remains lean and future-proof. This creates a development experience where the code I write today won't be rendered obsolete by the next version of a third-party bundler.

This commitment extends to a strictly zero-dependency architecture. To satisfy the need for a truly in-house solution, every critical piece of logic - from the way requests are routed to how the final HTML is rendered in the browser - is authored within the engine itself. This "batteries-included, dependenices-excluded" approach means that I can remain the sole architect of my tools. When I improve the routing logic or optimized the rendering pipeline, those improvements will ripple across my entire ecosystem and projects, creating a unified and predictable foundation for every project I plan to migrate to the Marrow Engine.

The focus on total ownership extends beyond the source code and into how the engine is also distributed and delivered. Marrow Engine is not intended to be another generic package living on a public registry alongside everything else; it is a private pillar of my own infrastructure. To maintain the integrity of this in-house philosophy as I been doing with other projects, the engine will be published and distributed exclusively through my own internal registry, The SudoVanilla Registry. By hosting this pipeline myself, I ensure projects depend only on my own uptime and standards, creating a completely self-contained loop from the first line of code to the final deployment.

Then there is the mater of the iconic package.json file and the node_modules directory. For me, this is one of the rewarding aspects of the migrations. For years, these have been a tax of web development - a massive, sprawling footprint of thousands of files all required just get a basic "Hello World" onto the screen. By committing to the Marrow Engine and the Deno runtime, I am finally stepping away from all of that bloat of the NodeJS ecosystem and its infamously fragile dependency graphs.

Removing the package.json file requirement is more than just a file deletion; it's a shift towards a more cleaner, more intentional project setup. Since my projects will now utilize the deno.json file to manage modules and configurations, the traditional package file pretty much becomes obsolete. This doesn't just declutter the root directory; it eliminates the storage tax of having a local node_modules directory that consumes massive amounts of storage and inevitably complicates a CI/CD pipeline. This helps a leaner way to build, where the only code on my machine is the code I actually intended to put there.

With the removal of these was required legacy files, comes a realization: NodeJS is no longer a requirement when building my projects. Finally, dropping the requirements of NodeJS, I'm severing ties with the Node runtime and moving into an environment where the engine isn't tethered to a twenty year old system of architectural baggage. No more worrying about version managers like NVM or the inconsistency between local and production Node environments - I'm tired and done with these hurdles.

Stack

To bring this barebones philosophy in place, into the codebase - I've made a choice regarding the technical stack, Marrow is currently built to handle TSX and Markdown files as it's primary building blocks for components, layouts, and pages. There's already documentation and importing CSS module files as well, along with hashing class names.

By choosing TSX, I'm not just chasing for a familiar syntax; I'm also leveraging the power of TypeScript to provide type-safe component structures without the need of heavy, external UI libraries. Deno's native ability to handle and parse JSX/TSX means I can rewire expressive, component-driven layouts that remain remarkably close to standard JavaScript. This allows me to create a predictable flow where data enters a component and clean, optimized HTML comes out the other side.

By integrating Markdown directly into the core support, I can transform raw text into fully rendered pages while keeping the authoring process as simple as possible. Together, these two formats allow Marrow Engine to stay lean: TSX provides the structural precision, while Markdown provides the flexibility, all without straying from the engine's barebones minimalist, high-performance goals.

Structure

To keep the cognitive load low during this transition, the structure of projects that'll run on Marrow Engine will intentionally mirror the familiar setups of my previous Astro setups. I've adopted the ./src/ convention as well where the core of a site is organized into logical, high-level directories. This isn't just copying how other frameworks work; it's about creating a muscle memory bridge that allows me to focus on the engine's internals rather than reinventing how directories should be structured.

I've setup the ./src directory behavior to be pretty much the same as Astro, as an architecture that is divided up into clear functional zones. Pretty much the directories you would expect such as components, layouts, pages, and styles. Of course, developers are still mostly free on how they do things their way, but like with Astro pages are required to be in ./src/pages/, as it's still the main entry point for automatic routing. This ensures that while I begin the process of rebuilding my existing projects, I can move with speed, knowing exactly how things should be layed out.

I may also consider putting in defaults, such as setting page layouts to ./src/layouts/Base.tsx automatically if it exists. Could do the same for index.css/index.modules.css and among other things that can work in this similar system.

A basic project would look like this:

.
├── src
│   ├── styles
│   │   └── index.css
│   ├── pages
│   │   ├── projects.tsx
│   │   ├── index.tsx
│   │   ├── contact.tsx
│   │   └── blog.tsx
│   ├── layouts
│   │   ├── Base.tsx
│   │   └── Article.tsx
│   └── components
│       ├── Header.tsx
│       ├── Head.tsx
│       ├── Footer.tsx
│       └── Card.tsx
├── index.ts
└── deno.json

Transitioning

This transition from a high-level mature framework to a brand new barebones engine will be a tactical migration. I will look into this starting with a small rollout into smaller, simpler projects - specifically Biotri, Indexlet, and eventfully ButterflyVu. These projects will be the ideal "patient zero" for the Marrow Engine because they'll allow me to test the core TSX and Markdown rendering pipeline without immediate pressure of a complex authentication or heavy database logic. Once these foundational projects are stabilized, I can start moving onto larger projects of mine and gradually start retiring the last of my Astro-based infrastructure.

However, a shift this radical is not without its own hurdles. The most immediate challenge will be replicating the "magic" I once took for granted, such as automatic asset optimization and seamless CSS bundling. Without a mature third-party framework like Astro to handle these under-the-hood tasks, the responsibility falls entirely on the Marrow Engine - and by extension, on me. I expect to spend significant time fine-tuning the filesystem router and ensuring that the custom build process remians as fast as Deno promises.

Despite these challenges, the goal remains the same, which is for total architectural sovereignty. Every bug I encount during this transition is an opportunity to improve the engine, ensuring my ecosystem of projects are running better on Marrow Engine. This is the growing pains phase of building an in-house solution, but it is a price I am more willing to pay to own my stack.

---

This introduction marks a new beginning of a long-term commitment to a new way of building my projects and more to come. The Marrow Engine is in its early experimental phase - the bones are being set and laid out. It's an ambitious leap to move from a comfort of a proven framework to a raw unpredictable custom-built engine, but for someone like me who is obsessed with building their own in-house solution, there is no other way forward.

I'll be documenting the evolution of Marrow Engine here or within its own documentation. This is the start of a more intentional, independent ecosystem, I'm quite excited to see how deep this rabbit role will go.

---

The Marrow Engine has been open sourced under the GNU Affero General Public License on SudoVanilla Ark and documentation are already available to view to get started on using the new engine.

Marrow Engine is only distributed under the sudovanilla.org domain name, as part of the SudoVanilla Umbrella Policy. If found else where would be unofficial and not controlled by SudoVanilla.

• Documentation: https://marrow-engine.docs.sudovanilla.org
• Package: https://registry.sudovanilla.org/js/@sudovanilla/marrow-engine
• Source Code: https://ark.sudovanilla.org/korbs/marrow-engine