React in Drupal Core?

Podcast episode player
0:00 0:00

Matt and Mike talk with Drupal core committter Lauri Eskola, Drupal JavaScript maintainers Théodore Biadala, and Matthew Grill, and Lullabot's own Senior Technical Architect Sally Young about adopting a front-end JavaScript framework, specifically React into Drupal core.

Episode Guests

Lauri Eskola

Thumbnail

Co-Maintainer of the Theme API, Drupal core committer, and frontend framework manager, Lauri is an engineer in the Drupal Acceleration Team at Acquia.

Théodore Biadala

Thumbnail
Senior Performance Engineer at Tag1 Consulting, and JavaScript maintainer for both Drupal 7 and Drupal 8.

Matthew Grill

Thumbnail
Senior JavaScript Engineer at the Office of the CTO in Acquia and a JavaScript Maintainer for Drupal 8.

Sally Young

A smiling woman with long dark hair and dark glasses, wearing a white top.

Senior Technical Architect working across the full-stack and specialising in decoupled architectures. Core JavaScript maintainer for Drupal, as well as leading the JavaScript Modernization Initiative.

More about Sally
Transcript

Transcript

Matt Kleve:
For October 19th, 2017, it's the Lullabot Podcast. Everybody, it's the Lullabot Podcast episode 219. I'm Matt Kleve, the Senior Developer of Lullabot. Here with me, as always, co-host of this show, Senior Front End Developer Mike Herchel. Hey Mike.
Mike Herchel:
Hey, how are you doing?
Matt Kleve:
Hey, you know, I'm doing pretty decent. This is something like the more things change, the more they stay the same or something like that.
Mike Herchel:
It seems like we've had this discussion before.
Matt Kleve:
We've been there before. But you know what? It's okay because I think we'll get it figured out, it's going to be great. What are we talking about? We've been so cryptic.
Mike Herchel:
Yeah, we're talking about React, JS, and Drupal ...
Matt Kleve:
We're going to put a front end framework in core?
Mike Herchel:
I know, I know. It's kind of scary.
Matt Kleve:
Well, we've got the people on that have been figuring things out and making it work and we're going to learn all about the drive or the movement, or you know, the folks behind the idea that maybe we should put something like React in Drupal core.
Mike Herchel:
Yep. Absolutely. First up we have Lauri Eskola, he is a co-maintainer of the theme ATI and provisional Drupal A core committer and a front end manager. Lauri, with three guys at the end have drupal.org and he lives ... he comes to us from Bangkok Thailand. Welcome.
Lauri Eskola:
Thanks for having me.
Matt Kleve:
Thanks for being on dude, that's great, and also no stranger to the podcast, we have with us a Senior Performance Engineer Tag One, he's a JavaScript maintainer for both Drupal 7 and Drupal 8. He got rid of the overlay module in core, which sounds like something to be known for to me, he's known as Nod on drupal.org. He's joining us from France, we have Theodore Biadal. Hey Nod.
Theodore B:
Thanks for having me.
Matt Kleve:
Next up we have a senior JavaScript engineer at the office of the CTO in Acquia, Doctor Paul on drupal.org for about six years, is also a JavaScript maintainer for Drupal A, all the way from San Diego, California, welcome Matthew Grill.
Matthew Grill:
Hi, thanks for having me.
Matt Kleve:
I'm glad you're here. Also no stranger to the podcast, we have senior technical architect at Lullabot, she's an expert with both JavaScript and Drupal, she's the person I go to for all my JavaScript questions, I'm told she's a pine cone aficionado, she's known as justafish on drupal.org where she's been for almost 10 years, but now we know that she actually hates swimming. Hey it's Sally Young, hey Sally.
Sally Young:
Hi, thanks for having me, and thank you for telling everyone about my pine cone fear as a child.
Mike Herchel:
If anyone has pine cones you can bring them to BADcamp, you said you were coming to BADcamp.
Sally Young:
Yeah, I'm coming to BADcamp
Matt Kleve:
So, let's jump in, so Sally what's it been, has it been a year or so since we had you and I think Matt, was Matt on the podcast, and Preston or something like that, we talked about the folks who wanted to put a front end framework in core, and I think the idea has evolved since then, yeah?
Sally Young:
The issue was open two years ago, so we were like half way through the process ...
Matt Kleve:
It's been a while yeah, okay.
Sally Young:
When we had that last podcast, so yeah we had that issue going for about two years, and we decided maybe we should pick something so that we could focus on all the other hard problems, so we picked something and here we are.
Mike Herchel:
Okay, so ...
Matt Kleve:
So, if you don't mind just giving us the short highlights, why was this necessary, I know there were a bunch of people with pitchforks like, "Don't do that, that's dumb!" In a brief sentence, why do we actually want to put a front end framework in Drupal core?
Sally Young:
We want to create some better UIs for the admin interface. Views, for example, has a lot of stuff when you click around, lots of interactions, I don't know if you remember the User one, but ...
Matt Kleve:
I was a fan.
Sally Young:
Yeah, but every time you change something, the whole page would refresh, we don't have that now, but there's still a lot of complex JavaScript interactions that happen there, and it would be nice if we could write that in an easier way, and maybe in a way that the rest of the world is used to, maybe they could be able to jump in a little bit quicker than trying to learn custom JavaScript stuff.
Matt Kleve:
So, people actually use Drupal not only on building UIs, but people use these UIs, and we ought to make really good user experiences for them?
Sally Young:
Yeah, that's the hope.
Lauri Eskola:
So, it's been building these kind of modern style UIs in the Drupal core, such as the setting stray, which is a good example of something where we could really benefit off having these more modern tools, and just because if we don't have the tools that people mostly use for building that kind of UIs, it makes things very, very complicated, and it has been I guess nice for many people to experiment that, but I think we've got enough of that, and we've seen that, that's not the path that we would like to take, and we could really benefit off having these better tools. So, we've actually during these two years we've tried different kind of approaches to avoid adding a JavaScript framework in the core.
Mike Herchel:
Another JavaScript framework.
Matt Kleve:
Yeah another JavaScript framework is probably fair, because ...
Mike Herchel:
Backbone.
Matt Kleve:
Yeah, well okay yeah.
Mike Herchel:
The stuff that's in there where we already have Backbone, and we have some interfaces built using Backbone, but I don't know anybody that is wanting to build another interface in Backbone, if you are, good luck.
Matt Kleve:
So, do you think Backbone's going to be inked out?
Mike Herchel:
I don't want to commit to saying that it's going to be inked out, but I think that if the framework discussion moves forward and we do come to some agreement, then I think the new interfaces should be built with this new framework, and not with Backbone.
Matt Kleve:
Okay, so this was discussed recently in DrupalCon Vienna, and the decision was made to concentrate on React, can someone walk us through that discussion?
Lauri Eskola:
So, we had a discussion with a bunch of people who have been active in the Drupal core JavaScript, and what we discussed in that meeting was we first tried to find a consensus if it was a good time for us to choose a JavaScrip framework that we would like to build these ne UIs on, and we managed to find a consensus that it is a good idea for us to choose this Javascript framework at this point.
Then we proceeded the conversation to a specific framework, and we had multiple different frameworks that people proposed as their framework of choice, and the frameworks that were brought up were React, obviously, and besides that and Elm, as far as I remember there was no other frameworks that we would have discussed in that meeting, and almost everyone brought up React as at least one of their options, so it was the easiest to start building consensus on, and we managed to build the consensus that it would be a good idea to start figuring out if there's some unknowns in implementing, or using React in Drupal core, and that's why we opened up the issue in drupal.org based on that conversation.
Mike Herchel:
I think the smartest thing you did in that issue is you time boxed it to a certain amount, because that's the type of thing that could just go on forever.
Lauri Eskola:
Yeah, that's something that we specifically wanted to do, we want to give the community a chance to give feedback, it's actually very valuable to get the feedback from the community, because there's a lot of expertise in the community, so we definitely do want to get the feedback from there, even though we thought that React would be the best choice. The feedback has been very good, but it's very useful to have to time box, because we could already see that it was going in circles, the discussion, so having the time box that forces us to make some kind of a decision. It would run for a long time.
Mike Herchel:
So, it sounds like the choice on if we're going to add a framework to core was already made, is that correct?
Sally Young:
No, I wouldn't say that, that was correct, the whole idea of this was to be an experiment to see if we can do all these things that we've supposed that bringing a front end framework into core will do for us, and if it doesn't work out, then we've improved our internal APIs, and that's great, and we'll think of something else, but yeah it's definitely not set it stone.
Matt Kleve:
Okay, and the choice of React, to me it sounds like that was made to eliminate the bike shedding a little bit, is that choice final? I've seen some other issues being opened up with View JS and web components.
Lauri Eskola:
The decision, in a sense isn't final, because we are only proposing that we only React on our research and the team that we have are mostly working on Drupal JavaScript, committed or researching using React. I think that is pretty much final unless something very serious would come up, and we would figure out if we have to rethink our choice or not, but the team currently is most committed working on React. So, in a way the decision is something that we don't want to change, but if something comes up then we definitely will change that, and we are definitely still open for the other framework issues, doing research on other possible solutions, or ways to solve the same problem, but the Drupal core, JavaScript team isn't committed for researching those.
So, if the community comes up with resources, we build those frameworks, I think it's better for everyone, because we will get the feedback based on multiple different point of views, so we have more talks that we can base our decision on when we make the final decision. So, just to sum up, it hasn't been decided that React, or any framework will be added into Drupal core, in sense, but it has been decided that we will research some JavaScript framework, and the team is currently committed to research React specifically.
Matt Kleve:
This is not actually an honest to goodness initiative, or is it? But, it does have a lot of momentum from Dreece right, because Dreece was the one who initially blogged about it and said, "Let's do this damn thing," right?
Lauri Eskola:
It is an official initiative now, so it's proposed now as such, try to take initiative for Drupal core in this keynote in Vienna, so since then it has been official initiative.
Matt Kleve:
Outstanding, cool.
Mike Herchel:
So, when we're talking about React, are we also talking about Redux, and JSX, and maybe Webpack and everything that comes with that?
Sally Young:
Possibly, JSX probably, because most people use it when they use React, and so it's very familiar. As for the other libraries we did discuss it a little bit, but I don't feel that we're quite at the stage to be thinking about all of that yet. We have huge problems to face us yet rather than, which JavaScript state management system should we use.
Mike Herchel:
So what are those next problems that you're working on?
Matt Kleve:
Can we ask that question in a second, I've got one that I think we need to clarify first, can somebody give the 30 second sales pitch to somebody who's not a React fan that says, "This is why this is a good solution"?
Sally Young:
can try. Okay, so React is extremely popular amongst the JavaScript development community, it has a huge community of developers and contributors around it, there's huge numbers of libraries available that plug into it, like Redux, which you mentioned. There's tons of learning resources out there, conferences, lots of excitement, lots of job openings we found as well, it was one of the things we looked at, what are people excited, and getting into, and what are people hiring for?
Matt Kleve:
So, as a framework it's popular, and it has a lot of momentum behind it?
Sally Young:
Yeah, it renders stuff into the dom, there's other good frameworks, which do that too, but the community around it as well is very important, and the support for it is important. I really like it on a technical level, because I like the way its life cycle events work, it's actually not too hard to pick up, because it doesn't do a ton of stuff, if you look at something like Angular for example, it's very opinionated, which is good, you have to build your app in a certain way with tons of stuff, whereas React is like a small library that just does one thing. React 16 came out recently and it's very, very fast and very small, so that's all quite exciting.
Matt Kleve:
So, I have not mentioned this, I am not up to date I admit it, but weren't there some licensing issues that blew up in the last month or so?
Matthew Grill:
There were. Were being the operative word there.
Matt Kleve:
So, we're all good there.
Matthew Grill:
React 16 was released and relicensed under MIT, not the BSD patent clause thing that Facebook had released.
Matt Kleve:
Which MIT code can't go in the Drupal repost, so it'll have to be pulled in with composer or something like that? Not composer ...
Mike Herchel:
No, I don't think that's true, I think there are MIT libraries.
Matthew Grill:
I think it can be included.
Matt Kleve:
Oh, see I told you I'm not up to date, cool.
Lauri Eskola:
MIT is one of the licenses that is actually compatible like Drupal's license.
Matt Kleve:
There we go, cool.
Mike Herchel:
Great, yeah that's good to know.
Matt Kleve:
What's the timeframe to work on this, and to maybe get this into course, that's the decision that gets made, and what are the next steps to work on?
Theodore B:
So, as far as steps are going, there was back ... It's been a while, but there's been a document explain the process of big UX changes, and so right now we are just at the prototype phase. So, I don't know, maybe you need to ask Matt on when the prototype is going to be ready, but soon after that, we need to come up with a plan, because it all depends on if we can fix the issues of accessibility and teaming and that kind of things, and once those issues are solved we can have a proper plan to extend the pages that we want to make in React, or pictures that we want to have in React. So, I don't have any date, I don't think anyone has any date to give, but that's at least the process we go through I think?
Matt Kleve:
That's accurate, I started work on a React prototype already of the example that we proposed, which was the DB log page, and that's coming along nice, but one of the main issues it's always been is the main APIs, the HD APIs to support building these kind of interfaces, and right now it's based on a modified Views rest export, but there's some challenges around that, so that'll take some more time I think. That's going to be the hardest part, not the building these components in React. So, if we can get that resolved.
Sally Young:
I did laugh this morning, because DB log module seems to have become the most talked about module in all of Drupal.
Matt Kleve:
Exactly.
Sally Young:
There's been implementations in View, and I think someone started a web components one, and Daniel Rainer made a blog post about a web socket integration he added for it, and then I was talking to Christina this morning, she was like, "Oh yeah the DB log module came up on the UX core today," it's like wow, people are really interested in DB log all of a sudden.
Matt Kleve:
That's one of those modules that hasn't been touched much since logging got extracted out into whatever you wanted it to be.
Sally Young:
Right, and that was the point of teasing it, because it was so simple, and the interface for it, is really simple, so we didn't want to worry about trying to do something really complex for our first go at it.
Mike Herchel:
So, I see something in the issue to choose a front end framework and it says, "We want to have sufficient real use experience to make a final decision prior to 8.6.0's development period," which starts in 2018, so my understanding is that we're trying to have these demos up and these real world examples done by the end of the year so we can maybe figure out if there's any blockers?
Lauri Eskola:
Yeah, I think we want to get the demos done well before that, so we have time to make the decision, time to get some feedback on that, and so I would say we probably would like to have these demos up around November-ish time. So, I think the demoing period shouldn't be too long, and we should then, once we've actually gained some experience moved to that actual building stuff phase.
Mike Herchel:
Okay, are we going to be using React for backend UIs like Views, or is this going to eventually be used in a toolbar, and the quick edit module, and the setting strain, stuff like that?
Matthew Grill:
They could, but those are very hard things to implement and do, so let's start cautiously small.
Mike Herchel:
One of the questions I had down the road is that React seems to be moving very quickly, if we put a version of React in Drupal core, and it's included when you're logged in as admin for the settings tray and toolbar and stuff like that, is the front end going to be stuck using that same version of React, or could that be ... Is it possible to run two versions of React, or how exactly would that work?
Sally Young:
That's a really good question.
Matthew Grill:
We don't know.
Sally Young:
Yeah we don't know. I would say I personally would prefer the admin theme to be decoupled from the front end themes, so that we're not injecting React into whatever you want to build in your front end.
Mike Herchel:
Yeah that's a good point.
Lauri Eskola:
We are trying to avoid messing up with the team experience of the front end teams. In
any way our priority is to make things over there at this point, but what we are experimenting is UIs that are for the administrators, or content owners. I think the mentioned UIs, such as the quick edit toolbar, might be something that we consider at some point to built using this, since they are using Backbone, but yeah like Matt said they are definitely not that high on the list, just because of the complexity of those components.
Matt Kleve:
But, if it's in core, somebody could build whatever they want with it. There's a benefit to that, I think we saw that with jQuery, we've got jQuery in core, "Look I need to do something with JavaScript, hey look I already have jQuery I might as well use it," I think the same thing could be held with React.
Sally Young:
Yeah maybe, I mean JavaScript APIs for doing the stuff we did with jQuery have caught up to that now, so that might not be necessary, but we also ...
Matt Kleve:
That was just my old example, that we had jQuery so we might as well use it, now we have React, we might as well use it, when we're doing something.
Sally Young:
Sure, we did see a lot of problems with that though, hence jQuery update module.
Matt Kleve:
Hey you beat me to it, yeah.
Sally Young:
Yeah, so we'd have to think that through very carefully.
Matt Kleve:
So, we need a react update module.
Sally Young:
Oh goodness.
Lauri Eskola:
If React is actually going to be part of the core itself, or if it's going to be part of some kind of administrative team, so that it couldn't be of any use outside of the administrative teams, and that has been the path that we have already taken on the Drupal, we have already seven, and teams both internal, they are part of the product, but we don't suggest anyone to implement anything based on those two teams.
Just because of the architecture of Drupal, people could still sub team, seven team if they want, but with React, because we are building something new, we could even prevent people from using the React that we have in Drupal core for their own purposes, because I think that is something we are not trying to tackle, and I don't think we are trying to encourage more people to use React on their front end teaming, whatever they are do, but instead we are just finding a solution that we can use for building these administrative UIs.
Sally Young:
Yeah, and the challenge there is you don't necessarily want themes to use react components by hooking into what we've done in the admin team, but we probably want modules to be able to provide some way of doing something in the admin team probably, but then we get into these questions of how opinionated can the admin theme be now? Is it going to be like Calypso in WordPress where that's the admin theme, you can't really theme it too much, or how much flexibility are we going to be able to provide if we go down this route?
Mike Herchel:
Yeah, and installing new admin themes, how exactly is that going to work?
Sally Young:
Yes, good questions we need answers to. There's one thing some people have been thinking about is it's a Mozilla project, which lets you have a sort of form API type thing, but spits out React component, so that might be one solution to what we do there, and you could provide your form in PHP and it will convert it if you want, because we don't necessarily want to force module authors to learn React in order to build their great things for admin in Drupal, but maybe you could override it with the React, something like that. Anyway, that's all ...
Mike Herchel:
What was the project that you said that can automatically create React components, you said it was Mozilla or something?
Sally Young:
Matt, do you ...
Matthew Grill:
It's like Mozilla React JSON scheme of forms. Yeah if you Google those words, it will be the first thing that comes up.
Mike Herchel:
Okay. Let's see if I can spell all of that. So, let's talk about challenges of React. I know React has a faster release cycle, and what else are we anticipating that could potentially screw us over in the long run? Is there anything else that we're worried about, or that might be difficult?
Lauri Eskola:
Well, the react maintainers and the React community has slightly different viewpoints on how to develop these type of applications, or I don't even know if they've considered these kind of applications, probably not, because we are kind of a niche use case, but they come with the different kind of viewpoint, and they want to restrict different kind of things from happening. Let's say, if you explain to them about our form alters, or about our pre process functions, they would probably be scared about what we are talking about, because they don't like that kind of thing, and mixing that kind of culture, with the way of how Drupal is used to doing things, can be tricky for us, but I think there's also a lot of things we can learn, because if we can remove some of those layers, we can potentially simplify the architecture by a lot, which can help us build things faster.
Sally Young:
You'd be surprised with stuff like that though, I was talking to Nate Haug, Quicksketch, at Vienna, and he's been working on a project with me actually that's Node, and we use Redux, and just figuring that out, and at Vienna he was like, "I've been trying to map over things from this React application over to Drupalisms," and he was like, "So, Redux, reduces are just like Hooks," and I was like, "Yeah actually, now that you say that, they are exactly the same as Hooks more or less." So, I don't think we're too different.
Lauri Eskola:
Yeah, there's some differences on what you can do, and what you can not do, and yeah, so obviously there is similar kind of patterns, but I've found that if you compare two of these things, I've found it more restrictive, how React works, or how Redux works, because of the way it.
Sally Young:
It just does less, it's a UI renderer it's not a CMS, so it's not going to, if you're trying all the things that we're doing.
Lauri Eskola:
Yeah, but let's say if we discuss about the React components, it's going to be confusing for the developers that you can modify our props, because they are immutable, and in Drupal we don't have anything that is immutable, so it can be something very new for people, and then we would have to teach them about the state, and what is the difference between two of these concepts, and because at work I've been teaching many people how to build things using React, I've seen how frustrating it can be, and I think I was mentoring one person using VI, and what he was doing, building the application he was pre processing the data that was coming for a component, so that he was setting it into a state, and it was very difficult to ... I was figuring out how could we make it work in the right way.
It was difficult to go away from that mindset that you can modify everything, and switch it so that nothing needs to be modified, and then once we managed to go through that process, and we made everything immutable, and made it so that we don't use these kind of patterns, everything was so much more simple, we had this data going one way through the components and everything became so much more simpler than it was with the other way of doing things.
Matt Kleve:
We're talking with some of the JavaScript experts in the Drupal community, about adding React to Drupal core on the Lullabot podcast. We'll be right back after this. Hey podcast listeners Matt Kleve here, hey I wanted to let you know real quick about Florida Drupal camp 2018, yeah I know it's October, but we should start thinking about what's coming up in the new year, and one event you should not miss is Florida Drupal camp. It will be happening February 16th through the 18th in Orlando. It's always a great event, the folks down in Florida do a great job. Bring your family, they can go visit the mouse, you can go do some Drupal, and then go see the mouse later, but yeah it's a great location, a great venue, a great time, Florida Drupal camp February 18th in Orlando, Florida. I'll tell you that Orlando sounds pretty nice come February so make plans right now, you can check out their website fldrupal.camp.
Mike Herchel:
Welcome back, we're talking React and Drupal, this Lullabot podcast. So, React has a notorious learning curve, I don't know if it's quite notorious, but several people I know including myself have had some issues ...
Matt Kleve:
Kinda like Drupal, right?
Mike Herchel:
Yeah.
Matt Kleve:
So, I suppose the two kind of fit together then.
Mike Herchel:
If you have two hard learning curves, that makes the whole thing easy maybe right? No, how are we going to deal with that, what training resources are out there? Have any of you had issues or difficulties learning React? I can tell you my experience afterwards.
Matthew Grill:
I never found React particularly difficult to grasp. It's a view library at its core, and the concept, if you work your way up from the beginning, are not that complicated. From my perspective, the tooling associate with React is the significantly more complicated piece, and that's the stuff that Drupal should have away from you, as the user that want to build interface using React.
Sally Young:
Yeah, the tooling is difficult, and when I built my first React site, the tooling was way, way, way worse than it is now. So, I can't give a good answer to a learning curve of React, because if I look at it now I'm like, "This is all so easy, this is great," having been through the gates of hell to get there in the first place, but yeah we have a lot of those build processes in Drupal core now, which Matt can speak more about, which hopefully makes it a bit easier.
Matthew Grill:
Yeah, I mean the last time I was on this podcast we talked about introducing the transpile step for Chorus JavaScript, so if you're doing JavaScript for Drupal core, you're already using a built process. So, we can just make this a little bit more complicated, and hopefully not affect the user.
Sally Young:
I think you made this point to me in Vienna, but maybe a perception of view being easier, or React, which is odd because I don't think I'd every heard that outside of this particular issue on drupal.org, but one thing we talked about was the way they present their tutorials, so I think when you start the view tutorial on the website, you just drop in the script, and you just start going, and the HTML is something quite similar, or if you've come from Angular is very similar. Whereas, I think in React, you're a bit more encouraged to get going with that tooling straight away. There's actually a really good project called Create React app, which is under the Facebook incubator GitHub account, which tries to set up all of that tooling for you, and it's really, really good. So, I think that's super helpful, but the thing is, is whatever app you're building and whatever framework it is, you're going to have to deal with all of that stuff eventually anyway.
Mike Herchel:
So, how did you first learn React Sally?
Sally Young:
So, we decided we wanted to built lullabot.com decoupled, because we'd worked on a few sites where we'd done, we actually did something in Zepto, it was a jQuery type thing, and it plugged into a Drupal site, and it was a standalone app that did its own stuff. So, that was cool, and then we wanted to see if we could do an entire decoupled site, so I had to choose a UI framework to do that in, and so I grabbed all the frameworks, and tried a little bit of each of them, and I found React the easiest, and it was also the fastest to render in all my tests as well, compared to everything else, so went with that, and yeah then I just tried building a big thing, and had to learn as I went.
Mike Herchel:
That's the way to do it, you just start building stuff right?
Sally Young:
Yeah, I mean that works for me, some people prefer tutorials, articles.
Mike Herchel:
What about you Matt Grill? How familiar are you with React, and how did you get into it?
Matthew Grill:
I strongly avoided learning a JavaScript front end framework for a very long time, because I couldn't decide what I wanted to do and someone was like, "Look at React," and I was like, "Oh this makes sense it's a small set of things that you build upon and work your way up to building a really complex application," and I just started building toy things, and now I used it for almost everything totally comically at this point, but it works well. But, I have an interesting story about someone learning React. I had a friend that had never programmed before, and had never really even done any programming on a computer ever really, and he went from zero to a React development job in just under six months very recently, so I was pretty excited to help him along that journey, and learn React and JavaScript. So, he did a complete 180 career shift, so it was good.
Sally Young:
I've heard that story from several people actually, a friend of mine used to go to this meetup, where refugees would come to the country and wanted to learn something, and so they would all start learning JavaScript, and were able to get jobs pretty quickly, and get ramped up quite fast.
Mike Herchel:
Cool, Lauri, and Theodore, how familiar are you with React, and how did you get started in it?
Lauri Eskola:
I've been working using React on several client projects, and how I got into it, was we building an API for a client, and they needed a very small application on top of that, and then we just kind of figured out that it would be cool to build it on JavaScript, and we tested out a bunch of different frameworks, and they figured that React was probably easiest to learn for us, and there was good examples of how to build what we wanted to build using that, and we just went ahead with that. For me, it was like the build tools was really the most difficult part, it took me a long time to figure out what is going on there, and to figure out how flexible everything was.
You can customize anything you want, because you just build everything from scratch, and I think on the first project I was building, I couldn't really get all of the benefits out of React, because I didn't know all of the possibilities in the beginning of the project, because with Drupal I have learned that there is this one way, or two ways, because Drupal is more opinionated than React, but then on the second React project that I was working on, we just went nuts, and did everything that we wanted to do, how we wanted, because it supported that and then we could do it.
Theodore B:
And as for me, it's a bit different, because I don't really have much time to develop stuff, and I learned React, the basic did the tutorial, that kind of stuff, but I didn't build a whole application with it, or a whole website, so I was mainly there to make sure whatever decision is not going to be too much at odds with what we currently do with JavaScript and Drupal core, because that's the part that I know most, I like React, and all the JavaScript framework for the concept. They popularize guess, but I'm not really into the actual execution of it.
Mike Herchel:
Cool.
Matt Kleve:
Mike how about you? Tell me about your React experience. Since we're the hacks on the podcast today.
Mike Herchel:
Yeah, yeah no joke, so I'm a front end developer, and I feel like in 2017 it's almost required that you know React. Back when lullabot.com was being developed by Sally, and a couple others, I would go in there to try and knock out an issue or so, but I was on a client project at the same time, so I couldn't really dedicate myself to working on that, and I kind of got lost just looking at it. So, that was frustrating, it turned me off for a little bit.
Recently, I've been doing this suite of courses by this front end developer named Wes Bos, W-E-S, B-O-S, and he started with just a JavaScript 30 thing where you do 30 JavaScript challenges in 30 days, and afterwards I did an ES6 course, which was really, really useful, because if you're programming JavaScript or you're programming React and you're doing modern JavaScript, it's hard to tell where the modern JavaScript ends and the React begins without knowing that syntax, that hey this is just built into modern ES6, ES 2015 JavaScript, and now I'm in the process of doing a React course from the same person, and honestly it's been great, and I've been learning a whole bunch, and building a little project app and stuff like that, and the more you get into it, the more sense it makes, so at that point, I'm hoping to get some polar requests into the lullabot.com.
Matt Kleve:
Do you think React is going to work well for Drupal Mike?
Mike Herchel:
You know, I don't know I have a couple reservations, like I said earlier where if you're pulling stuff into the front end at the same time, then if you have two different JavaScript libraries up there, but then it might not matter, if it's completely decoupled, you're not going to have that quick edit, and you're not going to have that toolbar, and stuff like that. Other than that I think it'll work fine, the project that I'm currently on does have, it's Drupal 7, and we have some React components that are built into it, and they seem to work fine. I honestly think that pretty much anything is going to work better than this jQuery in state management stuff that we're all handling by hand, and hopefully enable some better UIs that are a little bit more performant than we currently have.
So, now as opposed to a couple of years ago, I was a little bit against it when we initially talked about pulling in something like this into core, because we didn't know if React was still going to be popular now, and honestly I guess our same argument could hold, we don't know I'd it's going to be popular going forward, but we can make a better educated guess now too. In addition to that, we've had the chance to make Drupal's internal APIs better, so hopefully this will help out, but one of the questions that's in the back of my head is, "Will React be obsolete in three, to four, to five years, with web components and things like that coming out"? So, if anyone has any thoughts on that please share.
Sally Young:
I think that Facebook is very invested in React, they use it in a lot of stuff, and if they see using web components as being a useful way to render things in React, I think they would move towards that, but I don't know, who knows, who knows what the Internet's going to look like in five years time, can't really make a call on that. Just have to work with what we have now.
Mike Herchel:
Yeah, I'm pretty sure there's going to be cat GIFs.
Sally Young:
Definitely lots of cat GIFs.
Mike Herchel:
Yeah, other than that I don't know.
Sally Young:
I read a really interesting article yesterday, it opened up saying something like,
"So, my company built on web components a while ago, going forward, and here's all the massive amounts of problems we now have, but things are getting better," so I don't know,
it's tough with web components, we're moving very slowly it kind of seems like now, but I don't know.
Mike Herchel:
Yeah, I remember hearing about them three to four years ago, and there's various different things that were supposedly moving in that web components encapsulates, and I remember hearing recently that HTML imports are now not going to be implemented on any browser. I think they were implemented on maybe Chrome, but now it appears that they're not going to use that, they're going to use ES6 imports, or you can use what do you call them? The template literals to pull on your strings or whatever, but ...
Sally Young:
Yeah, I think we can't really make a decision on something that's not as solid as the one we've gone with.
Mike Herchel:
Yeah, and the argument could be, even if we wait five years, we're still not going to know for the next five years.
Sally Young:
Right, and then you know if web components take over the world, and React doesn't
adopt web components, then we'll just have to rewrite the theme in web components.
Mike Herchel:
Yeah, so let's talk a little bit about maybe how this is going to work for, I mean I'm guessing if we're implementing React on the backend admin interface, and for whatever reason, I disable JavaScript, which now you can still get around your admin interface if you have JavaScript disabled, is everything going to completely break, or is there going to be some type of fallback with that, and ...
Matthew Grill:
Are you hinting at server side rendering?
Mike Herchel:
I'm kind of wondering, obviously ...
Matt Kleve:
Just throwing a soft ball.
Mike Herchel:
Yeah, with server side rendering you would need node on the server, which of course would dramatically increase any type of complexity.
Matthew Grill:
Well there's PHP, the VJS thing, I think you could probably set something up to service that vendor there.
Mike Herchel:
I'm pretty sure that's going to be more complicated than running node on the server.
Matthew Grill:
Well it might not be, in the long run it's like do you add an additional stack in technology to your server to render parts of your HTML, but one of the ...
Matt Kleve:
And what you mentioned was a PHP library? I'm sorry I'm not familiar with it.
Matthew Grill:
Yeah, it's a PHP extension library, something. I don't know what they're actually called, I'm not a PHP developer ...
Matt Kleve:
You install a thing and put a line on the PHP.INI file right?
Matthew Grill:
Yeah, Lauri got PHP VJS, yeah, yeah that's it, but one of the really interesting things is that with React 16 there's no checksums, that slipped by me initially, and I didn't really grab onto this, but Drupal could still technically render the HTML initially, and then React could just bootstrap it afterwards.
Mike Herchel:
So, React is just going to kind of reorganize the dom with ...
Matthew Grill:
It just takes over all subsequent adjustments to the dom after the page is loaded.
Mike Herchel:
All right gotcha.
Matthew Grill:
So, if you don't have JavaScript, then you'll just get a one time render of this page basically.
Sally Young:
Right, but then you need your templates in two places unless we figure out how to render all the react components on the server, which is why you might want to do something like PHP has read8 bindings that might be not a good idea though, I don't know. It's a hard problem.
Matthew Grill:
These are all hard problems, yeah exactly.
Theodore B:
And I have a different solution to, well a different answer to the question, so for a long time, I've been worried that Drupal 8 doesn't work on proxy browsers, so it all depends on how we use React, because we can have a very optimized administration UI or content editors that uses React, and with all the fancy stuff, but still keep the old form based admin interface, but removing as much JavaScript from there as possible to have fall back, or it doesn't make sense to remove everything right away, so maybe we can find a use for that, and also make sure that the admin interface works on proxy browsers that are used in less connected places.
Mike Herchel:
So, when you say proxy browser, you're talking about stuff like Opera, or something like that?
Theodore B:
Mini, yeah Opera Mini, and UC browser as well, and a bunch of other Chinese browsers.
Mike Herchel:
That's interesting.
Theodore B:
So, it depends on how we go about building the new React admin, or JavaScript based admin.
Mike Herchel:
Does Drupal have the APIs in place to make all of this work? How much work, for example, you talked a little bit about the DB log module, are those APIs sitting there waiting for us, or does custom development need to be done? What about if we move into something more complicated like Views, is that going to, I'm guessing a certain amount of work is going to need to be done on the backend to expose those APIs?
Matthew Grill:
Yes.
Mike Herchel:
Good answer, good answer.
Matthew Grill:
There are some, definitely some APIs, and for example right now the DB log prototype, we are suing views because the existing core rest work doesn't support lists of items, and so you can only get one DB log entry per HTTP request right now with the built in rest API, so we have to use a View, but that introduces a whole bunch of challenges that I have had to work around, so this is not the most awesome it could be.
Lauri Eskola:
So, one of the big parts of the API that we are missing, is in the validation, which we currently do only on the form level, but obviously when we go using the APIs, we need some kind of validation on that as well, and that is something that we haven't yet figured out, so there is different kind of things that we have to figure out like simply exposing some kind of APIs, then figuring out how are we going to validate these things, and how do we convert some of the existing logic that we have built in the UI into other places, so that the exposed APIs also can leverage that? And, those are problems that many people who are building decoupled sites or use those APIs already have to face, but the core developers, if they don't happen to use the APIs that way, will never actually know about that. So, it's very good for the API development, as well that we don't fool ourselves, and get some experience, what works, what doesn't work.
Matt Kleve:
Right on, so what's the end game here, if we're going to get something into core, is this going to be an experimental module like some of the other initiatives, or some of the other projects they're going toward, what's the future hold for this?
Lauri Eskola:
So, I think we would like to experiment in the contributed space as long as possible, make some changes for Drupal core to support those contributed modules, those improvements would be
available for all of the users of the APIs of course, but eventually probably point six point seven, they're all going to proceed to core, and then we would create the experimental module or team, or experimental something, where we can experiment with this Drupal core itself. So, the idea is not to yank in something immediately and get locked on that.
Matt Kleve:
Isn't it great the way we're versioning Drupal now, like this is possible.
Lauri Eskola:
Yeah minor releases.
Matt Kleve:
Yeah exactly, yay minor releases. Cool, so we're coming almost to the time limit, so why don't we all just go around the horn, and I would like to give you a soapbox to talk about your little corner of this project, and maybe give some promotion to something that's happening that you're excited about, or just 30 seconds or whatever to rant. So, Lauri if you don't mind kicking it off, anything you'd like to add about React in Drupal?
Lauri Eskola:
I've been working on the render system and theme system programs, and if we can really move forward with these kind of improvements, I think the team that we have can spend less time on the team system, and render system problems, and can move forward on the other kind of problems, which will help us, and I'm really happy about that. I'm also really excited to get the leveraged code from wider community that React, or the other framework, whatever framework we in the end decide to pick has, because if that makes building UIs so much easier. So, those are the things that I'm excited.
Matt Kleve:
Matt Grill your turn.
Matthew Grill:
I think echoing what Lauri said, and additionally, we're not, I mean at least I'm not trying to make anyone's lives more difficult if you're already working with Drupal. In the end we're just trying to provide some level of modernization perhaps, and if you don't care about React, and you want to work on other JavaScript issues, there are tons of them, please we can also use more hands.
Matt Kleve:
That's true, Sally Young.
Sally Young:
We're going to be at BADcamp, and we're going to work on some of this stuff, so if you're at BADcamp, and want to come and work on some of this stuff, you should wave at us, and I think it might happen on Friday. Is it going to be a front end summit Matt?
Matthew Grill:
There will be a place where we can talk about front end things.
Sally Young:
Yes, is it Thursday or Friday?
Matthew Grill:
I don't know.
Mike Herchel:
I think it's Thursday, I remember looking at it. I'm getting in Thursday night, and I remember looking at that and being kind of disappointed it looks like I can't make that.
Sally Young:
Well we'll be around the whole rest of the week probably working on this, so you can come and work with us too.
Mike Herchel:
Sounds like fun.
Matt Kleve:
Outstanding, Theodore, anything you'd like to add?
Theodore B:
As usual, we need more contribution, and JavaScript patches, and some issues that are not React, or any JS based, so if you're interested in JavaScript and
want to contribute, feel free to ring me, or any of the and we can point out any issues you can work on.
Matt Kleve:
Outstanding, and how can somebody jump in and be useful to this React in Drupal movement? Maybe they're not going to be at BADcamp?
Matthew Grill:
Drupal slack, the JavaScript room on Drupal slack is where we're having a weekly meeting in there where we're going to talk about this, and so, yeah. Get in contact with me, I have plenty of issues and patches that need review, and things that need feedback.
Mike Herchel:
And your contact info is on our podcast page, so yeah.
Matthew Grill:
Yes. Apparently it is.
Matt Kleve:
It will be, yeah for sure.
Mike Herchel:
People that are listening to this.
Matt Kleve:
Mike Herchel do you have anything you'd like to say about this topic to close us off?
Mike Herchel:
Yeah, I'm kind of excited about it, and I will be in BADcamp this week when this is published, the Friday and Saturday, and I will also be at Drupal camp Atlanta, and that's November second, third and fourth, and so yeah if anybody wants to say hi, come say hi.
Matt Kleve:
If you like what you hear, if you hate what you hear, we'd love to hear from you. You can tweet us @Lullabot, or leave a comment on the podcast page on our website, lullabot.com.
Mike Herchel:
Yep, and feel free to give us one star reviews on iTunes, and Stitch or anything else that we have.
Matt Kleve:
We'd love to hear five star reviews too, but yeah just let us know how we're doing, we'd love to hear feedback.
Mike Herchel:
I'm just trying to be honest Matt. Is there anything else we're missing?