Why I Built Spaceport

Another framework?

In 2015, I started building a web framework. Not because the world needed another one—it already had plenty—but because I needed a better way to build the applications I wanted to build that didn't require the constant reinvention of my app while the newest web technologies were rapidly evolving. I wanted to have that control, instead.

I'm Jeremy Schroeder: graphic designer, app developer, software engineer. If there's a thread running through my career, it's an obsession with building systems—not just applications, but the tools and patterns that make applications possible. Spaceport is the result of a decade of that obsession, shaped by watching the web evolve and occasionally lose its way.

The Problem With Modern

Let's talk about React for a moment.

React is an incredible piece of engineering. It's also, in a very real sense, a rejection of the web platform itself. The browser gives you HTML, CSS, and JavaScript—a document model, a styling system, and a scripting language that have evolved together for thirty years. React's answer? Throw most of that out. Render everything in JavaScript. Rebuild the DOM from scratch. Add a virtual layer on top of the real one.

It works. Millions of applications prove that it works. But there's something uncomfortable about building on a platform while simultaneously ignoring what that platform provides.

And React was just the beginning. The JavaScript ecosystem developed a peculiar addiction to reinvention. First came the single-page application era: client-side routing, client-side state, client-side everything. Then, when we collectively realized that maybe the server had a purpose after all, we got the SSR/RPC era—server-side rendering bolted back onto client-side frameworks, remote procedure calls dressed up as function invocations.

Each generation of meta-framework promised to solve the problems created by the previous generation. Each one required learning a new mental model, a new build system, a new deployment story. Keeping up became a job in itself.

What Rails and Laravel Got Right

Meanwhile, in the world of Ruby and PHP, something interesting was happening: nothing much.

That's not an insult—it's the point. Rails and Laravel established a model years ago and have been refining it ever since. Full-stack, batteries-included, opinionated about the things that don't matter so you can focus on the things that do. You can start a new Rails project today using patterns that would have been recognizable in 2010, and that's a feature.

These frameworks prove something important: you can build just about any application—from prototype to production, from side project to startup—without chasing the JavaScript framework of the month. They got the developer experience right early, and they've kept it right.

Spaceport exists in that tradition. Not because server-side rendering is trendy again, but because it never stopped being a good idea.

Close to the Metal, Far From the Boilerplate

Here's the thing about staying close to vanilla web technologies: you inherit decades of platform improvements for free.

Every time browsers ship a new CSS feature, Spaceport applications can use it. Every Web API addition is immediately available. There's no waiting for framework bindings, no hoping someone writes a wrapper library, no compatibility layers to maintain. Baseline is the baseline.

But staying close to vanilla doesn't mean staying primitive. Spaceport supercharges the client-side by putting the server to work—and by putting Groovy to work.

If you've spent time in the Java ecosystem, you know the tradeoffs: incredible power, incredible verbosity. Strong typing, long build times. Enterprise-grade reliability, enterprise-grade configuration files.

Groovy changes that equation. It's what Java would be if Java had grown up alongside JavaScript instead of in opposition to it. Dynamic when you want it, static when you need it. Closures that feel natural. A syntax that gets out of your way. The same expressiveness that makes modern JavaScript pleasant to write, backed by the full power of the JVM.

With Spaceport, your server-side code can be as fluid and iterative as your client-side code used to be—before it got buried under bundlers and transpilers and build steps. And because Groovy compiles to JVM bytecode, you have access to the entire Java ecosystem. Every library, every tool, every piece of infrastructure your organization has invested in.

A Different Way to Think

Spaceport isn't trying to compete with React or Next.js on their terms. It's asking a different question entirely.

What if your framework complemented JavaScript instead of replacing it? What if the answer to "how do I add interactivity?" was usually "write a few lines of Groovy" instead of "install seventeen npm packages and configure a build pipeline?"

Make no mistake: Spaceport brings modern features to the table. Reactivity. Server actions. The patterns that make contemporary frameworks powerful are here. But Spaceport is also about something less glamorous and more essential: encapsulation. It gives you tools and systems for keeping code reusable, keeping logic dynamic, and—most importantly—bridging the gap between front-end and back-end in a predictable, unsurprising way.

Spaceport maintains its own, small front-end JavaScript library when reactivity is required. But it's built into the system—you don't configure it, you don't bundle it, you don't think about it. This is a deliberate rejection of the "build your own framework" philosophy that's become disturbingly common in the JavaScript world. You know the pitch: here's a router, here's a state library, here's a fetching solution, here's a form handler—now spend the next six months gluing them together and calling the result your "stack", only to find that one of those parts is being phased out for something new.

Spend less time building the framework. Spend more time building your app.

For Java developers, Spaceport offers an escape from the ceremony. Groovy cuts through boilerplate like nothing else in the JVM world. Configuration is minimal. Hot-reloading isn't an afterthought—it's a first-class feature, fast enough to feel instant. There's no traditional Gradle or Maven build pipeline standing between you and your running application. Use version control to drive your releases, or, if you're feeling adventurous, wing it while working on production. We won't judge.

For JavaScript developers tired of the framework treadmill, Spaceport offers stability. Learn it once. Use the web platform directly. Stop relearning how to do the same things every eighteen months.

For everyone, Spaceport offers a reminder: the web is already good. Sometimes the best framework is the one that helps you use it.

Early Days

Let's be honest: Spaceport is new to the scene. A decade of development, yes, but fresh to the world. It needs real-world testing, rough edges filed down, documentation expanded. The kind of battle-hardening that only comes from other people building things you never anticipated.

Right now, Spaceport is an excellent choice for solo developers and small teams—people who want to move fast, stay nimble, and spend their energy on their product instead of their tooling. The dream is bigger: a state-of-the-art toolchain, a seamless deployment platform, the kind of integrated experience that makes shipping software feel effortless.

But here's the thing: even today, Spaceport isn't a toy. It runs on the JVM. It has access to every Java library ever written. It inherits decades of performance optimization, security hardening, and operational tooling. The foundation isn't experimental—it's one of the most proven runtimes in existence. Whether you're prototyping a side project or architecting something that needs to scale, the underlying technology can handle it.

Spaceport is ready to build with. And if you're the kind of developer who likes getting in early, shaping the tools you use, and being part of something from the beginning—it might be ready for you.