Progressive Decoupling and Drupal’s Front-end Future
DrupalCamp NJ 2016 BoF
Download audio recording (m4a)
NB: There may be some errors in the text with regard to correct attribution and the actual transcription process. Please report any errors to preston.so@acquia.com.
prestonso: Hello and welcome to the BoF. This BoF is called “Progressive Decoupling and Drupal’s Front-end Future.” I’m really glad to be here at DrupalCamp New Jersey with some amazing contributors and people in the community here. And I wanted to just very quickly give a little bit of background, because I’m sure most of us are familiar with the issues and the content that has gone out. But I just want to sort of summarize it all so we have it as a baseline.
So recently, I guess last year, Dries posted a pretty bold statement of a blog post, which argued in favor of potentially a client-side framework in Drupal core. Now, this client-side framework idea is something that runs the gamut of: could be a view library, could be a component library, could be something like React or very lightweight, or it could be something more involved such as Angular or Ember. Now, the reason for this is that the fully decoupled Drupal approach that many people are currently leveraging is problematic in a number of ways, because it really severely limits the site builder’s ability to influence the front end.
And it gets rid of things like localization on the front end; it gets rid of all the things that make Drupal really great on the front end. So, Dries put forth this idea called progressive decoupling, which is really meant to be an organic concept. It’s meant to be sort of something that we define. It’s not tied to the concept of a client-side framework in core, and I want to be very clear about that. He wants us to imagine some kind of a vision moving forward for what a richer, more interactive experience would look like, but not necessarily tied to fully decoupling, not necessarily tied to, let’s say, per se, a client-side framework.
So, as a result of that, I put forth an issue on the Drupal core issue queue basically proposing that we select a framework and sort of evaluate these decisions. Obviously, there’s been a whole lot of discussion and many people have come in with a lot of differing opinions about this. It’s been very controversial, obviously, and I know many of you have spoken up about it. And one of the most compelling posts that came about in response to this whole thing was Lewis Nyman’s post, which I’m sure most of us have read, which basically argues in favor of a UX-first approach to improving the way that we work with JavaScript and our UX as well.
So with that in mind, was that a good background, baseline? Can we introduce ourselves for everybody? I’ll start off. I’m Preston, I work at Acquia. You’ve seen my writing. (group laughs)
ironsizide: My name is Alex Rhodes; I work for Message Agency out in Philly.
stevector: Steve Persch, now at Pantheon, previously at Palantir.net. At the last DrupalCon North America I did a presentation called “Rendering HTML with Drupal: Past, Present, and Future.”
lauriii: I’m Lauri Eskola, on Drupal.org lauriii, and I work for Druid. I’m also right now one of the theme system’s co-maintainers.
dawehner: I’m Daniel Wehner, user name dawehner, and long-term contributor and with Chapter Three and Tag1.
shaune: I’m Shaun Ellis. I’m relatively new to Drupal; it’s been about two years that I’ve been working with it. I am a front-end developer for many years, for about fifteen years, and I came to Drupal, and so I feel I have a lot of opinions and I’m very interested in having this discussion, so very excited about it actually.
wheatpenny: My name’s Levi Sigworth, I work for a pharmaceutical company, and I built the front end for the site for DrupalCamp New Jersey, and so really interested in understanding more about how we’re going to make sure to maintain the intent and integrity of the HTML.
drewcipher: I’m Drew Keller, I work for Eastern Standard in Philadelphia.
nickgs: I’m Nick Selvaggio, I run Sego Solutions on Long Island and run the Long Island Drupal User’s Group.
davidhernandez: I’m David Hernandez. I helped with Drupal 8 front-end systems and one of the Classy maintainers. I’m one of the New Jersey camp organizers, and I’ll be starting at FFW this week, so one of the things I’m really concerned about is the front end in Drupal 8 and Drupal 9.
prestonso: I think we’re all very concerned about this, and I think it’s great — we all want to see Drupal succeed obviously, so I want to make sure to preface this by saying this is going to be unopinionated and neutral. We’re not here to have a debate; we’re here to talk about what moves Drupal forward the best way. So what I want to do to frame the discussion just to start off is to talk about a few problem statements, things that we’ve seen in the wild and things we’ve noticed with regards to Drupal.
The first is that there is a wide perception — and I think we all agree about this — that the user experience of Drupal 8, while it’s a huge step forward and it’s really awesome, is considered to be perhaps a little bit behind some of our competitors. That’s the first problem statement.
The second problem statement is that increasingly, front-end developers are choosing JavaScript over PHP or over server-side languages for the primary reason that it’s a great language to use on [erratum: the server side and] the client side. People are decreasingly choosing PHP because of various reasons — whether it’s a good idea or not; we can debate that — but there is a large trend in the web development industry toward JavaScript.
The third problem statement is that we have our REST server in core, which is a huge step forward thanks to WSCCI in Drupal 8, and we want to make sure Drupal is also API-first, because that’s very important for our fully decoupled implementations — single-page apps, native mobile apps.
And the fourth problem statement is that we really want to make sure that Drupal is future-ready. We want to make sure that Drupal stays relevant for years to come. 8.x is going to be around for probably at least 3-4 years at the minimum, so we want to make sure that 3-4 years from now it’s still a relevant framework to build sites on.
So with those in mind, I want to kick off the discussion and get people’s ideas about how we can think about these four problem statements and move the project forward. And once again, I’m not going to say that it’s a framework or that it’s this solution or WebSockets, but that’s a good starting point for us to talk about.
nickgs: In terms of the front end of Drupal, are we talking just about the administrative interface or just how we approach developing Drupal applications altogether?
prestonso: So I think initially, it really is focused on the administrative back end. That’s what my issue focuses on, and the main reason for that is because it’s the most application-like portion of Drupal. I don’t think we should focus on, necessarily, the end user-facing theme or end user-facing UIs such as Contextual Links — that should be a later, longer-term focus because that introduces a whole lot of other issues.
But in terms of things like our node edit form and especially things like the Views UI, we can see a lot of room for improvement there. And I was just looking at the Views UI this morning, and we have very good progressive enhancement on it. Everything works without JavaScript enabled, which is a very important consideration. However, if you start performing operations in very quick succession, you get some problematic race conditions where some AJAX requests go through and then they come back and then you’ve got this really bad collision of problems. And part of this could potentially be resolved by some kind of management of state on the client side, and it’s important from the context of managing a large UI, in particular such as the Views UI, that we do maintain some kind of state on the client side. That’s my opinion.
nickgs: Now, I mean, from a Views UI perspective, just that whole interface, stepping back from how the calls are architected, just how you use it in terms of the user interface. Is this comprising that idea as well in terms of changing how it looks?
prestonso: Absolutely.
dawehner: It seems to me that the actual problem with that UI is that the concepts we have are so complex at the moment. Even if you talk about the Fields UI as well; the actual problem is rather the mental model for people, and then maybe the technical implementation based on that mental model, but we should rather start with the mental model to help things. The Block UI: When you want to put something somewhere on the page, it is totally the other way around from how people think. It seems to be this is rather the discussion that we should focus on first.
shaune: I think even just taking a step back from that, my big problem — and I love Drupal in a lot of ways — but when I was first working with Drupal, there was just a major hurdle to get over in terms of the terminology and the Drupal way of doing things, and when you’re talking about front-end developers who are very comfortable with JavaScript and CSS and HTML, and they have to slow down to get over this hurdle of learning Drupal from the inside out, you’re actually limiting a lot of your prospective contributors by — and I’m not saying they shouldn’t know anything about Drupal — but if you can separate those layers and if you can deliver a RESTful APIs for doing these things, then you don’t limit your contributor base, essentially. Or, if you’re recruiting and you want someone to develop your front end — and again, you said that’s a future discussion; this is primarily focused on admin-type stuff — but even that, having that kind of flexibility within the organization to design the admin tool to exactly meet the workflow and user needs without having to be a Drupal themer. On the admin side it gets more complicated, but that’s my take, and I worry that Drupal is too much of a closed community to outside contributions in a way, and I think Drupal 8’s made a lot of good progress away from that, so I just want to see that continue. And I’m not saying that it should be completely decoupled either.
lauriii: I’m just having a bit of difficulty understanding why we are discussing using the progressive decoupling on the Views UI or the Fields UI, because it’s mostly the site builders and the developers using those UIs, and it doesn’t actually attract any of our users more. If it feels a little bit more snappy, that’s what I believe. Instead, we should be focusing on the things that help our users — the masses — the users that we have and helps us build better sites for the content authors and those. So are there some actual problems that we can discuss on the content authoring experience that should be discussed, because I didn’t hear a mention about that at all in this discussion. We are only talking about Views UI, and that is for developers, and that’s completely irrelevant for the masses, and that’s what I think. And sometimes I feel like: What is the goal of this initiative, because it feels like we are thinking of people — we are thinking of making better experiences for people who are irrelevant in this case.
stevector: I think the working hypothesis that I’m hearing from you, Preston, is that our user experience needs to be improved, and perhaps we can improve our user experience if we have a better developer experience, because if we have a better developer experience, we’ll have a wider set of developers, who can improve the user experience, and they’ll have an easier time improving the user experience. But I am skeptical about all the jumps that are being made as that gets fleshed out, because we can talk about what are the user experience improvements, what is the mental model that we want for the blocks system. We can talk about that independent of thinking about where is the state managed: Is the state managed on the server side; is the state managed on the client side? That for me is a discussion to be had after we talk about how are people supposed to think about blocks at all.
lauriii: I definitely agree that we need to make as good a user experience as we can make for the site builders and the developers, but that’s what we have been doing research for, and none of those have brought up any message that it should be faster or snappier. And it’s more about, like you say, naming things, and the whole concept of Drupal. Everything is so difficult. When you create a view, you have to know about — you want a display, you have to know about blocks and pages, and all that. Then there are attachments and everything.
davidhernandez: It seems to me that there was a lot of confusion in the conversation when it was originally started by Dries, that there were certain goals that he’s outlining; there were certain goals that you, Preston, put into some of the posts that you put up. And it doesn’t seem to me like some of the solutions are matching the goals and some of the stated problems. And I think a lot of people would agree what problems we have, and it doesn’t seem like the direction of the conversation is going toward solutions that will really fix those problems. So, what everyone’s bringing up here is that we know we have major UX problems in the interface, and much of this decoupling conversation isn’t geared toward fixing these problems. These are logical problems; they’re interface problems. There are UX solutions for them that mostly revolve around rebuilding the interface; it’s not a question of: We need to attract more developers to fix these problems. We need to attract more UX expertise who will outline how to fix these problems, because we have lots of developers who can fix them, but we have not had a good tradition of listening to UX people and actually doing what they say.
prestonso: That’s actually a very good point, and I think that most people have brought this up. I come from a UX background. I was originally a UX designer, and so I definitely identify with the UX issues and the problems that have been coming out. And I definitely agree that the usability study that came out last year is an important focus for us, and it’s something that I probably overly deemphasized in writing this issue.
However, I think it’s important to note that as you said, we have a lot of developers, but we don’t have a lot of UX expertise, and it’s very important that the UX contingent of the community has a very strong voice. And in the past, this has been a real challenge. We’ve had a lot of challenges implementing any really ambitious and lasting UX changes. We saw this with Spark. We put forth a lot of proposals that a lot of people agreed on, but then when it came to actually building them, scope had to be reduced significantly when it came to a lot of these proposals. For example, Responsive Preview didn’t make it into core, because of a lot of concerns about how that was going to impact aspects of Drupal.
That makes a lot of sense, but I think that what’s important to keep in mind is that user experience and developer experience go in tandem. They go hand in hand; they’re two sides of the same coin. And one of the things that I found interesting about Lewis’ post is that he proposes that we start from the UX design and move from there, which is a sentiment that I hear echoed quite a bit. If we want to do that, however, that means that we have to be willing to make some really tough choices about Drupal’s architecture as a whole. It’s not something where we can say this has to be reduced in scope because of this other problem. If we are really interested in a UX-first approach, UX has to be prestiged above everything else, including developer experience. This whole idea of trying to focus on the user is very important, but all of those things often get overruled by developers who are saying, “Oh, we have to architect it this way, and it has to be according to these specifications.”
So I definitely share the concern that there’s not been enough focus on UX, and I think that’s a very important thing to note. However, are we going to put forth a vision that’s going to be torn apart, basically, in terms of UX? Or are we going to try to move both forward at the same time, both the UX and the DX of using Drupal? And I think we’re talking about two very distinct and potentially very conflicting threads, which are, let’s improve the user experience, and I think, when Lauri talks about the site building experience, what’s really important, I think, is that yes, site builders and people who are developers are using these UIs every day, but we want to enable anyone to use these UIs. Views UI should be something that anyone who is installing Drupal for the first time should understand immediately. That’s part of it; that’s absolutely part of it. This wayfinding, the naming things; that’s why Kevin O’Leary has come up with a Simple English localization for Drupal. All of these things are really great.
At the same time, however, we have a growing number of people who are conscious of the fact that we need some kind of unified API on the client side that handles state or handles these sorts of things for the future.
dawehner: So for me it seems to be that we are kind of trying to solve all the problems at the same time, both the long-term problems like the fact that PHP is going away, both the medium-term problems of having a unified API, both the short-term problems of our UX. So I think if want to solve the top five UX problems, we could solve them much faster and then iterate later. And then, now we look at the mid-term goals and now we need the unified API. And I think that kind of approach would be more successful than what we do currently, which is trying to design the entire system.
prestonso: So I’m curious, because I think a lot of this debate that I’ve started has a lot of parallels to Symfony. A lot of people — Symfony solved a lot of problems for Drupal, but it also made some people very unhappy. I absolutely agree with you — my sort of vision for that issue was to kick off a discussion and get us talking about this particular, possible solution to this issue. What’s been really great is that it’s kicked off a whole lot of debate around other solutions as well. And so, in this trajectory of what Dries calls progressive decoupling and basically solving problems in a piecemeal fashion, we have some quick wins we can do immediately. There’s already proposals for things like Turbolinks in core, which will basically allow us to have partial renders without client-side rendering. There are solutions like that that give us quick wins and definitely fall into that same category of how do we prevent people from moving completely off of Drupal or fully decoupling Drupal, which is what we want to avoid. So I think that the overall vision has to include all of these small pieces as well, and we have to have these progressively larger and larger wins, I think, to give us the experience that we want.
However, that being said, it’s very difficult for us as a community to agree on what the most appropriate JavaScript API is. We’re not all JavaScript developers. There’s quite a few of us who are, and there’s a lot of us who have JavaScript experience, but our primary focus is on Drupal and Drupal’s existing API. So one of the things that I’m really curious about is how do we envision the contrib world being able to land on, let’s say, a unified developer API for these interactions empowering client-side state at a pace that will allow us to make sure that we stay caught up with everyone else.
stevector: I think for that to work, what we’ll need is a vision for how we’re supposed to think about rendering: the steps of rendering, independent of PHP or independent of JavaScript. What are the steps necessary to take data in Drupal and render it into HTML? We’re slowly moving from a global mindset that Drupal core historically has with its block system, where all blocks have to be thinking themselves about, “Am I supposed to render? What global variables can I pull in to render?” And we’re moving toward a system where blocks have to provide cache metadata and declare exactly the things that they’re relying on. So we’re shifting our mental model gradually of “how do things render.” JavaScript frameworks have their own mental model. A lot of them have the model-view-controller mental model. So if we’re going to end up picking one of these JavaScript frameworks, I would like us first to think about how do we want to conceptualize rendering at all, and can we make incremental improvements on the PHP side that match that vision? So if we want to think in terms of model-view-controller, how can we represent that just in PHP? That’ll make it easier for us to say, “Okay, we’ve decided on React. React is the view layer; now we only need to replace this one slice of the view layer.” What we have right now is a better system, but it’s still very hard to draw all the lines too. The question I always ask is if you want to cut off Drupal’s head, where is the neck? Where do we slice off and make Drupal headless? And if we can draw clear lines, even in ternally on PHP, then it’ll be much easier to expose those same lines client-side.
prestonso: I was just talking about this a couple days ago with Wim Leers, and one of the really interesting things about how Drupal does rendering is that — one of the biggest strengths and one of the biggest weaknesses is the hook system. It’s both a blessing and a curse in that we have a colossal render array that you can replace — patch, basically. And that sort of model is very different from the model that we find in these MV* frameworks. So I guess I need to open that up — how should we reapproach rendering? Is there something we need to do to evolve the render system in Drupal to potentially accommodate ways of doing client-side state or thinking about ways of integrating more closely with a JavaScript-powered view layer?
davidhernandez: Well, so what Steve is saying is right, and we’ve had a conversation about this before. What we’re lacking now is a strong vision for what we want that model to look like, and the discussion of a framework itself is premature. [indistinct] The framework discussion is probably something to have a year from now, after we figure out what we want the vision to actually look like. And we’ve already had conversations about a lot of different things, like building a proper component system instead.
I think it would be better if we can work toward something that’s a little more agnostic so that we don’t have to decide on a particular framework while a lot of people use different frameworks, and we decide where those cutoff points are, so that people can make clean separations and plug in different kinds of systems that have a much better approach, but we have to know what that big picture is and where we can create those separations. If we don’t do that, then we’re just going to end up with this intermixed web that we have now; it’ll just be intermixed with some other framework or solution. But if we create a separation point and figure out exactly what we want to do, as we evolve, we’re more likely to probably just come up with another solution. It’s what we’ve always done in the past. Drupal people will figure out exactly what we need to do, then as we’re working on it, find out — come up with a new idea — a year from now, all these frameworks will be completely different. New ones will develop, some will drop off the face of the earth, but we need to build some kind of pluggable component system where we don’t even have to worry about it; we don’t have to make that decision. And we’ll internally come up with something that just makes Drupal much more advanced and much more pluggable, so that everyone can kind of get what they want.
nickgs: I think I agree with that. Kind of building on that, taking a step back, if our goal is really to improve the UX of Drupal, do we even have these architectural conversations right now? Do we talk about just what do we want to change? Like you said with the mental model, how the Views UI is laid out, how the block system is laid out. For us personally, we never bring clients into those screens because it’ll scare the crap out of them. And we usually build our own interfaces that match how they use it, and that’s how we’ve always done it, and it works pretty well, but I do think there is a sentiment growing, at least with our client base, that Drupal is getting more and more complicated, and they are looking at other things. It just works. It should just work like that, and there’s this perception that there should be an easier interface. The Views UI, I mean, forget about it, we can’t bring anybody into that.
shaune: I agree, and I think Preston had a good point that UX is not just about the end user experience; it’s also developer experience. I work with a group, IIIF, it’s the International Interoperable Image Framework, and the whole focus of it is to publish data for presentation for clients, essentially, that will interoperate — image-based resources that will interoperate among museums, libraries, institutions so we can share our resources, basically. And it’s an active fight to make sure that that presentation data is kept simple, to fight against complexity in it, and to make sure that these back-end data models that don’t need to be there are not. So, I think simplifying that and providing just what you need on the front end to render the view is critical. I also think that when we talk about these JavaScript frameworks, they all get conflated together, but a lot of them are very different. You can use the React view layer with Backbone.
nickgs: Does the developer experience really drive the user experience? Shouldn’t it be the other way around?
prestonso: This is a very interesting question, because my sort of opinion is that you can have a UX-first approach, and UX is the focus. But if you don’t have developers who are willing to work with those APIs, you’re not going to get any advancement with UX.
dawehner: The actual problem is that Drupal historically targeted the entire market: both the really simple thing, both advanced site-builder stuff. One reason why Drupal is actually still used is because people can build really complex things with it, just by clicking things. So these kind of complex UIs — there’s some kind of point in having those, because it gives people the power to actually do something with it. A content author, for example, that particular persona has totally different requirements from the site builder, and I don’t know whether we should keep up with those different kinds of personas, or whether we say: there’s just one persona, or much less personas, and we just need to get something good for all of them.
evgeniy: But instead of just having one size fits all, we can also have different approaches. For example, filters can be used for a particular group of people who need to enter 1-2-3. And they don’t need to know all the complexity that’s behind it, because they just entered a few things of data and that’s enough for them. In the same way with administration interfaces, if you have different people working with it, one can be a starting site builder and another an experienced developer. So maybe there is an “Advanced” button somewhere there as we have in desktop applications that hide a lot of complexity from a non-sophisticated user.
wheatpenny: I think the question then is, who makes that decision? So in your case you’re making the decision; you’re the advanced user who is making that more straightforward feel for a content editor. Do we have the ability as a community to define those roles and make those decisions for other people? Me, I wouldn’t want the community defining for me who my advanced users are and who my medium-term users are, who’s lightweight here. But is there a way that we can set up so it makes your life easier as a developer to set up those roles?
evgeniy: Right, but to your point: We shouldn’t define, but otherwise, it’s already defined today. You have what you have anyway. I think that making it simple for others — the goal we are trying to achieve here is more adoption, at the end. So basically, targeting it toward a bit different user groups, we’ll be able to solve it.
shaune: I think this comes down to the usability and the user experience studies actually providing evidence for making certain changes or deciding who is — who is this interface for and what their goals are and stuff. And having those play a bigger role in the development process might be a way to have some of those questions answered.
wheatpenny: It’s the same thing we do for our clients: We define user roles, we understand what those user roles are trying to do, and then we build those needs. It’s the same thing, it’s just like turning it in on ourselves and examples to it.
davidhernandez: Could we clearly define what we mean when we say developer experience? I want to make sure we’re all on the same page. (group laughs)
stevector: I’ll take a crack at it. So we’ve been talking about the Blocks UI and the user experience and the developer experience. The developer experience when it comes to blocks in my opinion has to do with how comprehensible is it to a developer for how is this page put together at all, and right now, it’s difficult for a developer to understand how does Drupal create this page in total. The user experience side: I think we want a user with no code experience to be able to go to the Blocks UI —
davidhernandez: But are we talking about a developer who might be using Drupal, who has to interact with that page, or a core developer who might have to make changes to the product and who is working on that page?
wheatpenny: Are you saying, “Do we include site builders as developers?”
davidhernandez: No, I’m saying, are we talking about ourselves that are working on Drupal core as the developer experience for fixing the Views UI or are we talking about some developer who’s just working for a company using Drupal who might have to build something that interacts with Views or part of the Views UI or something else?
prestonso: I think it’s the latter, with an eye toward them becoming core contributors in the future.
dawehner: If we improve the life for everyone, I think we can improve the life for ourselves.
evgeniy: To make some simple UI, you need to work a lot on defining it and then making the background architecture to actually enable it. With this, I think it’s the same approach where core will need to work a lot more so that it’s easier for the majority of developers who are using it. And that’s our user base that we’re trying to expand, so we need to serve them.
lauriii: (indistinct) Some bad user experience — developer experience for the developers of Drupal core itself, but for the users of Drupal they are great, because they can just have their old, smelly code there.
prestonso: I think you raise a very good point though, which is that there are multiple kinds of developer experience, and I think that one thing that’s important to keep in mind is that as we’re trying to get more adoption and as we’re trying to enlarge our community, what kind of developer experience are we going toward? Is this a developer experience that is going to be good for Drupal developers, because in that case, we’ve done a really good job. The DX of Drupal 8 is great, but is it a great experience for all developers across the world who might be working with different paradigms or might be interested in pursuing problems in a different way? So my concern around DX in particular is how can we make Drupal welcoming for not just people within our community to interact with our APIs but people outside the community?
mcaudy: Sorry I got here late, but I read your meta blog thing, and I’m very familiar with this area. I’m Mike Caudy of New York. I got held up driving in. I’ve been doing Drupal as a back end as a service for 3-4 years now. Originally, I needed to deal with lots of data and I needed to display it, so I started using Flex, with just Drupal as a back end. Then when Adobe bought whoever they bought (indistinct), I switched to ExtJS, basically, where you have panels and widgets that you can drag around a dashboard, and having things like REST user interfaces. So the last year, I’ve been doing hybrid Node.js-Angular with Drupal as the core SQL back end, and I think, to me, the cutoff is clear where — there’s this huge ecosystem going on in the JavaScript world which is very hard to keep up with — I think Angular’s going through this huge change right now. But those are the people — the people that I think, if you were really talking about bringing in new developers just sort of ad-hoc from outside the Drupal community; you need to make Drupal as aware of the whole JavaScript ecosystem as possible. So I would just cut it off with REST interfaces. I know you seem to have — I read your GraphQL stuff, and you seem to have questions about the future of REST, which I don’t quite understand, but for me, (indistinct) the consensus seems to be just build a REST back end in Node, and then, all the Angular stuff, whether you use Ember or Angular or Angular 2 or whatever, all that gets decided ad-hoc. So Drupal can just come in with a REST interface; I would build off of Views, which is very well-established, and then try to make it as flexible as possible and just have this cutoff with REST. I’m very curious to see what you have to say about REST.
prestonso: So this is something that we talked about at the very beginning, which was the idea of fully decoupling Drupal, or completely headless Drupal, where it solely serves as a RESTful back end. First of all, it’s very problematic because we lose all site building functionality: layout management, all of the stuff that —
mcaudy: Well, you would have to rebuild it.
prestonso: Well, if you wanted to integrate with a framework that’s decoupled, then you would need to figure out some way to reinvent it. But the second issue is that this is an area where a lot of people are already working. This is a very saturated industry: back end as a service. Right now we have Contentful — providing a CMS as a service — we’ve got Firebase; all of these providers are already out there. And my worry, as someone who feels very strongly about the need for Drupal to keep its current user base, is that we’re opening ourselves up quite a bit for disruption by these services if we explicitly endorse this direction of full decoupling. It means that we’ve lost the battle when it comes to Drupal controlling the front end, unless we tie ourselves to some kind of a front-end JavaScript implementation.
mcaudy: But if you just have JSON coming out of Views, and run that over REST interfaces, then you can just do whatever you want on the JavaScript front end.
prestonso: But you have to rely on a developer. You can’t just have a site builder do that without any code. Now you have to rely on a JavaScript developer to do that.
davidhernandez: It’s the usual Drupal problem, where we’re still stuck in that point where we’re trying to decide: Is it a product, is it a framework? If you build a framework, then you’re competing with other frameworks. If we’re sticking with a product, then we’re competing with other products. We’ve always bridged the gap in a way, and that’s what’s made Drupal really strong, because you can build a site, where you can treat it like a framework and build really complex things. So you can do full decoupling, you can do Node(.js) stuff, but you just have to be really careful about: Do you do something where now you’re affecting installation requirements? Do you do something where you lose multilingual support? Do you lose all the front-end support and site building? Now you’re in a completely different market. I think this also goes back to a conversation that doesn’t happen enough, which was brought up earlier of — it would be really nice to sit down and have a really nice discussion about personas. And core doesn’t have personas right now, and it’s something that we should probably do, and then really decide where are we going to focus that effort, because once we do that, then that will take care of some of those decisions.
prestonso: Two things I want to say, because I think we’re starting to run out of time. The first thing is that I completely agree with you, Michael. I think that anyone who wants to use Drupal as a RESTful back end, they should be empowered to do so. We should not stop by any means people from taking JSON feeds from Drupal and powering their applications. That is absolutely, 100% true. However, we do want to make sure that people, as you [David] noted, don’t want to necessarily move off of these architectures that they’ve been relying on for a long time. And that’s a big concern as well. Now, the second thing about personas: I think that’s a very good point, and I think one of the things that would really be useful is that currently in Drupal — and this is something I read in the usability study; I’m not sure exactly where I’m getting this from in that study — but there is a lot of conflation of functionality that is content editor and site builder-focused. What if we completely separated those two roles out? Like what we have right now with the Quick Edit toggle. What if we had an experience where you can switch between an authoring mode and a site building mode? And that would go, I think, a long way to solving a lot of these these usability issues.
evgeniy: And that was one of the strengths that Drupal had initially, and that’s why it had a lot of success, because it enabled not just simple content editing but also flexibility for those simple users who are content editors to actually change something more than that. I think that’s a huge benefit that was there, and right now, with the move to Symfony, I guess what worries me here is not to lose that base of advanced content editors who are a great portion of users and advancing into developers sometimes. But now, we are trying to capture a huge market of object-oriented developers, who are a completely different kind of beast. So, they are real developers, and they want specifications for APIs. It’s not like: I want this nice interface; it’s very different experiences.
mcaudy: So I’ve been using Panopoly as a distro because it was designed and built basically by Earl Miles. I’ve been doing Drupal since 2007, and I know that Earl’s the man, okay, so I think if you want to keep the majority of the Drupal developer base happy, don’t drop using Panels, and Panopoly is the current best generation of that, and I assume that he’s working on the next thing later or whatever, but what you get with that is the Panels part of it; it’s sort of a product, if you will. You come with a standard that has a layer built on using Panels, which is confusing for Drupal developers in the first place. There’s some people who don’t like Panels, there’s some people who don’t like the new version of Panels, but for me, Panopoly gives you this complete use of Views as you know it, essentially. If you learn it, it’s a background system that gives you the layout for all of our — I don’t know how familiar you are with this, but it’s got in-place editing. So it’s got blocks; it’s all very Drupal. To me, that’s where the Drupal developers working with a Panopoly-like distro, designing, doing information architecture, all that kind of stuff. Then you just generate JSON from that coming out and let the people on the front end do whatever they want.
shaune: I have a different view of that. I find one of the powerful things about Drupal and what I would love to be able to use it for is very fast prototyping of RESTful interfaces, and I love the content type ability to create these content types and formatters. And being able to use that instead of creating my own MongoDB and Express.js server — I’m a front-end developer; I don’t want to be doing that actually. I would love to have a GUI to model my content and do a prototype with Drupal as a back end. That’s maybe wishful thinking, but it doesn’t seem like it would be that far off. You can do that, of course, with Drupal, but there’s probably as many steps as it currently takes to set up the MongoDB and everything. Something where you can just disable the view layer and make it a RESTful interface.
lauriii: So I have one more question that is about the separation between the user interfaces and the admin interfaces. So let’s say when we work on the admin interfaces, we have to be able to use Form API and things like that that are built on the render system. Do we have to then duplicate all of these pieces on both the PHP and the admin?
(indistinct)
dawehner: And this is basically where the issue of Alex comes in, which is maybe we need to render server-side in JavaScript as well to have this kind of unified experience. The other thing we could do is maybe write it in two layers, but at least have similar concepts. So let’s say we have something like components, and then we leverage exactly that kind of mental model as well and maybe the needs we have; we write everything in PHP as well.
stevector: Maybe YAML files.
(group laughs)
stevector: (indistinct) Preston, I think you and Wim have been talking about GraphQL a lot because it gives you that mental model of the components ask for the data that they want. Our current mental model is more: “Here are all the variables, we’re putting them into the Twig file; use whatever you want.” We can kind of flip that and say, “No, components, you have to ask for what you want.” And we can do that on the server side and that’ll translate much better to the client side.
dawehner: Yeah, I was wondering in GraphQL, how that would work with the model of Panels.
stevector: Well, I think it lines up exactly with the model of Panels.
dawehner: And then you have sometimes — because in Panels it’s basically that the components, they render something, and then you have configuration which puts together the data and the components.
stevector: You got a mini-panel; the mini-panel has to declare the types of data that it wants. It has to say I want a taxonomy term and give me a node. And then the panel knows what to do with it.
prestonso: All right, well, I think we’re just about out of time, so I just want to recap a couple of things. Just to highlight a couple of things, just to make sure we’re all sort of on the same page.
We talked about UX and the importance of focusing on the UX solution first before deciding on architecture. And we talked about some of the risks of that. We also spoke about the need for personas, which I think is a very good point and will help us to define what exactly do we want to have for our use cases in Drupal. We talked a little bit about fully decoupling and some of those approaches, and we talked about some possibilities of evolving our render system to actually accommodate some of these concerns. Is there anything that I’ve missed?
Great. So thank you all very much.