 My name is David Wong. This is decoupled front end in the future. We're going to mostly talk about quote-unquote headless Drupal It's not going to be a very technical talk I mean, we're not going to be sharing code or like hey use this directive here It's going to be mostly high-level about you know the implications of using it going headless The difficulties and or challenges faced when going headless and what headless actually means And so if you're here expecting, you know, coach snippets and how-to's this might not be the session for you But if you wanted to have a discussion about the practice of doing headless What this entails then you're in the right place So this is your your last chance. I guess to escape and offer up your seat to somebody else Again decoupled front end in the future. My name is David Wong. I'm eating on Twitter I don't actually talk very much about headless on Twitter. So, you know, there's one reason not to follow me I actually post a lot of Instagram images I've given this talk a number of times already to a different Audience every time I've talked in front of developers I've talked in front of designers and I've talked in front of JavaScript people who you know could give it You know two craps about what Drupal was and so if I ramble a little bit It's because I've tried to make this talk a little more inclusive than straight Drupal devs talking at each other And I actually only have about 20 minutes of slides prepared because I'm hoping to hear back from you guys I certainly don't feel like the end-all Master or the person who knows everything there is to know about this particular subject And so the microphone there is for questions and discussion afterwards I work for a company called Acquia as you probably have noticed by my shirt and this is version 0.9 of This talk I've given it like I said three times already because most JavaScript MVC frameworks are like 0.1 Anyway, I figured this talk is never going to be perfect, but if we're here to talk about things like that We're okay with less imperfection So we're here to talk about ostensibly quote-unquote headless Drupal Actually, let's do a first show of hands. Who's heard about the concept headless Drupal? It does this word mean something to people. Okay? Usually when I ask people about headless Drupal, I usually get two reactions. I get that or that And so you're either super excited like yes headless Drupal the culmination of my dreams or what the hell are you talking about and I threw this one in for my nieces. This is her favorite movie and as By proximity also mine now apparently So what is headless right? What is headless? Everybody has an idea of what headless is and I think all what 400 people have joined the headless Drupal group on G.o with a different conception of what headless might mean For some headless is Drupal as a content model and entity API minus the client-facing theme layer For some headless just means Drupal as a restful web services endpoint For some headless means Drupal serving as a content repository for a greater system of web properties or web apps For some headless simply means bring your own front-end. I want to bring my own front-end to Drupal More prosaically your app up front Drupal in the back, you know, whether it be another CMS system It need not necessarily be JavaScript and yes, of course headless Drupal does also entail Client-side JavaScript MVC frameworks rendering Drupal data and this is the popular and the widespread conception of what headless is But my point here is that headless is a lot more than that You talk to headless of some people like the old drush drush is headless. Well, yeah, drush is headless Drupal too This is a minority of use cases in the wild right now of quote-unquote headless Drupal The JavaScript MVC framework use case is actually a small sliver of this wider use case of using Drupal as a services endpoint And we'll talk a little bit more about this. So why would you go with headless Drupal? Why would you not use the totality of Drupal? Why would you chop a piece of it off? So these are some of the things you might get you get complete separation of concerns Maybe Drupal isn't or shouldn't be the everything to you You get a Drupal back-end and a front-end app of some kind and when I be front-end app I'm being very agnostic about front-end app your iOS app your Android app Your your other CMS app, you know Drupal feeding something like Apigee, you know all of these are headless use cases You can in theory get ultimate control of your front-end stack when you rip off the Drupal front-end and bring your own front-end app You bring your front-end to the table. It is absolutely yours to 100% control and tweak as you like and For those of you who are themers and traditional themers of Drupal That you know, this is a Drupal site. This is from a demo framework An open-source demo installation of Drupal that we use quite frequently at Acquia So let's take a look Let's just take this image right here 36 hours in Brooklyn, right? It's just an image and a view right It's it's just got a label. How hard can it be? How ugly can the markup be right? Right and there are people who've been railing about this for years I've been doing Drupal for seven of those years and as long as I've been in Drupal There's been a certain individual let's say the king of Denmark who has been railing against this sort of thing forever And it's been you know He's been pushing that stone up that hill for seven years and you know This is Drupal 7 this is after years and years of his it was complaining and cursing and this is still what we have Right and at this point I was going to do a more an impression but since he's not in the room I won't but but catch me at a party and I might do it You you get all the power of Drupal's content modeling tools, right? We're not taking any of that away Drupal's content modeling Drupal's content authoring and workflow all these things that we use on the Drupal Chronicle back end, you know, none of this goes away when you take away its front end, right? Users roles and permissions. This is a huge pain to implement on your own like you get this for free for free, right? And all the restful serialized entity data you can eat right because Drupal just spits that out willy-nilly as easily as you'd like it to and I wish Jeff eating or somebody like that. We're in this room right now. This value cannot be oversold You know like we get there's this Drupal community obsession with with oh, you know, it's Drupal so point-and-clicky and then even outside of the Drupal community It's so easy to point and click, you know, it's Drupal's for point-and-click developers It's not for real developers, but from a content modeling and information architecture and content Management for lack of better word perspective, you know, nobody ever said oh crap I just point and click my way to a really robust content model Nobody ever complains about that, right? Like if you want to go and write it and extend your own classes be my guest But you know point and clicky you can do a lot damn worse than creating robust relational content models pointing clicking wise And doing this, you know using Drupal says as a service layer I mean Takes us one step closer to that mythical holy grail of right once publish everywhere, right? You know like this this sort of idea that we're never going to be able to Write specific bits of content. We can't keep chasing Devices and and and contacts as they pop off like we have to get a step ahead We have to be more agnostic. We can't be just okay now We got to make an iphone, you know view or we got to make an ipad view. Oh crap Now we have to make something to adapt for watches. We have to be more agnostic from the get-go and As a bonus nobody says you can't keep your headed sites either, right? Like, you know, you can have some headless Drupal and headed sites working side-by-side or even at the same URL if you wanted None of that goes away What does go away though other things you don't get and this is where it gets tricky Anything that comes from Drupal's front-end and this depends right? I'm saying anything right now So let's assume that we're doing a fully headless site. We have cut off the theme layer entirely You don't get anything from Drupal's front-end Drupal is a data service at this point And so all the things that you relied upon from Drupal's front-end from like anything that comes from Drupal's render pipeline Oh, yeah, that's kind of gone Anything that involves say drag-and-drop visual templating Anything that you know allows site builders to say, oh, yeah, I want this panel here I want this block there. Oh, and I want this block there and rendered as this display or this view mode Yeah, that's kind of your front-end problem now, right? It's no longer Drupal's problem Drupal's not going to give that to you right now at least not the way it's architected and we'll talk about that as well too Panels display suite modules any of those Drupal components that otherwise might inform things like display that might help you display things that might Do it for you without you thinking You know these go by the wayside, you know like you it's one of those things like you want It's like when you divorce your parents at 17, right? You want emancipation? Sure, but you know, you're not getting allowance anymore Front-end facing form API form API, you know welcome to rolling your own form API Basically anything that comes from Drupal's front-end and I'm taking a hard line here saying that you know work work You know this is the The headless Drupal that you've heard about maybe the head not the headless Drupal you've built But the headless Drupal you've heard about you know Josh Koenig's talked about this a lot and we actually co-presented this about a month ago The idea that we're going to completely chop off the front-end Now there's degrees to this and I'll show you some examples of where these degrees can take place Like we don't have to unilaterally chop off Drupal's front-end But if the ultimate goal is to have complete independence of front-end and back-end These are some of the implications that we have to live with at least for now and These are not trivial hurdles. I want to re-emphasize this like this is not something you go and say damn it I'm gonna do it, you know and screw it This is gonna be easy and and these frameworks make all this work easy because it can't be overstated how much of Your customers of your clients of the people who end up using your Drupal sites Who aren't necessarily developing your Drupal sites rely on these functionalities or have come to accept Drupal as that thing that provides that Functionality, you know for years and years and years We've sold and we've built and we evangelize Drupal as this particular thing that will give you all these features and all these functionalities and now comes along in the last year a Practice that says yes, we will make our front-end developers lives easier. We're going to embrace these new technologies We are going to draw the line here for our developers and what I haven't really seen is much of a conversation around Well, what are the implications for the users of these sites? What is it? What are the implications for the perception of Drupal at large, you know? What does this mean about what's Drupal's role in all of this because it is changing and the changes that I just talked about are huge they're not trivial and That's sort of discussion sort of fallen by the wayside it gets a little, you know sweep swept on the rug like oh Yeah, you know like well, that's just something we just have to accept when we go down this route Well, I don't think all parties involved have really considered what going down this route means I think we've talked a great length about the technological benefits But you know how this changes Drupal's positioning to clients to users to site builders It's tremendous and it's something that I would like to talk about today And all this comes down to the fact that Drupal's theme system within Drupal itself is privileged, right? Drupal's theme system has access to things that the services layer right now in Drupal does not or at least does not easily have So why in the world do we even do this thing? You know after we talked about like the pluses and the minuses Why would one want to do this and there are compelling reasons for what would one want to do this? I asked this before and I was gonna how many people in here identify as front-end developers No, it's not about half. Okay, great The truth is front-end moves fast. It moves really fast. It moves way faster than Drupal Drupal contrived and especially Drupal core front-end You know Drupal is always chasing the innovations in front-end and I've said this in two talks already and This is something that I feel very strongly that Drupal is not a front-end trend center It is definitely a follower and sometimes a fast follower, but it's never a trend center And we're always more or less at the agenda of other forces when it comes to integrating things into the Drupal front-end Separating a front-end layer from Drupal allows it to move independently of Drupal itself And so the dependencies upon Drupal and Drupal's the Drupal pace car. Let's say, you know, we can you know Take the fast lane and move around it It'll allow front-end to move at innovation speed and like Drupal and the content model Which hopefully aren't changing as fast as your front-end technologies Move at its own pace your content model your site when you build it. It has its own speed as well The Drupal core moves at its own speed Drupal contribute moves its own speed your sites Data model has its own pace which it might be faster or slower than Drupal and your front-end You know your front-end technologies that the things that you want to leverage from a technology perspective they have their own pace as well and It's sort of I think it's been described as the Goldilocks solution I think by the four kitchens guys that everybody gets to use the tools that they like and move at the speed that they Like front-end developers aren't hand shackled to the limitations of Drupal's markup or its speed or its ability to innovate Your content creators your content modelers and your information architects get to use the same Drupal goodies that they've known Since forever and are familiar with and your your developers who develop in Drupal get to keep the Drupal parts that they like And this all goes back at least for me to the reset the lesson of the responsive web Which is we can't predict the next big change at least on the front-end You know the responsive web came and completely shook web development to its core Ethan Markoats seminal article on responsive web the one with the the black and white images on a list apart if you guys remember seeing that came out a couple months after Drupal 7 went official 1.0 and It was not a thing until then and Drupal 7 was shipped Basically in ignorance of this trend that suddenly came blew up the front-end development space and changed our work as front-enders forever essentially for the last four years and What are we doing in Drupal 8 to anticipate or accommodate the next earth-shattering change that comes in front of us As an aside, I want to point out that Drupal has two heads Drupal is actually a two-headed beast. There is the admin interface that has a head And there's the customer facing, you know, your public theme. That's also a head Right now. I've really only talked about cutting off one of them But we'll also talk about cutting off the other one So let me give you a couple examples of sites that I'm talking about who are at least in some way headless And maybe not headless in the way you're thinking but are truly headless When you when you think about the larger taxonomy of what it means to be headless a Drupal site For example feeding mobile apps right now. This is a headless site. There's there's content that's being pushed to a device that has no It doesn't care what the what the endpoint is that it's pulling data from on your mobile device. This is a headless Drupal site This is common sense media. I used to work for them. They have Common sense media or they have native mobile apps that are pulling data directly from the Drupal website and spitting it out Under the common sense media app. They're feeding data to set top boxes They have API's that they're monetizing. This is in many ways headless Drupal, right? You know the Comcast box that's pulling data out of this Drupal website. It's a headless Drupal instance There's an unnamed client a Drupal content is Drupal is being used for content modeling for narrative data It's plugging into this massive online retail system that's fronted by Angular So this yellow box imagine is its ERP system its blue box is Drupal and this green box is you know Whatever system that Drupal is also referencing and all of this is being combined and matched together and shoved into this one web App at the top which is powered by Angular Which is pulling its data from multiple sources. So in this case, it's not even headless Drupal It's Angular wrapping a constellation of systems underneath it of which Drupal is only a small part Headless Drupal can also be Let's say if you have a Drupal site that is pushing content to other Drupal endpoints that have a public face But this original silo does not so for example, you have an authoring environment. That's pushing content to multiple endpoints This is in a way headless Drupal as well And then sort of the holy grail at least from a front-end developer is that you have a Drupal site That is completely separated where you have swappable front-end teams Techniques and systems and you have this Drupal base. That's consistent. So let's say, you know You have a Drupal base of a large site you want to build the front-end of ember one day You're gonna have you're gonna have another team build it out of Angular. You have another team that's building it out of I don't know React or whatever. I shouldn't be naming all JavaScript, but the same idea that you can Build sites with a consistent Drupal back-end, but let the front-end be whatever you want You know as needed and the last thing And I don't have this is not very well thought out, but but this is I know it's kind of a thing You know there's this talk about the internet of things and it comes back to this notion of being prepared for the next big thing and being Moving beyond this idea that Drupal has to own everything end-to-end and predict everything and that we have to keep bending Drupal The internet of things shmin and of things I'm 34 years old and I'm already seen enough of the internet where I'm like Internet of things whatever, you know let the kids have it, right? I don't even have kids yet But I think the the the the propositions offered there are valid You know like Drupal content on non web devices. Jesus talked about this I think everybody here at least has one non web device that might have a browser that you know You know Drupal reading in my Kindle. Okay. What who really wants to do that? You know, I think being dismissive of new technology before it really emerges is a fool's errand And I think that if we were going to dismiss things like the internet of things out of hand before They really have a chance to explode we're gonna look like idiots in the end if we don't you know bet correctly And I don't feel like like betting against it is a good deal. So and this is where I get kind of out of there What if I I'm gonna preface this by Larry Garfield the guy in the vest in the middle Came up he said yesterday that Drupal's admin UI doesn't really have API so much as it has buttons with DB calls mapped to them And this goes like today idea that Drupal's theme system and Drupal's admin are privileged privileged systems within Drupal itself Like they have access to APIs that no other system in Drupal do and so the idea of making a Completely decoupled but for you know equivalent front-end is difficult is because we have an architecture like this right now But what if all Drupal front-ends were decoupled service-based apps including the ones that ship with core What you know, what if the admin if seven theme were actually seven dot app and it was say a backbone app Or you can swap it out with an ember app or you can swap it out with whatever the hell kind of app you want You know it versus the twig theme system, you know, what if we could do that? What if Drupal was built like that from the get-go such that these systems could be equivalents to what come with core And that that's a bit of my challenge Okay, what the pantheon sign? Oh, it's because I work for Acria. That's why Oh And so that's my challenge, you know And I've had conversations with people like what if this could be possible What if this is the way Drupal was built or at least a very viable option? What if this wasn't something that didn't take a tremendous amount of work like it does now and Wasn't full of compromise, you know What if we everything including Drupal's native front end started on the same foot as everything else? And this is the little coda and this is my little wrap-up. I don't have like a punishing or a drive-home message, but Drupal has for its existence tried to be all things to everybody It's an all-in-one soup-to-nuts Drupal shaped hammer Everything can be solved in Drupal Drupal wants to solve your complete web problem from the moment You want to enter content to the last bit of CSS that you render you build the app Oh, yeah, sorry that took a second you bend the app to Drupal You build the use case around Drupal and you live and die by the entire stack until now Everything from your hello, there we go presentation Content data model all three layers are done in Drupal and are expected to be handled by Drupal But what if Drupal is just another layer in your stack and didn't have to own all of it And you could swap out any piece freely at any time for any other technology that you wanted and so my argument at least is by decoupling the front end we make Drupal as a system more flexible more useful more relevant to developers in the world than less and There's this analogy that Josh Koenig used and I really love it there's a big Venn diagram of Drupal developers and this other circle is Skilled front-end developers and the intersection of the two is so narrow as to be almost a line or maybe a dot and that there's a Universal development and work that's going on that's kind of outside the purview of Drupal And we're not leveraging it whatsoever And if we could bring those two circles more closely into alignment even by a fraction we would introduce so much more Fresh blood ideas vitality and developers into the into our ecosystem than we have right now and Mr. Spock agrees with me so So so these resources have changed a little bit There's a headless Drupal working group Which is kind of like a bazaar of people throwing out their ideas and there's not really any focus and actually part of the Reason I pitched this conversation is to bring a little more focus through the discussion So that we have something to work something towards I know Amitai is giving a talk later today about his work with Drupal 7 and And and headless and his interpretations of how headless should go. I would highly recommend going to that too He likes to talk as much as I do which is great And I'm David I'm eating on Twitter feel free to berate me on the Internet's and I want to have a conversation here These are all the slides I have but I was told by Stephanie that I must have this slide on here So you can cast that judgments upon me and and and rain and rain them down like blood from the sky But I don't clap but clapping when it's over. I would love to hear people's thoughts on this at the microphone And if I know it's gonna be difficult But if we could try doing go into the mic and if not if that's not gonna happen, I'll just repeat it All right, stripe shirt Okay shot. Let's shop. Yeah What we need is like a really a boom mic, right? You know and like with a big fuzzy You know like a TV show I'll just repeat your question. Sure Right, right How do we sit versus other CMS's that have similar systems? I'm glad you asked Wordpress has some stuff going on that's very interesting Wordpress has oh you can't see is haha. This is on my screen. Okay. Here we go Hey, everybody WordPress has something called client dot j dash j s which is a reference backbone app Wrapping the WordPress JSON API. So this is a reference app that they've built For other developers to to copy and to look at I Know I think it's is a type of three. It's one of the major European CMS is is working towards fundamentally transitioning their architecture such that their admin experience is a services-based Architecture and so is it type of three? Okay, I mean it's not shipped yet, but it's something that they're actively there's an initiative there to bring that to light And so at least where there's simply there's WordPress. There's type of three There's others there granted all of this is very much the cutting edge, right? Like I'm not selling the alarm after the house is burned down like there's an ember But you know that the fire has not consumed us all yet But what I would like to do is At least get in front of this problem and not wait until Drupal 9 to seriously have this conversation You know like during you know Drupal 8 has introduced all this great change in decoupling systems that we previously thought were monolithic And we've broken things apart architecturally at least on the back end And I mean the very very back end not like the seven theme But like the systems underlying it that allow for much more plugability and Decomposition is that the right word? Yeah, a deep decomposition of components underneath Drupal that allow at least in theory swapability where there was none before And I would like to see a similar level of effort expended for the front end such that we can do similar things there I'll come back to you Your thoughts around So the the the question asked was a client wants to refresh their D7 site where the content model is Satisfactory to them, but they want to have a front-end refresh that may be more than just CSS How would headless, you know, how would headless you could use case for this Right, right. No, and that's one that that's a good point. There is no clear and Obvious and or recommended way to do this right now. Everybody implements it from scratch. Go ahead Yeah So the for the people on the TV who watches next week. It's a solstice project on GitHub an angular wrapper for solar as an intermediary of Drupal sites Did you want Larry's actually going to step up to the mic. Wow following the rules That's why I took a seat on the aisle here. So I could do that job. Good job so one of the challenges to what you're describing is an awful lot of Drupal's power and flexibility comes from that tight coupling and the fact that you know you have Render arrays that are modified by a configuration that is embedded within a piece of content that controls the display That's how you get panelizer. That's how you can't even do that kind of thing if you have You know a fully decoupled front-end and back-end You lose a ton of that flexibility because everything is a lot more coarse-grained And if you made it as fine-grained it is now then you haven't actually decoupled anything, right, right, so I'm not going to say we shouldn't do it for that reason I'm actually going to say we desperately need to do it But how do we make the argument that it's okay to lose? Per elements cache capabilities like we have now with render caching in the name of this kind of decoupling How do we make that case that certain things will break and not be possible if we don't privilege one theme system over another? How do we make that? argument I think and this may not solve the problem, but the way I'd envision it always is that there would be I I Don't want to open up the universe for any and all possible front-ends But I think an acceptable compromise that would get us a lot more forward that would move us a lot more forward is to have a Reference angular implementation that maybe is tightly coupled to Drupal a reference backbone implementation That may be tightly coupled to Drupal that Drupal is making assumptions about this front-end to a certain degree That would allow that kind of privileged Coupling and then that you know we can at least build an angular map It may not be any anger app, but it might be you know, we might be able to For lack of a better descriptor, you know something like sub theme this this angular app to build Angular apps off of it won't be a blank slate one But it would make certain assumptions about Drupal and Drupal will make certain assumptions about it and that we would have Instead of just being tightly coupled to twig and the rendering rays and and the Drupal theme system We would have at least multiple options at that point So if I could continue on that, yeah So you're not as much saying don't have a privileged front-end as have multiple privileged front-ends I guess I would say I guess I think it's multiple privileged front-ends is better than just one and or a highly deprivileged one And I get what you're saying. I don't think it's actually feasible Because you know the power of having everything in memory together in PHP is where that coupling and power comes from There's just things that you know, there's a depth that an angular app will never get And there's a depth that a front-end built with Silux or symphony that's talking to Drupal over rest behind the scenes and still serving pages is never going to get that Unless it has render arrays by doing through it now. I'd love to get rid of those all those render arrays I'm actually asking you please help me make this argument To fully break these things apart, but how do we make that argument that there's some level of? Easy flexibility that we lose when we break things apart and simplify them that way. I don't know the answer I so I am throwing that out So while we marinate on these questions out anyone else please jump in please anybody who it's okay glasses Please step to the mic. Sorry. I don't know what it's a say man. Fair enough. Yeah So yeah, I mean I don't have the answer either, but I think that it might Make sense to like talk about specific Drupal versions now that we have the beta out and everything, right? I mean and think of it as separate problems. I mean, yes, yes, we want to solve that particular issue in Drupal 7 No, I also think that it might make sense to to talk about these issues like making You know as you said you don't you don't have access to form API and you don't have Access to the output from the field for matters and so on so maybe think about these problems separately and try to solve Each of these cases separately and as as you know as as much as you as you can and achieve as much as you can But break them into separate problems instead of thinking it thinking of it as you know one big giant sure issue I'm big on open data and governance so wouldn't it be interesting for Drupal to be like the headliner for every single government to Publish their data as an JSON format together with their sites in Corporation and that way just push Drupal to to more and more government sites try to promote it and Actually fill in the giant giant gap We have right now because a lot of governments just don't go for big data because it's a lot of stuff stuff to actually deal with right now They have to actually redo most of their stuff because they can't just do it with the platforms they're using and If we can then in one way or another propose like yes, which the Drupal and It's basically with a click of a button and you just publish JSON data next to your current Like your current front end without changing anything would not be an interesting idea to actually promote and work with Yeah depends on the government Yeah, obviously you have the thing is that's our North Korea. We love that Yeah, but like Belgium is pretty big on it right now. They're trying to promote open data But there's not a lot of government well internal government doing it because they're actually The biggest issue is they have the current sites are using do not support Open data in one way or another and the thing is no Drupal 8 support for services is much better than 7s out of the box Right, and then this is almost like a talking point at this point about Drupal 8 Look, oh, you get the rest module and it's actually kind of nice to have it built in The question isn't that the rest is rest going to be strong enough in D8 It's what are we getting out of rest and how can we make that more robust for the needs of a fully baked app like this? You know like we can get data out of Drupal just fine now The question about governance like that is just it's governance of the government You know it's getting clients on board with hey Let's expose some of this data because Drupal can't do it and fairly trivially to it that At this point we want to make it more robust such that we can build better apps around it than just simply querying No data let's say All right, who wants to step up Okay, I'll repeat your question. That's fine. So oh That's hard to summarize So I think if I if I'm hearing you correctly you to take a page from the the single-page app model where you know You're lots and lots of JavaScript calls as needed pulling in data, you know just in time and then rendering it as needed. Yes Sort of okay We got a fixes mic situation. Yeah, did you ever reply Larry? conversation I guess the implication of that then I think that goes back to what David was talking about before that means No panels no panelizer no display suites no field for matters You have re-implemented all of that in your angler app. It's anyone actually want to do that. I'm not volunteering but how do we You know, how do we have that capability without having that, you know, you're configuring the formatter as part of the So Like if you if you manage to share the data that you clicked In in NFD's modules like this place you'd you can you could use it in in the JavaScript app to Render whatever you need and that way like you wouldn't take everything away You just a half of it or some part of it So and do it again. Yes. So you're saying you're still re-implementing your formatter But your formatter configuration can still be on the server. Yes One of the so one of the things that that Jesse Beach and Carl read a minute talked about And I feel like I'm sort of channeling and speaking for them as well because they couldn't be here We talked about this in Austin is has anybody seen Carl read one's talk about Writing a new render pipeline Sorry, you're like that. So normally it's Morton that's trolling me during my talks and so you're taking Morton's place Okay, there we go. So Carl read a man had proposed this new object-oriented render pipeline, which was like, okay Yeah, yeah, yeah, and then in the end He was able to address by fragment and tired rendered sections of pages of nodes By URL and so, you know, give me this URL of this region this block down to this field rendered in JSON and When both Jesse and I saw this not to speak too much for them. It was just kind of Eye-opening like wow, why can't we have that all the time like we're getting kind of the best of both worlds We're getting Drupal rendered Objects in JSON addressable by URL that we can predictably call again and again and again And these can be fragments of an entire rendered page. And so, you know Drupal is Informing it. So the fundamental problem that we're talking about here that Larry's bringing up is that there's no way in the current services Bake architecture that you can build a Drupal site Easily or it without tremendous pain that allows the author to both express content and Intent for that content. And so if the author has an idea of like this needs to be a sidebar and this needs to be, you know Rendered as a blah blah blah on this different side There isn't a reliable way to do this right now via our services API because you're just going to bring back a node, you know unrendered via Via our JSON API and then you're going to have to decide what to do with it once you get to the angular side And angular might not know anything about, you know, how Drupal might render it, you know via plugins or via Via panels or, you know, what have you and so that that's part of the way there and I Feel like this this sort of space here what we're trying to get Drupal to Be all things to all people but in a different way than it has been before Is this weird place where Jeff Eaton gets on board and people like Jesse get on board and people like myself get on board Where the content strategists are trying to build a more context context and device less Sensitive Drupal Drupal that that's more universal that isn't built for just desktops or just built for html or just built for Responsive websites, you know the Jeff Eaton's of the world and then there's like the front-end engineers of the world who want to use tools like Ember and Angular and react and you know, whatever the hell new framework comes out tomorrow Because it's better tooling. It's more fun to do and it's a damn site better than Drupal's theme layer And then there's the third which I guess I sort of fall into where I Don't want Drupal to to stay The current Drupal model is getting a little long in the tooth and it's hard to defend against other Products that might do certain things better Drupal as a whole might do all of it better But that we ignore certain innovations in areas front-end or otherwise is at our own peril because that's where talent and interest and attention are Going and we want to be able to capture at least some of that or at least be relevant in those conversations Because if we don't then it's just me like oh Drupal That's a site to use to make your complex website not much else. Oh Yeah What right no, that's absolutely possible So there are people who are building angular components into their Drupal website So Drupal's rendering a page and then as one of your panel blocks or panel panes is an angular widget of some kind You know like this this is the if you look at Austin of Yeah, the Sally Sally young did a talk about I think it was NBS MEC and they're using that technique Angular embedded within Drupal as a portion if not the majority of a display There's also people, you know like common sense media like I gave before where they have a headed website Regular plain old Drupal like you would make right and then a separate stack that mirrors that from a data level But is just an API endpoint and all their API stuff based off where there be iPhone apps You know Comcast set top boxes, whatever I'll talk to that So there's that as well. I mean that that's what people are doing currently the goal is for these D8 or D8 point X or whatever to Not have to jump through hurdles to not have to write all this service of stuff to not have to sacrifice as much as we're sacrificing as I described so that These alternative front-ends can be if not first-class citizens at least not sitting You know essentially in the bathroom in the tail where they are right now Stripe shirt again Mike doesn't like Talking about JavaScript libraries and frameworks that might sit on top specifically for a minute and forgetting the other options that could be the head In your experience and From feedback you've received so far case studies you've heard Do you think there are any libraries that are better fit than others for whatever reason be it community? Technically whatever for this kind of implementation with Drupal or is it literally just it's a free-for-all. I think it's a free-for-all I think you asked three different front-end developers to get three different answers. I think the technologies are so new and the Changes the differences between them are so opinionated that it really is just almost religious now at this point You know like is Android or iPhone better, right? Let's not answer it from the core doctor of sense, but like from a you know usability sense, you know is your Android iPhone better, you know You ask three different developers, they'll tell you three different things So the question is if So the question is will the complexity of allowing multiple client heads to a triple site in the future lead to overwhelming or Increasing workload and or complexity of projects. I actually think it I Think in the long run it actually reduced complexity in that you can just we can that Drupal site that you're building a head on top of May last six years seven years doesn't change right or changes slightly right and you can swap out that front end as You want you can swap out the vendor that provides that front-end as you want if you have a vendor that specializes in a particular JavaScript skill set but knows nothing about Drupal they can still write a robust app on top of your Drupal site Right and somebody comes in as long as your as long as your your API is well documented I mean people have been writing web apps on top of robust API's for you know decades now Sure, right. Well, that's true, and I'm not saying we should get rid of the HTML front end Anyway, I'm not I'm not saying cut off Drupal's existing head You know, I'm ultimately saying you know give the option of either popping that one off and like a Lego man Put the one with the red face on versus the yellow face or alternatively have multiple heads You know in an array on top of your shoulders Each with different colors There's nothing that will put nothing I proposing is saying let's lose Drupal's current ability that's published straight to HTML I'm never going to propose that. I'm not saying Drupal should only be a back-end architecture Never that's never a goal. Well, I don't think that's necessarily true. I think Having more options when it comes to publishing given the proliferation of the context that our content is expected to be on is Only a good thing like limiting ourselves the HTML. I think is a fond It's fondly looking at our shoulder into a past when web development was more simple I think we should embrace complexity. We should embrace innovation and not Pretend like it's not going to catch up to us So I've heard a lot of talk about these swapping out of front-end and front-end Systems being highly opinionated. How do you? Do you see these front-end systems being contributed back? How do you see this is? impacting Contribution are they going to be so opinionated and so specific to the content model as to be unable to be contributed back to the community? Wow, that's a hard question In this perfect world that I've envisioned right that isn't really fully visioned. It's more like a remembered dream than anything else We would have Reference apps like it let you know for each of Several front-ends and that these apps would be general enough that you know like like the way how base themes are I mean base themes are really opinionated, you know Omega 3 versus Zen versus, you know Versus Aurora versus what's another opinion a one? Adaptive theme your mother ship right, you know all of these have strong opinions and people in Drupal have managed to get along with Those just fine, right, you know, they might have arguments in the hallways or say, you know Your system sucks, whatever but sites get stood up all the same. I don't see that Model changing for something as you know swapping out a front-end whether it be, you know, this JavaScript framework or another Front-enders are by nature. I think very opinionated or at least the opinionated ones end up speaking and that Propagates more opinions, you know, and so Yeah, please Just wanted to make a note about the the content writers so it's really important to to realize that when we go decoupled that the The the administration experience in the content model is far different. So it's not page centric It's it's much more agnostic to the endpoint. So the difficulty in that is The way in which content is written and stored Doesn't really allow for preview and also requires a different Thought process as to how to create that content So that's something that's really important. So I think For this to work first of all it needs a particular type of organization and a certain level of complexity Overall that I don't think this is a hobbyist. Oh, no, no right by no means, right? This is yeah is more of a larger structured organization direction and Also, the content model will likely still have to have some sort of a page centric option for cases where you were Explaining that you know the author wants to have that right sorry bar. They want to have that that sent So it's probably the the solution is some sort of a blended approach to structure content. That's completely decoupled from the endpoint and page centric Content modeling and you know how that gets divided on that point what I'd say is Those editors are going to be incapable of previewing the content to all of the endpoints that it flows period So what has to be important is to identify where their concerns lie Does that person really care about the mobile experience for their users? Or is it just that they really care when they're compositing the days editorial for the splash page on the home page of the site? And and so it's it's with anything it's about identifying where the concerns lie from the stakeholders point of view But I think what's being proposed is why I'm trying to think about how to deal with the fact that we are in a multi-tenanted multi-device world and Support the fact that that's going to keep growing faster than our editor's concerns will Yeah, so maybe this ties in a little bit with that contextual thing But I was just going to say I mean just thinking about the menu system alone and the idea of having a pre-expanded section and The idea of then maybe being able to drill open up other sections and go in and that's been sold You know three four different ways just in Drupal on board and then you know It's going to be approached a million different ways from all the other You know our frameworks and so but all the user ones at the end is just that little pancake button and just to click on something But you know it's sort of so over diversified Do we really exhaust all the no we can't Just because they're clapping doesn't mean we're done Yeah, but go ahead Back in the days when we built our own CRMs, you know, I did a lot of fiddling with trying to headless stuff one of the big challenges is forms, you know, you mentioned forms API and Has there actually been any practical thought about how we would manage the input and output of forms? Through this kind of thing right so what I mean that you know what I keep talking about having a reference implementation Is that there is no reference implementation? There is no best practice, you know in fact There might only be worse practices out there, you know Who knows because there isn't actually that much sharing going on either and I'm encouraged to see as many people as there are in this room today But certainly anybody who's doing this sort of thing right now seems to be doing it mostly in isolation Except for a couple people who are very verbose on the g.o. Group and are sharing everything like code and everything Um, and I actually would wish they share less because they tend to dominate the channel But there is no collaboration around this yet It's really really new. I mean it is really new and there is no structure. There is no initiative. There is no working community even around this and I Mean, I would at least consider it a minor minor minor victory If walking out of this Drupal con there was at least a more cohesive community of discussion around this topic because There are obviously a lot of conversations to be had left, you know beyond this 45 minute one And there are people who need to hear it beyond just, you know Larry Garfield that who's who Need to see the the importance of this use case, you know in a more broad sense And then on Larry's side the kind of how far have we made any kind of progress for Drupal 8 on The removing of the button that is the you know the admin functionality being a button on the form rather than being an API call It's a slow and ongoing battle Progress is being made Like the big one is The entity API actually exists independently of the node form now, which is the first time in Drupal history That's been the case. So that's a huge win But it is an uphill battle because we're used to It's easy if I just do it all as one thing That doesn't make it simple that makes it easy for me to write right now But it means all I can do is that one use case and then that cuts off all of these other potential heads So, you know, I've been fighting that fight at a different architectural level for a long time And it is a hard battle and that's why I'm asking, you know, how do we make that case? You know something else that occurs to me who here's a module developer Who's module developers in the room? So I'm gonna call it to you the same thing I've been saying in a lot of my dev talks Push everything you can to your twig files in Drupal 8 Because this is wonderful little tool called twig.js that compiles twig templates the same twig templates you have in Drupal to JavaScript based templates instead of PHP based templates So you can override Templates on the client side using JavaScript instead of on the server-sizing PHP It's a little more work than I'm just hand-waving, but There are tools like that if we can push things to the right place that let us pick and choose selectively and I think that's My best guess is, you know, we need to be able to break things at a place where this piece we can then do selectively so it's not as much rip out the head as You know start picking out hairs like push all display logic to twig templates because then they can always be overwritten and Reimplemented client-side in JavaScript The the initial goal of the whiskey initiative and of the scotch initiative was to have all blocks as their own Things which means something like Facebook's big pipe where? You know you load at the skeleton and then you parallel request 20 blocks Which come back at strings and you assemble them into the page becomes really easy to do that that's the kind of stuff we've been trying to build and The biggest challenge has been fighting against the architecture That is already there that makes that really really really hard and fighting against the people who are still trying to leverage that architecture So that's that's the challenge we have is You know making a different set of trade-offs to make this kind of stuff possible and Just making the case for making a different set of trade-offs is hard even before you start coding it No, I agree I don't expect this to be like an easy sell to to the larger Drupal community, but Somebody's got to carry the torch. And so, you know, I'm here I'm up before before everybody leaves for lunch and because I'm really hungry too And I'm going to start getting cranky and saying opinionated things if I don't eat soon There is a buff a headless buff at one o'clock in g room g 110 It's right after lunch. So everybody should be you know sleepy and satisfied and we'll have much more moderate opinions. Yes When is it? Yeah, oh, you'll you'll bring it at the buff. Okay, so if you come to the buff, you will show a scaffold application He's building a marionette for writing web apps. Um, once again, cast your judgments upon me at this URL I'm at eating's if you want to hate me Or tell me I'm stupid. Otherwise, thanks everybody for coming. Enjoy your lunch