And there are some questions on there.

I was able to read most of them, or be able to read most of them. Maybe we need some help from you, the people who wrote it down. Yeah, so the idea is that we're actually going to answer your questions. Maybe it's also nice if we read it, then you maybe put up your hands so we know who the question asks, so we can maybe have some in-depth answers as well.

All right, so let's start with the first one. The first question is, how to deploy it? Vektor can do the answer to that one. OK, yeah, how to deploy it. We deploy it, you can deploy it using any process manager.

For example, supervisor will be OK. The way to deploy Volto is that you have to deploy Plone as you normally do that. And then you have to deploy the SSR server that Volto builds on the build process.

And you just have to run this JavaScript that is the server JS bundle. You have to run it with Node. And as I said, you can use whatever process manager that you are familiar with, or with systemd also. There are people that does that without just

systemd running things and stopping things. We do it using PM2. PM2 is a process manager that is done with Node. And we started from the beginning. I think that we'd never tried anything else for Volto itself. And then when there was all this thing

about the release of supervisor for Python 3, and the maintainer wasn't very eager to release it, then there was problems, then we started to deploy Plone as well with PM2, because why not?

I mean, yeah, it's a Node tool. But it can run whatever process that you want, right? And PM2 is a great tool. It has a lot of features, even the paid ones, because they also leave from doing premium services. But it's been nice, and we are very, very, very happy

with it. I think that in the documentation, we have a section. It's very raw. We have to improve it, but you can go there and take a look how to do that. Then another thing that I mentioned in my training is that you have to deploy your main Volto site in your DNS server.

But then you have to make available Plone also for the clients, because the client's browsers are going to hit Plone REST API. So normally what we do is to set up the same server and the API folder for Plone directly. And I think that's it.

What should be said about it? Thanks for that. Yeah, we can go now. We have more questions. So whose question was that? You got a correct answer, right answer? Enough?

It's about course, right? Yeah, about course. If you have a deployment, and you have such a deployment, as I said, so you have the server name, and then in the API, the course then doesn't jump because you're using the same server name. And then you don't have to worry about the course.

So avoid course at all costs. That's our experience. Yeah, just simply don't deal with that. Just use the same name as your main server, because just better. Yep. All right. Next, well, kind of question. It's more like a like statement.

Show us some case studies. Sure. So we have a demo can probably answer that better, but he has a talk tomorrow, I think, in the afternoon, which will be a case study. And he just added it to the repo, I think. You can say. Absolutely, yeah. I created a pull request. I repeated it myself and nurtured myself.

Uh-oh. But I wanted to have it for this panel, right? So yeah, you can blame me and punch me later. So yeah, I mean, we have like four public Volto projects that have public websites. The other ones we're not allowed to share or talk about.

And I know a few companies that also did Volto projects, and I will try to get them to add their sites up there as well. And yeah, just check out the readme, right? Maybe at some point we should also publish case studies

on Plone.com for Volto. I guess that would make lots of sense. Yeah, so it's there, I guess. Yeah, and there were some other talks as well, I think, with case studies. I think yesterday was one. Yesterday.

Nikola did a talk today. Yeah, indeed, today. All right, then a really long question. So the question is, do you have a plan for a non-UI, non-admin package? It means only having API and router as core package. Yeah, I can answer that one. So basically the question is, so we have, of course, the REST API,

and there's some code in Volto which handles all the backend calls and has some helpers methods there and routing. And do we provide a package with just that information? Well, no, we're not gonna provide a separate package, but you can just use Volto

and only import that part of the package. So you don't need to use the old machinery of Volto. You can just import the actions, the reducers, and routers, and the routes, and you can basically write your own front-end, whether that be in React or in Angular

or Vue or jQuery, whatever. So that you can do, and you don't need to split up the package. You can just import only the stuff you actually need, and that should work. Who's question was that? Yeah, good, yeah, all right.

And I think that it's even feasible with create-volto-app, I mean, with the overrides. Yeah, you can even do it with the boilerplate. I think that it's doable. I never tried, but. Yep, all right, next question is how to extend it. Who wants to do that one?

That's a complex one, so you go. No, the other one is that complex. All right, so extending. Yeah, so there's multiple ways of doing it. So the easiest, I would say, is extending as in creating your own site. I think there's quite a lot of documentation, so we have the training material there,

so if you do want to create your own site, and extending, so adding views, overriding views, et cetera, et cetera, there's all documentation to do that. If you mean extending by add-on products, as we know them in Plone,

there's multiple ways of doing it. So currently, we don't have a full add-on structure in place, that means that we would like to have a structure where you only have to specify which add-ons you want to use, and then every configuration and overrides and everything will just be automatically picked up. We don't have that in place yet, but what you can do is create your own MPM package

with a certain specific views, actions reducers, you name it, everything you want to do, and import that in your theme package. So you can definitely do it that way. But yeah, indeed, we're still working on making it even better for developers or easier for developers to work on.

Whose question was that? Anyone? Nope, all right. Then I guess we did a good job, right? All right, next up is complex layouts. That's yours, Victor.

Yeah, you're the complex guy. Complex layouts. The other day I was, yeah, I was updating role about our new blocks development, and then we had a nice talk about it.

And yeah, I think that some moment in the future we could even treat the frame with what we call the frame header, footer, and a likes as blocks as well at some point, and reuse again the concept of layouts that Mosaic intended in the first place, right?

So for now, we only have one layout that is the one that the app APP component is forcing, but at some point in the future, we can imagine that we can extend that to be also composable. So you can have several layouts that also defines,

as we are defining blocks, we can define the different components of a page and the disposition of that page, right? And then pair, I don't know, pair route or pair content type or things like that. So I think it's doable. Yeah, I would like to add something,

like the short answer to that is I would say yes, because we did two projects, one for the Humboldt University in Berlin, and an agency created a really complex agency theme, so super fancy and everything, and really hard to implement with modern web technology.

And tomorrow, I will talk about that in my talk. So there you will see an example of a complex layout to a certain extent. And we have another project where we also did quite complex layouts, so grid layouts.

And we have the blocks around, but we're still trying to find the right level of reusable blocks, right? Because creating something reusable is really hard. We did that wrong quite, at the first time, we created a super Uber block

that can do everything, right? So you add a block there, and you can add that in a grid row or whatever, and then later decide what it is, if it's a card or an image or whatever, and that was the response we got from our client when we went there, and we were super proud what we did. They said like, oh my God, that's way too complex,

and then we moved back to simpler blocks, but if they're simpler, then they're more client-specific. So we have to find a good way in the middle, but still the answer is I think yes, we can do all kinds of complex layouts.

All right. Whose question was that? Must be Oskar's. No? Whose question was that? No one here? Oh, yeah, there. Yeah, we have a bit of a light shining in our eyes, so it's not that hard to see. Was it okay? Was it good? Everything answered?

Almost everything. You have some additions? No? You can, we'll probably have some time after to add additional questions. All right, next up is event. Instant behavior plus date block, I think. Yeah.

Yeah, so events. Yeah, I think it's, I mean, the type is there, but I mean, the question is, as Timo already said earlier, do we even want types, or is it just we have one, we have a page where you actually add specific fields to, or specific blocks to,

which makes it a bit different, or makes it look different? And I think the last is definitely something we're going to look, the direction we're going to take, so you don't need to create, like, 40 different content types in your website, but you can just create a page and add,

date, start and end date, and which makes it an event, or add a listing to it, which kind of makes it a collection, or if you want to say. So, yeah, we have date, time widgets, they're already there, they probably need some improvement, but at least the basics are there,

so you can definitely add events in your site at the moment. Is that question answered? Not sure who's, question it was. Sorry, yes, you? He asked if we did an additional content type.

Yes, we basically reused everything that, like we, like that depends on Plone, right? So if you add a custom content type, it will show up in Volto, and it will work right away. So any content type that we have in Plone is also in Volto. Like, I showed a customized version with that single page, right? I mean, that was something that I made up.

Yeah, so all dexterity content types will just work in Volto as well. So that includes the events, but also news items, images, files, you name it. The thing is that probably in the demos, you are not seeing it, because we deliberately remove it,

because we have the widget for the dates are not quite yet, and then we had an issue with the widget for the event type. So there's a PR for that, I think Andrea was working on it in Sorrento, and yeah, we have to work a little more on it,

but we didn't want it to show people something that doesn't work well, and then we remove it from the demos and everything. But it's there, and of course, you can use it as any other Plone content type. Yep. All right, next up, site with deep content structures, navigation levels,

and it's probably more or less the same question, as the bottom one, which is why no second navigation level or drop-down menu? Who wants to take that one? Yep? Dima, go ahead. But for me, they're separated, right? Kind of? Kind of, I mean, one is, nah, Dima already is.

So how about the deep content structures and navigation levels? So we deliberately did not implement portlets on Plone REST API and on Volto as well, right? And this is how Plone 5 handles deeply nested structure, or it handles it on two ways, right?

One is the drop-down menu that we just recently added, and the second is the navigation portlet, right? Adding in a navigation portlet or something that looks like that is super trivial. One of our interns did that in half an hour or so, right, so in React, it's super simple. You have all the necessary data in Redux anyways,

and then you just display it basically, right? And you just add it to your main view or wherever you want it, right? So that's super trivial. We could add something like that, but since it's so easy to do, I don't see any reason that we have that. We can think about a replacement in general for portlets and how we want to handle that,

but that's a complex topic. So yeah, we have the option there to do that. We could even resemble what Clone does today, right, if we want. There's no technical problem there. I see it's more like a decision what we want to do, so that would be easily doable.

And the second question is, why no second-level navigation? The only answer I can give there is really my personal answer. I don't like those small drop-down menus where when you slip, you're immediately gone with your mouse, right? I hate that a lot. So what we do with clients when they ask for that

is we do those fat drop-down menus, and we did that for most of our projects, actually, because they have deeply nested structure, and then you need something like that, right? Though the problem with that is that it's always kind of client-specific, so we implement that on our own. But the good thing is that it's in React, so it's super simple to build it

even for every project, right, or to just reuse something that's already there. So again, it's something that we can decide as a community what we want, right? Do we want a drop-down menu? Do we want a fat menu? Do we want to keep it like things as they are, right?

It's not bound by any technical means, and implementing that in React is a lot easier than in Plone, right? So I'm open for discussion, I guess. Yeah, and maybe at some point we can, so currently we have the, of course, we have the styling of Pastanaco UI, and we have the styling of the theme, basically, the default theme,

and we could also ship with multiple themes by default, where maybe one theme does use drop-downs, and the other one uses some fancy navigation thingy. Yeah, so that's definitely doable. All right, now really important question. Is it compatible with Guillotina?

And the question wasn't even from Ramon, he said, but I don't trust him, though. No, I'll answer that one to start the pillow fight. So short answer is it's not 100% compatible.

Most of the calls are the same. The APIs are kind of the same, almost the same, slightly different, but I think it's mostly, has to do with how can we keep up the APIs in sync? And that's a hard question, I think,

because both systems are different. If you try to force it in a way so that the API is exactly the same, for me, from a front-end perspective, I'd say it should be easy to doable, but there's always opinions in the back-end, so I think there's some people with strong opinions, both in the Volto camp and in the Guillotina tent camp.

I'm not gonna name any names, but you know who they are. So if they have more beers together and if they discuss more, or maybe should have less beers and discuss less, but I don't know, at least if they figure out a way to make a generic API which will work with both systems,

then we can definitely get there. But yeah, so I don't think there's any technical reasons why it shouldn't be possible, like fully, 100% compatible. Yeah, I think that's the answer, so it's not a technical issue.

Want to add anything, Victor? I'm not giving Timo the mic. Yes, it's compatible. All right, then the question, migration from Plone X.X to Volto. Wow, X.X is not really specific, so it could also be from 1.0, all right.

Who wants to do it on that one? Yeah, I mean, doable, right? I mean, we migrated from Plone 4, lots of client projects from Plone 4 to Volto. We have a migration pipeline based on Transmogrifier that does that.

And yeah, of course, it's like the main problem there is that you have to migrate from pages to composite pages, right? So you have like TinyMCE text field, rich text field, and you have to migrate that to, you want to migrate that to a composite page, right?

So that's like one block then, where we add everything, right? That's possible, that's doable. Main problems are cover pages. We migrated from cover to Volto composite pages. Mosaic and the like, right? That's the problem. Even if you would want, like migrating a cover page

to a Volto grid block page, whatever, would be doable, but it would be like a lot of work, and it wouldn't be anything that you really want to see, right? I mean, resembling a cover page in Volto, I mean, it would just look like ugly and old.

So we don't want that. And then the client wants to like overwrite that. So what we did actually is, or what Rodrigo did, he will give a talk about migrations as well, and he will like cover that, how to do those migrations in his talk tomorrow. What we did is like, we added a post-migration step.

So we run the entire migration, like for everything. And then we add empty pages for the cover pages, right? Or the composite pages. And then in the post-migration step, you can add a JSON structure for every page and overwrite that, right? So we just overwrite that,

and then we can see everything together. We have all our migrations in the CI, so the CI runs. It migrates everything, then runs the post-migration step, adds the composite pages, right? And then we can show that to the client. And they can even like tinker with the pages on their own and tell us like, okay, we're done.

This is how we want the overview page to look like. And then you just go to Plone REST API, drop that and copy that over into your JSON file, and then it's there, right? That's the cool thing about the blocks, which we haven't talked about that, but we also like, yeah, we use that a lot, right? So just like get the response from Plone REST API,

copy that over to the file system, and then make Plone pick that up and add that. And that worked quite well for us, so yeah. All right. Next up is something we're not sure what it was. So it says, can I add content via CLI?

Whose question was that? No one? All right. Then we're just gonna take a guess. So my guess is that it has to do something with maybe like Plone CLI kind of things. And content being fused maybe, I don't know.

Could be, I'm just guessing here. So we don't have something similar to Plone CLI. I guess it would be really nice to have though, and not that hard to build actually. So currently if you want to create your own view or action or reducer or anything else which is custom in Volto,

you basically usually copy over some existing view and make some changes, but indeed it would be nice to have Plone CLI kind of UI that you can actually just add your own views and et cetera, et cetera. So that's, if somebody's up for that as a sprint topic, then that would be really nice.

Sure. I understood that like differently, I mean just adding content to Volto is like via Plone REST API, right? I mean you just do a curl. Yeah, but this is the back end, yeah. Okay, I mean if you want to add like stuff to Volto programmatically, you just use curl or HTPI or whatever, right?

And you just do a call, then it's there. Yeah, Python. Yep, all right. Next up, why Semantic UI? It's your fault actually. It's my fault indeed. I think, I mean I kind of answered it in my presentation as well.

Yeah, so when I started with Volto and I wanted to have a look into what CSS framework to use, I of course did research on like not all of them, at least all the popular ones. And the main feature I was looking for is how easy is it to theme

and does it have like a theming support and theming meaning that you can actually override stuff and when looking at all the system, Semantic UI is actually the only one which had theming like really built in and really well done. I mean you can, for example, you can do theming in Bootstrap,

but it basically means you copy over a theme and you change some stuff and now you have your new theme. With Semantic UI, you basically derive from a theme and you leave the theme intact and you override only the stuff which is specific for your own site. Which you were kind of used to in Plone

or in the Plone or in the Zope world. So that was actually the main reason to choose Semantic UI. Another reason was it does really feature complete, so this actually has a lot more component than, for example, Bootstrap or material has. So they have, for almost everything,

they have a component and they have really great React bindings as well. So all the components are there so you don't need to have any widget or component. You can just use the Semantic UI ones instead of writing your own and maintaining your own and especially the maintaining part is, of course,

for us as a relatively small community, it's really nice if we can use external libraries so we don't have to maintain them. Whose question was that? Anyone who's here? Oh yeah, does it answer the question? Yep, perfect.

All right, next question. Where do I see the state of my objects regarding workflow, I guess? Will, this is a question with, kind of poignant, right? Yeah, you can see it in the menu but you have to click on it and you can see it also in the bar.

In the toolbar, there's a middle, there's a line and four pixels line that shows the color code for your, the current object. I already had some complaints about that because you had the colors and accessibility about that

and the people that are color blind could be a problem. However, out there did some variations of the current but that variations imply to set some, to place some things in the, outside the CMS UI elements,

sorry, elements like the toolbar or the sidebar and then place the status of the object in the, along with the theme and the proper content. This is something that we should also continue to work on

and to iterate and we, yeah. It's nothing that is set in stone as anything in Volto and we can, yeah, yeah. As I said, iterate over it and see what's the better approach for it and yeah. Perfect. All right, so next up, on third-party products,

how do you plan to keep the backend part in sync with the Volto frontend part? Yeah, that's a good question. You don't? So, I mean, what we could do is create a Python package

which includes the MPM package as well and have some fancy including everywhere but it will be a mess. I mean, we made that mistake over and over and we're just managing JavaScript resources and CSS resources in Plone. And I mean, that's just not gonna work.

So, I think the good thing about Volto is that we actually, what we're saying is, let's do Python in the backend and we're using PyPy, Python package management in the backend and we're using JavaScript, CSS, JARN, all the package managements in the frontend

and we use it for the frontend. So, let's keep them separate. So, actually, you use the tools where they're meant for and not try to make yet another problem with combining them. Yeah, to keep them in sync,

I mean, depends on how many products you have but if you have a huge site with a lot of Adam products, maybe it is some work to keep them in sync. On the other hand, I think there will probably be a lot of add-ons which are only in the backend or only in the frontend. So, I don't think there will be that many products

which have both backend and a frontend component and if they do, yeah, it's not, I don't think it's that hard to keep both lists in there. So, it's manual job and it's intentionally manual job. Anything to add?

Nope, whose question was it? Yep, question answered, yeah, yeah.

So, right now we have on one package the view part, the backend, some site setup tools, whatnot. So, usually when you update to a new version product, you kind of do the whole thing in the same place

and you go to the new version and when we start seeing all these third-party products appearing in this new environment, it could happen that you upgrade the backend side and then you need to be sure that the version

on the frontend is gonna be compatible and it's gonna keep working. Yep, that's true. No, definitely, I mean, it's something which you indeed have to look into because it could be that, I mean, the only thing which is, which is required is that the API will more or less

either be the same or at least be compatible with the frontend and backend. So, it also depends if you create an add-on package, if you make the frontend really specific to certain backend calls or if you make it more robust so it could actually maybe handle the current version but also some version in between or an older version.

And I mean, I don't think that, usually the API doesn't change that much and if it doesn't, it's probably like a major version in which you'll probably know that something needs to be changed. But yeah, it's something which you maybe have to do with trial and error to fix it indeed, yeah.

I can maybe add something from first-hand experience because we created two add-on products already, like kit-concept-0, where you have a backend part where you add behavior for meta-description, meta-title and those kind of things, right? And then like a frontend part and we thought

about creating hooks on the frontend and stuff but since it's relatively easy to just overwrite a few files we left it like it is, it's something that we definitely want to look in but it's like, you can write those add-on products and the second example is collective sola, right? And the right level of abstraction most of the time is the REST API, right?

I mean, this is what we did for Plone Core, right? REST API makes a lot of sense to have the backend separate from the frontend because think about sola, right? You have an endpoint that returns everything and the sola structure but then it depends on the frontend that you're building, right? Maybe you are using Volto but maybe you are using

something else on the frontend like Vue or something. So you want the backend part but you don't necessarily want the frontend part, right? And we don't want to prevent anybody to use Vue or Angular or whatever, right? We're like, use whatever you want, right? This is why we have the REST API. This is the flexibility that the REST API gives us

and the same is true for like the other way around. Maybe you create like a frontend package like for another backend. Maybe you want to use Elasticsearch, right? And there are tons of like awesome libraries specifically for Elasticsearch and for sola, right? That gives you widgets for like everything, right? I mean, just like Google for that and it's like awesome what you have, right?

And if we would enforce our choices to everybody, right? By like binding those two together, we would lose a lot of flexibility and also make it hard for people to move on because this is like what I did before in Collective Sola, right? I started to add like different frontends for different Plone versions.

So I had like views for Plone 4, views for Plone 5, classic Plone views, React views and everything and then suddenly you add like 10 different versions in your like package, right? And that's just a mess. And we have the REST API and that's the right level of abstraction and we should use that right level of abstraction, right?

On this, yesterday, I believe it was you, Phillip, that mentioned about having something like at runtime saying go to like a shop of third-party products and doing it this way will make us go farther

away from that idea because if I understand correctly, if you have let's say four different add-ons on Volto, you need to create a Volto app that depends on all those packages and Volto and compile it and serve it, right?

So that idea gets farther away, right? That's true but that's like by purpose because like the bundling process is really important to like keep the bundle small and allow Webpack

to do things like tree shaking and stuff, right? So I think it's like almost like nuts to like ship a modern like JavaScript application and not bundle, right? And the other option that we have is like to create something like resource registries, right? I mean, what we did there, right? Let the bundle run like on your browser

with like NPM or whatever with arbitrary packages and who here wants that? So that's not going to happen. We don't want it and we won't do it, right? Then again, remember that we are talking about a lower level on add-on packages, for example.

We are talking, remember that we bash everything regarding UI out of the add-on. So the add-on is, as I said in my talk, it's only content types during setup, serializers and the serializers and maybe some endpoint, right, that you need.

And it's contract, it's API. So it's not going to change that that often, I'll say. And still, it happens also when you are working with Plone right now. You pull an add-on and then you do the customization over that add-on. Maybe with Jbot, you're customizing templating, right?

So you don't have to do that because you do it in the portal part. And you also, the process spares you to do that also. So basically, it's going to be also not that difficult

to do and it's not going to change that often, I think. I guess we have to know when people start using Volta more in production websites and if more add-ons will show up and see where we go from there, yeah. I can also add, I have some firsthand experience regarding this shop idea because we built for a client

a large application in Angular 2 where they had that idea to offer their clients lots of different enterprise packages all in Angular 2 and they asked us to build a shop-like system so you can go to that and say I want this app,

I want that app, right? And then dynamically it works, right? But the thing is then you can't bundle that and you have to create different bundles and stuff. That's incredibly, incredibly complex and it's like impossible almost to have that app then in a performant way, right? So you will totally screw it up. So it's definitely nothing that I would recommend.

I mean we did that, it's doable, but I would never do that for Plone. That would be like a horrible thing to do. All right. Well there's already last question at least on the paper. We couldn't read it though. It says description field in, and then there's a word

and it could be Paris but description field in Paris doesn't sound like a real question to me but do we know whose question it was? Yeah. Yeah, so indeed.

So Voto, there's basically two ways of editing in Voto. I mean as we're used to in the Plone world, we always need to have at least two ways of doing the same. But no, I'm just kidding. But it's, so we have the visual editing part where all the blocks are and you can still edit

with a normal form. So if you just add just a news item or just, I don't know, like an image or a file, that will just render a form and it will still have the description and it will still have the title, et cetera, et cetera. In Voto, in the visual editor basically

where we have blocks, the description is not by default in the interface. What you want to do with the description is I guess you could specify it specifically for that page or auto-generate it based on the content

and I think the last option would make more sense because I guess in most pages, people don't fill in the description because it's just, yeah, just an extra filter will just go to the content. But yeah, that's something which you can also fix in your view. So you can actually in your view or maybe in the REST API, you can probably also do it

to check if the description is empty and then show and then return like a summary or the first paragraph of your RIX text, for example. Does that answer your question? Yeah, perfect. So do we have any other question?

Oh, you wanted to go in this one? I just wanted to add that you can bring it back. It didn't went anywhere. It was only not in the default content. But it's also not in the tile chooser because we choose to do that. But you can bring it back. It's configuration if you need it. The reason why we removed it in the first place

was because we had a hard to solve UX problem, right? Because if you create a new page, you have the title and then you have the description, right? And then you enter the title, you hit return and then what do you do? I mean, do you create a text tile or do you move to the description tile and then next time that's kind of like magic

that one time when you hit return, you move to the next block that is there, the description block or you create a new one, right? And that was really hard to solve that problem or where does the description field then has to be, right? Does it have to be on the top always and it's fixed?

Is it required or can we move it around? And then we need to do something that is done in Mosaic, right? Like connect a field with a tile, right? And that introduced lots of complexity and the feedback that we got from our clients

was that the description is some kind of metadata and what worked really well for us was like, as Rob described, right? To separate the two and tell the clients, so this field is for the overview pages and put whatever you want on the page itself. That was something that clients asked us a lot for

and I think it makes a lot of sense as a default but it's open for debate. All right, anyone else have any questions? Oh, lots of them, good. Okay, now that you're all due to, I want to repeat the question from the previous talk

that was now that TypeScript, seems that TypeScript has won the JavaScript language wars. So have you had any thought about that, supporting that in the future? Yes, so I think there was a question on my talk as well, indeed.

So what happened a lot in Plone is that we actually create new concept of doing the same and which is really good and then we still keep the old way of doing it and that's really bad. And we try to avoid doing the same thing in Volto

so we try to not jump on the bandwagon too soon that we're actually saying, okay, we want to support this new technology and we're gonna deprecate the old one but still be able to support it. I think TypeScript is something which I'm not 100% sure if they won. I mean, I think it definitely looks promising

and a lot of people are using it. There's still also a lot of people who are still, I would say ES6. I mean, there's also still a relatively new technology but a lot of people still use ES6 as well. And I mean, what could be is that ES7 or eight

or whatever they're gonna call the new version might take a lot of concepts from TypeScript like we had with CoffeeScript for example. So CoffeeScript was like a variant which a lot of people really liked and then the ECMAScript standard took a lot of those ideas and now CoffeeScript is I think completely dead.

I'm not sure if anybody uses it anymore but I can imagine something happening the same with TypeScript as well. Maybe not, maybe it could or maybe it doesn't. So, but the short answer is well, if TypeScript is here to stay and maybe in a year or two then it's still there then yes, we probably do switch to TypeScript

but that will probably mean that we're rewriting the whole code base in TypeScript and also updating all the documentation that all the new developers should do it in TypeScript so we don't have like 20 ways of doing the same. I would like to stress a fact.

When I like started to learn like the ZCL, like the new ZCA and stuff when it was introduced, what scared the hell out of me was that you could like register components like both on like a Python level and then on CCML, right? That was long before Grok and everything, right? And then like so you could register a component

on Python level, you could do it on CCML and then we put like two or three other layers on top of that, right? So I think we have five ways of doing that, right? And that was like as like a relative newbie. Actually, I was quite experienced already but like that was like totally confusing me, right?

And we kind of have the same problem with our interns right now, right? With just React. So like 99% of all documentation for React is like ES6, right? So like all the documentation, all like all screencasts that you have like academic courses and everything, it's like without TypeScript, right?

And we kind of already have the problem with like, if you're in the React community, like the hot thing is like is hooks, right? So like from class-based component, they move to function-based component and using hooks, right? And that's already something that in our company for the interns is a hard problem, right?

Explaining them that like if they look around, right? They like, they do what like also experienced developers do like they look at Stack Overflow and stuff, right? And then there's one example with class-based components and another one with hooks, right? And then they're like, okay, what shall I do now, right? And then you have to explain them both, right? And that totally sucks. And imagine when we put then TypeScript

on top of that, right? Then we have like lots of components again. So we had that question last year already. And I really like the, like what we said at the end that when like create React app, which is like the standard starter for React, if they move to TypeScript and like TypeScript is really everywhere,

then we will move to TypeScript, right? But before that, I wouldn't do that. All right, I think there was another question there. Just related to the question before, is there any plan that you can have components

or world to components, so client-side related, but not active? So like we have with the quick installer, so the deployment can provide certain things and the users or the admin users can then enable certain functionalities so that you ship Volto with a richer functionality.

So it's not just what the client we're asking for and you need a developer to have this. Because if you have this, it's fine to separate the things. Use the JavaScript way to install JavaScript packages and Python way to install Python. But then I can imagine that we would have a small link

so that maybe the JavaScript component I activate can go to the backend and say, I want this backend component also to activate so that I can actually store my data. That would be really helpful because we don't need to have the same shop experience,

clicky-boondy like WordPress. We don't want to install the universe by click. But I really like the way how tools like Odoo does. They basically ship with everything. It's like a full build-out with a lot of packages and add-ons. And then you go and say, I want that,

and then you enable it. It's basically enabling functionality. It's not going anywhere and sucking add-ons from the internet. This is really nice. Yeah, I can answer. So, well, just a question, actually. So what would be the use case?

So when looking at like WordPress or something, I can imagine because everybody just installed WordPress and does some stuff with it and it's usually like a smaller site or at least something which is, I guess, easier maintained by just the web editor himself

and using the web editor itself. Just maybe some small hacking in there. But I think most blown websites are not like that. I think most blown website are actually made by companies or consultants who actually know what they're doing. And I think that's mostly,

they know how to set up an instance and to fetch packages from everywhere. So I'm not sure what the use case will be if we do it like that, because that would also mean that you need multiple steps of enabling the add-on. So you actually have to install it and then you also need to, from a UI perspective,

you need to install it. Personally, I don't see that advantage, but that maybe because I don't have that use case. But yeah, I mean, sure, everything can be built. Yeah, but currently I don't see the benefit of having something available like that.

But maybe we should have a beer and talk about your use case later. All right. Did you think about naming convention for add-ons and because at some point you will have, I mean, not to repeat the issue we have now in Plone,

because we have collective, but nobody associate that name with Plone or only we do that. Also, in the future, you two separate add-ons developed by community by add-ons developed by the core team.

I think we already made that mistake. I think we have a Plone organization on NPM and we have a collective organization on NPM. I'm not sure if it's a mistake though, but yeah. Yeah, so I think that's the answer. So we have a Plone organization on NPM that's where you also see the add-plone forward slash

photo package where you want to install them. So all the packages which are within the Plone organization are under the Plone umbrella, so maintained by Plone. And there's a collective organization where people can put collective or their own code in. And you can also, of course, create your own organization

or no organization at all, which most packages are. They don't have a name spacing. Yeah, so we're not forcing it, and you can more or less see where the packages are coming from and who maintains them. Yeah, national question, yeah. At least to keep Volto name in the add-ons name,

or to start with Volto minus add-on minus something. Yeah, I guess. Now I forgot what I was about to say, seriously.

We can do a rap battle in between. Yep. Go ahead. Any other questions? First of all, thank you for your work

in modernizing Plone. And my question is regarding accessibility. Have you checked or evaluated the accessibility of Volto regarding the screen readers and so on? I'm the only one with a mic. So, yes, we did. So I think it was in Tokyo, right?

Or was it at a sprint after? I don't remember. After. After, all right. Oh, you have the mic now, you can answer one. Yeah, actually we put a considerable amount of work into accessibility because we do a lot of government site and university sites and stuff like that. So accessibility is always a requirement, right?

I think we started to discuss it in Tokyo, maybe. And then at the Beethoven Spring, Paul, I, and a few other folks sat together. And Victor already worked on a few things. So we basically set up static code analysis

based on A11YX, which is a static code analysis tool that analyzes the source code and checks for A11Y. Violations, we were able to fix all of them during the sprint, during the Beethoven sprint.

Then I also added Cypress X, which is like, Cypress is like a robot framework, like acceptance testing framework written in JavaScript. And there's an X, so an accessibility check add-on where you actually can go to a page or do some action

and then check if there are any accessibility problems. So we have those tests in place. So we test on two levels already, like the static code analysis and on an acceptance testing level, though that's not enough. So we actually manually check our websites,

our client websites, and we try to merge back everything that we can into Volto. And the Plone Foundation is currently trying to, Paul, am I allowed to say that on stage, like talk about that? I won't tell you.

Paul? Paul's not here. Okay, so there's a possible funding project from the European Union to actually do an accessibility audit for Volto, actually. So we will get an audit. And actually on two of our client projects,

we already got audits or we will get audits, also accessibility audits, right? Because I said it's really important. So it's something that is there. We don't have the official audit or approval, but it's definitely there and it should work, right? And if it doesn't, then let us know. Any other questions?

Oh, we have to stop. Oh, we're already late. Sorry. No more questions. If you still have any other questions later on, you'll know where to find us. All right, thank you.