 Merci tout le monde, je suis très heureux de vous voir maintenant. Je sais que c'est tard, c'est la dernière conférence de Drupalcon, donc c'est un plaisir de vous avoir dans la salle. Nous allons parler de quelque chose un peu spécifique, parce que la plupart de cela n'est pas sur Drupal, c'est sur une autre technologie, mais je pense que cette technologie est très, très intéressante, et je suis sûr que dans quelques années, on va le voir dans Drupal. Pierre, peut-être que vous le savez, vous le savez parce que l'initiative de l'UiSuite, l'UiSuite, c'est un moyen d'implementer un tout système de design dans Drupal. On ne parle pas de l'UiSuite aujourd'hui, ne vous inquiétez pas, on parle d'autre chose, mais nous allons commencer avec ça. Donc, grâce à l'UiSuite, nous pouvons implémenter tout l'artifact de ce système de design, components, types, layouts, exemples et un team, et cette implémentation sera disponible de l'arrivée de l'office, parce qu'on génère des plug-ins et on connecte avec beaucoup de Drupal API. Nous aimons l'UiSuite, surement, ou les clients aimons l'UiSuite, parce qu'ils aiment ce système de design, et quand ce système est correctement implémenté, c'est très utile. Parce qu'il n'est pas tenté d'améliorer le site, il n'est pas utile, il est aussi réusable et réusable. Donc, nous pouvons avoir beaucoup d'advantages de partager un single Drupal team dans tout le site de notre compagnie. Mais, quelque chose s'est passé, après plusieurs ans de faire un projet successeur avec l'UiSuite, un de mes clients m'a dit que nous aimons l'UiSuite, nous aimons l'UiSuite, nous aimons l'UiSuite. Nous aimons l'UiSuite sur le Java app. Vous savez, c'est une twig, c'est une twig technologie, et c'est plein d'UiSuite. Donc, je me dis, oh, je vais avoir une vue, et j'ai quitté mon travail. Je sais que depuis un an, j'ai eu une vue. Et pour six mois, j'ai eu beaucoup de problèmes, mais en mars, j'ai trouvé quelque chose d'intéressant. Donc, ce que l'un de mes clients m'a dit, un an plus tard, il m'a dit, qu'il n'avait qu'une implementation par technologie, une implementation pour Drupal, une implementation pour Java, une implementation pour Salesforce, tout ça. Il m'a demandé pour une single implementation, wrote once for good, shared between every technology, and this, of course, server side and client side. How can we achieve that? Is it even possible? Yes, it is. But it's very challenging, because it's not only universal. Of course, it must be universal, Donc il doit être sécurisé par défaut, parce qu'il doit être réalisé sur le cloud. Il doit être réalisé dans un browser pour Headless. Dans un serveur, même un serveur qu'on ne connait pas. Il doit être réalisé avec primitivement. Donc, il n'y a rien à propos d'une langue spécifique ou d'implementation. Et il doit être ouvert à la source, et déjà dans un standard d'administration, d'être accepté par le client. Donc pourquoi pas le docker ? Le docker conteneur semble bien. Vous mettez l'application d'administration dans un conteneur de docker et vous communiquez avec l'application d'administration. Et ensuite, vous avez un service d'administration qui travaille avec tout le monde. Mais maintenant, parce qu'au début, j'ai dit à vous sur le web browser, Headless doit être couvert. Et au second, le docker est lent. Je sais que pour nous, le docker est rapide, parce qu'on vient de la technologie plus lentée. Mais quand vous faites quelque chose, vous savez, vous avez déjà fait tous les règles du business. C'est la dernière chose que vous faites, et vous avez déjà perdu beaucoup de temps. Donc, l'administration doit être très rapide. Donc, nous n'avons pas beaucoup de réseaux, parce que nous n'avons pas de réseaux que nous voulons voir. Donc, nous n'avons pas beaucoup de TCP, pas de HTTP, et bien sûr, pas de la technologie, pas d'administration et pas d'administration. Donc, nous avons un look sur ce qu'on appelle l'Edge Computing. C'est un peu de buzzword, comme Cloud Computing, mais à l'arrivée de tous les buzzwords, nous pouvons trouver des trucs intéressants. Et parce que l'Edge Computing a un gole d'exécuter les trucs les plus clairs possible que possible par le code de l'administration. C'est quelque chose qu'on va faire avec nos besoins et le target. Et nous avons trouvé WebAssembly. Qui sait de WebAssembly ici ? Bien, 10 personnes. Donc, pour les autres personnes, WebAssembly est un target de compilation. Donc, vous n'avez pas de trucs dans WebAssembly, vous avez des trucs dans d'autres langues, des langues légales, et vous compilez pour eux, pour WebAssembly. C'est un bon site, parce que c'est plateforme indépendante. Vous pouvez le faire partout. Nous parlons de ça en ligne. Très bonne performance, néanative, très légère weight. WebAssembly module est entre 10 et 100 fois plus petit que le container de docker. Sécure par défaut, c'était construit depuis le début pour être sécurisé. Et, bien sûr, l'open source. C'est très développé par beaucoup de compagnies et il y a des gens que nous connaissons, des gens du Comité Drupal qui a été récemment resté il y a quelques années, qui étaient très influenciaux dans cette communauté, comme Lean et Mat. Donc, encore une fois, 30 ans après Java, on a dit que les Ounces se sont emmenés à tous les côtés, including WebBrothers. Est-ce que ce sera plus successement que Java ? J'espère. Donc, il y a trois domaines et deux qui sont très intéressants pour le service. Le premier, c'était initialement préparé pour augmenter Java Script. Parce que nous faisions trop de trucs en Java Script, et Java Script est fragile, Java Script est slow, Java Script a beaucoup d'issues, et des gens disent, « Laissez-le, c'est le plus gros, laissez-le avec une autre langue, et laissez-le au brosseur. Ça nous permet de faire des rendements de Laissez. Et le second, c'est aussi construit comme un système universal, parce que c'est agnostique et safe, vous pouvez le filmer avec aucun code, aucun langage. Donc, c'est bien pour le service avec les rendements. Donc, ce qu'on veut construire, c'est un module WebAssembly qui cache le système des rendements. Donc, ce que nous avons besoin, nous avons besoin d'un service de rendement. Nous serons très similaires aux rendements du Drupal. Nous avons besoin d'un emploi et d'une jeanne. Nous avons besoin d'une jeanne. Peut-être que tu sais, Twig est la porte de jeanne sur PHP, donc c'est facile. Et ensuite, nous mettons tout le système des rendements à l'intérieur. Mais qu'est-ce que c'est? Sorry. Nous avons juste copy-paste un Drupal team. Qu'est-ce que nous allons vous montrer dans quelques minutes? C'est un Drupal team. Vous pouvez le trouver dans Drupal.org. Et ce Drupal team sera interprété par le service de rendement et la jeanne dans le module WebAssembly. Donc, nous avons tout ça. Drupal Team, Drupal Renderer, Twig Like. Qu'est-ce qu'on peut avoir pour l'API? Je pense que vous avez vu le titre de la conférence, donc vous le savez déjà. Laissez-vous avoir un look sur le bon, vieux Render API. 17 ans auparavant, durant le sommet, Eton a eu une idée fou. Il a dit, pourquoi nous n'expandons l'API pour tout le Render? Pas seulement les formes. Et la journée a commencé. J'adore Render API. Je ne sais pas si vous l'avez aimé. Mais il y a des features, des avantages. C'est difficile de trouver d'autre. C'est déclaratif. Donc, c'est facile de type. Et vous pouvez serialiser facilement. Vous pouvez mettre le Render array dans JSON, en YAML. C'est plus facile parce que l'arrêt, la structure, vous pouvez alter sur le fly et alter plusieurs fois dans le lot, comme le pré-processing. L'application data c'est efficace. Vous pouvez déclarer, d'exemple, un attachement dans le haut niveau de votre Render 3, il va aller au top. C'est curieux. Le système de caching c'est très efficace. Vous savez, si vous disablez le caching de Render API, vous verrez que Oslo sera sur votre site. Le management d'assemblage, c'est non-sens, efficace. Et la magie est plus tard. C'est l'amour. Vous êtes séparé tout le lifecycle de votre Drupal Request Processing pour construire cette grande, grande Render 3 et quand c'est terminé, avant de séparer la réponse Http single rendering. Mais est-ce que nous l'avons? Parce que c'est une relation de l'amour et même Jeff, le créateur de Render API six ans plus tard, il était comme oh peut-être peut-être que j'ai fait un erreur. Je me sens mal. Bien sûr, Render API aujourd'hui est très anoyé. Donc est-ce vraiment ce que nous voulons couper, ce que nous voulons imiter pour notre nouveau Render API sur la plage? Je crois que oui. Parce que ce que nous appelons Render API selon moi c'est deux parts très différentes. Nous avons le ten-manager. Le ten-manager c'est l'ancien part de la Render API. C'est tout en rapport à un thème charme, vous voyez? Et nous avons le Renderer avec le nouveau. Toutes les belles choses sont dans le Renderer. Bien sûr si vous avez un Render avec un thème h-thème le Renderer nous appelons le ten-manager. Mais tout de suite le Renderer fait beaucoup de choses que nous voulons avoir dans notre service Renderer. Donc let's take the Render API mais sans le ten-manager. Donc sur le white vous avez un liste de les plus populaires des Renderer. Et j'ai retiré avec gré pour calling the ten-manager. Donc nous gardons markup plaintexte initemplate html tag et component. Component c'est la dernière parce que c'est nouveau c'est d'un project c'est introduit mais component c'est un game changer parce que je pense c'était la dernière chose qu'on a besoin d'un ten-manager. Maintenant, nous avons décidé sur le scope. Let's take another decision. No primitive oh, sorry no executable object only primitive. We don't want to use executable PHP object in the Render API because if it's primitive you can serialize you can share you can send and it's language agnostic. So for example in the Render API I am building this kind of stuff is forbidden and has to be replaced. Only six primitive type and that's good because they are more or less the same between all the languages and also in the template. Let's just have quick look on a few example how it's built. First for string, scalar and markup we have kind of the same but a bit more compact and easy to manipulate with escape by default. So it's very secure. For HTML element instead of HTML tag we have element but it works the same we just fixed a few weirdness we have today for example for nesting element for component so the SCC stuff we have the same too I'm not it's more compact because there is no legacy so we can do something a bit nicer but it's the same I don't talk about attachment libraries I don't talk about many other API but once again it's the same So for the API we are building and the API I will do a demo in a few minutes we need only twice properties for components that mean renderable with template and libraries in light template if you want to have some markup on the fly HTML tag for the smaller stuff some properties related to this system artifact because we are implementing these systems and the bubbles 12 it's nice, no it's compact but Drupal also have a compact render API because if you keep only everything if you remove if you get rid of everything related to the manager and you keep only the good stuff you have this it's compact it's clear and I hope this is the direction we will take so let's talk about Drupal last time before going to the to the solution Drupal render API can be fixed Drupal render API didn't get so much evolution since the coming on Drupal 8 with a more compact API we can have more consistency a better developer experience and also we can rid of the ten manager with two hold for a time we can also increase the speed because you know render API take around 10% of each request so every progress we can do will be interesting and if you use primitive only we can validate the render tree by Jean Chema and have a lot of goodness thanks to Jean Chema and also we can expose the API on the web why exposing the render API on the web why having endpoint I will show you why because it's what I do with my rendering service let's go so after thank you so after six months of prototyping with my friends we got this a way of sharing your design system in a tiny universal package and use it everywhere this kind of API it's changing all the time so don't see the details but you have the same payload the exact same payload with primitive of the language with a render tree render array and you run this payload in all languages can be Python, PHP, JavaScript anywhere the result is good for us it makes up API it works as expected it's very comfortable we are already building some internal website with that the speed is crazy I will show you that and the security it's as strong as expected we are developing open source and we are licensing with GPL3 so step by step we are releasing the code we have a website dilla.io where we are pushing the experiment so it's a moving target sometimes it doesn't work well but it's we are transparent about what we are doing the speed is incredible a full page a full page it's 10 ms let's say it differently everything is 10 ms with dilla if you run a full page half a page complicated component or small component it will always be around 10 ms because it's not the complexity of the render tree which change the time it's 30 times faster than Drupal render API when we package a Drupal team as a web assembly module we are around 600, 700 kilobytes so you can download it download it for headless rendering and I think we can reduce to 300 kilobytes at the end of the experiment let's do a demo so this it's the ui suite bootstrap team taken from Drupal org package in web assembly and running in the browser so this is the alert component I'm changing the data and the renderer service it's executing the data the template engine the tweaked data template and the asset library stuff everything is executed we're lucky in Drupal of course there is JavaScript but the JavaScript here it's only used to send the payload to the web assembly and to get the result and print in the page there is no JavaScript logic everything is in the web assembly package so if you do that server side with Python you will have the same result you can change the variant if I change you can change the props dismissible you see the cross oh yeah falsies it disappeared you can nest of course it's the render API so you can nest component my button is inside my alert you have some style utilities so let's take the shadow let's take a big shadow I hope you will see it on the screen the shadow is supplied and also we are managing css variable of course the css variable rendering will be done by the browser but we can put them directly in the render tree we can control it from the render API I change the primary color and it changes everywhere so even the back developer can change the css variable when they are rendering their data let's finish I know there is a closing session it's not all perfect because we haven't finished yet we have an issue web assembly module can only communicate with the code with JavaScript, Python, PHP, Ruby, everything with numbers so as we are sending complicated data mapping numbers, string, arrays we are sending all this stuff so today we have to maintain a binding for every language we support and it's not like how you do it and it's done and we don't care it's a mess this binding layer is a real mess and for today it's the biggest issue we have and maybe the only one we hope something will happen in only two weeks late november, early december the third release of web assembly will happen the preview 2 thanks to preview 2 we will be able to put the binding the type interface into the web assembly module that means this time it will work as expected you will have a web assembly component and you can run it everywhere so today we have two two path lines one for the web who is building the Drupal team into web assembly compatible with browser and javascript it works the demo i show you it works the demo i show you is based with web component but you can use it with react, with view with anything and we have dilla edge dilla edge is the work in progress and we have to wait a few weeks before finishing it and this will work with other side but the good news it will also work with browser so at the end dilla web will disappear and we will have a single web assembly module for front and back so thanks everybody this is dilla an experimental design system renderer service for the cloud, for your browser for your server, for the edge very inspired by drupal because we are drupal people and it will be released soon i hope if you want another demo you can meet me after this i am in the US suite table if you are in love or hyped by web assembly let's have a drink because i think we have a lot of love to share some question very quick question hasn't somebody else surely done this before has somebody not done this before are there other equivalent services that have tried to do this rather than take the drupal renderer and make it universal for six months it was looking impossible because we discovered web assembly then it was possible so i think if it has to happen it has to happen now because what we need is web assembly preview 2 will be released in 2 or 3 weeks before this technology was available i don't see another way of doing that follow up question how much of the learnings of a simplified renderer api are applicable to drupal core like you talked about removing the team manager how realistic is that what kind of time scale would that take so now we have ADC component and there is some people are excited about replacing most of the template managed by the team manager you know by ADC component ok if we move all this to ADC component we can it's very simplified maybe someone from the renderer api will scream if he heard me that but i guess if we move to ADC component we can remove the team manager excellent other question don't be shy