OWL: The Fastest Javascript Framework in the World

Géry: 0:00

Owl represent about 15 months of work. The resulting framework is about 5000 lines of code, so if you think about that, it's quite small for its feature set. All feature from Owl fits into that 5000 lines of code. I would say it's medium sized in the world of JavaScript framework. I tried to make a prototype for a very small minimalistic component system using web as a template engine, and web is the main template language for a tool. You can think in terms of evolution or revolution. You can evolve your framework making some change all the time, but at some point you need your revolution. And that's what it was. We just want people at Odoo to feel productive, happy and to be comfortable.

Olivier: 0:43

Hi Odooers! And welcome back for another episode. Today we'll test out a new concept, taking a dev and tag approach. To kickstart this series, we invited Géry Debongnie, software developer at Odoo. He coordinated the complete revamp of our JavaScript framework. We'll explore the roots of this change, the different implementation choices that were made, and the new features that got added. Ready? Let's dive in! Hi, Géry.

Géry: 1:06

Hello, Olivier.

Olivier: 1:07

How are you?

Géry: 1:08

I'm fine. It's a pleasure to be here.

Olivier: 1:09

For me as well. So could you explain what you're working on, what your job is?.

Géry: 1:16

At Odoo, I'm kind of in charge of the JavaScript framework. So all the code that is running in your web browser. And more precisely, I'm specialized in the web client code, meaning the back office application, you know, the application where you have users interacting with accounting sales, whatever. Some of that code is executing in the browser, your web browser, and you talk to the server and I'm working mostly on the JavaScript code.

Olivier: 1:45

It's a big responsibility because basically your work is used everywhere. And so could you explain how you got to do that? Were you hired to do that, or is it something that just came with time?

Géry: 1:56

I was hired at Odoo like nine years ago and I knew nothing about JavaScript at all, really nothing. I expected to work on the Python framework, to be honest.

Olivier: 2:08

Okay. But you still were supposed to work on the framework. You were interested by that?

Géry: 2:12

Yeah! My background is in mathematics, which is kind of unusual at Odoo, and I expected to work on big conceptual abstractions. And in my mind the Python framework was where it was.

Olivier: 2:26

It was the place to be.

Géry: 2:28

And JavaScript was kind of a place for script kiddies. Back then. It was just like random work, but not really structured, not really professional back then.

Olivier: 2:37

And how did you discover JavaScript then?

Géry: 2:40

Oh well, I started very simply. My first task was working on the pivot view, if I remember correctly, and I started working on that project for a while. I had to learn JavaScript completely, which was not so difficult in a way. I had other people to do helping me as well, and I worked on that code base. And then that task led to another task which led to another task and so on.

Olivier: 3:07

And the you just became the expert. Pretty much never stopped working on JavaScript. It's so much like R&d. It's really, woah!

Géry: 3:16

There was no team back then. It was just a bunch of tasks and we were assigned tasks. And of course, your first task in a way, change the way you will be considered by Antony in particular, and you will be tagged to that code base and at some point you will not escape.

Olivier: 3:33

Antony is is the CTO for people not knowing, you might find talks that he did that Odoo experience a bit everywhere on YouTube but just go have a look. And how many people were in R&D back in back at that time?

Géry: 3:46

I'm not sure. I would say 30, around that number.

Olivier: 3:51

It was really nearly nothing. So yeah, it was really like a small classroom.

Géry: 3:55

Yeah, it was in the farm, which is now called Farm one, because.

Olivier: 4:00

The original office

Géry: 4:01

Yeah, we have three farms now. And we had like a few rooms, you had the Python framework room, the JavaScript framework. It was not really a team, it was just a place where people working in JavaScript were working and I guess that's the origin of the actual teams.

Olivier: 4:21

Okay. And so when you started really working on the framework, what were the big milestones? How did it evolve in time?

Géry: 4:29

Okay. I just want to say that; first I came At Odoo after version seven and it was really the beginning of the web application. The first web based version of Odoo was 6.1. And back then I want to say a 'good job to the original developers', in my opinion, they did a fine job back then. They really have a kind of well structured code base with classes and widgets. And back then, there was not much example of large application. So it was really a good beginning. But the problem was that it was a good base initially, and the code started evolving in all kind of directions. We had to push feature, to merge feature all the time and we could not really take a step back. No one had the responsibility to take a step back and change the direction of the project.

Olivier: 5:20

Yeah, it's often like that when you're working on code and development. You add things, you add things, and at some point you realize, well.

Géry: 5:27

What are we doing exactly?

Olivier: 5:29

And you realize that you have to clean a little bit.

Géry: 5:31

Yes. It's really, I guess, typical maybe of the startup mind. I remember that Anthony told me we were a startup, even though there were more than 100 people working at Odoo back then. But it was still a startup. And we just were just moving fast. And back then it was, I would say, the Wild, Wild West. There was no module system, for example. That's a really something that struck me, when you had JavaScript files, you needed to declare them in your asset system, and it was just a single function that was executed in the global scope. So, you had to make sure that your file was loaded after a load of files that it depends on. And it was really a struggle. When you have to change the order of the JavaScript files that you want to to work with, just to make it work. Otherwise it would crash. And it was working. Everything hadto work on global variables. So, everywhere we had to load functions from open ERP.web, dot something, for example, and it was kind of unstructured.

Olivier: 6:37

Very, very manual. And yeah, no structure at all. Puts everything there and to load and....

Géry: 6:43

It was very manual because we didn't know better then.

Olivier: 6:45

And so, how did we change that then? I suppose the next sentence you're going to say is, Oh, but no, it's not now and then it changed'

Géry: 6:56

It changed. And that was one of my first personal projects. I would say. I was really worried about that. And I studied the JavaScript ecosystem back then and noticed that the other applications had much better tooling and module system. And so, I started doing it one myself. I showed Antony that we could use a module system, at least to resolve dependencies ourself properly, so we would not depend on the order of the files. And it took a while to convince him, but I did it.

Speaker3: 7:28

But you managed to.

Géry: 7:29

Yeah, I think it was a good example of change being driven bottom up, you know, at Odoo back then. Even now, but back then in particular, you could initiate a project if you believe in that. Of course, if it takes so much time, you have to convince Anthony or someone that is useful. But you could, you could do it. And I started working the defined function, which was the module system back then, and after a few months I could merge it. And I think I'm not sure, but I had the largest commit in the Odoo code base because I had to to move every single JavaScript file from the code base.

Speaker3: 8:08

Remember the number. You remember the number. A lot of lines.

Géry: 8:11

And I have no idea.

Olivier: 8:12

People will have to check it.

Géry: 8:14

But for years after that, if you blame the code base, you would find my name everywhere.

Speaker3: 8:22

Everywhere, I guess because yeah.

Géry: 8:23

Initially. But after it changed, I was no longer the main author.

Speaker3: 8:28

Sure.

Géry: 8:29

It was a fun fact.

Olivier: 8:31

Okay. And then what happened? And then? Well, the framework and the web client evolved. So first open ERP became Odoo, around version nine. We made the new design, so we redesigned the look and and feel for the client. There's huge gap between eight and nine.

Géry: 8:50

Yeah, it was a big milestone. But back then my team was about four people, so we have a number and then studio arrived in version ten, if I remember correctly.

Olivier: 9:02

So, Studio is that thing that allows non developers to customize the UI and just add fields, change pretty much everything without coding a single line.

Géry: 9:10

Yeah, I think we should explain just a little thing before that. Is that Odoo is very particular in a way, it's that a lot of the user interface is stored in a database and it's really uncommon in the world of web application.

Olivier: 9:23

True. And how is it stored?

Géry: 9:26

In XML document. So yeah, is that a good point, I wanted to say that, but there are two points. First, it's stored in database. It means that you can customize it at one time. So whenever a user is working on a Odoo database, he can, if he has the right to do that, change the user interface just dynamically and it will just work. He doesn't have to restart a server, does not have to update a code base and nothing at all. Just update some documents, some simple documents. And the fact that it's in XML is a really important part of Odoo because it allows other add ons to customize existing XML documents by some special system called XPath. It lets you hook into specific place in XML documents and change them. And that's key to do customization, but it's kind of detailed. I just want to say that the UI is, not all the UI, but a lot of the UI is stored in that database and Odoo studio was then just basically a UI on top of that to edit.

Olivier: 10:31

So that you don't have to edit the XML yourself.

Géry: 10:33

Yeah, exactly. And it's useful for a business analyst or even customers if they want to use it directly to design their own customized application.

Olivier: 10:45

Sure. And so you had to adapt the framework, the JS framework, I mean, to work with that.

Géry: 10:50

Exactly. Basically, I remember when Martin started working on that, we had talked about how to do it in the JavaScript framework and the answer was it could not ever work without redoing everything. So that's what we did at the end. We started reworking the JavaScript code for the view to make it useful for the studio. And when we released studio, we released a new set of views that was used only for studio. And it took us one year, one extra year, not that much, but a little bit less than that, to remove the old views and to replace them by those new studio studio.

Olivier: 11:29

Long term project and you're achieving it step by step.

Géry: 11:33

Exactly. I think it's very common when you have to evolve a system to make it useful at each step. It should work at all times. Of course, you cannot stop Odoo for one year and say, okay, now we.

Speaker3: 11:43

We will put a banner 'Sorry, this view doesn't work. Come back in six months. It will probably be fixed.' It doesn't work like that.

Géry: 11:50

So it would be nice, but no, it doesn't work like that. So it's common when we change framework piece, you know, it's like a changing a part of a car while it's running. What should we do? Do we just have to add an extra motor or extra piece and then hook them, pipe them together, make sure it works, and then at some point you can remove the old ones.

Speaker3: 12:10

So it's a very good image. Well.

Géry: 12:15

Okay, so then version 11 was the new views. And then after that, I noticed for the next few years a big shift towards more and more JavaScript. And I want to explain that a little bit.

Before that, the main idea driving Odoo development was: 12:29

you write your model in Python, it will talk to the database and you describe your user interface in those XML documents and that's the way you will work with Odoo. And I think most people, even now, probably work like that. They write XPath and they write a Python code. But at some point, we need to have the extra step of polish. You know, you cannot do everything by just standard components. You cannot display, for example, this accounting reconciliation component, it's not a view, It's something completely specific to accounting. And more and more during these years, we saw more and more use of JavaScript for specific use case, for business use cases. At the same time, the JavaScript ecosystem completely exploded. You had bundles, frameworks, spiders, whatever, a lot of stuff where updating on the on the JavaScript scene and Odoo was moving further and further away from the state of the art.

Olivier: 13:33

So it was about time to modernize.

Géry: 13:37

Yes, exactly. I noticed that when I saw that new people, newcomers at Odoo, some of them started knowing about React framework or view framework or the other kind of tools, and they were not really attracted to the JavaScript codebase at all. It was kind of weird going back to the middle age. And so there was a need for a change. Also, there was another reason for that. It's that it was not just the state of the art, it was the fact that since we had to use our JavaScript for more and more complicated use case, the complexity of our code base was increasing very fast, because every feature that you add interact with other features and you need to be sure that they work together. And the way it worked with the old widget system, that was the previous framework back then, you had to do it all by hand every time. And it was getting difficult to work with the JavaScript ecosystem. And that's why I think at some point I wanted to modernize that. And I tried to make a prototype for a very small, minimalistic component system using QWeb as a template engine. An Qweb is the domain template and language for Odoo.

Olivier: 14:57

Yeah, which is used for alot of things, to generate PDF, this kind of thing as well and views.

Géry: 15:03

So I made a prototype, about four years ago on that and I managed to convince Anthony again that we could work on doing a new component system. I sold it to Anthony like a small change, even though at the end.

Speaker3: 15:21

How easy was it to convince him? Because it was it was not that small, actually.

Géry: 15:26

I think it was ready to be convinced. So he felt the time was right.

Speaker3: 15:31

All the signs were pointing to the need for a change.

Géry: 15:34

It was not very difficult. Yeah. Even funnily enough, it was convinced that we needed such a system and not using an existing framework. But we can talk about that just a little bit later. So he agreed to let me work on that, I made a prototype and I worked on what became Owl in 2019, and at the end of the year, Owl 1.0 was released. That was the first release for Odoo version 13.

Olivier: 16:01

What was using it back in the day?

Géry: 16:04

For other version 13? It was not used very much. It was just used at some some components like the control panel. Our first strategy to convert our code base to all was to start bottom up again. So to start converting some some end components and then to convert the buttons of this component, this one, and.

Olivier: 16:25

Move up in the in the tree of dependency.

Géry: 16:27

Yes, exactly. But it was a daunting task to update our code base. I don't know more than 100,000 lines of code on JavaScript code, XML, all of that needed to keep working and to convert that to a completely different system. So it was a big task.

Olivier: 16:42

Plus the things kept on being made on top of that by other teams.

Géry: 16:47

Yes.

Olivier: 16:48

It was being developed for other needs at the same time. And so I guess it is a nightmare.

Géry: 16:53

Exactly. The car was still running and.

Speaker3: 16:57

Adding pieces anyway, so we.

Géry: 16:59

Replacing the motor and at the same time, some other people were painting the c ars. I don't know. It was very scary in a way to do that.

Olivier: 17:09

Okay. So and the strategy changed after that?

Géry: 17:11

Yes. After that, we change dthe strategy to go the other way. So instead of going bottom up, we went top down. We started working on the root component and then the child component, so on. So the web client components, the nav bar, the action container, the place where the menus are displayed were converted and we had to write adapters and all that kind of plumbing code to make sure we could use at all time the old widget system with the component system in every order. So in some case, you had all component which contains a widget which contains a new component and stuff like that. So it was a kind of a plumbing nightmare, but we made it in a way. At the same time, a lot of other changes were coming in the framework. So for example, we modernized our assets pipeline, we use the modern JavaScript module system and all of those changes were coming at the same time concurrently to what we were doing.

Speaker3: 18:11

So it was perfect and super easy.

Géry: 18:14

Those mast three years have been really interesting. I'm not sure it's a compliment, but I mean, yeah, no.

Speaker3: 18:23

That's a good way to say it, once it's over. You probably weren't saying it this way once it was being done.

Géry: 18:30

We lived in interesting times and so let's just keep going that roadmap, the way the framework evolved. We worked for one year to update those main components and we started working on Owl two after that, when we noticed that we could fix some small errors, we could add some missing features that could not be added to the all one code base to make it faster and stuff like that.

Olivier: 18:56

So yeah, actually using it, you realized that things needed to be changed into the framework. It's also pretty much typical, I guess, when you developed any kind of tool and actually even outside of development, you develop something, you make something that is supposed to be used to do something else, and then you realize that it could be better or it doesn't really work in this case.

Géry: 19:17

You need to fix all bugs, then you need to add additional feature to rework it to make it fit a little bit better what you use it for. And sometimes you have some big changes that you just don't know how to put into the existing system. And that's why we had to do to make Owl two. In a way, we were stuck. We could not move past the actual design of Owl one. We were not very experienced in framework designs, so it was a good moment to start doing it in a better way.

Olivier: 19:47

And benefit from the experience you got from the first iteration. Yeah. And so this brings us to version 16. So the last version, Bleeding edge version of Odoo, where is Owl in that version? Where is it used?

Géry: 20:00

And it's used nearly everywhere in the appliance, but not everywhere in Odoo. So I just want to clarify some important point. Odoo has many different aspects of it's code base and in particular, I want to explain what the website is. The public website is not at all rendered by Owl, it's rendered by the server. So you have templates on the server side. They are rendered for the public website and that part is not at all in Owl and I guess it'll never be done in all. But that's another question. And you have some other small code base that are not still converted to Owl, but almost everything is done for version 16.

Olivier: 20:44

So that's a big achievement.

Géry: 20:46

Yeah, we started removing the old code base a few weeks ago. I had a request where I removed 120,000 lines of code. It was not mine. I just approved it.

Speaker3: 20:56

But that's all right. I guess. So.

Géry: 21:02

I just want to add another point. So it's the fact that my team grew from, let's say, four people when I started working on the JavaScript team to now nearly 20 people. So that gives you an overview of what it looks like.

Olivier: 21:15

And people are not scared to start doing JavaScript Odoo anymore. Some of them maybe, but it's not legit anymore. I suggest we discuss the details of all a little bit more now. So first thing, actually we didn't mention it, but I guess it's time to do it because people might be like 'Owl'? But why? Why did they call it Owl? What does that name mean, actually?

Géry: 21:44

Well, when you start working on a project, you need a name. I don't know why, but we always need a name, of course, to think about what we are doing. And course we needed a name. I just was looking for a short name. I wanted a catchy name. And at some point we found a Owl where the tree first letters of Odoo Web library.

Speaker3: 22:05

Perfect. Perfect.

Géry: 22:06

And fun fact, there is a Unicode Owl icon.

Speaker3: 22:10

So it's nice, but it's everywhere.

Géry: 22:13

It's easy just to copy paste that icon everywhere. Yes. So that's why it's called like that.

Speaker3: 22:20

Cool.

Géry: 22:20

It was just a code name first, but.

Olivier: 22:22

Then you need a name for this kind of thing. You know, you always need to name your baby, right. And it kind of is yours, so. Okay, so we mentioned that it was a homemade framework. Why going from a homemade framework instead of using something already existing? So you mentioned that earlier. You mentioned you we were we would go back on that. That's the time. Why did you do that choice?

Géry: 22:47

Okay. So that was a question we asked ourselves many times. But my answer is that, you should think of frameworks like cars, let's come back to that analogy. Cars are optimized for various use cases. You have fast cars, racecars slow. No, slow cars is not..

Speaker3: 23:09

Usually you don't buy them for slow cars.

Géry: 23:11

I meant small cars, big cars to move a lot of stuff, family cars. And they are all kind of solving the same problem, which is moving stuff from somewhere to somewhere else, but in a different way. And if you think about that, they are optimized for various use cases. And frameworks are exactly like that. You have frameworks that are optimized for server side, for ease of development, for raw speed, whatever you need for. Each framework has a feature set, and that feature set implicitly or explicitly defines some of the best use cases you can use them for. And for example, I think that Google use many frameworks. They have some custom frameworks as well for their own applications because the state of the art does not satisfy their use case. And for Odoo, it's the same. Odoo is very specific in the fact that, as we mentioned earlier, a good chunk of the user interface is stored in a database, and even if it's not storing database, it's stored on the file system as XML templates. So in both case XML and you can use Express to customize them. So, this is extremely powerful and we want to keep using that system for Odoo. And if you think about that, there are no frameworks, to my knowledge, that use an XML language as a base for the templating system. No, no. So we could have used Vue or React and made some translation layer to translate an XML template into an actual React template or Vue template.

Olivier: 24:46

But then there was a cost in complexity and performance, I guess.

Géry: 24:50

Yes, not only that, but in developer experience? Developer would not feel like they would use Vue.

Olivier: 24:58

And we're like a new framework, so why not just going for a new frame?

Géry: 25:02

Exactly. So that's one of the main points. Another point is that we need our code base to be very customizable. So that's one of the big selling point to do, is that we have many add ons and those add ons, they basically plug themselves inside the core system. You have a web client which is the base of the user interface application, and then you may have accounting add on that will plug itself in, that will add all extra features and all other add-on will do the same. And so they need to be able to hook themselves into the user interface at different level to customize it. And to do that. The way we do that at Odoo is to monkey patch existing JavaScript object classes, stuff like that. And if you think about that, if you look at the the state of the art in the framework, JavaScript, JavaScript, I'm sorry, they move toward using functional components, it's really something that you cannot not notice. If you look at look for it class components have a bad reputation since React experimented with that and they all moved towards functional components. And functional components are wonderful. I'm not saying that they're bad, but.

Olivier: 26:17

For what you need for Odoo, it's not the best thing.

Géry: 26:20

Exactly. If you use functional components at Odoo, you cannot observe or modify the content because it's all of the content of your component is captured in closure and it's not accessible from the outside. And it's a good property to have, but it's not good when you want to do exactly that.

Olivier: 26:35

You want to inherit and change a few things in to, to adapt. It's exactly it's the very definition of a class.

Géry: 26:42

Exactly. And so why not using class components that fits perfectly our use case. We don't want to use large inheritance tree, that's for sure. But we want to be able to customize components from that site. So that was one of those main reason for building a customized framework.

Olivier: 26:58

Okay. What would you say makes Owl special? What are the key features?

Géry: 27:04

Owl is a new framework that was started from scratch and quite recent, like just turning three years old now. And so we had the luxury of having good lessons from the past and we could use some modern JavaScript feature like promises, and we could integrate into Owl na synchronous system. That means that you can in Owl, defined components in a way that they can themselves loads their own data and they will only be rendered after that data is loaded. So it takes some time, to fetch data from the server and in the meantime Owl will just stop and will resume it when it's done. So that's quite unique in my opinion, the way it's done in Owl. Another special feature for Owl is the class based component system.

Olivier: 27:56

That I just explain. It's not really modularity.

Géry: 27:58

Yeah, it's not really different from a functional component in a way, but it works for us. Also, of course, it's completely designed to fit perfectly in the Odoo assets pipeline. It's a big point when you work with frameworks to have some good tooling with that, and Owl designed to work with Odoo of course.

Olivier: 28:19

Sure, sure. And as you mentioned earlier, with the with the fact that we have this increasing need of having very specialized. So you were talking about the reconciliation with jet in accounting 16. Go check it out. It's amazing. You were mentioning this thing, we will need more and more of this in the future. So it's good that the framework is done to allow that easily or as easily as possible.

Géry: 28:41

Yes, I think now that you mention it, that the fact that it's asynchronous is really important for Odoo because it lets you customize some specific part of the user interface. Even at the data level, you know, you can change some components to be asynchronous seamlessly. With a core component, you will not know that it's asynchronous. But it can be changed in such a way. And if you would have to do that in a normal framework, you would have to probably do a lot more change along the parent chain to load data and then to transmit that data to the correct component. So it's it makes it really nice and seamless to work customizing all the components. Another point I think I should mention is Dynamic template compilation. So that's really good. It's not really unique. You could have that feature in Vue or other frameworks, but it's usually not done the way it's done at Odoo, where we store the user interface in XML templates, for example, the form view. Ad then we load that form view in the web client and we will transform that into an Owl template and we will create a new template function just dynamically on the browser. And that allows you to make from view like the way we do without having to create a separate component for each screen at Odoo, which would be a very complex. Another feature of Owl, it's more like an implementation detail because you will not be exposed to that feature as Owl developer, most likely. It's the engine. It is based on block DOM, which is a virtual DOM that is custom made as well. And it is based on a block tree instead of a HTLM tree. And because of that, it's incredibly fast.

Olivier: 30:21

Could you explain a little more why?

Géry: 30:23

Okay, so I think I should explain what a virtual DOM is first. The way many frameworks work is that they have to represent in memory the state of the rendered application, and usually it's done as a tree of HTML elements. So you have a div, which is represented as an object, and all its children are represented as sub objects and so on, and they have attributes and all of that is a big tree. Basically the process is to create that tree and the framework will transform that tree into actual HTML elements. So to do that, it has to traverse that tree completely and create a new HTML element for each of them, each of those nodes or a text node, and then set attributes and add event listener. And all of that work will need to be done to create HTML element. After that, the framework need to update your user interface, so it needs to generate another tree representing your user application, the user interface. And then it needs to compute a diff to patch the real domain. So you need to traverse both tree and then see what's different. And if something is different, then do the corresponding operation. So it's a long process, it's expensive and that's why people are saying that virtual dom are overhead. It's a pure overhead. If you think about that. But it's very useful for Odoo because it allows you to have asynchronous . You can render in memory and do a lot of work and whenever everything is ready, you can patch to them. So Owl use block Dom, which is a virtual dom, but with a twist. Instead of working at the granularity of element, it tries to split your template into large blocks. And so it works at the highest or coarser granularity possible. So you have huge blocks which represent the tree of your state instead of the tree of your elements. And each block correspond to a template element internally that it can clone in one operation. So it does not have to traverse the complete HTML tree. It has to traverse just the state of your components, which is a very small like one or two order of magnitude smaller, and it has to do much less work in responding.

Olivier: 32:34

I guess it's much faster and.

Géry: 32:36

It is much, much faster, of course. To my knowledge, it's the fastest virtual dom in the world.

Olivier: 32:40

And since we're talking about performance, so about Owl in general, what are the performance? How does it compare to to other other existing frameworks?

Géry: 32:49

First, I want to say that performance is not really the primary focus or thing that you should look at in your framework, because most frameworks are fine and if you have issues with performance, it's most likely not coming from the framework anyway. Probably your code is guilty. I know that's true for me. So don't take too much seriously performance.

Speaker3: 33:12

Still, we want to know.

Géry: 33:14

It's difficult to benchmark because what does that mean? Performance. But there is at least some standards or well known benchmarks. And the most famous to my knowledge, is a framework benchmark project. There is not really a name, and what it does, it defines a suite of tests, of benchmarks, tests that you could implement, and then it has a baseline implementation of JavaScript, in pure JavaScript. And your framework then can be compared to that baseline implementation. So you can check what the overhead of using your framework is compared to a business.

Olivier: 33:48

You have different test cases you have to implement every time each of them, and then we compare.

Géry: 33:52

Then yeah, exactly. So you implement all those test case. So like, 10,000 rows in a table, replacing those rows by other rows, updating part of them, software, stuff like that. And then you just do the average, the geometric average of those numbers and you can have some number.

Olivier: 34:10

And so did you do it for Owl.

Géry: 34:11

I just ran some benchmark yesterday on Owl and then compared Owl to some of the most mainstream frameworks. So the numbers are like this. The React framework has, as you can say, a 60% overhead. It has a 1.6 score, 60% overhead of the overall baseline implementation. So it means that, you lose in a way 60% of your performance using React. Angular is 50%, Vue is 20%, which is incredibly good, but they have a specific directive to help with that in some use case. And Owl has a 15% overhead, which is a really really good number. So if you compare to most framework, I would say that Owl has a really good feature set. It's a kind of a high level feature set for its size and it's a very performant.

Olivier: 35:07

Yeah. So the ratio is good. Good news.

Géry: 35:10

Yes. I'm very proud of that.

Olivier: 35:12

And is there other things you would like to mention about performance of Owl?

Géry: 35:16

Yeah. I think you should see that the benchmark is just pure performance, but in reality, in practice, an application is not bound by its pure performance. You have other questions that may help a lot. And Owl has a reactivity model exactly like Vue. It's the same, basically. And it means that it can stop components that are not impacted by some change. So in a way, if you think about that, it completely skips and doing no work is very fast. So your model is a big driver of of performance in practice, even if it has a small overhead because you have to observe which components depends on which part of the state. But that overhead is earned back by just not not doing.

Olivier: 36:06

You don't have to check everything when .

Géry: 36:08

Exactly.

Olivier: 36:09

Okay. How many people were involved on writing really the Owl framework?

Géry: 36:14

At first, I was working on it for nine months alone. It's kind of a baby.

Speaker3: 36:22

Yeah. See.

Géry: 36:26

Then part of my team helped me. So I would say Owl one represent about 15 months of work for one person overall and about six months for Owl version two as well. But it's hard to say because I was one of the main developers initially, but now some part of my teams got involved as well and specialized.

Olivier: 36:49

So sharing the work.

Géry: 36:50

We have three, four developers working, able to work on Owl at least.

Olivier: 36:57

Good. And, I'm forced to ask this. That's typically the question Anthony would ask How many lines of code?

Géry: 37:03

It's a very important matrix, apparently. But yeah, Owl was first designed to be minimalistic. Initially, I just wanted a small component system. Now I had to add feature and feature and feature at some point. But still the resulting framework is about 5000 lines of code. So if you think about that, it's quite small for its feature set. It contains the template compiler and everything slots all feature from Owl fits into that 5000 lines of code.

Olivier: 37:31

So it's actually pretty small. I mean for a framework, it doesn't strike me as huge.

Géry: 37:36

I would say it's medium sized in the world of JavaScript framework.

Speaker3: 37:40

Okay, That's all right then. Let's just maybe give a small word about the conversion of the codebase, because here we were, of course, giving numbers about the Owl framework. And then there's the Odoo code making use of it. So you mentioned that everything in the web client was converted for version 16. I guess this was a big, big effort compared to just writing the framework. Was it bigger?

Géry: 38:05

Oh, much bigger. Yeah. The framework is a big project, that's for sure. But converting the thousands and thousands of lines of code in the code base is a huge team effort. And for version 16 we had, all my team, about 620 people were working on that full time and we had to ask many other teams to help with that as well. So for example, the accounting recognition widget had to be converted by the accounting team. At some point. They needed business knowledge of what they were doing and we could not really do it efficiently. We had the technical knowledge of Owl and they had the business knowledge of course, and it's the same for many other specific actions, views and all that kind of business specific code had to be converted by the code owner in a way.

Olivier: 38:50

And so it was a big team effort and we had to dialogue with a lot.

Géry: 38:53

At Odoo, it was a big transversal work. So it's a very important workload.

Olivier: 39:00

So it was super interesting because that's really the... I mean, it's really interesting to see that because it was a huge change. It involved a lot of people and at the end of the day, it went fine. So it's a good example to look at I guess.

Géry: 39:11

It's a difficult process of changing. It's a revolution. You can think in term of evolution or revolution, or you can evolve your framework making some change a long time. You have to do it, of course, but at some point you need your revolution. And that's what that was.

Olivier: 39:26

Okay. That brings us to actually my last question for this episode. What is next? Is there another revolution coming soon?

Géry: 39:33

Evolution or Revolution?

Olivier: 39:34

Revolution. Will you break everything?

Géry: 39:38

I think you should not expect Odoo to ever be stable or completely stable, that's for sure.

Olivier: 39:45

Sentence you shouldn't put out of context.

Géry: 39:49

Definitely. Yea, it will probably never be completely stable. We have many ideas for change at every level of the framework, so we were talking a lot about Owl. I think Owl is mostly stable. Maybe someday there will be an Owl tree. But it's not planned yet. We have sometimes ideas that would require a change. We put them in a list of tagged with Owl three, and maybe it will be done someday. But there is no plan. Definitely no plan.

Olivier: 40:17

There aren't that many cases that, you know, won't work with the framework. And so there is no imperative need for this.

Géry: 40:25

Maybe someday we will find a high value feature that we want to do. Maybe server side . I don't know. Probably not. So nothing much will change in Owl itself, but the Owl ecosystem can evolve. For example, we are working on dev tools extension for Owl, kind of react dev tools, so you can open your browser the developer tools and you have a tab where you can explore the componentry and interact with it. So that's coming very soon.

Olivier: 40:57

That's amazing because, that's definitely... I mean when it comes to developing something, touching the UI on a website, having these debug tools is just someting you have to have. And having something that helps integrating the way you work with the JavaScript side is very, very welcome.

Géry: 41:11

So yes, tooling is very important and you need to see something to understand what's wrong or what's good with that. So for example, those dev tools will let you see what component is rendered in real time so you can see if it makes sense or if you have an error in your code that goes out.

Olivier: 41:27

And also for someone new entering the the Odoo technical ecosystem and discovering it, it's always good to have something. You know, when you're discovering it, you need to break it a little bit and be like 'Well, what's there? What's there?' and having these kind of tools is also very important because those visualizing what the code is, what the structure of the code is behind.

Géry: 41:48

From a learning perspective, that's definitely true. So, yes, I think the main changes in the future would be more focused on the tooling and developer experience, making it nice to use in Odoo, all that kind of ideas. We just want people at Odoo to feel productive, happy and to be able to work with it. to to.

Olivier: 42:11

Okay. I guess it's a very good mindset to have when you're in charge of a framework, of course. So thank you very much for your answers. It was super interesting.

Géry: 42:22

Thank you, Oliver, for having me at your podcast.

Olivier: 42:24

And that's a wrap for today. Thank you for joining us. I hope you enjoyed discovering the behind the scenes and the JavaScript magic of Odoo. Let us know if you'd enjoy further similar episodes. If you'd like to stay with us longer. Go check out the rest of the series. See you next week.