I have a confession to make, I'm obsessed with building my own in-house solutions to already existing software. From building my own components, CSS utilities, content management systems, static server directory viewer, and whatever I want to build next; I've always preferred have more control of an in-house software over the convenience of a third-party, already matured, library. For a long time now, Astro was an exception I made as the go to framewaork for building projects, web apps, and websites with tehir elegrant islands architecture and fantasic performance, which was enough for me to keep my obsessed self at bay - well, up until now.

Every developer will eventfully hit a wall of where the this feels like a contraint rather than a superpower. I didn't just want to use a fast framework to develop with; I wanted to start even understanding the basic mechanics of the engine core itself and take a deeper peak behind the curtain - revealing the magic. This decision has finally head to a something that has been a long time coming now: I'm going to be transition away from Astro to build my own framework from scratch that'll build on top of the Deno runtime.

This means that another big change to all SudoVanilla projects that are already built on Astro. As this transition isn't just a weekend experiment, it is a commitment to a new foundation of all existing and future projects. So, all of SudoVanilla's projects are now slated for a complete overhaul to be built on top of this new framework I want to build. Over the course of the next year or two, I'll be migrating them over to it, battle-testing the framework in real-world scenarios until it's just not just a hobby project anymore, but to be the new backbone of what powers SudoVanilla projects.

Philosophy

The name of the new framework I'll be developing has been named Marrow Engine; the name marrow represents the "barebones" nature of this project. Like with any other complex system, marrow is the hidden, internal source of vitality, protected by a secure structure. By stripping the layers away of modern bloat, I'll be focusing more on the essential core. This new framework isn't meant to be anything flashy, or feature-heavy; but designed to be the ground zero support that is needed for my existing and future projects without the extra fat of unnessary dependencies or complex build piplines.

This commitment extends to a strictly zero-dependency architecture. To provide the needs for this new in-house solution I'm building, every piece of logic - from the way requests are routed to how the final HTML is rendered in the browser - is authored within the framework itself. This whole "batteries-included, dependenices-excluded" approach into the development means that I can remain to the sole architect of my own tools. When it comes to making more and more improvements to the routing logic, rendering pipeline, a stable workflow, and more will create a ripple across all my projects, creating a unified and predictable foundation.

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