GitHub：https://github.com/smartboot/feat
Almost every Java developer has complained about Spring: slow startup, memory-hungry, bloated dependencies. Change one line of code, wait five seconds for a restart, staring at that line in the console — "Started Application in 5.234 seconds" — you can't even tell if it's a log message or a mockery.
What hurts even more is when you complain to a colleague that "Spring is too slow," they'll most likely hit you with: "So you want to use Vert.x? Or Quarkus?"
You go silent. Because you know those frameworks are indeed fast, but you also know — learning new APIs is painful, team training is expensive, and being unable to find answers when things break is desperate. In the end, you sigh and keep waiting for those five seconds. After all, "at least I know how to use it, at least everyone on the team knows how to use it, at least I can Google the answer when something goes wrong."
This kind of "developer endurance" — we've all been through it.
But here's a counterintuitive fact: over the past decade, Vert.x, Quarkus, Micronaut, Solon… countless frameworks have crushed Spring on performance benchmarks, yet not a single one has truly shaken its position.
Why?
Because when it comes to technology selection, the first person to make the call isn't the CTO, not ops — it's the programmer sitting at their desk. And a programmer's top priority when choosing a framework has never been "how much electricity this server will save," but rather "how fast can I learn it, how enjoyable is it to write, and can I find answers on StackOverflow when things break."
Spring's real moat has never been technology — it's the "human" experience.
1. Where Did Spring Win?
Many people think Spring's dominance comes from its massive ecosystem. But the ecosystem is just the result, not the cause.
The real reason is: from day one, Spring's design philosophy was never "high performance" or "lightweight" — it was the ultimate developer experience and productivity.
Think about it — which evolution of Spring ever caused you pain? From Spring to Spring Boot, from Spring Boot to Spring Cloud, developers barely had to relearn anything; it was just a natural extension. Your resume says "proficient in Spring," and at the next company's project, those @Autowired, those @RequestMapping, those debugging strategies — still completely applicable. You don't even need to read the docs; muscle memory lets you complete 80% of the development work.
That's Spring's most terrifying strength — it built a comfort zone of mental models. In this comfort zone, auto-configuration makes you feel "understood" rather than "interrogated"; IDE plugins make you code like a wizard; and those 200,000 Q&As on StackOverflow, the countless tutorials on YouTube, the wall of "Spring in Action" books in the bookstore — together they form a barrier no new framework can overcome.
On a deeper level, Spring has become a team collaboration language. When two Java developers sit down together, they don't need to explain what dependency injection is, what AOP is, what transaction propagation is — these concepts have been internalized as the industry's common language. No matter how good a new framework's performance is, if it can't integrate into this common language, it creates friction costs in team communication.
To put it bluntly, Spring is essentially a "developer welfare framework." It shifts costs from developers to companies' cloud bills. Meanwhile, challengers often shift costs back to developers — you learn new APIs, step into new pitfalls, dig through GitHub Issues for three days to find an answer — all in exchange for performance gains on the machine.
In economic terms, this is a trade destined to fail.
2. The "Fatal Blind Spot" of Performance-First Frameworks
The Java community has never lacked "technology-first" open-source projects. Their selling points are remarkably consistent: fast startup, low memory usage, high QPS.
These are indeed what enterprises need. But the problem is: just because enterprises need it doesn't mean programmers will choose it.
Imagine this scenario: you recommend a new framework to your team, saying "it starts in just 100ms." A colleague asks: "How does it inject dependencies?" You say: "Programmatic configuration." Another asks: "What about database access?" You say: "Write your own Reactive Client." Then: "When something goes wrong in production, can you even understand the stack trace?"
By this point in the conversation, you've already lost.
4 seconds faster startup, but 4 weeks of learning curve; 8MB less memory, but 8 hours debugging a bizarre issue; 9 out of 10 team members know Spring, and hiring someone who knows some niche framework won't even pass resume screening. Not to mention when your boss asks: "Will anyone still maintain this framework in the future?"
Performance advantages show up on machines, while experience disadvantages show up on people. Enterprises pay for machines, but programmers pay for themselves. This is the structural dilemma of all "technology-first" frameworks.
3. Feat's Third Path
While developing Feat, we've been asking ourselves a question: instead of building "a better Vert.x," could we build "a faster Spring"?
The answer is yes. The core idea boils down to one sentence: Write Spring-style code during development, generate efficient plain Java code at compile time.
Specifically, in Feat you still write the familiar @Controller, @Bean, @Autowired, @RequestMapping — the mental model stays exactly the same. But when you run mvn compile, the annotation processor reads these annotations at compile time and generates the corresponding CloudService implementation classes. These generated classes handle bean creation, dependency injection, route registration, and resource cleanup.
At runtime, Feat no longer scans annotations or uses reflection — it directly loads the generated plain Java classes via ServiceLoader and executes them according to a fixed lifecycle. Route calls become ordinary method invocations, dependency injection becomes direct field assignment. No reflection, no dynamic proxies, no full classpath scanning at startup. The annotations you write are merely "intent declarations"; what actually runs is plain Java code generated at compile time.
What does this mean?
We ran a comparison test: the same Hello World example, Spring Boot 4.1.0 takes over five seconds to start with 12MB of memory; Feat needs only 400ms and 4MB of memory.
From five seconds to four hundred milliseconds, from twelve megabytes to four. You're still writing that same return "hello", but the engine behind it has completely changed.
More importantly, configuration errors are caught directly at compile time, instead of throwing an obscure reflection exception at startup or even at runtime. Since everything at runtime is plain Java code, Feat is also naturally friendly to Native Image, with even greater optimization potential in the future.
You don't need to leave your comfort zone — just swap the furniture inside for lighter materials.
4. Honest Boundaries
Of course, Feat is not a clone of Spring, and we have no intention of overstating.
The current data is based on Hello World scenarios; we will continue to publish results under real-world business complexity. Feat makes reasonable simplifications to Spring's fine-grained annotations — the core development model is consistent, but it's not 100% syntax-compatible. Additionally, after modifying Controllers, Beans, or feat.yml, a recompilation is required; during local development, ensure your IDE triggers Maven compilation.
Peripheral ecosystems like Spring Data, Spring Security, and Spring Cloud are still under construction in Feat.
We acknowledge the gaps, but we also want to demonstrate a path: high performance and great developer experience have never been mutually exclusive.
Final Words
The Java community doesn't need a second Spring, but it needs someone to prove: developers don't have to compromise between "the joy of writing code" and "the speed of running code."
Spring defined what Java development "should feel like," and that in itself is a great contribution. What Feat wants to do is make that feeling run a little faster.
Technology selection has never been a purely technical problem — it's a people problem. When a framework makes developers feel "I know how to use it, I dare to use it, I'm willing to use it," it has already won half the battle.
If you're also tired of the endless startup wait, give Feat a chance. After all, those few seconds you save are enough for one more sip of coffee.