A Frontend Love Story: Why the Strategies of Today Won't Build the Apps of Tomorrow

If you’re a frontend developer in 2025, you are a survivor. You’ve mastered a craft that exists in a state of constant, churning evolution. You embraced the power of declarative UIs, celebrated the elegance of modern component models, and learned to build entire worlds inside a browser tab. It was, for a time, a kind of honeymoon. We were in love with what we could create.

But honeymoons end. And for many of us, the love story has become strained. The passion is still there, but it’s buried under layers of accumulated complexity, performance anxiety, and the nagging feeling that we’re spending more time fighting our tools than building the ambitious applications we dream of.

This isn’t just a story about the pain of frontend development. It’s a story about a false choice we’ve been forced into a choice between two flawed paradigms that are holding us back from building the future.

(Part 1 of 5 in the v10 blog series. Details at the bottom.)

Part 1: The Client-Side Heartbreak - A War on a Single Front

Our first love was the interactive, client-side application. We were promised a world of rich, stateful experiences that felt like native desktop software, running entirely in the browser. But as our ambitions grew, so did the heartbreak. The very architecture that gave us this power became our cage.

The Tyranny of the Main Thread

The core philosophy of a truly performant system should be that "the browser's main thread must be treated like a neurosurgeon: only perform precise, scheduled operations with zero distractions."

Mainstream frameworks do the opposite. They treat the main thread like a frantic, overworked general practitioner. We ask this single, precious resource to be a world-class UI renderer, a high-performance JavaScript VM, a sophisticated layout engine, and a millisecond-responsive event handler—all at the same time.

The result is a constant, low-grade war for milliseconds. Every developer knows the feeling in their gut: the janky scroll as a list virtualizer struggles to keep up; the button that feels "stuck" because a complex component is rendering; the entire UI freezing during a heavy data calculation.

This isn't just a technical failure; it's a breach of trust with the user. Every stutter and freeze erodes their confidence in our creations.

Death by a Thousand Optimizations

To compensate for this architectural flaw, we've been given a toolbox of manual overrides. In the React world, this is the "memoization tax." In other frameworks, it might be manual change detection strategies or complex observable setups.

The result is the same: you, the developer, are forced to write extra code to prevent the framework from doing unnecessary work.

This tax is most obvious when looking at a "performant" component side-by-side with one that is performant by design.

import {useState, useMemo} from 'react';

// A typical "optimized" React component
const MyComponent = React.memo(({ user }) => {
    // This will only log when the component *actually* re-renders
    console.log('Rendering MyComponent');
    return <div>{user.name}</div>;
});

const App = () => {
    const [count, setCount] = useState(0);

    // We must wrap this in useMemo...
    const user = useMemo(() => ({ name: 'John Doe' }), []);

    // ...to prevent MyComponent from re-rendering
    // every time the App's state changes.
    return (
        <div>
            <button onClick={() => setCount(c => c + 1)}>
                App Clicks: {count}
            </button>
            <MyComponent user={user} />
        </div>
    );
};

import {defineComponent, useConfig} from 'neo.mjs/src/functional/_export.mjs';

const MyComponent = defineComponent({
    // The user config is passed in from the parent
    createVdom({user}) {
        // This will only log when the component *actually* re-renders
        console.log('Rendering MyComponent');
        return {text: user.name};
    }
});

export default defineComponent({
    createVdom() {
        const [count, setCount] = useConfig(0);
        // By using useConfig, the user object is stable across re-renders
        const [user]            = useConfig({name: 'John Doe'});

        return {
            cn: [{
                tag    : 'button',
                text   : `App Clicks: ${count}`,
                handler: () => setCount(prev => prev + 1)
            }, {
                module: MyComponent,
                // Pass the stable user object to the child
                user
            }]
        }
    }
});

At first glance, the Neo.mjs syntax might seem more verbose than JSX. That's a deliberate design choice. Instead of a custom syntax that requires transpilation, Neo.mjs uses plain, structured JavaScript objects to define the UI. This makes the code more explicit, eliminates a build step, and creates a blueprint that is incredibly easy for LMMs/AIs to read and manipulate.

Because the core is pure JavaScript, it also opens the door for optional, more familiar syntaxes based on Template Literals in the future, should the community desire it. The real story, however, isn't the syntax, but the outcome: the elimination of the memoization tax.

This isn't an advanced optimization strategy; it's a tedious, mandatory chore. It's a tax on our time and a cage for our creativity. We spend a significant portion of our development cycle simply preventing the framework from doing unnecessary work, a task that the framework should be doing for us.

One of the core goals for Neo.mjs v10 was to 'meet developers where they are,' making the framework more approachable with familiar patterns.

While the syntax for these functional components might feel familiar, it's crucial to understand that this familiarity is just the tip of the iceberg. There is a LOT more to it.

The State Management Labyrinth

Nowhere is this pain more acute than when building a truly complex, stateful UI. Forget a simple login form. Imagine a common enterprise requirement: a massive, multi-page, drag-and-drop form generator for a government agency, with 300+ fields, conditional logic, and real-time validation.

How do we even begin to build this in a single-threaded world?

The state management alone is a paralyzing choice.

Do we use hundreds of local state hooks and create a component tree so riddled with props-drilling that it becomes unmanageable? Or do we build a monolithic state object in a global store, only to find that every keystroke triggers a performance-killing update across the entire application?

We reach for heroic third-party libraries—each a brilliant solution to a problem that, if we're being honest, shouldn't be this hard in the first place. The simple act of building a form, a fundamental building block of the web, has become an architectural nightmare.

In Neo.mjs, forms are powerful, self-contained state managers. Each FormContainer inherently manages the data for its fields, building a hierarchical data object based on field name attributes. This simplifies data collection, validation, and even supports complex nested structures and lazy-loaded sections without requiring an external state provider. While forms can seamlessly integrate with the framework's state providers for broader application-level data sharing, their core functionality for managing form data is self-sufficient.

Part 2: The Server-Side Mirage - A Different Kind of Heartbreak

The industry saw this pain and offered a solution: "The client is too slow! Let's move rendering to the server with Server-Side Rendering (SSR)." Frameworks like Next.js and SvelteKit promised to solve our problems by delivering fast-loading, pre-rendered HTML.

And for a certain class of website, it was a revelation. Blogs, marketing sites, and e-commerce storefronts have never been faster. SSR is a brilliant strategy for delivering content.

But it is a poor strategy for building applications.

The promise of SSR quickly becomes a mirage when confronted with the applications we truly want to build.

How do you build a multi-window IDE, where a user can drag a component from one screen to another, when the server's job is to send you static HTML? How do you manage the persistent, real-time state of a financial trading dashboard when every update requires a round trip to a serverless function?

You can't. You end up with a clunky hybrid, where the dream of a fluid, native-like web app dies, caught between a slow client and an inflexible server. The server can't possibly know the intricate, second-by-second state of a complex user interface, and the client is left trying to hydrate static markup into a living, breathing application.

SSR isn't a solution to the problem of application complexity; it's an elegant retreat from it.

Part 3: The Architectural Epiphany - The Third Way

We've been trapped in a false choice: a client-side app that's a nightmare to scale, or a server-side site that can't handle true interactivity. Neither of these paths leads to the future we were promised.

The entire client vs. server debate is a distraction. The answer isn't about where you render, but how your entire application is architected.

The only real solution is to escape the main thread entirely.

This is the architectural epiphany that powers Neo.mjs. It’s a framework built on a simple, powerful idea: your application should not live on the main thread. It should live in a Web Worker.

By moving the entire application—the component tree, the state management, and the business logic—into a dedicated App Worker, we liberate the main thread to do what it does best: paint pixels. The result is a level of performance and responsiveness that single-threaded frameworks can only dream of.

That 300-field form generator that was an architectural nightmare? In Neo.mjs, it's trivial. The form's state and validation logic live in the worker, completely decoupled from the DOM. The main thread only ever receives the minimal set of changes required to update the view. The UI remains fluid and responsive, even with hundreds of fields, because it is architecturally impossible for the application logic to block it.

This isn't a workaround. It's a new paradigm.

Part 4: The AI Revelation - The Framework for the Next Generation

This architectural shift doesn't just solve the problems of today; it unlocks the possibilities of tomorrow. The next great leap in software development is upon us: the rise of AI as a co-developer and a core part of the user experience. And this new reality exposes the flaws of our current tools in a new and unforgiving light.

Neo.mjs is uniquely positioned as The Framework For and By AI.

The Framework FOR AI: Building the Cockpit

Interacting with powerful AI models requires more than a simple chat window. It requires a cockpit. A multi-window, IDE-like environment where a user can write a prompt in one window, see the AI's reasoning in a second, view the generated code in a third, and see a live preview in a fourth.

This is impossible with traditional frameworks.

But it's native to Neo.mjs. Its multi-threaded, multi-window architecture is the perfect foundation for building the complex, data-intensive UIs that the AI era demands.

The Framework BY AI: Speaking the Right Language

AIs are now writing frontend code. But we are asking them to write JSX or other template syntaxes—a mix of HTML and JavaScript that is verbose, error-prone, and fundamentally human-centric.

AIs don't think in JSX. They think in structured data. They think in JSON.

Neo.mjs is built on the language of AI. It uses declarative JSON blueprints to define UI. An AI generating a JSON blueprint is an order of magnitude simpler, faster, and more reliable than an AI generating JSX. The framework's DomApiRenderer then takes this simple blueprint and translates it into hyper-performant, secure DOM operations. The AI doesn't need to know how to build the UI; it just needs to describe what the UI is.

Beyond the architectural innovations, a significant effort has been invested in making the Neo.mjs codebase inherently understandable for AI. Through countless dedicated sessions, we've meticulously added intent-driven comments to core files (like src/core/Config.mjs), ensuring that when Large Language Models are pointed to relevant source code, they can easily grasp the underlying logic and design. This commitment to AI-readability is a testament to Neo.mjs truly being a 'Framework For and By AI,' designed for the future of collaborative development.

Your Invitation to a New Way of Building

This brings us to today. Neo.mjs v10 is not an upgrade—it's a new operating system for the web. It is the culmination of years of architectural pioneering, refined into a cohesive and powerful whole. It is the realization of the "third way."

Quick Project Overview

Neo.mjs is a pioneering multi-threaded JavaScript framework that redefines web development. Leveraging an Off-Main-Thread (OMT) architecture, it delivers unparalleled performance and scalability for complex applications, enabling desktop-class multi-window experiences with advanced features like shared state and component persistence, and a zero-builds development workflow. Its unified class config system provides a consistent, declarative approach to building UIs, managing data, and orchestrating application logic, ensuring linear scalability even for the most intricate projects.

We've rebuilt our core, created a new functional component model, and revolutionized our rendering engine. But you don't have to take our word for it. We invite you to explore for yourself.

Choose Your Own Adventure:

• I'm skeptical. Show me the code. Dive into our collection of 74 live, interactive examples. See the code, edit it in real-time, and witness the performance for yourself. No setup required. Many more demo apps can get navigated to from here.

  
  **[=> Explore the Examples Portal](https://neomjs.com/dist/esm/apps/portal/#/home)**

• I'm intrigued. How does it actually work? This article is the first in a five-part series that goes deep into the architecture of v10. Start with our deep dive on the new reactivity system that makes manual optimizations a thing of the past.

  
  **[=> Next Article: Deep Dive into the Two-Tier Reactivity System](./v10-deep-dive-reactivity.md)**

• I'm ready to build. What's the "Hello World"? Our create-app script will have you running your first multi-threaded application in under a minute. Experience the difference firsthand.

  
  `npx neo-app@latest`

Conclusion: Fall in Love with Frontend Again

For too long, we have accepted the limitations of our tools. We have patched the symptoms, paid the performance tax, and lowered our ambitions. We have forgotten the initial joy of building for the web—the thrill of creating something new, powerful, and beautiful.

Neo.mjs v10 is an invitation to rediscover that passion. It's a framework built on the belief that you shouldn't have to choose between performance and interactivity, between a powerful developer experience and an ambitious user experience.

It's time to stop fighting the main thread. It's time to stop paying the performance tax. It's time to start building the applications of the future.

It's time to fall in love with frontend again.

The Neo.mjs v10 Blog Post Series

1. A Frontend Love Story: Why the Strategies of Today Won't Build the Apps of Tomorrow
2. Deep Dive: Named vs. Anonymous State - A New Era of Component Reactivity
3. Designing Functional Components for a Multi-Threaded World
4. The VDOM Revolution: How We Render UIs from a Web Worker
5. Designing a State Manager for Performance: A Deep Dive into Hierarchical Reactivity

A Personal Note from the Author

Neo.mjs is one of Europe's biggest Open Source Projects, using the MIT license.
Meaning: The entire code base, as well as all demo apps and examples, are free to use.

To put the magnitude of the project in numbers:

Number of files:

• /src 303
• /apps 260
• /examples 471 (105 executable example apps)
• /test 48
• /resources 420

We are talking about 22,000+ commits inside the ecosystem, and 5000+ closed tickets. 770 passing unit tests.

While the Blog Post Series goes deep into the heart of the v10 core changes, they are barely touching the surface of the entire project. We are talking about a Buffered Grid on AG Grid level, Multi-Window IDEs directly included inside the Neo.mjs Website, a fully functional Calendar app, a vast component library, and more.

While Neo.mjs made it into the Top5 of "The most exciting use of technology in 2021" of the OS Awards Program, it is fair to say that the framework is an underdog. Maybe the most underrated framework in the history of frontend development.

I encourage you to take a deeper dive into the code base and examples. You will find countless hidden gems, and concepts which would have been worth patents.

Neo.mjs is an Enabler. Using it can give developers wings, and push companies literally years ahead of the competition.

My belief in Neo.mjs's transformative potential led me to dedicate myself fully to its development, stepping away from a "Custom Software Engineering Senior Manager" role to bring this vision to life. While the open-source landscape presents challenges, we are actively seeking partners and sponsors who share our vision and want to accelerate the future of web development.

There are several exciting enhancements on the horizon for v11+:

• A Neo.mjs middleware (SEO support, critical rendering paths, backend-connectors, Websocket connections to clients)
• A multi-window LLM UI
• A new design and theming system
• Template Literls support, for those who really want it
• A new version of the Docs App
• A lot more Learning Section Content

Neo.mjs is at a pivotal moment, poised for its next phase of growth. Your engagement is crucial to shaping its future and accelerating its impact. Use your chance to influence the project roadmap, let us know what you would love to see next, e.g. via opening feature requests. Most importantly, you can help to increase the visibility, to allow the right people to find the project. Even with something as simple as a mention on social media.

A huge "Thank you!", to everyone who was involved with reviewing v10 items.

Best regards & happy coding,
Tobias