Thank you for coming, everyone. This session is Meet Up with Plone Community and the Japanese JavaScript Community. This session is not a silent listening session, not a no.

You can raise your hand at any time and ask questions. First of all, we introduce the organizers of this Meet Up. Good evening. I'm Yoshiro Hino. I'm presented today with an introduction to React community.

I'm the CTO of SADI Switch. Nice to meet you. Hello. I'm Kazuhiro Hara. I'm a full-stack web developer. I have helped the front-end of Plone

at the Manabu company since nine years ago. I was coding HTML, CSS, JS for some universities

and public institutions using Plone.

There are special answers. Please introduce yourself. Sure. My name is Eric Breo. I'm a Plone contributor and I've been doing a lot of Python, of course, but now I'm just a front-end developer and I've been using many, many different frameworks, as we all do,

but now I'm using Angular 6. Next, please. Hi. I'm Timo. I'm CEO of KConcept. At KConcept, we used to do a lot of Plone, but in the last five years, we did large projects with Angular 1 or Angular JS, with Angular 2,

and with React on the front-end. Thank you. Hi. I'm Rob. I'm a freelancer at the moment. I've been doing front-end for a long time, 20 years maybe, maybe longer, so I've been doing lots of vanilla JavaScript,

as is what goes back then, and probably did most of all the frameworks which were used up until now, and at the moment, I'm mostly doing React. Hi. I'm Victor. I'm Timo's coworker at KConcept,

and I've been a kind of full-stack developer and, yeah, worked a lot with Plone in the last 15 years, and now I'm moving slowly to front-end as well, and I kind of like it, and, yeah. To the dark side. To the dark side, yeah.

Thank you. And there are speakers of front-end day. Please introduce yourself. My name is Tadashi Koyiwahara.

Mr. Arai, please. I'm Masutaka Arai. Please call me Masa. I usually use Angular and Django. Thanks.

Hello. I'm Rina. I am an IoT engineer. I talk about engineering muscle training interface, IoT muscle training. Thank you.

I'm Tadashi Koyiwahara, freelance long-term developer. I talk about how to enter creative work, about minissary and creative motion, creative vision, motion builder, easy fun.

Thank you. Thank you. Oh, sorry. I'm Bata Ryuki. I'm Hiyukazu Egashira. Please call me Hiro. I talk about today's session, the Immersive Web.

It showed WebXR. I'm now main role is XR engineer. I'm main tool is Unity. Thank you.

Let's try the first question. Please request for everyone. If your question is difficult, let's repeat Google Translate, please.

Very difficult question. Okay. First question is, what is the most popular JavaScript library in Plone development?

Shall I answer the question? Anyone can answer.

I mean, as a Plone community, we always have been really open and friendly or open about the frameworks and what people were trying out. I guess you can say that I heard that people are working with AngularJS at first, Angular 2, React, Vue and Aurelia, I think.

And yeah, Angular 1 is more or less that, right? Nobody's using that as far as I know. Angular 2 is, we have, what? Angular 7, I'm sorry, I'm so sorry. Don't want to be offensive. So Angular 7, we have that great Angular SDK

written by Eric here, which is a great foundation if you build an application on top of Angular 2, right? But it's not like a full CMS from it, but just an SDK, right? So that's what we have in Angular 2.

Then in React, we have Plone React or Volto, which is not an SDK, but it's a full-featured frontend for Plone. And I know that the people from, for Teamworks from Switzerland, they started with an, I think, I'm not sure if it's an SDK or like a frontend,

a full frontend implementation for Vue.js, but I'm not sure if they're actively using it, and those are the projects that I'm aware of. And we have mockup questions. Yeah, where?

Yeah, just to, regarding current Plone, the current version of Plone is not using any of the framework, while a little bit React, but what we have is currently something we name mockup that we made specifically for Plone, and it's not based on such a framework. For now, we are agnostic regarding Plone 5.

Right now, there is no specific solution that have been used widely, so what we have been talking about are just what we are currently using to build the next versions of Plone.

And yeah, you mentioned at lunch that in Japan, Vue.js was the most popular framework, right? Yeah, Vue.js is popular in Japan, but I think React is the most popular according to the sessions of the Plone Conference 2018,

and React session is maybe seven sessions about, but Vue.js is no session.

I use React. I love React. Vue.js user... Oh, oh, hey. And Vue... Oh, only two. Yeah, yeah.

Ah, so three. And I said, I mean, there are at least two other people in the Plone community who are using that from Plone teamwork, and I think for teamwork, they built their solution on Vue. They made that decision like a year ago or so. Yeah. They studied it at the lab. Yeah.

But it's like all on different levels, right? As I said before, if you want a full feature framework, a full feature format, then React is the only option right now. If you need an SDK, then Angular 2 is, I guess, a good option. And Vue.js is also a very good choice, right? Yeah, it's a good choice,

but the starting point will be a different one than Angular. So my personal opinion is that, like, React is at first place, not in terms of, like, that it's the best framework, but that's the framework that most Plone developers are currently pushing, and then Angular 2,

and then Vue. That's, like, my feeling, but I could be mistaken, and maybe others have other opinions. So the question here was, is it most popular according to all the talks which are here about React? And Plone is, and has always been,

like, a duocracy, as we call it. So it's actually, if people actually build something using a specific technology because they like it or they have other ideas about why they want to use it, that's what is used. And actually, this year, this is actually the first year, as I know, that there are actually this many React talks,

or I think that's maybe, like, the first year there's any React talk at all. Last year, there were Angular talks, and there are less talks about Angular now because the product is already there, and React is now, there's a lot of talks about it because it's new, and we introduced it here. So that's the reason why there is a lot about

React calls talks, and not that many other ones at the moment. But maybe next year, there's a lot of stuff being done in Vue.js or Angular or Elm or any other framework which pops up in the next year, and then maybe there's no talk about React, and there will be talks about other technologies.

Vue is more popular next year? Maybe. So maybe if somebody will step up in the Plone community and create something with Vue, like for Teamworks, for example,

and then maybe they will build something really awesome, which they will show next year in the Plone conference, and that could be that we're all doing Vue back then, but we'll see. We never know. We didn't plan, or we don't plan this, but we have to say it's growing organically.

I think these questions also still trigger the pillow fight, right? And I really think that it's not about which framework are you using, because the three frameworks that are mentioned here are clearly converging, at least in a way of

how they think that things should be done, and also in several ways, right? I mean, and concepts, and how to do things, right? And it's not about the framework, but what you get,

what is the finally solution that you get to. So it doesn't really matter which framework are you using. It's the final thing that you are producing, and you are using as a solution to do things and to accomplish things at the end.

I have a question for the people who are using Vue.js, so you and you and you. Are you using JavaScript or TypeScript? JavaScript. Yeah? And you? And I have the same question for people doing React,

so I don't know who is doing React here. So is there some people doing React with TypeScript? No, I mean, you are doing? No, no, you're not. Some people are doing it? No? With? Flow, okay, yeah. So I already discussed about it with Timo,

but I would like your opinion. You people are doing Volto. Would you consider moving to TypeScript? Yes or no, and why? Personally, I'm still a bit undecided on that. I come from a Python background, and I had to learn Java in the university,

so I kind of hate strongly typed languages, but TypeScript is a bit different. They have a duck-typing system, right? So I think they got that right, and we did large projects both in Angular 2 with TypeScript and in React, right? And TypeScript has its merits for sure.

If you use TypeScript, then your error reporting is a bit better, but it also gives you a bit less flexibility, and React has things like Flow or PropTypes that go into the same direction, and personally, I'm still undecided. I guess I wouldn't oppose moving to TypeScript

if the majority of developers would want to do that, but I'm definitely not totally pro or con in either way. Yeah. Yeah, so indeed, React has Flow, which is, as far as I know, not that often used.

I mean, it was a thing, like, when it was introduced like two years ago, I guess, or one and a half year ago, people started using it, but it's not as popular as it should be or as the idea was. What you do see is that more people are moving in the React world as well to TypeScript,

but still, the majority is just using JavaScript at the moment. Personally, I like TypeScript, so I think it's definitely a good language, but my main concern at this stage to move photo, for example, to TypeScript is that most of the examples

and most of everything which you actually learn in the React world is still based on JavaScript, so if that's gonna shift towards TypeScript, so more documentation and more training material will be available in TypeScript, then I'm definitely for moving to TypeScript, but at the moment, I'd like to, since it's already quite hard to get more people involved into doing development,

if we introduce more technologies and more changes into them, I'm worried that it's gonna be even harder to get people in. But since there are a lot of people, I mean, in Angular, you have to do TypeScript, so that would mean that more developers will do TypeScript, learn TypeScript anyway, so I guess we can finally, yeah, make it,

maybe rather soon. Yeah, I always, I approach the Angular world first when I was learning front-end development, and for me, it was, I mean,

it still is like a novel, dealing with another layer of abstraction, and it's somehow hard, especially when you're learning something new. When I stepped down, stepped down or switched to React, it was like throwing away

one of those layers of abstraction, and it was easy for me to understand and get into the modern front-end world, and it's true that all the goodies that TypeScript gives you are definitely okay, but again, I think for maybe, yeah,

having or not having this layer of abstraction is still a big deal, and yeah, maybe we get the wrong time into approaching Angular because it was just starting, but yeah, on the other hand, we have to, in React,

we have to do the same same default, right? Like TypeScript does, or like using decorators or not, or using this Vable whatever plugin or not, and then that is something that TypeScript gives you for granted, and it's the only thing that I will say that I could miss right now from TypeScript,

but this is something that you also can solve by giving a developer guideline, right? Like, no, Volto is going to be, this plugin, this plugin, and this plugin, and if you are developing for Volto, you should follow those guidelines.

That'll switch like next month. Oh, okay. Next slide, please. Let's see the next question. Is how important is dynamic UI

or expression for developing websites with Pro? Do you understand this English? Okay. Expression is content.

Which content? How important is rich UI and rich content for... Yeah. Yeah, yeah, yeah, yeah. So yeah, I think I get the question.

So I think we cannot keep CMS the way it was like five years ago or ten years ago because user expects something else. Right now, people get used to dynamic website. They get used to nice UI,

and if you do not deliver that to them, if you just push a form with a basic submit button at the end and then you're going to reload another page, they're going to be disappointed, right? It's not possible to keep on with this kind of approach. So CMS need to face that, and it's a super difficult challenge because CMSs have been built at a time

where we were not involving JavaScript a lot into web pages, into website. It was not... We didn't add this kind of expectation at the time. So their structure is not designed really originally to manage that easily, and that's a nightmare because CMSs are super complex.

It's not just about building one application. It's about building an application which is able to build a website. So it's a kind of meta application, right? And if you want to plug JavaScript in this story, it's a nightmare, and we have been facing that. We made a lot of effort to try to do that,

and I know other CMSs are doing it too, but we have to. There is no choice. We cannot escape that. We are supposed to deliver a nice UI. We need to keep up with the standard, right? So it's a big challenge, and I'm not sure we are addressing it the right way already,

but we are trying, and I guess we are on a good track now, but, yeah, absolutely, it's super important. You can... It's a must-have. I don't know if you have an opinion on that, but I mean, it's... I fully agree with you. Same.

We obviously agree because we are into that, right? But I'm not sure everybody is aware of that because we have been spending all our time developing stuff the whole way, and it was totally valid for such a long time

that it's kind of difficult to switch the mindset, right? And it makes sense, I mean, of course, but we definitely need to face that right now. I just want to add one comment. The reason why we all switched our mindset wasn't that, like, we had that idea or that somebody told us to switch the mindset.

I think the reason for all of us is that we have clients' project and client needs that we only could fulfill by switching that mindset, right? Because all the projects that we are doing usually include multiple backend systems these days, and you need to build a frontend for multiple backend systems,

and then you can't say the CMS is dominating all the other use cases because that's not the case any longer. Web projects became more complex than they were maybe five or ten years ago. So that was the driving force behind that. I do have a question connecting with that.

One of the things I have seen in the very beginning of my participation in the Plon community was this statement from John Kelly that one of the most important things

is to give a rapid turnaround on user interface development so that you're actually working on making the interface better, getting a better user experience for the customers, for the consumers.

And I guess my thought is that doing all the frontend work we're now doing is exactly to getting that rapid turnaround back into the community and making the old vision important again

so that it's all about empowering the users with a simplified, good user interface. So I would like, not only from the Plon community, but also from the Japanese frontend community to know how much they feel

that the JavaScript environment enabled them to deliver very quickly and very continuously a better design, a better user interface, and a user experience.

Can I answer that? Yeah, sure. So yeah, short question, absolutely yes. I think in Plon 5 we have two problems, or we have two problems in Plon. One problem is a technology problem

that we weren't able to introduce the latest UI libraries that are out there into our stack because our JavaScript stack is outdated. That was one problem. The second problem is that since Limi left, we didn't have that UX dictator, right? And I think that's essential for a good UX, right?

That there's somebody who has a background in usability and a strong opinion on how things are supposed to work because if you let like 300 developers do whatever they want, you will never end up with a good UX, right? And I think we're doing the step

in the right direction for both. So with Volto, we have like, or with Angular SDK as well, or with Vue, we have the new libraries at our fingertips, but that's not sufficient because if you just integrate them, it's like you have a better UX,

but it's not like what we're aiming for, but we also have Albert in the community luckily for us, and we're iterating over every version that we are pushing, and we're trying really hard to get a better user experience, and then we have both in my opinion, better technology and a better user experience,

but that's really hard to get where Plon used to be, I think, in 2018, and not like look back what Plon was in like 2000 or something, but I think we have a good chance to get to that point again. I mean, you mentioned,

you asked if there is a way to do that easily. No, I mean, we need to be aware that it's going to be difficult, it's going to be expensive. Why? Because we are building something different. We are not trying to build Plon the way it was because it's not good enough anymore. As I said, we cannot help having a better UI.

A better UI means it's dynamic. It's dynamic. It means more features, more stuff to do, so you might doing it in Python, Haskell, or JavaScript. At the end, it's going to be expensive because you are doing more stuff, so it's going to be difficult, and it's going to be some pain. Let's be honest about it.

It's not for free, that's for sure, but we need to do that, so we keep on the right track because everybody's doing it, so basically, we're not doing web the way we are doing web 10 years ago, so that's it. I totally agree with you, so it's the question, does it give you all really a fantastic speed-up

and a better... I always remember Timo saying, it's making fun again writing the front-end stuff, and that's what I want to hear also from the Japanese community. Are they really...

Does it make fun working with the stuff for you?

Your question to the Japanese front-end engineer is to ask that you guys are enjoying the creating the JavaScript or our content?

How? In my opinion, I like to learn new styles

and new technologies, and in my company, I'm creating a sound platform to learn Python through the web, so our team needs to create content to learn nice images or training, and we need to create a new user interface and so on,

but our team just wants to create some new and some valuable things for the customers, so that even creating content or even learning new technologies and writing code, even any kind of thing, it's a tough world,

but we can enjoy it and continue creating. Use the mic.

So that's it. I think that the content technology is the most important thing and that's why I wanted to introduce you to the Japanese front-end engineer.

Thank you very much. Japanese source.

English. Okay, my presentation. So, I don't like.

I'm too bad. So, I like JavaScript. And I like make motion and creative logic, creative, so calling.

I like creative motion. So, animation. I don't know. I don't know what I'm talking about. Micro interaction.

Micro interaction. So, I don't like this. I don't like this. I don't know. So, it's fun when you done it.

You like to create something and you like to make it done. Okay. Is it okay? If I can say something about it, I saw your talks this morning. I saw yours. Most all of you stated that the stack,

the stack to make JavaScript right now is terrible and super difficult. I mean everybody agrees on that. You need to know Webpack and NPM and a lot of dependency and you need to manage that and migrate every time because there isn't an update. So, you all said so.

And you found some strategy to avoid the difficulties because everybody want to have fun at work. Of course, we don't want to suffer. And first, I remember you. You said, okay, my choice is Angular because it's easy. Everything is in there. You have all the dependency internal and you start with the CLI and everything going to be great for me.

So, that's your solution. Your solution was to use Adobe and export from there using a plugin and that's nice too. So, depending on the use case, of course, the tooling might be different but there is some way to achieve that. And I am facing the same thing. And in my talk, I was explaining that I've been rebuilding some elements

that I used to have in the Python stack. I mean, the prone stack, like Mr. Developer, for instance. I was missing that very badly. So, I created a new Mr. Developer in Node.js so I can use it in NPM project, right? So, we all developed some strategies because right now, the stack is terrible.

And the tooling is terrible. And we need, as a community, the JavaScript community, need to improve the tooling, need to improve the practices. And we, prone people, have a great knowledge about how to do that. So, we can bring that to this community as well. But this is a work we have to do and it's not done yet, basically, right?

My answer is JavaScript engineers get bored easy. Really? So, in my opinion,

yes, sometimes we feel like that so that technology in JavaScript will change so quickly so that everybody is focusing on, yeah, it's Angular. Next time, it's React something. I think we shouldn't listen too much so that if you think that

I really like the structure of React. So, you can use React or even you can use EmberJS today. I have used the VueJS for a long time and before using VueJS, I used the KnockoutJS. Do you know that?

Yeah, KnockoutJS. KnockoutJS. It's a little bit old, all the stuff, but it has the same MVVM structure and I do love the MVVM and I already using the MVVM framework for a long time. So, in my case, I didn't change anything in JavaScript

a community or environment. So, I think that may somebody feel like a JavaScript engineer get bored easily, but you shouldn't. It's okay. You don't need to follow them. You can do what you believe. So, for example, if you like React,

you can use React. That is my answer. Thank you. I ran JavaScript last year, but now I'm running RizML. Do you know RizML? RizML is direct of

OCaml built by Facebook. Messenger was built RizML, Facebook Messenger. Can I say a word? No?

Okay. So, I agree that if you go to a JavaScript conference, there are always new things that people talk about and it's easy to get the feeling that it's moving really fast and that you have so many choices, right?

But you have to differentiate between what happens at the conference and what people talk about and what companies are using or projects like Plone in the real world, right? And it takes some time for a framework to get a certain degree of adoption. And I think that my personal feeling is that

what's called this JavaScript fatigue, right, is a bit over because we have like three stable and major frameworks with Angular, React and Vue, right? And I think all three are valid choices that companies could go with, right?

So yeah, I think those are really two different things and it's a good thing that the JavaScript community is so agile that so many new things happen that there are so many like, that was something that appealed to me very much in the JavaScript community that people are just like toying around with stuff, right? They're just doing that because they can, not because they have a use

case. And that's a great thing because we all enjoy what we're doing and it's great to just have a pet project and work on that and present that, right? But it's a different thing if you have a pet project and you toy around with it or if you use that in real world projects, right? And I think it makes sense to just like separate those two and keep that in mind.

Time is over. Sorry. This session is over.

Thank you. Thank you for but we have another question but next time. Next time. Thank you.