Building a business solution with Guillotina
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 53 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54842 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Plane (geometry)Computer virusServer (computing)Cartesian coordinate systemMultiplication signComputing platformSoftware developerRight angleProcess (computing)Front and back endsMeeting/InterviewXML
01:17
Content (media)Form (programming)RoboticsVolumenvisualisierungCanadian Mathematical SocietyTelecommunicationComputer animation
01:55
Point (geometry)Multiplication signScaling (geometry)Point cloudDifferent (Kate Ryan album)Moment (mathematics)FacebookCloud computingCASE <Informatik>Data storage deviceRight angleProgrammable read-only memoryXMLComputer animation
03:20
Mathematical analysisMachine learningProcess (computing)Formal languageComputer-generated imagerySubject indexingInformationData storage deviceMedical imagingMachine learningSource codeProcess (computing)Formal languageComputing platformFront and back endsElectronic data processingRight anglePattern recognitionMorley's categoricity theoremInstance (computer science)Enterprise architectureVirtual machineProgram flowchart
05:05
Dependent and independent variablesEndliche ModelltheorieMenu (computing)Front and back endsCartesian coordinate systemLogicMoment (mathematics)Library (computing)ScalabilityIndependence (probability theory)Entire functionForm (programming)RoboticsMobile appCASE <Informatik>Flow separationTemplate (C++)InformationTransformation (genetics)GUI widgetComplex (psychology)Heegaard splittingProcess (computing)Arithmetic meanDebuggerRight angleStandard deviationPlanningPoint (geometry)Disk read-and-write headVolumenvisualisierung2 (number)Instance (computer science)TouchscreenChainComputer animation
08:29
Keyboard shortcutFamilyGraphical user interfaceData typeDefault (computer science)SurgerySet (mathematics)SimulationForm (programming)GUI widgetImplementationPresentation of a groupCondition numberField (computer science)InformationLibrary (computing)Computer animation
09:43
Front and back endsCartesian coordinate systemComplex (psychology)Traverse (surveying)Interface (computing)Client (computing)Object (grammar)Library (computing)System administratorRepresentational state transferForm (programming)Mechanism designIntegrated development environmentDemo (music)Computer animation
11:23
Graphical user interfaceDemo (music)NP-hardInfinite conjugacy class propertyDemonCone penetration testSicComa BerenicesDesign by contractDesign of experimentsSynchronizationSpacetimeProbability density functionWordExistential quantificationDifferent (Kate Ryan album)Category of being1 (number)Point (geometry)Domain nameCartesian coordinate systemEmailData managementElectronic mailing listInformationMathematical analysisInstance (computer science)Message passingDesign by contractPosition operatorSource codeReading (process)TrailFilter <Stochastik>Inheritance (object-oriented programming)Type theorySubject indexingComputing platformPresentation of a groupSource codeComputer animation
14:56
Multiplication signProduct (business)Projective planeSoftware developerLine (geometry)Interface (computing)CodeExtension (kinesiology)Social classScripting languageDependent and independent variablesComplex (psychology)PressureInheritance (object-oriented programming)Right angleFunctional (mathematics)Front and back endsInformationPoint (geometry)Type theoryService (economics)CollaborationismCursor (computers)Information overloadDomain nameOpen sourceAttribute grammarComplete metric spaceData structureComputer programmingGreen computingPattern languageFunctional programmingConfiguration spaceDebuggerWeb 2.0Rule of inferenceFormal languageComputer fileMoment (mathematics)GodContext awarenessRun time (program lifecycle phase)Compilation albumCartesian coordinate systemInstance (computer science)Video gameIntegrated development environmentGoodness of fitComputer animation
20:59
Multiplication signGame controllerInstance (computer science)State of matterMathematicsGoodness of fitDataflowComputer programmingDifferent (Kate Ryan album)Connectivity (graph theory)Dependent and independent variablesKeyboard shortcutContext awarenessFront and back endsGraph coloringGreen's functionView (database)Artistic renderingProcess (computing)Software developerRight angleEvent horizonDatabaseNoise (electronics)DebuggerComputer animation
23:27
Projective planeKeyboard shortcutMiniDiscFiber bundleFlow separationModule (mathematics)MereologyMoment (mathematics)Software developerLink (knot theory)Data managementInheritance (object-oriented programming)Sinc functionOvalResultantRegular graphRepository (publishing)Multiplication signFront and back endsOcean currentPlastikkarteWeb 2.0Right anglePoint (geometry)Source codeDebuggerLine (geometry)XMLComputer animation
26:15
Coma BerenicesPlane (geometry)Conditional-access moduleDataflowBranch (computer science)Software developerSystem on a chipRight angleRepository (publishing)Module (mathematics)NeuroinformatikMultiplication signData managementResultantBuildingComputer fileSingle-precision floating-point formatRevision controlChainInheritance (object-oriented programming)Different (Kate Ryan album)Compilation albumComputer animation
27:05
AreaMereologyInheritance (object-oriented programming)Total S.A.Right angleIntegrated development environmentCodeCASE <Informatik>Software maintenanceProjective planeCommon Language InfrastructureLibrary (computing)NP-hardForm (programming)Configuration spaceSubsetPower (physics)Mobile appExecution unitMultiplication signConnectivity (graph theory)Software developerOrder (biology)Goodness of fitReal numberSoftware frameworkInformationInstance (computer science)Cartesian coordinate systemBoilerplate (text)Buffer overflowJava appletPoint (geometry)Web-DesignerComputer fileLogicTemplate (C++)State transition systemFood energyScaling (geometry)Revision controlData structureTerm (mathematics)Product (business)Pay televisionWave packetComputer programmingEvent horizonSingle-precision floating-point formatLevel (video gaming)Web browserScripting languageInjektivitätOverlay-NetzUnit testingType theorySoftware testingComputer animation
36:05
Plane (geometry)Lecture/Conference
Transcript: English(auto-generated)
00:01
Thank you. So, hello. Well, you might know, but I've been doing Plone for a long time, like 10 years, and last year I started working for HANA, and now I'm a front-end developer, and so my job is to build a front-end application
00:24
on top of an endless platform, which is Guiotina, right? So this talk is about Guiotina, but actually about using Guiotina, right? It's not about Guiotina development, and Raymond just explained a few things about it. So it's really about what you do when you have Guiotina as a platform.
00:44
So, first question is, what is Guiotina? So you had a lot of details and explanation from Raymond, but let's put it very, very simply. Guiotina, Guiotina is a resource application server. Okay, so what does that mean?
01:02
It means it serves resources, okay? Just resources. So maybe the question is, what is a resource? So a resource, a resource is just like a content, and if you know CMS, you know what is a content.
01:21
It's a content, but it's not for human. It's for non-human users, okay? So it just behave like a content. It can be shared, it can be published, it can be moved, it can be deleted, it can be whatever you want, but it doesn't render. You cannot render it in any way, okay? That's what a resource is.
01:40
So for a robot like R2D2, that's fine. So R2D2 is not fluent in six million forms of communication as C2PO, but it does get chosen properly, right? So it can use Guiotina. So, well, the question is, why not Plon? Because if resources are not good for humans,
02:03
at the end, we want something for a human, so what's the point in using this instead of something like Plon, which does work with human, we do know that. If we want to manage things like content, well, the problem is, we need to scale.
02:20
And Plon cannot scale that much. Guiotina has been designed since the very beginning for high performance, and it can store millions of resources. So in our case, at HANA, we are having a cloud platform, and it's currently used by 20 different companies, and it's managed about 10 millions of resources.
02:43
So that's big, and our biggest in-premise deployment for Facebook, managed at the moment more than 13 millions of resources. And it could scale more, all right? Initially, we started using the ZODB and Restorage,
03:00
and at the time we reached one million of resources, it start begin to be very difficult regarding performances, and that's why we have been using Guiotina. And so if you need to manage more than one million of resources, you should definitely consider using Guiotina, right? So that's the reason why.
03:21
So let me explain what we do exactly. The HANA platform is dedicated to collect all the information used in an enterprise, so all the sources of information you can imagine. We collect all the data, and we index it so people can search information in a single place. That's what we do, all right? That's our business.
03:41
So how is it structured? We have some connectors, right? Able to talk with a third-party API, so it could be, I don't know, Slack, it could be Dropbox, it could be Amazon or Gmail or whatever. So we have those connectors connecting to those sources, external sources, collecting information,
04:00
and store it into Guiotina. And then Guiotina is running specific process to enrich this collected data. So it involves some basic data processing, some machine learning. So you have some, like for instance, automatic categorization, you can have language detection,
04:21
image recognition, these kind of things. And well, it does work very nicely. It's entirely asynchronous, and it's managing data very, very fastly, which is exactly what we need, because all customers needs to find information immediately, right? Surprisingly at the moment, the bottleneck
04:42
we have is indexation in Elasticsearch, but the rest is just scaling as much as we can. So we are dealing with this. I'm not involved in this aspect at all, so I cannot tell you a lot. I know we are investigating Kafka, if you are aware of it, but that's how it works.
05:01
So that's the backend, all right? Not my business. And yeah, endless is pointless without a head. So you're gonna call me stupid probably, but we are not under robot domination yet, so we build stuff for humans.
05:21
So at some points, we need to render something. Resources are cool, they are fast, they are efficient, but we need to render something at some point, because the customer is a human at the moment. So okay, why not plan again? Besides the scalability aspect I mentioned initially,
05:41
keeping a headless backend independent from the front-end app is a very sane approach, a very sane separation. Why is that? Well, I remember a talk from Paul Roland in 2012 I think, in Arnhem, where he explained how he ran Plone on a Raspberry Pi, so a very small device, right?
06:02
And he identified that small things like date rendering, for instance, or internalization, were extremely expensive, and by removing it from Plone, he was able to run Plone on a Raspberry Pi, right? So what I think is these kind of things
06:21
should be handled by the front-end. Templating processing, transformation chain, all of that that we do have in Plone right now is super expensive. So what about just forgetting about that? We just have a front-end, a rich application that's gonna take care of that, okay?
06:41
So a headless backend will only focus on operating the information and orchestrating access to the information, and that's all. So it could be super fast, and then you can scale. So what are the consequences? There are two consequences. First, we have a clean split between teams.
07:01
You're gonna have boring people, like Ramon. We're gonna deal with boring backend issues, sorry. And we have the front-end team, which gets all the fun and all the credits. So that's one consequence. Second consequence is we're gonna have, basically, a very rich front-end applications.
07:22
It means all the application logic gonna be implemented and gonna be under the front-end responsibility. So this means it's not just about creating a nice model dialogue or any fancy drop-down menu. It's not about that anymore, front-end. It's about making an application entirely.
07:41
So it's complex. So define complex. Well, a form library. This is super complex, as you might know. I mean, a form library is super difficult. There is a lot of use case. It's always end up to be super complex because the use case is complex, right? Well, we do have that.
08:01
We implemented such a library. So it's NGX schema form. Basically, it takes a JSON schema. So JSON schema is a standard. We enrich it with few information about the widget because JSON schema is not about rendering a form. It's about defining a schema. And so we enrich it with some more information
08:20
and we are able to produce a nice form. So let me show you rapidly how it is. I can switch from, sorry, I'm gonna escape. Yeah, so this is it. Where is my mouse? So you have the ability to, so I don't show you the,
08:41
I don't see the, yeah, the schema is here. You have something like this and it produce dynamically this form. So it supports conditional writing, field dependencies, widget overriding, custom widget, seaming, all those kind of things. We also have PastaNaga Angular,
09:02
which is implementation of PastaNaga design. So it's not this one, yeah. So all the widgets and all the small items we have in PastaNaga have been implemented in Angular. And with this sim plus the schema form library, we have been able to produce NSF PastaNaga
09:24
library, which is able to produce a form dynamically from a schema. So the schema gonna be delivered by Giutina and automatically we get a PastaNaga form to use it and render information, modify stuff. So let me go back to my presentation.
09:45
Yes. What else we've been doing? So with NSF PastaNaga, so this schema form thing with the PastaNaga theme plus Angular traversal. So Angular traversal is actually implementing traversal mechanism instead of routing, because routing is not efficient
10:01
when you are dealing with a website. Traversal is much better. So we have been implementing it with Angular. Plus the Plone REST API Angular, which is something I started for Plone initially, based on the REST API. But as the REST API of Plone is very compliant with the Giutina one, it does work entirely with Giutina.
10:21
So by putting all of that together, we've been able to produce the executioner. The executioner is the admin interface that Raymond just demoed very quickly. So it's client which allow you to see what you got in your Giutina and modify object and so on. And it have been actually very easy to produce. We've been doing this in few days,
10:42
because we have this rich environment, this rich tool set, toolkit of library in Angular, which are able to deal with Giutina backend. So producing something like the executioner is actually super simple. You just put together those libraries and you get something running very fast.
11:04
Well, regarding what we do at HANA, this is something much, much bigger than the executioner. It's a very big application. So I'm gonna show you quickly how it looks like so you have an idea of the complexity of it. It's not a full demo, it's just so you have a good understanding of what is it.
11:29
So you log in and then you get access to all your resource, all your documents. So, for instance, I'm gonna make a search. Here are all the stuff I have. So I can filter with many, many different criteria.
11:43
So I cannot read anything, but okay. I'm gonna filter down. Look for emails, for instance. What I'm gonna click, sorry. So that's emails, so that's basic indexing,
12:00
but I can also have, I have analysis per sentiment. It's able to recognize a sentiment into a document. So I'm gonna search for positive emails. So that's what I get, some positive emails,
12:21
and I could also search for negative ones. So you know the people who are using HANA Platforms are more lawyers. So it's on the legal tech domain so they are, for instance, looking since when such employee receive aggressive email from his manager.
12:42
So you're gonna use this to know that. Or you can also search for, like let's see, I'm gonna search some PDF containing the word contract. Sorry, it does not support typo. That's a shame, but we should fix that.
13:05
Oh yes, it's typo and typo. Oh, okay, oh shit. I cannot see it because it's type, I'm sorry.
13:26
Sorry, clear filters, yes. So that's some, all those documents contain the word contract. But if I want to make sure that there are contracts, we have something which is automatically analyzing if something is a contract or just something's talking about a contract.
13:42
So I'm gonna, where is my category thing? Oh, sorry, anyway.
14:03
No, sorry, I can't find it. Anyway, let's pass. And let me show you rapidly how you add a source. So for instance, if I wanna add a Slack source, I'm gonna get there. And I'm gonna authenticate to my Slack account.
14:21
So it redirect me to Slack and I agree. Yes, I do. And then I come back here and I'm gonna get the list of all the channels, all the, oh yeah, it was not automatically. Anyway, so it's already synchronizing everything.
14:41
So then I get my information here, collect it directly from Slack. So that's what it does. I will not go any further because it's not the point of this presentation, but so you just have an idea of how complex and big can be the application. Well, this application is about 70,000 lines of code.
15:04
And so just you can compare, the backend is half of it, 33,000 lines of code. So basically spaghetti code gonna be no way, right? There is no way we start managing
15:21
those 70,000 lines of code in any weaker way than the Python line of code, right? And I come from Python, so this is not my culture. I will not go with a spaghetti code approach. It's not possible. And as a team leader, sorry, as a team leader, my responsibility is to make sure
15:40
that my coworkers get the flawless developer experience. That's my main thing. Developer experience is everything. I don't, Apple really could not care about which technology you're gonna use or if it's nice or whatever. Developer experience is the only thing. On a long-term project, it guarantee you the project mentality.
16:01
It keeps the productivity good and it avoid to get team fatigue, right? So it's super important. And if you need to onboard new developers, that's also a key thing. I come from Plone, as I said, and I know how it should work. Because we, in Plone community,
16:21
we have a great culture about how doing development right. That's something we learn, probably the hard way, but we have a lot of knowledge for that. And the front-end community, the front-end people, not that much compared to us. So I've been trying to push the good practices,
16:41
I've been learn with Plone, to the front-end domain. And how do I do that? Well, simple. I just remove all the pain point. Everything which is painful, everything which produce confusion, everything which waste time, everything which involve ugly code or every config file, must be eliminated.
17:01
That's it. So, example. Webpack. Webpack is awful. Webpack is a most used bundling solution at the moment. And of course, you should use it. We have to use it. But you should not write your Webpack configuration manually. Don't do that.
17:21
No way. It should be generated. You should have a tool which does it for you. There is no way you do that manually. Every single line you write in a Webpack config is a liability. So no way. JavaScript. So, well, JavaScript, I have a pretty strong opinion about it,
17:40
but maybe it's because I'm ignorant or I don't have a lot of practice, but I would never consider doing any big front-end project with JavaScript nowadays. No way, no. I'm gonna use TypeScript. TypeScript is, I mean, I've been doing Python since 2006. For a long time I've been using a non-type language
18:03
and I was super happy with that and I totally agree that there is no problem with doing Python without typing and I know it's okay and I do that. It's fine. So I was, when I started front-end seriously, I was considering I could go the same with JavaScript.
18:21
Why not? I mean, it should work. It does not. It does not. Simply it does not. And I discovered TypeScript and it changed my life. I mean, really. For instance, if you just change the strict null check to true in your TypeScript configuration, everything which is possibly null
18:41
will break the compilation. So it means that if you enable that, you will never get, at runtime, on production, you will never get undefined as not metered blah blah blah. This will not exist anymore. And that's what you get every time when you do JavaScript. So with this, it's a big win. TypeScript is encouraging a lot the usage of classes.
19:03
Extension. You extend something, you adapt something, you use interfaces. That's something I know about. That's where I come from. And Python is working that way and I mean, this year is working very much that way and I feel the same about TypeScript. And I don't like this pure function approach,
19:22
functional programming. This is not how I want to work. I know it does work. I know it's efficient and so on but it's super complex for me to adapt to this. And plus, with typings, you get a lot of information. When you are working in a big team with a lot of front-end developer, it improves the collaboration
19:41
because every time you are in your IDE and you're gonna get a lot of information about such service, about such data structure, you get everything with the completion and you will not compile if you are using the wrong attribute, these kind of things. It makes refactoring easy. It makes refactoring super easy. When you are refactoring something
20:00
where you don't have any idea about the types, it's super dangerous. It's super difficult. So that's very important. Reactive programming. Reactive programming is also very, very important. Don't use callbacks. Don't use promises. There are weak patterns, okay?
20:20
So let me explain what is reactive programming. Sometimes it's explained in a very complex way. Reactive programming is a very simple principle. Let's say you have A. A is one, B is A, and now A is two. What is B? Well, in JavaScript, in Python, in almost any language, B is still one, okay?
20:42
With reactive programming, we're gonna say that B is A is a rule, and this rule gonna be enforced at any time. So with reactive programming, B gonna be two. That's basically what reactive programming is. Simple as that. Now if you consider a front-end context,
21:01
you have a button, and if something is not good, you want this button to be disabled, and you want this color to be gray, right? You could do that with promises like this. It's not good. Well, then I disable the button, and I change the color. Pretty good. With reactive programming, you're gonna split those two things. What you wanna do is this.
21:23
You're gonna listen to the is not good flow. It's an event, and every time it happens, then the button gonna change to a disabled state. And you're into the button, so somewhere else in the component, you're gonna be aware of your current state,
21:41
and depending on the state, you're gonna change your color. The difference is huge, because that's component responsibility to just bind the view to a state. So something is changing the state somewhere, and the view gonna react, okay? That's reactive programming.
22:01
And that way, you are sure that your rendering is always correct. Instead of this, where something might happen somewhere, something else might change the disabled to true, but at this time, we are not setting the color, and you're gonna get a disabled button, but with the green color, for instance. It might happen.
22:21
With this approach, it cannot happen. Anybody willing to change the state can do that, and automatically, the button will say, okay, I'm disabled now, so I'm gray. That's how it works. So it's something new for me, because in Plone, I mean in backend development, we don't care much about this ordering of stuff,
22:44
how things gonna be done, because everything will be done eventually at the time we are responding to the request. You have a request, it starts an event, then we do a lot of processing, we go to the database, we check whatever state,
23:00
wherever it is, we set the color, and we render something, and we send it. And at the time we send, everything have been computed, everything is done. So time is under control. But in frontend, time cannot be controlled. Anything can happen at any time. So the only thing you can control is timing. Time is nothing, and timing is everything in frontend.
23:22
And that's what reactive programming is addressing. Another thing which is super painful in frontend is dependencies management. So of course, for regular dependencies, you're gonna use NPM or YARN, and you're gonna get your dependencies from NPM, and you get everything locally
23:43
on your node modules, and that's done. But what I'm talking about is development dependencies. This means the package you are modifying, at the same time you are modifying your project, because there are some active dependencies, living dependencies. Well, if you wanna do that with basic NPM stuff,
24:00
it's a nightmare. There are several solution at the moment. Simlink is a basic thing. So with NPM, you can make a link to a package which is local, so the sources. And while it's super ugly, super messy, because you're gonna be on another place than your current project,
24:21
and you're gonna mess webpack in many ways, it's super weird, super difficult to debug, and you don't understand what's happening. And you will end up having several node modules in several part of your project tree, and that's a no-go. That's immediately L for everything, so no way.
24:41
Another solution is to bind to the disk bundle. That's kind of strange, but so you have some dependencies, you build them, you get a bundle, and then you bind your main project to this bundle. It's super painful, because you have to build everything every time, and that's not how it should work. Everything you change in your project, whatever is it in your develop subfolders
25:01
or in your main project, should start a build and you get the result immediately. That's how it should work. So that's not a good solution. And the solution that people seem to enjoy the most, the biggest actors right now in front-end, they propose this very bright solutions, monorepository, that mean you put everything into one single repository.
25:22
That's super smart, right? Because it's just, what it does, it turns Git into SVN. So that's actually quite surprising. But yeah, so I mean, it's easy to make joke about it. I know the front-end community is not stupid, and a lot of Brian developer are there, but I know their skill and so on,
25:41
but I guess I haven't suffered enough with big dependency management problems like we do in Plone since years, because we have like 200 eggs in Plone, and that's how we do stuff. So I've been suffering these kind of things enough yet, and I guess at some point, there will be an epiphany and they will understand
26:01
that are not doing it the right way. But meanwhile, I don't want to suffer. So I developed something named Mr. Developer, and the name might ring a bell, I guess. What it does is, well, super simple. You can, you have a file, Mr. Developer.json, where you define your dependencies,
26:21
and you can point to a Git repository, and you can check out a tag or check out a branch, and you're gonna automatically be added to your SRC develop folder. So the result is, everything is under a single SRC folder, so all the build chain gonna work automatically very easily.
26:42
You don't have many different node modules, because you're gonna kill your compilation every time. It's super powerful to manage flow, like you're gonna have a CI, the CI gonna use Mr. Developer to check out the right dependency for such build, and so you can manage version differently, you can manage everything super easily,
27:00
and it's making everything super simple. Regarding unit testing, well, don't waste time, just use Jest. There is nothing else to use. That's the fastest, it's super simple to configure, actually, you don't configure it, and it's super fast. So yeah, because it does not launch any browser, so you should use Jest and nothing else.
27:22
Regarding acceptance testing, well, no surprise, I mean, Protractor is super heavy and painful and difficult to maintain. The only solution you can consider is RoboFramework, right? And we have been using it for years in Plone, and that's the best one you can get, and the syntax is fantastic, everybody can get it,
27:42
and for our QA team, I would not consider giving them Protractor API or whatever, it's crazy. And now we're gonna talk about the big question. One of the most important and difficult shots for humanity.
28:01
So what it is. Well, no, I'm not king of Denmark or anything, so it's not this question. Not that one either, because the answer is 42 and everybody knows about it. Ketch.moot.on, maybe, it's a difficult one, but as we in Japan, I guess we're gonna go through with Wasabi and forget about the question.
28:21
No, the real question is Angular or React, right? So let's try to consider it quietly. I think we can do that, can we? So first, Angular is a framework, and React is a library.
28:45
So the consequences are, React is not open-ended at all. You will need to pick some third-party libraries, like routing or forms or whatever, in order to create your application, and this is super simple, and we are not talking about super simple application.
29:00
With Angular, it's not the case. You will get everything into Angular, so you do not have external dependencies to do these kind of things. So it makes upgrading much easier, much, much easier. It also avoids a lot of boilerplate code, because all the wiring is internal, so you don't need to declare too much stuff
29:22
on your own code, because all the dependencies of Angular, the internal dependencies are done. So if you compare the code of Angular to React, I mean, React and Redux are super verbose. I mean, you have a lot, a lot, a lot of code to achieve very simple stuff like just calling an endpoint.
29:42
That's craziness. And moreover, using a structured and a rich framework like Angular, will produce very structured project, and they are all structured the same way. And that's a major benefit when you need to onboard new team members, because you're gonna hire an Angular developer,
30:01
and you're gonna see your project, and it will be immediately comfortable with how it works and what does what, because it's clear, plus TypeScript is also providing a lot of information about everything, so it's a major thing, and that's something very important for us, for instance. I want to be able to hire a lot of people that can be productive immediately,
30:22
and we have been doing this, and it does work. And I do know some companies working with React where it's a total nightmare because of that, because a lot of people are React developers, but not real developers, actually, and it's very complex to make sure they can reach a point where they are productive,
30:40
and senior developers spends most of their time training the new developers. With Angular, I think we do not have this problem. Another thing about Angular and React is, in Angular, we have templates and CSS done the right way. It's something which is designed,
31:00
so just so you say, in Angular, you have HTML file, and you have a CSS file or a CSS file, and you have a TypeScript file where you implement the logic. In React, you have everything into a single thing under a JS6 format, so you have the JS code and the template at the same place. I think it's not right for designers. We need to have some designer-friendly approach.
31:22
So React Moto, it's all JavaScript anyway. At the end, it's gonna be JavaScript, right? So we are JavaScript developers, it's better for us, but you're not alone. I mean, Angular says JavaScript is not the only thing. You also have HTML, you also have CSS, and we should not exclude non-GS web developers
31:42
because it does exist, and we can take a lot of benefits by using them very actively into development. And when, at ONA, for instance, Ulrich's designer, so Albert here, is able to change stuff in the code. He's able to do commit, and we merge his stuff,
32:01
and he's just working in HTML and CSS and doing a great work with that, and with JS6, it's not possible at all. So when you have a big team, when you need to split the different area for each part of the team, it's super important. If you are just on a small team where everybody is a great JavaScript developer, well, React could be considered,
32:21
but if you want to scale, it's super difficult. I think it's important. And plus, I think Angular is providing a cozy environment. You have a major release every six months. Each major release is gonna have 18 months LTS,
32:41
and migrating is automatic. You just run with a CLI, you just enter ng-upgrade, and all your code is gonna be upgraded, and you could go to the next version. So it was not the case at the very beginning of Angular 2, of course. As everybody knows, it has been a total nightmare initially, but now it's done the right way, and it's super important as well for maintainability
33:00
and long-term maintainability of your project. The CLI I mentioned already is super powerful. I mean, my feeling about the React CRI is it does create an app. That's its name. It creates app, and that's pretty much what it does. With Angular CLI, you can do a lot, just like, for instance, migrating to a new version,
33:23
and it does really a lot of things, and that's super important as well to onboard people to make sure they don't have to spend a long time learning about how the project is working, how you build and so on. It's gonna be super easy.
33:41
And it's a cozy environment as well because Angular does not encourage low-level handling. It's not easy to do, and like, for instance, creating component dynamically, programmatically, this is not easy, it's possible, but it's not encouraged at all, and that's very good.
34:01
And as contrary with React, you are on this low-level thing, and to me, it's not a good way to approach productivity. We also have a big usage of dependency injections, and this brings plugability, it brings a lot of,
34:20
I mean, it makes overloading super easy, and that's also something which reminds me what I've been doing with Python, so it makes the whole thing easier for a beginner. So yeah, to me, that's the best developer experience we can provide, and that's, as I said initially, that's my first concern, my only concern, maybe,
34:43
and to me, Angular is doing it really right, really. And I, of course, we could imagine a React-based approach that would provide such a good developer experience, but I'm not sure it's gonna happen because I think it's a matter of culture,
35:01
and React people will not implement a framework, for instance, that's not in their DNA. They enjoy this low-level, light library approach, and that's for a reason, and I mean, I respect that. Some say React is a new PHP, I don't think it is.
35:24
To me, it's more like C++, and really, it is, and when I do React, I've been doing some React, I'm always afraid I'm gonna get a stack overflow in the browser, basically. It could happen, I mean, it's something to, I don't know that if Angular has the new Java.
35:41
I buy that, so yeah, I mean, so they choose the hard way, and that's fine, good for them, but I don't want that for my team, so I stick with Angular, basically. So thank you, that's it, thank you.