GÉRY DEBONGNIE: 0:01

I personally have the feeling that the framework Maybe it's not perfect, but the technology itself is really powerful. It works. It's battle-tested. They look at the Odoo itself. It works. We don't want like huge and difficult-to-learn framework. We want something that is light for us and for all functional developers, and we want it to be powerful at the same time. So we're kind of looking for those abstractions that have the highest ratio of value over cost of the abstraction. Each abstraction has a cost, even if it's even if it's not a runtime cost, it may be a mental cost. We just don't feel that the value added by changing Owl will bring a better return compared to disrupting the other ecosystem in such a deep way. You know, framework code costs much more to change in a way because the rest of the code base depends on it.

OLIVIER COLSON: 0:52

Hello Odooers! In today's episode, tech We'll be delving into Odoo fantastic web framework. We'll explore its evolution over the years, the decisions we've had to make, and where it's headed. I'm confident that both techs and devs will find this discussion truly enjoyable. So let's get started and I hope you have a great audio session with us. Hello, Géry.

GÉRY DEBONGNIE: 1:14

Hello, Olivier.

OLIVIER COLSON: 1:14

Welcome back.

GÉRY DEBONGNIE: 1:15

It's a pleasure to be back here in this studio.

OLIVIER COLSON: 1:18

Second episode to discuss some more JavaScript. Last time it was about also like the JavaScript library, the base blocks behind, uh, all the implementation of Odoo, actually. And today you're here to discuss about Odoo web framework. So what is that exactly?

GÉRY DEBONGNIE: 1:34

Yes. But maybe I should explain more precisely Owl is really just. You could see it like that. Just a component abstraction. It's really the basic building block for your user interface. And now today I think we are going to talk about the web framework in a more general terms. So by web framework I mean all the basic infrastructure code that lets you build your application, but not it's like a one level of abstraction higher. It's all those, um, all the code that helps you, uh, talk to the server, build a in a generic way, uh, any kind of screen, uh, utility code services, all of that is done by what we call the web framework. And I think it's a people don't realize how much the web framework is doing when you don't know much, much about Odoo. Maybe, maybe you will assume that we have developers working explicitly on each different screen, because for.

OLIVIER COLSON: 2:32

Anyone having having like, tried to develop a tutorial on the internet, uh, you can write everything from scratch, page after page, and.

GÉRY DEBONGNIE: 2:42

It could work. I think it's very common to work And it makes sense for a one-for-one shot application you have, like your contact pages. Then maybe you have a list view and a form view. And maybe you try to reuse some components between them, of course, but still you have to work explicitly on each different screen, each different page. And the web framework is doing, uh, really that's what it's, it's really good at. It's building your screen for you. It will define those basic form views, list views, Kanban views, and all those kinds of abstraction. And you need to to just write a short description of what you want to see. And the Odoo web framework will build from that, uh, concrete component template that will display your screen. So it's really helpful for developers to, to just focus on what they want to see and not how it will be implemented in Odoo.

OLIVIER COLSON: 3:32

It also allows more flexibility because of the Right. So, uh, you can inherit views, add just one field somewhere, uh, inside them, and the framework will handle all that and render that properly on the screen.

GÉRY DEBONGNIE: 3:45

Exactly. It's really very powerful in, in Odoo And then you add any fields or any kind of information inside your views. And from there, I mean, the web framework will build all templates and will display it dynamically. And that's very powerful, very useful.

OLIVIER COLSON: 4:03

And how is this, this modularity handled by the How would you how is it built actually because Odoo wasn't web-based originally. So it's been it's been a few years now. Uh, but how did it well, did it influence the design, the way the code is organized or how did it come and how did you work on it over the years? You mean.

GÉRY DEBONGNIE: 4:24

The modularity? Uh, yeah. I think, uh, the modularity was at the heart of Odoo from day one. Or maybe not day one. I don't, I'm not sure, but at least way before the web client, it was, uh, really based. Maybe by luck, maybe by good insight. It was built on XML document, uh, the user interface, and it still is, and it still is because it's really useful. So it didn't change that. And now the technology behind it changed a lot over the years. So first we have like a basic framework implementation. And that was actually what we call the web client. It's still called like that and most. Business code was only XML documents and Python code. You see, you didn't have to write that much JavaScript back then because you didn't need it. It was very basic. Now, the application evolved a lot over the years, and people need to customize a much more. The specific part of the flows, specific part of the screen, anything. And the framework evolved over the last ten years to meet that need. So yeah, it changed a lot from a technological standpoint. But the basic extended extensibility principle is still there. Mhm.

OLIVIER COLSON: 5:38

Mhm. Okay. And how did it evolve? So because you were talking about also that came pretty recently. We started talking about that.

GÉRY DEBONGNIE: 5:47

Four years four years ago.

OLIVIER COLSON: 5:49

Four years already. Yeah. Time flies. Uh, and uh well how did you maybe decide to well, you had to rewrite everything for Owl.

GÉRY DEBONGNIE: 5:59

Yeah, but we didn't really decide it. Like, uh, one day we said, okay, we'll rewrite everything now. Uh, it didn't come. It came, came up like that. So really, from the framework, just really kind of. It's an emergent property of the system. It was, uh, it was there all along, but we didn't really talk that much about the framework. And that's why we didn't organize the code really all the time with the framework in mind. We had we have, for example, still even now, we still have some, for example, assets bundling code that is in the base addon. And it should probably be in the web through the web framework.

OLIVIER COLSON: 6:34

So because the web module is the one adding.

GÉRY DEBONGNIE: 6:37

Yeah, the web module is the main JavaScript It's the web client code. But it's more than a web client. It's the web client is the application, the user interface that you see from a high-level perspective, like the the nav bar and the action manager and stuff like that. And we also have at the same time the framework, which is all the code that will generate those views and talk to the server. So the web, the web is doing all of that, and it's really more like a historical evolution like we have we needed to add some feature and then we add it. And the code maybe sometimes didn't change as much as it should. But still, we did pretty good work off of changing the code over the years.

OLIVIER COLSON: 7:25

And so you were saying there were still a bunch So the core of Odoo, what exactly is there?

GÉRY DEBONGNIE: 7:30

But I was thinking mostly about the assets JavaScript files, CSS files, and maybe transpile them, change them, all of that code, and put them together in one single simple file. Or maybe it will minify that that that code. All of that is still in Baz and should be on web and maybe not exactly. Yeah, we have some other controllers that are in the, in the base add-on.

OLIVIER COLSON: 8:01

Uh, how come it's, it's still because from a very if there are students listening to us. Maybe they're like, well, it's ugly. You shouldn't do that. Why are they keeping it like this? Uh, um, so first of all, is the plan to keep it like this? And second, why is it okay if it is okay to have it like that?

GÉRY DEBONGNIE: 8:22

That's a good question. I think it is okay in a way because it works and we don't have a really, really a big need to change. It would be more elegant from an intellectual perspective, but there is no, no really large need to do it. And I think it's the reality of large organizations. Sometimes you have code that's just there. It works. You don't have an incentive to change it right now, but maybe, uh, since you have a better vision of what you're doing, a better mental idea of what the framework should be and how it should be used in different contexts. At some point I think we should change a little bit the organization. But there is another reality that we should maybe at least mention. It's the fact that the code, the code itself is the result of the team organization. And until now, the framework code is mostly managed by two teams, the Python teams and the JavaScript teams. And that's why, in a way not really true, but in a way the both of them evolve independently. Mhm.

OLIVIER COLSON: 9:29

But they still do communicate right.

GÉRY DEBONGNIE: 9:30

Yeah of course. And yeah we'll talk about that

OLIVIER COLSON: 9:35

But okay. You can talk about it now. Uh why not. I mean the, the, you would say that the philosophy of the development is not the same because you have two different teams. And so sometimes you would need more, uh, centralization between, between both of them to go in the same direction.

GÉRY DEBONGNIE: 9:49

More coordination I would say. Yeah. I think there is a fact that, at some point, each team owns, in a way, some part of the code. Let the project team will manage the project code. The JavaScript framework team will manage the JavaScript framework code and so on. And because of that, the way we work is like we are. We are mostly concerned with evolving our own, uh, code base. And obviously, that's our job. And it's not so easy to go in a transversal way to, work on even to see the need when you need to, to do some change that involves more than one part of the code base. And I think we should do it. And we did. We actually did. For example, last year, uh, there was like a collaboration, a collab between the framework, the Python framework team, and the JavaScript framework team to improve the way, uh, views communicate with the server. So before that, views were doing a bunch of network requests in sequence to to fetch the data. When you look at, uh, for example, a CRM lead, you need to fetch a bunch of fields, and then maybe you have relational fields, you know, one too many and stuff like that. And those sub-fields may still contain other relational fields. Usually, you have many to many tags. For example, in a one-to-many,

OLIVIER COLSON: 11:18

Did you give a bunch of of of examples. So on the CRM lead or whatever other other model of such fields. Sorry. So so examples of such fields are on, on a specific model. So just so that people have a.

GÉRY DEBONGNIE: 11:30

Picture, I think I should have said, uh You have like the, the cellar-door is uh, one, uh, record. And so it's.

OLIVIER COLSON: 11:40

An order made by a customer. So you have a field on it that is the customer, and it is a relational field.

GÉRY DEBONGNIE: 11:46

Uh, yes. Yeah. It's a relational field. It's a many to one what we say it contains a bunch of other information, uh, a lot of information. And among the those information, you have a sell order lines. That's each element of the sell order. And so you usually have more than one relational field. Yeah. And so it's relational fields. It's one to many. You may have a bunch of uh order lines. You don't know how many beforehand. So this information are are stored in a different table on the database. And that's why you need to to load first the record for the, uh, the sell order. And then, you need to fetch the,the data for the order lines. And then maybe if those sales order lines contain themselves, for example, tax taxes, those are stored in a different table. Maybe it's a many to many tax. Yeah.

OLIVIER COLSON: 12:37

So it's even two tables because you have the many Yeah actually yeah it is.

GÉRY DEBONGNIE: 12:41

And so you need to fetch all the, all that data And what we did last year was to change that. We have a new controller, a new part of the code in Odoo that will just receive a description of what the view needs and will fetch all that data in one step and return it to the server to the web client.

OLIVIER COLSON: 13:04

I mean, okay, so it's way more efficient.

GÉRY DEBONGNIE: 13:06

So it's a it's much better to do it like this. Uh, it doesn't have to wait too much. Uh, all those network.

OLIVIER COLSON: 13:13

Requests, how much faster was that? You know, I.

GÉRY DEBONGNIE: 13:16

Don't have numbers. So you save a instead of doing, like, four requests, you you do it just once. So the part that fetches the record itself is, is faster, but it depends on the network condition and all all of that.

OLIVIER COLSON: 13:31

When did you realize that it was you or someone How? And more generally, how do you know where to put the effort to make the framework evolve? Because, uh, you, you, you were mentioning that the framework is an emergent thing. And so essentially that, well, you know, you start doing something, then you don't really care about making a framework. Then over time, you realize that there are things that you need to do in other places that look a bit like the ones you already did, and then that starts becoming a framework. So how do you know what to do? How do you choose what to do? Uh, for example, this optimization you were talking about, how did you know where does it come from? Yeah. Where did it come from?

GÉRY DEBONGNIE: 14:12

Yeah. The for that case, uh, it was really framework team that was the champion for this feature. So it was, uh, looking at the network tabs and looking at looking at all those requests and was looking for a way to to merge them together. So in this case, it's our own R&D, the Python framework team that started with this project and uh, they talked to us, and then we made it happen together. So for that case, this is, uh, internally and that's quite, uh, common actually we have in the framework teams since many other teams depends on us, it's common that they ask us questions on how to to solve a specific problem. When you look at it, we have like many kind of. Different problems. Sometimes you try to to give them a quick and dirty solution, if it makes sense. But you know, if you have the same question that comes back and again and again, at some point you start to say, okay, we maybe we need to to do something about that. Maybe we need to find a better way to, to to solve that issue. There is like a technical, uh, vision that we need to, to, to evolve over time. So we have questions that are asked. We have also other, um, other possible possibilities. For example, uh, we have uh, when we give trainings, we can see how people react to, uh, to the framework. Yeah.

OLIVIER COLSON: 15:43

I think it's important to do it because maybe actually possible to do them. Uh, they just don't know.

GÉRY DEBONGNIE: 15:50

Right? Yeah. That's a very common problem. And sometimes.

OLIVIER COLSON: 15:53

Probably the most.

GÉRY DEBONGNIE: 15:54

Common. And sometimes also we just, uh, look into We just look into all the Odoo code base for some keywords that we know are usually red flags.

OLIVIER COLSON: 16:07

You're like, what? What are these weirdos doing And then.

GÉRY DEBONGNIE: 16:10

Yeah, if you see something that's name underscore this or you will be fired. Uh, it's probably a red flag. And so we look into the code base for those, uh, those keywords. And sometimes we, we, we see we try to understand why they needed to use that for their specific problem. And maybe there was no other possibilities. So it makes sense even if you don't want to do it. But we need to update the framework to make it, uh, possible to solve their needs.

OLIVIER COLSON: 16:43

Yeah. If you start seeing the same hack or nearly something is probably needed in the framework. Yes.

GÉRY DEBONGNIE: 16:50

And it makes sense because, uh, Odoo is now You have, like, a lot of needs. You need to have your code base, and need to work in iFrame. It needs to be translated. It needs to be fast. It needs to work on other websites. It needs to work in many different situations. And all those needs need to be met in a proper way in a framework.

OLIVIER COLSON: 17:15

Also, I would say that the software is becoming And so we want to add this, this, this layer of polish that wasn't exactly that wasn't really there in the past, but that is really needed. And it is essentially JavaScript. Uh.

GÉRY DEBONGNIE: 17:28

Yes. And now the teams are getting larger. Uh, you have like so.

OLIVIER COLSON: 17:34

We also have the resources to.

GÉRY DEBONGNIE: 17:36

So many people are working on functional teams And so we have resources to make it work. We just need what's difficult is to have the vision of, uh, what's the best way to solve a problem. Sometimes you know that there is something wrong. You don't exactly know how to, uh, make it in an elegant way, you know, in a way that feels right. And sometimes, uh, you don't know it right away. And maybe six months later, some other feature will be merged, in Odoo. And maybe it will click that that feature can be used as a basis for, uh, the problem that you had before. And using that you may, you may now now solve the problem properly.

OLIVIER COLSON: 18:21

I think the, the fact having a clear mental image your, your framework, your software is doing is also very important, uh, because indeed, having something elegant is important. Not just because it's nice to do nice code and nice looking code, but just because it will be more it will be easier to understand for newcomers, it will be easier to use. And I think it's very important when you're making a framework, like to have something self-explanatory. Uh, I would say, yeah, I think.

GÉRY DEBONGNIE: 18:51

It's difficult, but when, when I, when we have it bypasses your, uh, your brain in a way. And it's, um, and your intuitive, uh, brain can, uh, validate that it's a good way to, to model the problem. And we want a framework that is light. We don't want, like, a huge, uh, and difficult to learn, uh, framework. We want something that is light for us and for others for all, uh, functional developers as well. And we want it to be powerful at the same time. So we're kind of looking for those abstractions that have the highest ratio value over, uh, cost of the abstraction. Each abstraction has a cost, even if it's even if it's not a runtime cost, it may be a mental cost, you know, because now developers need to know to know four things instead of two.

OLIVIER COLSON: 19:42

Yeah, indeed. Adding concepts, uh, always has a to understand them. And when you will read some, some tutorial or whatever about it, you will people will are going to talk about them. And so you need to understand what they're talking about. So there's always a cost because it's making. Things are more complex, actually, yeah.

GÉRY DEBONGNIE: 20:00

It's making maybe it's more efficient to have problem. Maybe one is better in one situation, and another idea is better in a different situation. But at the same time, people need, to use the correct one. And it's more difficult to the framework may not be better just because it's more efficient. In one case. It doesn't matter if people use the wrong abstraction anyway. So we need to find the balance between something that is, uh, very, very optimized, very fast from the performance standpoint, but also it needs to be intuitive.

OLIVIER COLSON: 20:37

Talking about intuitive things and making things Uh, what can we expect for the future of, uh, Odoo web framework? So, uh, what what what is what is coming? What are the plans?

GÉRY DEBONGNIE: 20:48

I personally have the feeling that the framework It's maybe it's not perfect, but the technology itself is really powerful. It's good, it works, it's battle-tested and it's proven to work. You can look at Odoo itself. It works. Uh, what's missing, in my opinion, maybe first is some nice packaging around it, you know, like a good documentation and maybe some tweaks here and there to to make the experience seamless. You want people that start to develop Odoo to feel that there is some cohesive experience, that it's it works and it's like they expect, you know, the, the principle of least surprise at the same time. So we want to design the framework to be, um, intuitive in a way that even if developers don't know that much about, um, the framework itself, they will by default use the correct, uh, solution. So that's what, uh, that's what called the pit of success. We want that. If they don't know, they will choose one solution maybe by elimination. And then that will be the the proper solution in Odoo.

OLIVIER COLSON: 21:58

The default option chosen by most people must be Yeah.

GÉRY DEBONGNIE: 22:02

So I think we need to sometimes we will evolve. We will change the framework in that uh, that direction. We will try to that's what we're doing now. We're trying to to change sometimes slightly, sometimes in a more important way. Uh, we need to change the way some components work to make it more easier to use. Uh, we need to, to, to update some, uh, mostly components and service. But really what's missing is the packaging around. It's a good developer. We want to have a better developer experience and so on. That's really important. But the the technology in the web framework may, may be at least some layers of of it will not change that much in my opinion.

OLIVIER COLSON: 22:46

Um, okay. Maybe I'm, I'm obliged to ask this question is there a null three coming to support all that?

GÉRY DEBONGNIE: 22:53

Exactly. That's a good point. I mentioned that the framework is good. It's not perfect, but it's good. And I believe that the bottom layer Owl itself is really good enough for all our needs. So if you look at Owl for the last Owl commits for the last year, you will probably see just a few, uh, minor fixes and some small improvements. And so far now we don't need we don't want to change it. We want to build the rest of the framework in a in a better to be it in a better position. But all will not change, at least for the next year. I would, I wouldn't expect so.

OLIVIER COLSON: 23:29

So far nothing is planned.

GÉRY DEBONGNIE: 23:31

Yeah we have a bunch of ideas, some radical, some We're just don't feel that the value added by changing all will bring a better return compared to the, uh, to disrupting the Odoo ecosystem in such a deep way. You know, framework code costs much more to change in a way. In a way, because the rest of the code base depends on it. Yeah.

OLIVIER COLSON: 23:54

It's changing what's underneath the framework. So then you would need to change the framework and then all the customization exactly on top of it.

GÉRY DEBONGNIE: 24:01

So exactly. So the main takeaway is that we want Not much Owl itself, but what's on top of it. We will try not to change it too much, but we all the time in the direction of making it more powerful, easier to use, and simpler to understand.

OLIVIER COLSON: 24:22

And that will be our final word because we have Thank you for your answers.

GÉRY DEBONGNIE: 24:28

Thank you Olivier.

OLIVIER COLSON: 24:29

Well, that wraps up today's episode, folks. I hope you've gained new ideas and knowledge from our discussion. Exciting isn't it? If any questions pop up, don't hesitate to post it to the pad so we can address it. Until next time. Cheers!