 I guess we'll start on time so everybody can get their dinners early or make their planes. This session is my brain is full, keeping pace with front-end and UX innovations. So if you're here expecting something else, this is not the right room. This is also way more people than I expected, so thank you all for staying until Thursday. We were totally ready to play to an empty house and just tell jokes and show meme gifs, but apparently we have to, you know, we're going to have to do our job today. Thanks for coming out for the last session. I appreciate that. Please work. Oh, here we go. Okay. My name is David Wong. I'm eating on Twitter, and this is my partner in crime, Brian Wald. We both are Solutions Architects at Acquia, and we've been sleeping for the last four days in an air stream trailer on East Austin. Most of these ideas came from that experience, so if they're a little kooky, blame the air stream. Before we start, let's take a show of hands here. Who here considers themselves a front-end person? Okay, a better question. Who here does not consider themselves a front-end person? Okay. Okay. There'll be something for you, too. You might have to wait till the end, but there'll be something for you here. So sort of the gist of this entire, you know, our thesis is front-end developers are expected to know a lot, and I'm guessing the majority of you out here who are doing front-end would not disagree with this statement. No, really. They're expected to know a lot. Here's a representative far-sight cartoon for those of us who are old enough to remember far-sight being in the newspaper. There's a child with a particularly small head saying, Mr. Osborn, may I be excused? My brain is full. And this is sort of the general feeling that a lot of folks that I've talked to, both of us have talked to, have expressed about what's happening to the state of the web, especially in the front-end, and, you know, how one's career or one's job might fit into it. I'm going to read a quote. Oh, Jesus, what is wrong with that? It's your fault. No, it's not. Okay. There's a quote from Frank Camaro. Who here knows who Frank Camaro is, the designer? Okay, not a few of you. Frank Camaro is a print and web and interactive designer of no small renown. He's worked for, you know, if you look at his client list, it's really big. And he has a very popular blog, and he's an ace designer. But this was a blog post he wrote, you know, less than a month ago. And the quote is, it's time to come clean. GitHub is confusing. Git is confusinger. Pretty much everything in a modern web stack no longer makes sense to me, and nobody explains it well, because they assume I know some fundamental piece of information that everyone takes for granted and no one documented. Almost as if there was a secret spread around to most everyone sometime in 2012, yet I somehow missed because, you know, life was happening to me. So I've given up on trying to understand even the parts where I try to comprehend what everyone else is working on that warrants that kind of complexity. And now I fear that makes me irrelevant. So I nestle close to the story that my value is in my quote ideas and capability to quote make sense of things, even though I can't make sense of any of the above. But really, maybe I'm doing okay, because it's all too much to know. Let the kids have it. And just let me put it this way, Frank Camaro is under the age of 35. So this is not an old man shaving his neck beard talking about the web. This is somebody our age or possibly younger. So how did we get here? This is just to warn you, this is not going to be a very long presentation, but we're going to take a little short history here. So, yeah, so here's the cut of Drupal 7 Alpha 1, which released on January 15, 2010. And this is where we're at. DrupalCon SF was happening in April, 2010. And I just wanted to point out, let's take a look at some of those tracks that are happening in 2010. So we have things like, you know, theme preprocess functions. We have things like a jQuery for designers, you know, PSDs to HTML. Like that was a thing that we were doing back then. You know, we were learning about typography and all of these things like that. These are things that we would consider as, you know, as themeers. We were considered, you know, these were things that we had to kind of just figure out because things were moving so fast and we wanted to, you know, take a look at what was the next possibility. And so then let's take a look at the next year. And what I'm trying to point out here is let's take a look at the tracks here. Okay, so we have a track for theming in this year in Chicago. We also had a track for design in UX. And look at all the rest of the tracks, you know, you have pretty much standard. This has been the same tracks for the last five years. Every other one has been very, very similar in terms of development, DevOps, and so on and so forth. And so then Denver happened and suddenly changed again. Now we have mobile. Now we have a design in UX. The theming one went away. You know, we don't have a front end track. And then we jump forward to today. So I skipped one year, but, you know, you get the idea. So let's take a look at now. So we don't have that theming one anymore. We don't have the mobile one anymore. Now we have a front end one and we have a UX one. And it's just one of those things that's just changed so much. But all the other tracks have stayed pretty much the same. So we have to adapt every year and everything's changing every year. And it's not even just like simple components. The entire basis of what we do has changed over these years. And in short, nobody knows where to put us, right? Now we have a front end track now. Maybe it's better, maybe it isn't, maybe it'll go away next year. But, you know, over the last five years, there hasn't been any consistency on where this sort of thing that we're going to talk about has sat. And there's confusion throughout the Drupal universe among the developers and the community at large about what kind of role front end plays and what kind of skill set go with it. And it's the kind of thing we're going to talk about today in the presentation. So the state of the web as Drupal 7 was released. You know, this is four years ago. Drupal 7, this is currently the still active version of Drupal that we've been working with up to this point. When it launched, or when it was released rather in 2010, IE 7, 8, 6, had 56% market share. Who remembers this kind of thing? You know, IE 6 support wasn't like a joke or an add-on fee. It was a thing, you know? And no one was thinking about mobile. Yeah, and then 2%. No mobile, right? What was mobile? My pager was mobile, you know? Everybody loved static CSS grid frameworks. A shout out to Massimo Vignelli, if anybody knows who's out from him, just passed away a couple of days ago. If you haven't seen Helvetica, absolutely see it. Grids, as we know, today were not existed. We got a lot of them, yeah. Who remembers Blueprint CSS? Drupal.org was originally prototyped against Blueprint CSS, and to my knowledge, still is based on its grid. Who remembers 960GS? There you go. Who's gone to a 960 or Blueprint session at a DrupalCon? Yeah. Web typography. And sorry to, Angie, if you're here, I copied this slide off of you. This is your font stack, until not too long ago. Those were your choices. That was it. And if you wanna do something else, it was gonna look like this. You're gonna have to inject Flash into your site that was not highlightable, and you had to use these crazy tags, and you were like, oh, what happens about the SEO and all kinds of crazy stuff, just to get some different fonts to show up? And then it didn't work on mobile, so there's that. When Drupal's ever launched, we had competing JavaScript libraries. This was an active question at the time. Who here has built anything on mood tools or prototype ever? Right, so it's, you know, what about the last two years? Exactly. I'd hope not. This was an open question, and I'm glad Morton's in this room, because I was thinking of him when I wrote this slide. The need for front-enders to learn version control was still an object of active debate as recently as the launch of Drupal 7. It wasn't, you know, maybe, gamers don't have to learn version control. Maybe you can just get away with doing what they were doing. FTP. Yeah, you know. Why would they need to re-revision their code? You know, that sort of thing. The ability to maybe possibly use CSS3 was a major point of contention. Like, oh, I don't know about this progressive enhancement thing, you know, like, you know, these cut-off sprites are working pretty good for us, you know, and... And rounded corners were really cool, so you had to do that. And how are you gonna do that with those images in the corners position? Right. Lifetime of Drupal 7, the same stack we were using before. All these assumptions are still in place. And so the Drupal front-end during this time, you were a quote, themeer. Who here still describes themselves as a themeer? You know, either in title on their card or by other people. It's okay. Okay, okay, more than you don't count. So this is, you know, your title might be something fancy. Other people might have used a different title for you, you know, in 2009, 2010. And maybe this is the way that you used to describe yourself, but the greater Drupal community acknowledges you as a themeer. And a themeer with it comes, you know, with theming comes a certain set of implicit definitions, which we'll go to in a little bit. At the time, when Drupal 7 launched, this is your media query. You have style sheet. Print. You know, print, your print media, style sheet injected into the info file. This is a media query. This is your style sheet, writing really, really long selectors in line. And hoping that targets the right, you know, H2 in your views. And this was your job. This is what you were doing. This is what people thought of you as, oh, okay, so we finished our application, now hand it off and they'll make this HTML. To make sites that look like this. Or this. Or this. That's the state of Drupal when Drupal 7 launched and the state of the front end. So what's happened? And I'm sure a lot of you can have different experience about what's happened, but we'll cover something else. Or when it happened. Or when it happened, right? It happened a little differently for everybody, I guess. Right. So HTML5 and CSS3 happened. You know, that was a big thing. That was a big game changer for everything that we just talked about. You know, no longer having to slice up your PSDs and, you know, insert columns for various different images to make them rounded corners. You could use that in CSS and it was probably okay because the browsers were changing. You know, people were using browsers for the most part that were advanced enough to handle these types of things. They had this built in, you know, we were progressing, moving away from the static HTML pages to applications that could be rendered in the DOM and be handled and do things like this in a more sufficient way. I want to point out this little inflection point that the blue line is IE and the green line is Chrome. That was a very happy day. And that actually happened in, I think, 2013. So you should have clapped them. Like, it's no thing now. You know, like whatever. Mobile happened. I think this goes without saying. Like I'm sure every single one of you in this room has a device in their pocket that's directly responsible for changing the front end landscape in our industry and continues to use it. You know, that's not going away. So that led to... MDOT sites. Well, here's built an MDOT site. Yes. Well, you're still building an MDOT site. Oh, thank God. Oh, congratulations. Which led to mobile web apps. Who here has built a site on jQuery mobile? Who here has built a site on something like jQuery mobile? Something that faked up your site. Your type gestures and all those types of things. Guys in the back, there's more seats in the front if you'd like. Come on down. Price is right. You're not closing down. Adaptive websites. Who here has built an adaptive website? A site that was fixed with on a different device. Okay. And then just a little over exactly four years ago, the 25th of May, I think it was, this article was published. Who here recognizes what this article is? Yeah. So this is the original Ethan Markot article on Alistair Park describing responsive web design. And this, in addition to mobile, more than anything has completely shattered the game when it comes to front end. And this idea of progressive enhancement, which I thought was total BS before mobile and responsive came out, is totally a thing. Like a capital T thing. This isn't just a buzzword that's known about. Progressive enhancement is an actual practice that is alive and well and even standard today. And before all the tools, that was really hard to do. Yeah. That's something that you could just do because you had something that was going to make it easy for you. It was like you had to spell everything out. You had to use browser prefixes. You had to do all kinds of crazy stuff. So let's pause for a second to consider it here. This, all of this change happened during Drupal 7's lifetime. Hell, it's still Drupal 7's lifetime. All this happened and Drupal 7, the tar ball you download of Drupal or the git repo you clone off of git.drupal.org, the same software, none of it has changed. All the assumptions that went into making Drupal 7, the Drupal 7 core are still there pre all these revolutionary things and we're still building science at the top. I wanna point out it's not like a blame thing that this hasn't changed. It's just one of those things that you, I don't think people were quite prepared for how quickly things moved. I think in earlier, I was watching one of Angie's speeches and she said you could take any word in the dictionary and add JS to it and you have a project, you know. So, you know, at this time it was something that, you know, we didn't know how it was gonna change and how quickly things had and what kind of fads were gonna come and go and, you know, people were just trying to make the best of what their situation was because it sucked mostly. So meanwhile, the rest of the web world that is outside of Drupal, Ruby's taken off, right? You know, and Rails and opinionated frameworks and all these other web frameworks that you can build viable websites, web applications out of increase in popularity and they have their own way of doing things which is at many times diametrically opposed to the way Drupal does things and there's an entire ecosystem of people that are used to building things a different way with a different perspective. JavaScript became cool again and JavaScript, when I was in college, I was like, what the hell? Like it makes things blink, you know. Like JavaScript suddenly is the cool language since everybody already knows it. Let's just use it everywhere, right? So in the back end, on the front end, for automation, for even more automation, for managing your packages and what the hell for everything, right? But, you know, JavaScript is still JavaScript and you've guys seen the book, right? This is the definitive JavaScript guide and this is JavaScript the good parts which is like a quarter of the size. So maybe JavaScript isn't awesome after all. So let's write a meta language that compiles down to JavaScript. Who's used CoffeeScript here before? Okay, same idea with CoffeeScript. Sure, let's do it with HTML. Who's written Hamel before? Okay, and we're gonna do it with more hands. It's much, much more large audience here for this one. So, you know, things like SAS come into play and things like Glass and things like Stylas, you know, that was the thing for a little while. But, you know. It's still kind of a thing. It's still kind of a thing. But the point is, you know, it was one of these things that we've gotten to this point where we're like, okay, we have to get some sort of tools to make this manageable. There's just too much, we're dealing with too much of an inconsistency across all the browser stacks of all OS and everything like that. So we started doing all of these things that make it more manageable and take care of all the tedious annoying pieces of it. That's why this came about. Frameworks, and then libraries on top of frameworks. And then libraries on top of libraries on top of frameworks. Frameworks for layouts, frameworks for buttons. You get the idea. There's a lot of stuff. And there's stuff on top of stuff and stuff on top of top of stuff. But still, this one's yours. Have you ever heard anyone say that, you know, when they're shining over your shoulder, does that, this looks like a Drupal site, you know? You've probably heard that once or twice before. And it's because, you know, let's get stuff back and think about why that happens. Well, it's because, you know, Drupal Framework had dictated the design patterns, you know. They had injected these design patterns that show up on every display layer on every Drupal site, one way or another. I mean, how many of you spent so much time taking out pieces from Drupal to make it display better? You know, like it informs you, all those things. You spend so much time doing that. And you're like, why am I doing this? It's like, how do I build a client for taking away things? And so you got output methods from default stylings, which I just mentioned. And you might have things that, you know, look like this. These are some of the design patterns that came about. And you have menus, you know, that look like this one. And you have forms that look like this. And so, you know, we're trying to, we're essentially, what we're doing here is we're solving for an entirely new universe at this point, you know, entirely new use cases. Everything is changing rapidly and people want things to look different than your standard stock of Drupal site. But we're still dealing with the same Drupal bullshit from Drupal 6, the birth of Drupal 7. And Drupal 7, again, like we said, has not changed from the day it was launched to now. And we're still dealing with this, no matter what the added expectations on top, mobile response of whatever are layered on top of it. We're still dealing with the same Drupal bullshit. I don't know if this is accurate now, but this is the 72nd slide. And so we're actually gonna slow down here now. But we've gone through 72 slides and we still haven't covered performance, touch, contextual awareness, testing, asset management, critical path, personalization, web components, shadow DOM, backbone underscore, designing in the browser, live prototyping, A-B testing, the list goes on, right? All of these things, sessions on them at Drupal Con, every Drupal Con now. You hear these words, you know these practices exist, you read Smashing Magazine and you know somebody's doing it and you probably ought to learn it. You know, you get the point. My brain is full. Right, that's it. I'm getting off the train. You know, I'm gonna be a print designer now. You know, web is done. I have thought about that. Web is done. So one of these ideas that we wanted to present today is that front end is its own thing. And it's not a subset or an extension of design or an afterthought, absolutely. Or a place you put your junior designers or developers rather. Front end is a thing. It's a thing that's complete with its own software stack. It's a thing that's complete with its own tooling, best practices and testing. And it's a thing that's complete with its own skill set that's as unique to front end as back end skills are to back end. And to treat it as anything less would be unfair to both sides of the equation. So it's as complex and as diverse as the back end. And taking that into account, the old rules do not apply. Yeah, it's no longer about styling the output and giving it from the back end developer just spit something out and says, good luck, throws it over the fence. We can't think that way anymore. I think that at the birth of where UX became a really big thing in the web, that kind of changed a little bit with the wire framing and the user testing and managing all of these things in the early stages so that they weren't doing that, which was a big problem. But it still happens. There's that notion of well, we'll deal with how this looks later, but we just have to get it functioning. And that's not really the way that we should be thinking about this. And the front end isn't a place to put your junior developers until they get good enough to be module developers. Who here started here as a themeer? No matter what your level of skill or your thing, you came in and you were just a basic themeer. As a junior developer, of course, theming is what you did. Who here started in like, this is where people started, where you put them. And so what we want to suggest is about changing the process. The way front end development is done. About equal footing in determining application architecture. Front end isn't the thing you think about second after you get all your internals done. And that front end is performed and practiced with as much rigor and maturity as the back end. Because front end is as mature as the back end now. The kind of software we're building, the kind of applications we're building on top of the back end are as complex as those in the back end itself. So a Drupal release cycle is long, which is a good thing. It's a really good thing. It means that we have a mature software. It means that people are utilizing it. It means it's being adopted. And it's being adopted across all types of verticals. But the thing is though, multiple front end production frameworks have been coming gone during this time period of the span of Drupal. So we've had all kinds of things that have started out at the same time that Drupal did and then went away before now or starting now and we have to somehow retrofit that to work with Drupal and make that bend into that method so you can actually use those things. We need to be more able to readily adapt Drupal to front end technologies as they emerge. Again, Drupal now, completely agnostic to it. Drupal is agnostic but also opinionated. And I think that's also the problem. But we'll talk about that in a second. Yeah. So here's a slide. Drupal 7's lifetime, X axis year. So yeah, so what we did is we just looked at when did these frameworks come in? We looked for the first commit and get and said, this is when they started and this is approximately how long they were adopted. So Drupal 7 has spanned all of that and it will be readily available for the next few years as production environments and that's a great thing but look at what's coming gone in that time period. You have all of your CSS frameworks. You have Angular coming in at that point. 960 died off, jQuery mobile like kind of still there but it's going away. And then you've got grunt coming in and KuFund has started during the middle of the process and it died out at some point. And so what we're looking at is, so when you look at this back half of it, when we started Drupal 7, how would we possibly ever expect what this is gonna look like? We don't know what the landscape of the front end's gonna look like at that point. And vice versa, when we started out, we were like, okay, let's build this for these frameworks. That's cool. This is a cool thing right now. Let's make sure that these work really well. And so we built those and those lasted and the other ones were kind of shadowed away. So the takeaway from that is we're never gonna know what's gonna come. It's gonna come and it's gonna take us all by surprise and it's gonna be the next biggest thing. And the things that we bet on now that are gonna be awesome are gonna die without our say so, without asking us. We need to make Drupal more take apartable. And we use the word take apartable instead of decoupled because decoupled is a word that has a lot of implications. When you say decoupled, people start thinking, like this very specific, angular thing. No, it needs to be more take apartable. We need Drupal to be this thing where we can build the thing we want versus just clobbering and chiseling away at Drupal to get it close to what we really wanted. We wanna build the thing we really want, not the thing that most closely approximates it. Yeah, so one of these things that I was thinking about is that we kind of need to build our front end to be resilient to that. And I say resilient in the way like, not like we have to make it something that doesn't do anything at all but just kind of lasts forever. I mean, resilient in terms of being able to have some sort of barrier in between that and the back end of Drupal and the front end of it so that we don't have to have these really painful middle points. We don't have to have these connector pieces to get what you want to do on the front end to work inside of a Drupal site. Because the next big change is going to happen, whether we say so or not. It's going to happen and it's gonna hit Drupal and Drupal has to be ready. Okay, Drupal's not a thing. We have to be ready to work with it or walk away from it or do something else because we simply can't just sit pat working on the technologies of today three years from now. And so here's our little fancy slide of how such a thing might exist. We're certainly not core developers, but this is an idea. Yeah, that's a good point. I don't want to put that forward as like a final statement of how we think it would ever look, but it's just that idea of we have to kind of think about how do we plan for the future without knowing what the future is? And that's a really hard thing to do, but it's the only way that as we saw through all these slides, how everything's changed so fast, we know that that's only gonna get faster and it's only gonna people have their fads and whatever else is gonna come next for how they wanna display their media and their sites. So maybe this is some way that you could do that. Think about it at least. So I hope you guys weren't coming here for a definitive answer. Like, yes, this is how you manage your skills all the way to the end and this is the track you need to go. Part of it is that, well, I sure as hell don't know what's gonna happen in the next two years with any certain deals. I wouldn't be up here. I'd be placing bets at the stock exchange. And at the same time, we can clearly see from the trend path of Drupal 7 that these kind of changes are going to happen. They're gonna take us mostly by surprise and we're gonna catch up and we're gonna try to shove things into Drupal and we might not be entirely successful in it. And the goal is that for Drupal to be successful, we need these front end technologies to be more readily, the front end, Drupal has to play ball with these front end technologies, whatever they may be as they come up and what exactly means to make Drupal more ball playable? That's a greater question and... I think the thing is, what it is more is you don't want Drupal to be opinionated. It has to be somewhat agnostic to the future of the front end because Drupal is not a front end per se. It's a piece that can bubble up to that point but in work with that very well, it can give you all the information and data you want and allow you to input it in a thousand different ways and query it out however it has to happen but that piece of it is very confusing and very hard to work with with the current state. So one, I didn't expect this many people to show up so thank you all for coming. Two, we figured there would be a lot of questions and or discussion around this and we're happy to talk about this. And if you guys think we're totally full of crap, please let us know too. There's a mic in the back and please somebody other than Morton be the first person because... No, no, no, people sit up, people sit up. Hi, I'm Peter. Hi, hi, hi. No, so I'm very happy to see this session. This is what I've been preaching for about six years in Drupal that we have a developer community who have been building Drupal for us as front enders. What happened when you do that? You asked your backend developers to build a front end technology they don't care about, not interest them, has no relevance for them in the day-to-day work. We can choose to do that also in Drupal 8. We can just lean back and wait and hope they will give us something that we then hopefully, or rather we will end up in the same development circle where we cannot do anything on it. So the logical answer to that is we have a coach pin tomorrow and you're all front enders and we need your opinions because right now we're like five or six coders who's trying to fix all of these things and make it work in a way that we can actually decouple our front end. That's one of our gold trick, what we wanna do, but we need more manpower and female power and geek power and design power and those who actually gonna use it. So the point is that everything you saw on this screen of how pretty much the whole front end ran us over, that's gonna happen again in two years. If you don't come in and help out. So it's actually, you can look at yourself, is that a choice you're gonna take? If you don't step up, that's the choice you take. So it's kind of a call to arms. It's now or never. This is the first time we had the chance to clear everything out of Drupal and make it new and actually change this action. This is the first time we're more than one. Front ender in the issue queue for wheels, we actually have a community around it. So when you go home tonight and you figure out if you wanna go to the coach principal, take a look at the mirror in the morning and say, do I wanna have a front end that's gonna be run over? If you wanna have that, don't show up. So Morton makes a good point here in that Drupal 8 is still somewhat in flux and that the direction that Drupal 8 takes in things is still up to us to determine and the people like us in the room who do have strong opinions about things how front end ought to be, whether it be decoupled or not, can still influence this decision going forward. Yeah, I think that also don't be discouraged because we are in the right direction with Drupal 8. There are a lot of things go in the right direction in terms of managing our libraries in the front end. So we don't have to require jQuery as our only JavaScript framework. We can do whatever we want with that. Those are the direction that it is going right now. It just needs some extra push. So you're not starting from scratch. People are on this and this is the direction that it is going. Thank you for doing this. This has been probably one of the awesomest presentations I've been to throughout this whole thing. Reason why, as soon as I get back, all of my bosses are going to watch this. Yeah, no, totally. So they can understand the situation. I feel that, and I might speak for many other people here, as a front end developer, it's kind of where do we fit in with the rest of Drupal. Yes, absolutely. There's sort of this disambiguation between site builders and front end developers. And it's oftentimes we wonder where do we, as front end designers, really fit into the greater Drupal thing? How do we really contribute back? And this is a really, really big point that our role and the challenges that we're facing are much larger than anybody actually gives credit for. Absolutely. Anywhere close to it. And so if we really are going to continue doing what it is that we're doing and we're going to continue using Drupal as the background behind what we do, then we really do need to get involved. And we really do need to contribute back and make our voices heard that the presentation layer, the back end is gonna be what it's gonna be in everything, but if we don't have a good presentation layer, if it doesn't have that aesthetic quality, it's not gonna be successful. Thank you. So the couple, I think it was on Wednesday, there was a session talking about object-oriented code and specifically working with Twig and doing some of the really cool stuff that Drupal 8 can't do yet with Twig. And more importantly, what I was noticing is that it seems like with Drupal 8 we're gonna have a much better separation between PHP code and our front end. So our front end really gets the attention that it deserves as opposed to having to teach all my designers how to navigate an array. So is there, as a part of keeping Drupal relevant from a front end perspective? Because as you saw, I mean, we've somehow managed to survive four years of very rapid change in the front end world. Do you think that the new REST API features and maybe an expansion of that could go a long way towards giving us the flexibility we need so that when AngularJS turns into something else and we have some other crazy thing we're supposed to use, that the data is still there. We can always work with it. That's kind of the vision. Yeah. Well, you go first, Brian. Well, I was just gonna say, I think that the idea of having a RESTful API and just being able to spit out whatever they want the data to be to the front end and want to manipulate that how we want is ultimately kind of the right direction for that. There's two pieces of that though. You can't just, that will shadow a lot of people by doing that entirely. We can't just say, here's some stuff, good luck. I hope you know how to do all of these frameworks and build them from scratch because that's hard too. I think that twig is a really good compromise in that way and helps people being able to use twig that aren't experienced in PHP but still can get the proper layouts and without the security problems that they might run into by doing something strange that they copied from a blog, for instance. So I think that that is a good point that having the RESTful API is going to be a huge player and giving us the data that we need to do and manipulate how we want. I was going to say, you guys should come to my decoupled Drupal buff yesterday but that wouldn't help at all. But seriously though, decoupled Drupal, headless Drupal, personal opinion, wave of the future, absolutely. Yep. I have a favor to ask. Sure. You had a slide that said PSD to HTML. Yep. And I didn't get a chance to take a photo of it. Oh please, no, sure. And I know that I could go and get the slides for this and then show it to my bosses and stuff. I've been working at an agency for about six months and their process is still this and I feel that they're not really listening to me. And I find that I'm gonna have to give a presentation from what I learned here at DrupalCon and I would love to end my presentation of a video of like, I don't know, 500 people, 300 people, saying this was your, my job or this was your job out loud because I think then they would actually maybe well come to the stage, come to the stage, yeah. Can I put my camera on? Please, please, yeah. All right, okay, okay. So we're gonna, is it on video? It's videoing now, should we say this was my job or this was your job? Yeah, come up to the stage, come on. Come on, yeah, come up to the stage. You come here. Someone has to hold your phone. Yeah, come on. Or you can fold that. Well, I probably need the slide. Oh, okay, fine, okay, fine, fine, fine, okay. So I'll go back and hold it and you could go like this. Yeah, okay, so we'll say it on three, okay. This was my job on three, okay. Wait, can I go under the, under the, under the. Yeah, yeah, that's the first time. Come on up, dude. There you go, there you go. Yeah. Yeah. Hey, this is the last session of DrupalCon, guys. We're told, you know, I'm going straight to the bar after this. So, okay, on three, all right. One, oh, are you in? Okay, one, one, two, three. This was my job. Yes. Next. All right. Cool. Yes. So two questions, one's a quick one, one may not be. Sure. The quick one is, why wasn't this on the first day? I didn't have a choice. We didn't write the schedule. We didn't write the schedule, yeah. The second one is, you guys posted a, you guys had a slide earlier, I took a picture of it. Yep. It was the quote by Frank. Oh, Camero, yes. Yeah, yeah. GitHub is confusing and Git is confusing her. Yep. Do you have a 30 second explanation of GitHub and Git? Because that's, yeah, it is confusing. Not a three second one, I could give you a 31. Yeah, 30 second. After this, find me, I'll give you a 30 second one. Okay, go ahead. So as I've gone to the conference, I've talked to a lot of people and some of them are in this room and I've gotten to know a lot of really cool people. And I'm gonna soapbox for a moment. I have the pleasure of implementing websites that are given to me by PDF. Wow. Nice. Yeah. That's a new one. Yeah. I know. And while I love the people I work with at the same time, some of these things happen and this presentation has kind of inspired me and speaking to a lot of people here to choose a path forward to come together as a community and decide what is best, but how do we do that? So I think one of the things that people, I personally want to inspire everybody in this value is that in this room is that what you do outside of Drupal is not unusual. You come to Drupal, the Drupal world and you're kind of like this misshapen thing, right? You're the ugly duckling. And the world outside of Drupal, people with engineering skills doing front end, it's totally effing normal. Like you go to a node meetup sometime, go to a Ruby meetup sometime. Like everybody is just like you. Well, maybe they don't look like you, but their skill set is just like you. It's only in this weird Drupal universe where the front end is like this unusual thing that nobody knows what to do with. Do we have this weird problem? Like where do we put the front end guy? Well, sit him next to the designer or sit her next to the designer. There's a greater universe of front end practice outside the walls of Drupal and Drupal would do well to look well beyond its internal walls to see what's going on out there because really, Drupal's not driving front end change. You see all those technologies, they're not native to Drupal. That was other technologies coming into Drupal, right? And we're not pushing change in here. We're adopting change from other places and if we don't want to be left behind we would continue to look beyond our walls and examine why that kind of change isn't happening within Drupal itself. Yeah, one of the points I was gonna make earlier that I forgot to make was when I was talking about how Angie said that you could take a word and add JS and you have a project on GitHub. Well, that's always a critique of front end developers. It's one of those things like, well, you guys just spin up something new and that's the new thing that everyone uses. Like every two months there's something new out there. And that's because it sucks the way that they give it to us right now. You have to find some new tools to make it work and that there's just more of a kind of a cry for help. Like, hey, I need something to make this easier for myself because this is taking way too long. This is way too complex. Everything's different in every different browser and we need something to standardize that. They have the luxury of everything being standardized because it runs server side, that's easy. So how do you, you know, you can't critique that because that's something that needs to change and everyone's just taking their own take of that. And I think what you're gonna see over time is that's not gonna happen this often anymore. I think that we're starting to stabilize various different frameworks that just work really well. So it's starting to get to this point where it's, you know, if you looked at a graph, it's kind of a, I think it will look more like a bell curve where you started out with nothing and then we got like a million different projects. And then I think it's gonna, you know, those are gonna die off because they were good ideas and people extrapolated beyond those, but it's gonna stable out. And then there's going to be, you know, some things that you're going to use for an extended period of time, not just two months. I definitely agree. So to finish up and to wrap up my portion is as I've gotten to know a lot of people and a lot of people will say foundation, Omega, and you know, we have a lot of people who have their preferred stacks and, you know, and I've had mine, but I have sat and listened to every person and every person's ideas and theories and ideologies and have instead of trying to compare them against my own, I decided to just listen and listen and just, you know, I don't rebuttal with them. I don't, you know, I don't compare or discuss. I just listen. And so I was kind of gonna say this has worked out really well for me. I've actually come up with a pretty good idea to try with that, that does with my particular situation, you know, PDFs, and you know, how we could start prototyping, how can we move the organization with forward in such a way where you're not stepping on people's toes, you're not, you know, you know, making people feel like they're outdated, you know. How do you bring them forward with you? So with that in mind, just want to extend to all of you, try something new, try something that you haven't done before or just if somebody does something different than you, listen to them without in your mind thinking like, well, why do they do that? Instead, just listen, and then take it back and, you know, apply it or don't, but otherwise, you know, keep an open mind. And I think that's how we can move forward as a group. Thanks. Jeremy? So first, well, this is the second session in a row now I've gone to where people have been talking about front-end design, it's its own thing, and it's a big thing. So I started as a designer, and then I was a designer-themer, and then I was a designer-themer front-ender, sometimes developer, you know. I've never worked in a shop that was big enough where you had, you know, 20 people who could specialize in all those different things. You know, it's been me building a site or if I'm lucky, me and one or two other people building a site. So are we at the point where that can't happen anymore? Because my head is exploding from all of this stuff. Yeah. Is there a way we could get back to that point where the tools are good enough and defined enough where someone could wrap their head around all this? Yes and no. I'm gonna caveat that by saying, if you look at the progression of any technology that's come up in the 20th century, that's reached a state of maturity, right? It used to be that anybody and everybody could fix their own car because it was just that simple, right? And now not only do you have mechanics, you have specialized mechanics. But at the same time, there are people who are hobbyists who are able to fix their own car, you know, including their Tesla if they so choose. It's a question of personal will at some point too, whether you wanna get good at everything. I don't think it's possible to be great at everything. That's, you know, it's like, you know, I wanna be awesome at everything, well, good luck, you know. But specialization has its own rewards as well. And I don't think you should shy away from specialization because it makes you feel like you're being shut out of other avenues, it's not, you know, like as this kind of technology proliferates, the need for specialists only grows, not decreases. Yeah, I kinda disagree with them on this. That's right. What I wanted to say though, not entirely, in terms of specialization, I think that my approach for this type of thing is, you know, if you can truly understand the fundamentals of what you're working with, if you can truly understand the DOM and the browser and understand, you know, the core values of various different frameworks and knowing how to do the fundamental JavaScript and things along those lines, you're gonna be able to get, you're gonna be able to do anything, you know, you're gonna be able to learn what you need to learn. And then what you do is you take a project and you look at what you need to do for that project and what technology makes the most sense. You know, I don't think, I don't like the idea, and a lot of people probably disagree, I don't think that Drupal is the best thing for everything. I just, I don't, I mean, I think that, I don't think, in the same way, I don't think that using some framework in the front end is the best for everything either. I don't think there's one thing that's the best. So it's like, what does my project need? What can I do with it? And then learning that to make it happen because you've already got those fundamentals expert level at that. So that's my thought. Thanks for your great presentation. Thank you. I come from a small segment, maybe. I'm a Drupal educator. I teach Drupal to graduate design students in a design school. And so Drupal 8 scares me a lot because the curriculum's gonna have to fill up their brain even more than it already does. But specifically, the thing I see, because I teach mostly people who become themers at the best, and maybe they're really just CSS artists. They're still PSD to HTML practice in my department, in fact. What would make Drupal 8 really more accessible for my students at the templating level would be to have some modular, pluggable templating engines. For example, PHP template, I know has a lot of limitations, but PHP has already taught in my school. Twig is not. So I have a whole new challenge in 15 weeks to teach Drupal 8 now. Is there a JavaScript server-side templating engine? That's another question. I don't know the answer to that. Yes, there's many, many of them. Handles bars, mustache, things like that. If you Google Curly Brace templating engine, you'll get like 100 pages of results. But the gentleman behind you, the Nordic man with the backwards hat may have an answer. Let me just ask you one more thing. Yeah. I did a session yesterday. It's a one-hour watch about how Drupal Twig works. You see that, and you're done. Oh, I'm with you. I only have 45 hours of instruction for semester though. I appreciate it. I like it. I said one hour. No, I know how that happens. Two hours, like 45 hours that are only for live. The thing is we have simplified stuff in ways that is absurd. Yeah, I'm not arguing with Twig as a choice. I'm just observing my dilemma. Sure, I'll tell you. So, pluggable templating engines for Drupal 8 where I could have a variety of choices for the underlying knowledge of my students would be really brilliant. The other thing I'd say is that a headless Drupal, or Drupal without a theme is prevalent in a lot of development practices I see. I heard you advocating for it. I'll share a takeaway that I got from the very last session in this room, which was a survey of a lot of site builders, pain points, the lack of preview, again, coming from my student level, it would be a huge challenge for headless Drupal. So I just share that. Yeah, that was my point about having some sort of intermediate era of some sort of template system like Twig to do that kind of stuff. So, yeah. Before everybody else starts trickling out, I think we're supposed to tell you to rate our session. I'll be like an Uber driver and say, I'll rate you high if you rate me high. To the man who was just up here, I would say that you should lobby for another course for your department because Twig is a very valuable templating system and it's used in a lot of different websites, not just Drupal. So that might be a different option or yeah, oh wow. But I think you could make a really, because if they're already teaching PHP, you know. Totally. I also teach in a graphic design program in Ottawa and we actually taught our students how to template with Jekyll and they're committing on GitHub because the school won't give us server space because we're a design department. But then I can see their commits and I can see when we're grading, I can see like even if they push at 3 a.m., I can see all of their commits two hours prior. Your designers are committing to Git. Yeah. That's freaking awesome. Because there's an app, so for Max, it's pretty easy for them. Cool. I think this wraps it up. Thank you everybody for coming. This is way better than I took in it. Thank you. Sorry, thank you. No, I'm sorry I missed the beginning. I was very unknown guys. You're brilliant. Yeah, I think it's partly bad. It'll be in the central area. I think that I'm going to be a company in the world of expecting to see something. You know, like I think really, really good. That's not there anymore. You're getting a great, you know, your JSON address and then you have to convert that into something that's understandable in some sort of framework. That's the hard part. And that's the thing that I think is pretty scary for a lot of people and the piece that is going to be hard. It's going to be, it's really the only way to say it. It's really the only way. Yeah, totally.