Accounting: Keeping Things Simple When Developing an App

quentin De Paoli: 0:00

The accounting app is everything an accountant would expect from an accounting software. And let me tell you, Olivier, that it's a shitload of features. We want to do that so that it's available for anyone out of the box. It's something we try to do everywhere in Odoo. We want to keep things simple, but even more with the accounting.

Olivier Colson: 0:19

When you take a random software engineer out of university or anywhere actually you ask him, Hey, what do you want to work on? It's unlikely that he's going to say accounting software.

quentin De Paoli: 0:29

Yeah, I think it's a mistake from them. They don't know what they're missing. Clearly, what I like about accounting is it's very centric to the world. It's very centric to any business. I think it's really with feedback from the three that we were able to have for version 13, a mature accounting app. Once every 3 or 4 years, if a line of code didn't change, it means that maybe nobody's using it because it needs to change all the time. And you have to go over what you've written in the past to improve that code.

Olivier Colson: 1:04

Welcome back For another Tech and Dev episode. Today we are joined by Quentin de Paoli, team Leader at Odoo's R&D Department. From Implementation Challenges to Team Management, we'll go over the behind the scenes of one of Odu's most used applications accounting. Are you ready? Let's go. Hello, Quentin.

quentin De Paoli: 1:22

Hello, Olivier. Thanks for having me.

Olivier Colson: 1:23

My pleasure. Really? Because I'm super excited about this episode because you're actually my team leader. And we're going to talk about my scope today. So it's super interesting. It's accounting. So first, before getting started, could you tell us more about you? How did you enter Odoo and how did you end up being in charge of the accounting team in R&D?

quentin De Paoli: 1:42

Okay, so I started working for Odoo 15 years ago, actually, and it wasn't called Odoo yet. And as you can imagine, at that time, the responsibilities were not that clear. And we were at I remember at some point we were only two people managing all the army of Indian developers we had. So yeah, I think it only started with version nine where we had enough manpower to split into teams, and that's where I inherited from the accounting.

Olivier Colson: 2:18

And how come? Because before you had touched it a little. But you don't have any accounting background yourself, right?

quentin De Paoli: 2:23

Yeah, no, I didn't have any accounting background. And it's only I learned doing things like like I was told to do and speaking with the accountants at that at that time.

Olivier Colson: 2:33

It's another of these stories where something needed to be done and someone was like, you, you're going to do it.

quentin De Paoli: 2:39

Exactly. And it was me.

Olivier Colson: 2:43

It's funny how you keep the responsibility after being designated like that because you're not the first one to interview like this.

quentin De Paoli: 2:49

Yes, I think it's because I like accounting. Actually. I like it because it's a functional part of the world, actually. And it teaches you a lot about a company when you know how to read a balance sheet and how to read a profit and loss report. So yeah, I thought it was a good idea to also improve my own knowledge of how the world works.

Olivier Colson: 3:10

Actually, it's a bit for the challenge of it I guess as well. Yes, it can be a pretty complex field, right? As we will see. Yes.

quentin De Paoli: 3:17

You know, accountants tend to say that what they are doing is complicated Once you break it down into logical stuff, logical part, it all comes very simple.

Olivier Colson: 3:28

The whole challenge being of breaking it down into logical parts. And so could you tell us more about what it is exactly? Because in the audience, I guess some people know what accounting is. I guess everyone has a pretty vague idea of what it consists of, but could you explain in practice what is it and what do we handle in Odoo for that?

quentin De Paoli: 3:50

You mean for the scope of our responsibility within Odoo. Okay, we have several responsibilities. I would say. The first being that we manage the invoicing app, which is everything people needs to issue customer invoice to encode their vendor bills and then register the payment. And yeah, that's more or less the basic stuff. Also issued a tax report. Then we have on top of that the accounting app, which is everything an accountant would expect from accounting software. And let me tell you, Olivier, that it's a shitload of features we have, like for example, the general accounting, but also the analytic accounting, the customer follow-up. So following the customer debits, we have the electronic invoicing, the bank synchronization, asset management, etcetera, etcetera. There are a lot of things and also we want to do that in a generic point of view so that it's available for anyone out of the box. But we have also to be adaptive for everyone in each country. So we have to allow people to adapt. How?

Olivier Colson: 5:00

So typically, what would that mean? So I live in Belgium. So are the things that are specific to my country within the way Odoo works and how what exactly? Yeah.

quentin De Paoli: 5:11

You have the chart of account which is different from someone living in France or what is it?

Olivier Colson: 5:17

So for people not knowing because you're using technical terms, what is a chart of accounts?

quentin De Paoli: 5:22

It's a set of account that you can use when you record an operation, okay?

Olivier Colson: 5:26

And it depends on the load. So depending on exactly how to change it.

quentin De Paoli: 5:29

Also the legal format of the reports you have to issue for the government are different. You may have some kind of electronic way of communicating your invoices to your customers or to the government, which is sometimes mandatory in your country. And all these kind of different rules are managed also by our team, which is in what we call the localization packages. And that's the third responsibility, I would say, of the team.

Olivier Colson: 6:00

And again, here, one of the big challenges then must be to have something that is generic enough so that it can be customized without being a total mess between the different localizations. Right, Exactly. Okay. From a technical point of view. Now, what would you say are the big challenges going more into the details? What would you say the big challenges are?

quentin De Paoli: 6:20

I think the first one that comes to my mind is that we have to deal with the legal requirements of each country, as I said, And that means that we have to search for the specifications and sometimes we find specifications that are not in English. So we have to Google translate it or we have to.

Olivier Colson: 6:39

Learn the language.

quentin De Paoli: 6:40

Yeah, or maybe we find the specifications. Well, I remember once we find we found for Singapore a specification in English with a provided file sample file of what the feature should do, but the sample file wasn't following the specifications. So sometimes we have to face things like that. Then we have to also cope with, I think, the community and people trying to push their needs before well because they see that it's a need for them. But we have to understand globally, if it's a real need for the country or not and it's important for doing it or not.

Olivier Colson: 7:19

So not falling into corner cases where someone is like, whoa, this is something I absolutely need, but only because he sees his case, his business, and it's actually not something that everybody needs.

quentin De Paoli: 7:30

Exactly. So we have to do it maybe more than other teams because we are more in communication with the community, I think. But it's something we try to do everywhere in Odoo. We want to keep things simple, but even more with the accounting, I think.

Olivier Colson: 7:45

Well, I guess it's also because people tend to consider their needs as more necessary because it's about money. And since it's about money, people are more I mean, afraid it wouldn't be done right. And it's legit, I guess. Yeah. Yeah.

quentin De Paoli: 7:59

Well, everyone sees his own needs first. And so something that is very important for someone may not be that important globally when you take the country in its globality.

Olivier Colson: 8:11

Other things that you typically have to handle.

quentin De Paoli: 8:13

Well, the other things are like any other R&D team. I think it's the being able to cope with large volume of data like we could have for the journal entries. And yeah, keep things simple in the interface and in the specification.

Olivier Colson: 8:30

So do you think the volume of data is as much of a problem for. Well, a problem, a challenge for accounting than for other team? Or is it more the case because in my opinion, journal items you tend to have a lot of them on a regular accounting. So just so people get what we are talking about journal items, it's one line on an accounting operation. So typically you're impacting one account with a given amount. This is a journal item. And so of course you have lots and lots and lots of them in the database, like typically millions.

quentin De Paoli: 9:00

Usually, yes and no. If you take a logistic company like Amazon, it will have a lot of stock operations. So it's also important for them to cope with large volume of data. The difference maybe is that everybody needs to have an accounting and so and everybody does not have the logistic of Amazon. So I think that's the only difference here.

Olivier Colson: 9:24

Okay. I suggest we now have a look at the way Odoo handles this, these problems actually, and what the model behind what we are doing is. I suggest we give a historical view of it since you're another Odoonosaur. So let's, let's just go into the history and see how things evolved, actually, because I guess, I guess getting the details of the implementation of everything is a bit useless here because people are just listening to us and you can show code and it won't work though, explaining what are the big. Of our models and how they interact and how we change them over time might be might be interesting, I guess. So let's start. What's the oldest thing you want to talk about?

quentin De Paoli: 10:10

Okay. I think the third thing I want to mention is that it really started with Odoo Experience for the release of version eight, where we presented what would be roadmap of the accounting for version nine. And it was a huge document, a Google doc that was made public, 62 pages.

Olivier Colson: 10:27

It's funny because we don't do that anymore.

quentin De Paoli: 10:29

No, no, we don't do that. And yeah, we implemented that in one year and we basically rewrote every feature of the accounting. That's when people started to adopt the accounting app. Before that, it was just a byproduct when you were willing a sales applications or timesheet management or something.

Olivier Colson: 10:52

You got as a bonus on top of other something else that you needed and you wanted. Exactly.

quentin De Paoli: 10:56

Okay. But since version nine, we really became a real accounting software, I would say. And we still find back some traces in the code that infamous which one you're going to commit a message on. You know when we release the version, what would be version nine of the accounting, the commit message, you know, you're supposed to be.

Olivier Colson: 11:19

Explain what you're doing.

quentin De Paoli: 11:20

Exactly. You have to you're supposed to be descriptive about the changes you're pushing.

Olivier Colson: 11:25

And you rather were disruptive.

quentin De Paoli: 11:27

Yeah. And I went for something else that was accounting. V9 Yeah. Which lasted it was.

Olivier Colson: 11:36

The only thing in the commit message. Yeah. And it's funny because this commit message is still famous today in R&D version nine. So it's been a while. And even in our team, we we pay the tribute to it a few times in our own commits. So for example, for V 16in the reports, one of the first thing that I put on it is reporting V16 Yeah. And then I give an explanation because come on. But yeah.

quentin De Paoli: 12:00

Yeah. The thing other teams were not that happy with that commit message but yeah, well I think it was okay because there was that Google doc of 62 pages explaining the whole differences.

Olivier Colson: 12:13

The fact is that people don't have that Google doc you know.

quentin De Paoli: 12:15

Yeah they should have kept it somewhere anyway. So that was version nine. It was the first big milestone for the accounting app.

Olivier Colson: 12:25

Could you give a few examples of what was introduced in version nine?

quentin De Paoli: 12:29

It was the first time we had a reconciliation widget for.

Olivier Colson: 12:36

So, what is that thing?

quentin De Paoli: 12:36

It was a UI to be able to reconcile the payments and the invoices from a bank statement.

Olivier Colson: 12:48

So to match them together. That's something you need to do in day to day accounting for people not knowing about it. Okay.

quentin De Paoli: 12:54

Yeah. Also the reports before the version nine were only PDF. So you had you wanted to to issue a profit and loss. For example, you had to click on a menu. It was opening a wizard where you select the different options you wanted and then you click okay and you get you got the PDF.

Olivier Colson: 13:15

Also, you had to choose the period and so you had a period object. So in the start, end of the fiscal year and these kind of things, yeah, yeah, yeah.

quentin De Paoli: 13:21

The period also disappeared with version nine. So yeah, a lot of big changes actually.

Olivier Colson: 13:28

And so what was put instead of this PDF thing?

quentin De Paoli: 13:31

The report were directly available in Odoo. You got that in your browser as HTML actually. Okay. Okay. Like a normal page. And so it was much more dynamic. And so.

Olivier Colson: 13:44

And after version nine, what happened?

quentin De Paoli: 13:47

After version nine, we kept the team that was dedicated to rewrote the accounting. We kept it and it was our main focus and the team started growing. We engaged more people, we started working more on localization.

Olivier Colson: 14:05

And that's the time where I came into Odoo.

quentin De Paoli: 14:07

Yeah, Yeah. A lot of good people came to you and others.

Olivier Colson: 14:14

Yeah.

quentin De Paoli: 14:14

No, just kidding. And yeah, the next milestone would be probably version 13 with what I would say, the accountingpocalypse.

Olivier Colson: 14:25

Code name, no, account name, accountingpocalypse.

quentin De Paoli: 14:28

Where we decided To destroy everything. To change, basically, I would say to change basically to main objects we had and to merge those two models into only one, namely the invoices and journal entries.

Olivier Colson: 14:44

Okay. So the journal entries are those things gathering the journal items we were talking about earlier. Yeah. And so we merged them with the invoice. What was the big idea behind this?

quentin De Paoli: 14:55

The idea is that you sometimes change an invoice you would like. The change to be automatically reflected to the journal entry.

Olivier Colson: 15:04

Yeah, because again, explaining the basics of accounting to people. Yeah, your invoice basically. So in the old model needed to generate a journal item because, well, your invoice is an accounting operation and so it needs to correspond to an accounting operation. So a journal, a journal entry. And one of the issues we had before the 13 was that it was possible to desynchronize the journal entry. So the account move, that's the technical name and the invoice and that's something we wanted to remove because it causes troubles, right?

quentin De Paoli: 15:37

Yeah, exactly. Although sometimes you just import the accounting from another software. So you just have the journal entries. And that time it was embarrassing to not having the invoices. Yeah. So to make it short, we wanted better synchronization between those two objects. So the idea came to merge those into one.

Olivier Colson: 16:00

And how easy was that?

quentin De Paoli: 16:00

We made it. We lost some sanity points doing so, but especially I think, yeah, yeah, it was a back-and-forth process. But yeah, we at the third try we had something that we kept and yeah.

Olivier Colson: 16:16

I remember there was a lot of discussion about that and yes. And so. Lauren So Lauren was the one in charge of really doing it and he tried like I think there were like three prototypes and the third was, was the, was the right one. I don't remember exactly what he tried on the previous ones, but it wasn't possible. And there was something funny about the performance as well, right? Yeah.

quentin De Paoli: 16:36

The performance is were not as good once we've done the prototype and once we were happy with technically how it was behaving, the performance were bad in comparison to what we had before. But the fact that they are the, the framework had improved itself and was faster.

Olivier Colson: 16:58

Yeah, there had been another refactoring in 13 from DRM, from DRM and lucky us.

quentin De Paoli: 17:04

It comes thanks to them, it compensate our our loneliness. And so yeah, that's basically how it worked.

Olivier Colson: 17:13

Okay so I guess there were other changes as well in V 13. Is there a way to summarize them or is it just too broad?

quentin De Paoli: 17:20

Yeah, the version 13 was also the version where we addressed the fiduciary market.

Olivier Colson: 17:28

And did we manage to do it?

quentin De Paoli: 17:29

Yeah. Yeah. And actually I think it's really with that feedback from the fiduciary is that we were able to have for version 13 a mature accounting app.

Olivier Colson: 17:40

And I remember that it was like the magical argument back at the time because there were a lot of little features everywhere that we wanted to add, and the product owners kept on coming with them. And every time the argument was, but it's for the fiduciaries, it was like, Oh, again. But at the end of the day, it's true that it made the software way better than before.

quentin De Paoli: 18:02

Yeah, it was a running gag, but it worked actually.

Olivier Colson: 18:05

So yeah, so they were right. Yeah.

quentin De Paoli: 18:08

Exactly. Yeah. To, to go on with the with the history. I would say that after version 13, the team only kept growing so that we are now 30 people. Yeah. That's a lot. Um.

Olivier Colson: 18:22

I don't think you gave the number, but between version nine and version ten, it was like four people. Four people? Yeah. So something.

quentin De Paoli: 18:30

Yeah. So the team grew a lot. And so every year was kind of a major, a major release for the accounting. But if I have to keep only one, I would say that the version 16 was the biggest milestone after version 13 because of the way we rewrote all the reports, the reportalypse commit reportallipse, Yeah. Because of the new reconciliation with jet as well.

Olivier Colson: 19:01

What was new about this new reconciliation with jet exactly?

quentin De Paoli: 19:05

Yeah what's new was that we had a total refactoring of the UI and that was the first time we also did so much things in JavaScript in one single place.

Olivier Colson: 19:17

So it's more complex than before. It's but it's working better, right? Yeah, exactly.

quentin De Paoli: 19:22

Good. Summarize.

Olivier Colson: 19:24

Okay. About this, this report ellipse thing, could you give a bit more details as well? Yeah.

quentin De Paoli: 19:29

So, but maybe you're more appropriate since you worked on that.

Olivier Colson: 19:34

That's my baby, So. I can talk about it for a complete hour if you want, but I don't think it will fit this podcast anyway. Yeah.

quentin De Paoli: 19:43

So for the reportallipse, we changed the way the reports were defined, the way they worked. So basically it's only internal stuff that people don't see unless they are trying to define a new report themselves, but it also comes with a nice bonus for them. Since we are now able to have different columns for what we call the generic reports. So reports that are just defined as data can have more than one column, which was not the case before.

Olivier Colson: 20:14

ngines as well, mix the way you compute the different parts of your report. So there is a talk I made at the experience about it. For people curious about the details or a more, more detailed, at least view of the whole set of features. But indeed to summarize it, I think it's, it's interesting to, to see how we how we decided to, to just destroy it like that because it was pretty, pretty heavy thing to do. And the fact is we already had this report engine in in since nine that was customizable and defined as data in the module. So there were things that we changed on it, but nothing big and nothing huge in the way you could use it and the capabilities of the model itself. And the thing is that we realized that there were things that we couldn't do easily and that was a problem and we wanted to add something to ease the definition typically of balance sheets, because you need to refer to prefixes of account, whatever. And that was one of the big triggers for this task because then, you know, we talked about it, I remember, and then one thing caused another. And at the end of the discussion we were like, okay, let's change everything. But actually it works now. So I think it's fairly interesting to see that again, there is one need coming and then raising other concerns. And at the end we decided to refactor everything, at least here in the reports, to fit the new needs and have something more, hopefully more robust in the future. But who knows, maybe in two years I'm back talking about the new refactoring of the reports. I hope not, but.

quentin De Paoli: 21:41

I think it's something really sane to do once every 3 or 4 years. If a line of code didn't change, it means that maybe nobody's using it because it needs change all the time. And you have to go over what you've written in the past to improve that code. Or maybe if you wrote twice the same line of code, maybe it means that you have to make something generic, make something more generic about it.

Olivier Colson: 22:07

I guess it's a it's a very sane philosophy to have as a, as a developer because it's it needs you to criticize what you did even just one year before and be like, okay, this on this thing, I totally screwed up. Let's do something else. And, and at the end, even personally and from a pure skill point of view, I think you become better. And of course the product becomes better as well. When would you say is the right time? So to to to do such an apocalypse like that? Because there were a few of them in accounting here. So I guess you're the right person to to discuss this. Yeah.

quentin De Paoli: 22:41

I think the right time is when the planets align themselves. So you need several things to make such a big refactoring. So first you need to have the need clear and it means that you you must have several people telling you maybe the same week, maybe in one month that this is too crappy. It should be changed in some ways. So you need to have time to do it. It can't be done when we are approaching the release or the Odoo Experience, for example, of course, because it would be too risky. And also you need someone that is willing to do it because sometimes you just face the problem and you're like, okay, yeah, let's hide it under the carpet until someone else find it because it's too big of a task and I don't want to bury myself in it. So.

Olivier Colson: 23:30

Or you like, okay, this is something we can do in the future, but for now, it's not.

quentin De Paoli: 23:35

Not the right time. Nobody has the time to do it. So, yeah, indeed, it's a mix of several things. And I think when those three are met, then we can start thinking about how we improve that specific feature.

Olivier Colson: 23:48

So there is a lot of discussion involved anyway. And, and it's, it's funny because people don't always realize that, but there is a big human side to the way those features will evolve and what things you're going to tackle because you need to have the right person and to have the right discussion to lead to this feature. It's a collective work.

quentin De Paoli: 24:07

Yeah, it's a collective because you may have the need to change for your own business case that you think about, but someone else in the team or the product owner or whatever might have Another thing that we would take at the same time with the same refactoring. So it's important to discuss.

Olivier Colson: 24:24

Yeah, indeed. So about the team now since you were talking about them. So you, you said that we were around 30 now and so the team, the team size like evolved a lot over the years and actually it even like doubled something like one year and a half ago I think. Yeah, one year and a half. What happened because when you say that to people and for us as well, I mean, I remember when were Anthony you I don't remember who told us, announced us hey by the way, you're going to get like 15, 15 new people in the team of 15. So, how did it go?

quentin De Paoli: 24:59

Um, yeah, I think it just. We tried our best, and it worked like that. And I think it's only because the whole team, the whole existing team stepped up and took responsibilities that we managed to keep every newbie.

Olivier Colson: 25:17

Could you explain how the team is organized now?

quentin De Paoli: 25:19

First of all, the newbies are coached by Ruben, which follow every development and is available for them for their six first month, I would say. And I'm reviewing and merging their branches and their features. So there are two people following them more or less frequently during those six first months. After that, they don't need to be coached anymore probably. So they just pick tasks in the pipe, develop them, and once those are ready, there's a set of more experienced developers that are able to help them.

Olivier Colson: 26:00

Grand Vizirs, I like this name? Okay.

quentin De Paoli: 26:03

Yeah, that's the name you chose yourself.

Olivier Colson: 26:05

I like it.

quentin De Paoli: 26:07

And on top of that, we also have a bunch of developers that we force or I don't know who to say that.

Olivier Colson: 26:14

Can you really say that in this podcast? Yeah. Yeah.

quentin De Paoli: 26:17

I'm their team leader. I can say that we force them to or we encourage them to, to make reviews, pre-reviews for the actual people that will review.

Olivier Colson: 26:30

So, so that's another way to learn and prepare to scale up eventually so.

quentin De Paoli: 26:34

That they can spot things before the final reviewer. It will help the final reviewer, which will probably have less to say to the developer, but also when they will see the final review, they will see what they missed. And I think it's a nice way for them to improve as well.

Olivier Colson: 26:51

Indeed. And it's it's interesting because it also allows to for the final reviewers to gain time on easy things and on small tasks. And so it gives them more time on other more complex things where it's well, paramount that they are the ones to have a look at it as well. So I think it's very, very useful actually as a system. And could you give more details on how we decided to run the team like that? Because it was not like that. Like I think even like two months ago, it wasn't like that. When did we introduce that? It's pretty recent, right? Yeah, it's pretty recent.

quentin De Paoli: 27:23

I can't explain exactly. At some point, you see there is a problem. You try to find a solution, you try a fix. And if it works. And so here.

Olivier Colson: 27:31

What? What was the problem exactly?

quentin De Paoli: 27:33

There were several problems. First of all, I felt myself that I wasn't really following enough the newbies, because I had plenty of other things to do. And so by pairing with Ruben, I think it's I tackled that the responsibilities of everyone in the team wasn't really clear. And so it was difficult to put priorities where it was needed and so on.

Olivier Colson: 27:56

And this was like a consequence of the fact that, well, we had this batch of newbies, which got more experience now and so produce more things. And so there is more work for the reviewers, but there isn't, there aren't more reviewers. And so it was more complex to handle. Exactly. And so if I get you well, the secret to handle this kind of big changes would be to stay flexible and really tackle the problems when you see they arrive.

quentin De Paoli: 28:19

Exactly. It's when you see there is a problem somewhere. You don't have to be stubborn and say, okay, we keep going. Whatever. We will make the people change their way of doing so that they will fit our process. But you have to change the process a little bit so that it the team will be more productive and you will have a better handling of everyone in the team.

Olivier Colson: 28:42

Yeah, and I think everyone will also feel more comfortable if you don't try to right away, put them in a little box and say you're going to be like this and rather try to fit the box to to the people you have and have something that looks like a box at the end of the day. So indeed, okay, so we are reaching the end of the episode. So I would like to end on a final question. Why is it so cool to work on accounting? Because you start the episode saying you liked it. So we know we want to know why now because it's not, you know, the hype subject that most people will tell you about when when you take a random software engineer out of university or anywhere, actually, you ask him, Hey, what do you want to work on? It's unlikely that he's going to say accounting software.

quentin De Paoli: 29:29

Yeah, I think it's a mistake from them. The first I don't know what they don't know what they're missing, clearly. Well, first of all, I must say that the team is really cool. Really? Really. And I'm not saying that because I'm the team leader. But what I like about accounting is, as I said, it's very centric to the world. It's very centric to any business. If you don't know the accounting, it will teach you things, that's for sure. And so it's also very cool for our own personal development. Because you learn things.

Olivier Colson: 30:00

Okay, so the final word would be try some accounting. Yeah.

quentin De Paoli: 30:05

Trying us is to adopt us.

Olivier Colson: 30:08

Well, thank you, Quentin, for your answers.

quentin De Paoli: 30:10

No problem. Olivier was a pleasure.

Olivier Colson: 30:12

Oh, my pleasure. Really. I hope you find it interesting because it was super nice. I know. I guess duty calls, and it's time for us to go back on the module and start the next apocalypse. Who knows? Who knows what we might be? We might be doing for the next version of Odoo, right? Yeah.

quentin De Paoli: 30:29

Let's go.

Olivier Colson: 30:30

And that's a wrap for this episode. Thank you for joining us. I hope you enjoyed discovering how accounting issues are tackled by developers. If you'd like to stay for further insightful tech and dev discussions, I suggest you listen to our previous episode about the fastest JavaScript framework in the world. Owl. Until then, see you next time. Cheers.