DEV Community: Boga

Reinventing a Solved Problem: An Architectural Review of Odoo OWL Frontend Framework

Boga — Sun, 18 Jan 2026 19:39:25 +0000

In this post, I want to focus on Odoo’s OWL framework — the first major layer of frontend complexity in Odoo’s web stack — and question whether building it was truly necessary, or whether it was an avoidable source of long-term complexity justified by the familiar argument: “it’s an ERP, so it must be complex.”

For context, OWL (Odoo Web Library) is the JavaScript framework used to power Odoo’s frontend components, including the dashboard, backend UI, and parts of the website.

According to Odoo, OWL was built from scratch to solve a specific problem: allowing third-party developers to override and extend frontend components defined by other modules without modifying core files or losing changes during upgrades.

On paper, this goal is reasonable — even admirable. However, the conclusion that this required building an entirely new frontend framework is far more questionable.

The same goal is already achievable in all major modern frontend frameworks (React, Vue, Angular) through well-established mechanisms such as component composition, slots, higher-order components, dependency injection, extension APIs, and schema-driven rendering.

What a Mature Frontend Framework Would Have Provided To Odoo ?

By using a mature frontend framework would have provided several major advantages:

Clear, evolving documentation Mature frameworks have continuously updated documentation that closely tracks real-world usage and features. In contrast, Odoo’s documentation is often incomplete, outdated, or misleading — a problem significant enough to warrant a dedicated post.
Security responsiveness Modern frontend ecosystems respond rapidly to security disclosures, issuing patches without requiring a full application upgrade. In Odoo, frontend fixes are tightly coupled to backend releases, making security patching significantly more disruptive.
A vast ecosystem From form builders and schema validators to accessibility tooling, testing frameworks, and UI component libraries — modern ecosystems provide solutions that Odoo either reimplements partially or lacks entirely.
Developer familiarity Frontend developers today are already fluent in React, Vue, or Angular. OWL introduces a proprietary mental model that developers must learn on top of Odoo’s already complex backend abstractions.

Instead, Odoo now maintains a hybrid frontend stack where OWL coexists with legacy code — including multiple versions of jQuery (2.x and 3.x) still present in parts of the system. This alone should raise questions about long-term maintainability.

Before comparing OWL directly to React or Vue, it’s important to understand how OWL actually works.

At its core, OWL consumes XML definitions sent from the backend and dynamically builds a component tree on the frontend. These XML views are parsed, interpreted, and translated into JavaScript-rendered UI components.

For example, consider a simple OWL form definition:

<form>
  <field name="my_model_field_name"/>
</form>

The frontend receives this XML and uses the OWL runtime to translate it into rendered UI components.

Parses the XML into a component tree
Issues additional requests to fetch model field metadata
Decides which component to render based on field definitions
Optionally uses the widget attribute to select a custom renderer

In other words, OWL acts as a runtime XML interpreter that generates UI behavior dynamically.

The Hard Truth About OWL

OWL’s flexibility does not come from a fundamentally new idea — it comes from deferring structure and behavior decisions to runtime. This is not unique, nor does it require a custom framework.

The same level of flexibility can be achieved in React for example by using:

Schema-driven rendering
Plugin registries
Declarative extension points
Controlled overrides via dependency injection
Permissioned component replacement

Many systems already parse XML, JSON, or DSLs and render them safely within mature frameworks — without reinventing rendering lifecycles, state management, reactivity, or tooling.

By choosing to build OWL, Odoo accepted the burden of:

Maintaining a proprietary framework
Rebuilding tooling that already exists elsewhere
Fragmenting frontend knowledge
Coupling frontend evolution to backend architectural constraints

In a follow-up section, I’ll demonstrate how Odoo’s XML-based UI model could be rendered and overridden cleanly using React.js, achieving the same extensibility without introducing a custom framework. The goal isn’t to claim OWL is unusable — but to show that building it was an unnecessary architectural choice that added long-term cost without solving a novel problem.

A Simple OWL Component vs a React Component To make the discussion concrete, let’s compare a minimal OWL component with an equivalent React component. OWL Component (Simplified)

/** @odoo-module **/

import { Component, xml } from "@odoo/owl";

export class Hello extends Component {
  static template = xml`
    <div>
      <h1>Hello <t t-esc="props.name"/></h1>
    </div>
  `;
}

Usage is typically tied to XML view definitions sent from the backend, and the component lifecycle, state handling, and rendering behavior are governed by OWL’s custom runtime.

React Component (Equivalent)

function Hello({ name }) {
  return (
    <div>
      <h1>Hello {name}</h1>
    </div>
  );
}

At a surface level, both components are trivial. The key difference isn’t syntax — it’s ecosystem gravity.

In React:

Component composition is standard
Tooling (linting, testing, profiling) is mature
State, effects, and error boundaries are well-defined
Integration with schema-driven rendering is commonplace

OWL must reimplement or approximate much of this — while also introducing a proprietary mental model that developers must learn in addition to Odoo’s backend abstractions.

React Pseudo-Implementation That Mirrors OWL Overrides A common defense of OWL is that it allows runtime UI overrides — the ability for modules to replace or extend UI behavior dynamically without editing core code.

This is not unique to OWL.

Below is a simplified React-based architecture that mirrors the same capability.

Component Registry (Core)

const ComponentRegistry = new Map();

export function registerComponent(name, component) {
  ComponentRegistry.set(name, component);
}

export function getComponent(name) {
  return ComponentRegistry.get(name);
}

Schema-Driven Renderer

function Renderer({ schema }) {
  return schema.map((node) => {
    const Component = getComponent(node.type);
    return <Component key={node.id} {...node.props} />;
  });
}

Default Registration (Core Module)

registerComponent("field:text", TextField);
registerComponent("field:number", NumberField);

Override by Addon / Third-Party Module

registerComponent("field:text", CustomTextField);

No core files edited. No fork. No rebuild of a framework just to justify ERP is complex and it needs to have complex UI framework with no ecosystem no tooling no documentation.

by using this simple structure at least someone can achieve almost everything in OWL.js while also if needed they can leverage existing ecosystem nice tooling.
As well as:

Runtime replacement
Controlled extension points
Clear override ownership
Predictable behavior

The same pattern scales to:

Permissions
Feature flags
User-specific overrides
Context-based rendering
A better implementation that handles menus and UI translations.

This is effectively what OWL does — but OWL bundles it with a custom rendering engine, lifecycle model, and tooling stack.

3. “But React Can’t Do Runtime UI Overrides”

This is the most common objection — and it’s based on a misconception.

React absolutely supports runtime UI overrides.
What it does not support is implicit, unstructured mutation — and that’s a feature, not a limitation.

Runtime overrides in React are achieved via:

Registries
Context providers
Dependency injection patterns
Plugin systems
Schema-driven rendering

All of which are:

Explicit
Traceable
Testable
Tooling-friendly

OWL’s approach relies heavily on runtime interpretation of XML combined with implicit behavior resolution. This provides flexibility — but at the cost of:

Debuggability
Static analysis
Predictable failure modes

React’s ecosystem favors controlled extensibility over unrestricted mutation. That makes large systems more maintainable over time, especially when multiple teams and third-party developers are involved.

In other words:

OWL optimizes for maximum runtime freedom
React optimizes for sustainable extensibility

Closing Clarification

The argument here is not that OWL is unusable, nor that Odoo developers are unaware of existing frameworks.

The argument is that the problem OWL solves was already solved, and rebuilding a framework to solve it again introduced long-term cost without introducing a fundamentally new capability.

Odoo didn’t just choose flexibility — it chose to own the entire frontend stack. And owning the stack means owning every limitation, bug, security issue, and ecosystem gap that comes with it.

That is the real cost of reinventing the web stack. This does not make Odoo unusable — but it does make its long-term evolution far more expensive than it needed to be.

Odoo Core and the Cost of Reinventing the Web Stack

Boga — Tue, 13 Jan 2026 20:09:36 +0000

Hello everyone 👋

If you enjoyed my previous post, thank you — and if you didn’t read it, that’s totally fine. You can find it here: Odoo Core and the Cost of Reinventing Everything.

In this post, I want to highlight some quirks and questionable architectural decisions in the Odoo codebase, specifically around validation, data handling, and error management. These issues significantly increase debugging time and cognitive load, and most of them are problems that mature web frameworks solved decades ago.

As mentioned in my previous post, Odoo chose to be a custom-built framework that reimplements every layer of a modern web stack instead of building on an existing one, despite mature frameworks having solved these problems decades ago..

1. The Validation Layer (or Lack Thereof)

Validation is a foundational concept in any serious web framework. In mature ecosystems, validation is:

Declarative
Centralized
Separated from authorization and business logic

Odoo, however:

Has no dedicated validation layer
Does not use any standard validation library (e.g. Pydantic, Marshmallow)
Spreads validation logic across models, controllers, and JavaScript
Frequently mixes validation, authorization, and state transitions

The result is deeply nested, brittle code that is difficult to reason about.

Here’s a real example from the Odoo codebase that validates whether a user can change the state of a leave request:

# https://github.com/odoo/odoo/blob/19.0/addons/hr_holidays/models/hr_leave.py#L1361
def _check_approval_update(self, state, raise_if_not_possible=True):
        """ Check if target state is achievable. """
        if self.env.is_superuser():
            return True

        is_officer = self.env.user.has_group('hr_holidays.group_hr_holidays_user')

        for holiday in self:
            is_time_off_manager = holiday.employee_id.leave_manager_id == self.env.user
            dict_all_possible_state = holiday._get_next_states_by_state()
            validation_type = holiday.validation_type
            error_message = ""
            # Standard Check
            if holiday.state == state:
                error_message = self.env._('You can\'t do the same action twice.')
            elif state == 'validate1' and validation_type != 'both':
                error_message = self.env._('Not possible state. State Approve is only used for leave needed 2 approvals')
            elif holiday.state == 'cancel':
                error_message = self.env._('A cancelled leave cannot be modified.')
            elif state not in dict_all_possible_state.get(holiday.state, {}):
                if state == 'cancel':
                    error_message = self.env._('You can only cancel your own leave. You can cancel a leave only if this leave \
is approved, validated or refused.')
                elif state == 'confirm':
                    error_message = self.env._('You can\'t reset a leave. Cancel/delete this one and create an other')
                elif state == 'validate1':
                    if not is_time_off_manager:
                        error_message = self.env._('Only a Time Off Officer/Manager can approve a leave.')
                    else:
                        error_message = self.env._('You can\'t approve a validated leave.')
                elif state == "validate":
                    if not is_time_off_manager:
                        error_message = self.env._('Only a Time Off Officer/Manager can validate a leave.')
                    elif holiday.state == "refuse":
                        error_message = self.env._('You can\'t approve this refused leave.')
                    else:
                        error_message = self.env._('You can only validate a leave with validation by Time Off Manager.')
                elif state == "refuse":
                    if not is_time_off_manager:
                        error_message = self.env._('Only a Time Off Officer/Manager can refuse a leave.')
                    else:
                        error_message = self.env._('You can\'t refuse a leave with validation by Time Off Officer.')
            elif state != "cancel":
                try:
                    holiday.check_access('write')
                except UserError as e:
                    if raise_if_not_possible:
                        raise UserError(e)
                    return False
                else:
                    continue
            if error_message:
                if raise_if_not_possible:
                    raise UserError(error_message)
                return False
        return True

This function:

Validates state transitions
Performs authorization checks
Constructs user-facing error messages
Raises HTTP-facing exceptions
Depends on implicit global context

All of this happens in a single method.

In a modern framework, this logic would be split into:

A state machine
A validation schema
A permission layer
A controller-level response mapper

Because Odoo lacks these abstractions, developers are forced to manually stitch everything together — leading to massive functions like this one and endless debugging sessions.

2. Data Type Handling (or the Absence of Normalization)

Data normalization is another area where mature frameworks excel. Incoming HTTP data is:

Parsed
Typed
Validated
Normalized before business logic runs

Odoo does none of this.
Consider a simple HTTP controller:

from odoo.http import request

class MyController(http.Controller):
    @http.route('/hello/user', type="http", auth=False, csrf=False)
    def say_hello_user(self, **request_body):
        if request.httprequest.method == "POST":
            name = request_body.get("name", False)
            if name == False:
                name = "Boga"

            return request.render(
                'my_module.say_hello',
                {'name': f"Hello, {name}"}
            )

And a simple form:

<form method="post">
  <input placeholder="enter your name" name="name" />
  <button type="submit">Say Hi</button>
</form>

If the user clicks “Say Hi” without entering a name, the value of name will be:

""

Not False.

So now we’re forced to write:

if name is False or name == "":
    name = "Boga"

Why does this matter?

Because Odoo never normalizes request data. The same field can be:

Missing (False)
Present but empty ("")
Present with a value

All three cases must be handled manually, everywhere.

And yes — checking for False is still necessary, because a client could send an empty POST body:

fetch("/hello/user", {
  method: "POST",
  headers: {"Content-Type": "application/x-www-form-urlencoded"},
  body: ""
})

Now request_body.get("name", False) returns False.

In frameworks like Django, FastAPI, or Flask + WTForms, this problem simply does not exist.

3. Error Handling: The Most Fragile Part

Error handling in Odoo HTTP is arguably its weakest point.

Errors are:

Globally intercepted
Tightly coupled to translation logic
Often returned with HTTP 200 responses
Extremely difficult to override or customize correctly

This leads to unpredictable behavior where:

A response looks successful
But actually contains an error payload
Or silently redirects

Consider this simplified example:

# my_service.py
class MyCustomService:
    def check_balance(model_id, user):
        try:
            send_http_request("/some/other/service", {
                "id": model_id,
                "user": user
            })
        except HttpClient.not_found as e:
            return e

# my_controller.py
class MyController(http.Controller):
    @http.route('/check/balance', type="http", auth=True, csrf=True)
    def check_user_balance(self, **request_body):
        try:
            user = request.env.user
            my_service.check_balance(user)
        except InvalidBalance:
            return request.redirect('/invalid/balance')

        return request.render('my_module.success')

This code will not behave as expected, because Odoo’s global HTTP error handling will intercept exceptions before your controller logic can respond properly.

Once again, the lack of a clean separation between:

Transport errors
Business exceptions
HTTP responses

Makes even simple flows unreliable.

Conclusion

Odoo tries to be:

An ORM
A web framework
A frontend framework
A business platform

But it lacks the architectural discipline required to do any of these well.

The absence of:

A real validation layer
Request data normalization
Predictable error handling

Means developers spend far more time debugging framework behavior than implementing business logic.

None of these problems are unsolved — they were simply re-solved poorly.

Odoo Core and the Cost of Reinventing Everything

Boga — Mon, 12 Jan 2026 18:47:41 +0000

Hello, this is my first blog post ever. I’d like to share my experience working with Odoo, an open-source Enterprise Resource Planning (ERP) system, and explain why I believe many of its architectural choices cause unnecessary complexity.

Odoo is a single platform that provides many prebuilt modules (mini-applications) that most companies need. For example, almost every company requires a Human Resources system to manage employee details, leaves, attendance, contracts, resignations, and more. Beyond HR, companies also need purchasing, inventory, accounting, authentication, authorization, and other systems.

Odoo bundles all of these tightly coupled systems into a single installation. On paper, this sounds great — and from a business perspective, it often is. From a technical perspective, however, things get complicated very quickly.

Odoo Core Components

Below are the main Odoo components, ranked from least complex to most complex, and all largely developed in-house instead of relying on existing mature frameworks:

Odoo HTTP Layer
- JSON-RPC
- Website routing
Odoo Views
- XML transformed into Python and JavaScript
Odoo ORM
- Custom inheritance system
- Query builder
- Dependency injection
- Caching layers
Cache System
- Implemented from scratch
WebSocket Implementation
- Very low-level handling

Odoo HTTP Layer

Odoo is not built on a standard Python web framework like Django or Flask. Instead, it implements its own HTTP framework on top of Werkzeug (a WSGI utility library).

This HTTP layer introduces its own abstractions, request lifecycle, routing, and serialization logic, including JSON-RPC and website controllers. While technically impressive, it reinvents many problems that have already been solved — and battle-tested — by existing frameworks.

Odoo Views

In my opinion, this is one of the most problematic parts of Odoo.
Instead of using standard frontend technologies, Odoo relies heavily on XML-based views. These XML files are sent to the browser and then transformed using Abstract Syntax Tree (AST) analysis into JavaScript. In other contexts (like the website), the XML may be converted into Python code and sometimes back into JavaScript again.

This creates:

High cognitive overhead
Difficult debugging
Tight coupling between backend and frontend
Poor tooling support compared to modern frontend stacks

It feels like building a car from raw metal just to drive from point A to point B.

Odoo ORM

Odoo’s ORM is not a typical ORM.

It implements:

A custom inheritance system (instead of using Python’s built-in one)
Its own dependency injection mechanism
A query builder
Caching layers (LRU)
Model extension via monkey-patching

While powerful, this system is extremely complex and hard to reason about. Debugging model behavior often feels like navigating invisible layers of magic.

WebSocket Implementation

Instead of using a mature real-time framework, Odoo implements its WebSocket handling with very low-level logic, sometimes in surprisingly small and dense files.

A single comment from the codebase summarizes this approach better than words ever could:

"This diagram shows Odoo is parsing WebSocket frames manually at the bit level—implementing the RFC specification from scratch rather than using battle-tested libraries like websockets or ws4py that already handle this complexity."

The “Odoo Is Old” Argument

A common defense of Odoo’s architecture is that “it’s an old system” — originally developed around 2005 using Python 2.

However, this argument no longer holds.

Odoo was largely rewritten from scratch around 2017 to support Python 3. At that time, many excellent frameworks already existed and had solved the same problems more cleanly, while continuing to evolve without breaking their ecosystems.

Today, even small changes in Odoo’s core can break custom modules unless they are limited to simple CRUD models with minimal dependencies on core behavior.

Final Thoughts

Odoo is a powerful product and a successful business platform. But from a software engineering perspective, many of its design decisions prioritize control and internal consistency over maintainability, clarity, and developer experience. If you work with Odoo long enough, you stop asking “why does it work this way?” and start asking “how do I survive this upgrade?”