 Alright, we have new people in here so I'll repeat the apologies from before. I am clearly not John Albin Wilkins, though we both have lived in Taiwan at some point in our lives, including currently. I will not repeat the joke I told before. John Wilkins is currently sick and unable to give his talk. This is a fill-in talk, which is mostly conversational and largely participatory about front-end, about as-essential crises in front-end, about what the hell we're doing in front-end. This is a much bolder abstract than I gave five minutes ago. John's talk will be rescheduled for tomorrow, provided he feels better. He currently has food poisoning, which you probably did not want to know. He probably didn't want you to know either, and it would make a really bad talk if you were puking up here. So if you're welcome, you're welcome to stay. We'll have a conversation about front-end things. Mostly you guys talking, more so than me, because nobody wants to hear that. And if you want to leave and go to a different session, this ten tracks wide, I will not be offended in the slightest bit. But there's a mic over there, and because people keep walking in and walking out, we might as well just start, because I have to apologize all the time anyway. Thank you. All right. This is a fill-in session for John Alvin Wilkins' talk, which will be tomorrow. I can't tell you exactly when, because that's still being figured out, but we will have a makeup session for John's style guide's talk tomorrow. So don't leave disappointed unless you're leaving tomorrow. So again, formal apologies that I'm not John Wilkins. I'll do my best to speak and gesticulate like him. I'm not him. Like I said before, we're both from Taiwan. He currently lives in Taiwan. I was born in Taiwan. If we ever decide to live in one place, we'd have to decapitate each other, because there only can be one. And we're here to talk about stuff, because I was asked to do this literally 45 minutes ago. I don't have a wealth of things to prepare it. Oh, God, more people to apologize to. Damn it. All right. Everybody come in, and I'll apologize to you all, and we can start. I'll just leave this slide up. Yeah. No, I'm not. Yeah, so everybody who just walked in and are continuing to walk in. I'm not John Robin Wilkins. This is a fill-in session for John, because John is food poisoning. He will be giving his talk tomorrow. Not quite sure when, probably in the afternoon. Check the schedule online. We will update it. We are having a conversation about front end as soon as people stop walking in, and I can stop apologizing. Otherwise, feel free to leave. I won't hate you forever. So if I wore John Robin Wilkins, I would be blonde. I'd have blue hair and be really, really pale. But his kids, but we'll keep talking about John, because he's not here. His kids are TV actors. They do Taiwanese variety shows, and they speak amazing Chinese, amazing Taiwanese, amazing English with perfect American accent. I'm super jealous of them, actually. Well, that's what it's going to turn into. It's going to be like 30 minutes on YouTube of me apologizing to everybody walking in before we can actually start talking. You know, I'm just going to start talking. If people hate what we're saying, they can just forget it. Okay, last chance to apologize. I'm not John Wilkins. This is not John Wilkins' talk. John Wilkins' talk has been rescheduled for tomorrow since he has food poisoning. We are going to talk about front end. Oh, I know. I'm already shocking. We're going to talk about some front end things. There's a microphone there. I encourage people to come up to the microphone and speak about this, because I am not the end-all authority of front end, as everybody knows. And so let's talk about some stuff. We're both from Taiwan. Talk about stuff. Okay, I'm just going to start asking questions now. Who are we? All right, who in your... We'll do some show of hand stuff. Who here labels themselves a designer? You know, whether by title or by affiliation, you're a designer. Who calls yourself a developer? And this is what you would call yourself, not necessarily what your card says. Who, when people ask you what you do, outside of DrupalCon, call themselves themeers? Does the word themeer have meaning outside of the DrupalCon text to you? Okay. Okay, well, WordPress. Okay, so outside of the CMS space, if somebody... If you got into a cab, let's say, you know, an Uber, let's say, this morning, and somebody asks you what you do for a living. Would you say themeer? No. Okay. What would you say instead of themeer? Okay. Why is that? Okay. That's a rhetorical question. We'll leave it at that. Okay. What do we do? Okay. So what do we actually do? So who here actually touches image compositional tools like Photoshop, you know, Sketch or whatever? Okay. Who uses that as their primary tool? All right. Whose primary tool is more, let's say, text editor, code editor? Okay. Who uses both, say, about evenly? Fewer than I thought. Okay. There's a long conversation to be had, and I'm going to stop apologizing now. So we're already talking. I'm not John Wilkins. This is not going to be John Wilkins' talk. That's going to be given tomorrow, but we're still talking about front-end. So we're happy if you can stay. There's this notion of what should we be doing? And John Wilkins' session is actually based on this idea, you know, that what we're doing isn't very efficient and it's a rough approximation of getting this design idea out of our brains and onto the web and sort of figuring out all these intermediate steps that quite frankly suck and don't fit well together right now. We're making rough stone tools to chip other stones to look more like the thing we want, and we're just knocking, it's all stone knocking. It's not actually making the thing we want. It's all these rough approximations. You have a question? Go ahead, please. Not a question. I develop user interaction with technology. Any way that the user is going to interact with a screen, whether it be a touch screen or just visual or whatever, I develop that interaction. Okay. Cool. All right. So by the way, if you guys want to step up and retort or ask me questions, I just have like 10 minutes of just this, the beginning, and then just sort of as to feed the conversation. And I'm going to stop apologizing now for all the new people in here. So there's this idea of what's difficult and what's easy. What's currently hard about our jobs? What's easy about our jobs? What's the hardest thing? Okay, I'm just going to point at random people. What's the hardest thing right now about your job, no matter what your title may be? Okay. You got it. Good call. Nick, another thing that's hard. User content. Oh, okay. Kevin. Okay, designing things with no visual interface. Okay. Wow. Anything else? Hard. Add providers. Okay. Somebody in the back. Figuring out what a client needs and getting it on the page. Okay. Politics. Politics. Yes. What's that? Support from the top. Support from the top. Okay. So conversely, what's easy about our jobs right now? Good tools. Okay. Collaboration. SaaS. What's that? Collaboration. Collaboration. Slack. Okay. Slack is easy to use. Yeah. Build tools. Build tools. Okay. So, thinking about that for a second. What do we want to do, aside from what's hard and what's easy? What is it that we actually want to do? Please, our clients. Please, our clients. Great answer. Fixed struples markup. Okay. Wait, so let's think about it. Fixed struples markup so that, so that, one last apology. Just Morton walked in. I'm not John. This isn't John Session. We're having a conversation about front end. John Session will be re-given tomorrow, Wednesday afternoon. But we're still having a conversation about front end anyway. You're welcome to stay or leave, except for Morton who, you know, whatever. You're, you're, you're allowed to stay. That's fine. You're expected to stay. Yeah. So between what we are currently doing, what we should be doing and what we want to do. This isn't very well aligned currently in the front end space nor, you know, you could really say ever been in the front end space. There's a lot of, you know, what we are currently doing, which is the best approximation of maybe what we, quote, unquote, should be doing, which may not be what we want to do at all. And this is a fundamental tension in the front end space that I personally have struggled with for almost eight years. And it feels like, you know, Morton, John, if John were giving his session, this would be a great theme, that theme, huh, about his talk, is that it's never quite good enough, is it? Tools, it's never quite good enough. It's never quite the design that wants to be on the web. It's never quite the realization of that platonic ideal that you as a designer, you as a front end developer, you as a UI developer want to have. And resolving that tension has been very, very hard. How many people went to Morton's talk yesterday about theming in front? Okay. How many people went to Steve Perch's talk about the history of rendering HTML? How many people have worked with Drupal more than four years? Does it feel like it's getting better or worse? Better. Better. Okay. Why is it getting better? How is it better? Some people in the front said, you're better. Twig, okay. Embracing other disciplines, that's a great answer. What else? Is it, I mean, is part of it you personally getting better as a developer too? Okay. That's totally a thing as well. Going back to the question of if things are getting better or worse for you personally, how many of you here feel the pressure to become more back-ended as you get longer and longer in Drupal? How many people have resisted the urge to get more back-ended? So those of you who didn't resist the urge, at what point do you no longer feel like you're, do you still feel like front-end developers as you get further and further back into the stack? Because you have to. You do it because you have to, for no other reason. Can I ask you to stand and face the audience? Would that be okay? Thank you. You're a front-end developer. Yeah. One at a time got here. Here, go ahead. Yeah. Could you stand and, thank you. You're a stroller. Jeremy, go ahead. Green shirt in the back. That's you. Can you stand up? Over here, there was a... It's 11 o'clock. Here. Stand up. So taking, let's walk that back up. Go ahead. So let me back this up a little bit more here. Okay. So who started here in front of development by accident? So you just sort of slid into it. You started as a site builder and then had to, went to front of development, sort of forced into it because nobody else did it. Okay. Who sort of slid into front of development through the gates of design, having to implement your own designs. How many of you here actually have a CS degree? So there's an interesting thing going out here in this space. I don't know what the breakdown would be if we asked this question in, say, a back-end, a colonial back-end session. I think the numbers are probably different. I think the history of people coming into front-end is much different than that of people who stick and stay with back-end. Who here feels that front-end is too back-end-y now? Like who regrets having to learn engineering principles and or PHP and wish that they didn't learn it? Regrets or resents? Oh, both. Yeah. Who here regrets or resents having to learn this PHP and or I have this idea and feel free to debate with me on this and there's a microphone there if you want to be amplified so you don't have to stand up and bear yourself or whatever. But even, who here is actually, okay, let's back it up even more. Who here has worked with a front-end presentational tool, a modern front-end presentational tool, be it a PHP one or a JavaScript one, an Angular and Ember out there? Does that, do these feel harder or easier than Drupal? Why are they easier? Go ahead, step to the mic, homie. It's yours. Just don't try it. Okay, so one thing I found really interesting is like this whole concept of headless Drupal, decoupling the back-end from the front-end. Because for instance, like usually when I think of a front-end, I'm thinking of like design. I'm thinking of presenting code. Like I get, for instance, like a layout or something like that from Photoshop from designers. And I'm thinking of how to create a user experience for that. And to do that, I need data. Now with Drupal, it's like I get this data but okay, it's so some of these blocks are in like sidebars and this and that and like all these other areas. Like there's all this overlay from how Drupal presents information. It's like I don't really feel like there's a clean way to just say give me all the data that belongs to this node that's going to be put out on this page. I don't really care where it goes because I'm going to determine where it goes. So when we start getting ahead with Drupal, then I'm just like, hey okay, I'll put out a bunch of Ajax requests for all the different areas where I know where things are, the data is going to be pulled into where I'm going to put it. Whereas I feel like right now like when someone has gone in the panels or they've gone into like the blocks and stuff and they've set up all this stuff. Like I kind of have to know all this information of the theme layer to say okay, where is stuff actually going to go? And oops, you know, I don't want the sidebar. Oh, well that blocks on the sidebar. Okay, well let me, you know. Maybe that's a little bit of, you know, an experience on my end but I feel like in general it's easier with a lot of these, you know, like Angular and the mean stack and stuff like that because I just get to say where's my data? What data do I want and how am I going to present it? And I don't really have to worry about where it belongs or who put it where, you know, stuff like that. But your clients don't have expectations of being able to put things where they want that. Like I said, I usually get something like say like a Photoshop layout or something like that and they're just like this goes here, that goes there, that goes here, you know, stuff like that. And sometimes it's not necessarily how it was quite built on the back end and so you're sort of starting to move things around. Yeah, there's templates but like I said, I feel, templates really aren't the problem as much as I just want data and I really don't care where it came from, I just want to know what the data is and I'm going to put it where I want to put it. Five second background. Sorry. How did you come into web development and where did you come from before Drupal? Basically for web development, I mean I was, you know, just, I mean I started in college, I guess. Sure, sure, yeah, yeah. So yeah, most of it's the JavaScript, HTML, CSS stuff and then I've started working with Drupal because my company basically said hey, we're going to do CMS now and so we're working with Drupal. Thank you. So to answer that question of why those frameworks are easier, it's, they do I think a much more effective job of communicating what this tool does not do and Drupal maybe has some, sometimes an identity crisis because it's so modular that if you wanted to add functionality that it doesn't currently do, well guess what? We can now attempt to at least make that functionality so it's the great sort of burden but also promise of Drupal which is leveraging the community to find out alright I want to do something, well probably somebody wanted to do something front end maybe before these frameworks came about and now not only is somebody going to step up and build modules for it but often we have half a dozen modules for it. And then that becomes a whole different thing. So I don't know if it's good or bad, I have mixed feelings about it. I'm more of a right tool for the job and if Drupal is it then that's great but it does muddy up that discussion of well what is the right tool for the job if there's so many tools out there. So that's, so let's say using Angular as an example I'm not going to use that to try to do heavy things in terms of trying to grab stuff for the database or I don't know what support it has for like caching or things of that nature right? It doesn't promise that so I won't use it for that and I'll never expect it from it. I probably get more demands for responsive than I do the flexibility of layout so the moment you do that. Of course those tools, yeah. Right, right, right. But the design, right. Let's give Wes a shot here. Yeah, so my background, I started out as a designer and I worked on Enterprise CMSs, the big air quotes there. So I've come from things like Tritium, Sitecore, Ektron, terrible, terrible, terrible, terrible, terrible tools. And I think that working in Drupal, there's a lot of things that are a giant headache and you have a lot of freedom and that can totally bite you in the ass but I actually, I love it because it is trying to accomplish probably too much sometimes but I'd rather be able to mess up and just break something than have a system that is totally like this is my content store and I'm just going to give you this and you can do a couple things and then it's like oh god the client wants this flexibility. I'm not going to do that. Yeah, so I actually find that Drupal is way better at things that try to do similar tasks when I'm working with some enormous website that gets way too many visits a day. So yeah, little perspective. Tritium costs a $400,000 for the license and it's like this is a giant turd. Like when I buy it and I turn it on I have nothing. I have nothing. I have no quality of life as a developer. I have no quality of life as far as like there's a web page I can look at. That all has to be done. It's like okay now I begin the two-year process of building a website. Hooray! Like it is the worst. Like I'd rather have something set up that's like oh I got too many days. Like oh my god I need to build everything from scratch and not only that the community like these companies that charge $400,000 for CMS like how many developers do you think they have honestly that know what they're doing? Like it's close to none. It's really really bad. So you know I'd rather have something open source from enabling other people to make cool stuff and all that kind of warm fuzzies and you know there are people that really know what they're doing that have been able to accomplish a lot and I can see how they do it and everyone's pretty open. So it's pretty cool. Thanks. I'm a back-end developer. What are you doing here? But I like shiny things. So that's why I'm here. Just rolling back to the question of like are the JavaScript frameworks more difficult. I did actually find them sort of difficult and that also comes from a project where I was delving into Rails and there's the key factor there of convention and I think that's what makes things easy because I found Rails extremely easy. It makes sense. It's well documented. Once you get around the idea of convention because the first look at it everything is like magic. Like how does this get there but by following convention and I think maybe that's some of the problems that we face in Drupal. Because Rails is opinionated and Drupal is it? Yeah and with such a huge community maybe it's hard to be so opinionated. It seems like we are becoming a little bit more opinionated and also more open because we're accepting the conventions from outside and that looks definitely much more promising for Drupal 8. Thank you. Yeah JavaScript on the other hand there's so many different ways you can do it so if you're looking at well what do I do now? It's like well are you doing copy script require JS? That's a problem I face there. Thanks. I just want to address the flexibility issue with Drupal as being a downside because to me that's the reason why I got into Drupal and why I love it so much I never saw it as a downside. The fact that it's flexible you don't have to use the flexibility but you have the ability to and when I'm starting on a project even on the front end I never start with the design or what it's going to look like I start with what is the experience that I'm creating and that influences what the design is going to be but it's also going to influence the back end which is why I ended up getting dragged into the back end and becoming more of a developer because there were features and things that I wanted on the front end and well damn it I'll just do it myself right? Do you feel like as a developer you seem dragged into being a developer are you forced to be something that I didn't think I was I guess at the time I mean initially but I mean it was some cool stuff it's not that I don't enjoy it to some degree at this point that was a leading question I do have an opinion on this sort of this back-endiness of front end but it's not necessarily a negative one no and I don't think it is because it's you know this is me I like solving problems and I like solving visual problems you know experiential problems but you know sometimes that leads to problems on the back end that are just as interesting I'm a front end developer who works with Drupal a lot but you know over the years have had that frustrations with the markup and I think that one of one of the things that's really interesting about what's going on now is there's this headless thing I really like the idea of headless I'm not for or against it what you guys are talking about is an interesting argument I can think of solutions where if the client wanted that flexibility to move things around I think that could be done in the front end but more what I wanted to say was more of a philosophical thought of how Drupal has given us markup that's kind of a pain but we go to the other end of the spectrum of wanting to do away with the markup entirely and just do it all ourselves which is kind of interesting but I think also Drupal's good it gives us a lot of solutions to problems that we may not think of like internal site search is the first thing that comes to mind or being able to sort things, archive them forgetting passwords, logins and that's something that if we were to do on the front end though certainly possible requires a lot more work for us up front so I think those are things that as fronters we can kind of take for granted in a platform Sure and things are always going to change so if we have to rely on something that's in core three years later when the new best thing comes out then it's just going to be a thorn on our side There was a thing from DrupalCon last year where he had a slide that had the length of time Drupal7 has been in It's somewhere on my hard drive here I think also there's different I think also there's different tools for different projects too I use backbone for a lot of stuff because it's really simple but then something like Angular or Ember which is much more large scale one page app may be more appropriate so it's just kind of using the tool belt Go ahead I mainly came from HTML, CSS some JavaScript so I jumped directly into Drupal and my problem mostly has been documentation if I have to say add classes to like the navigation li elements then I have to go dump into the preprocessor and there may be documentation I couldn't find it and what I could find didn't give me an example that I could understand to do what I needed to do So I guess that's part of the problem but yeah Hey guys we've got more people on the mic Actually this is perfect timing because I would love to contribute to that so one of the things that I think can really help with documentation that my company has been doing is we get college students excited and interested because it's something that they don't even have a language for yet in the education system and here you have this huge group of kids who are super eager to get in they want to get their feet wet they want to get some kind of notoriety and name recognition and so one of the things we've been talking to college students about is like okay get into open source if you see something that's lacking and documentation is a great way to start go through each step by step if you see something wrong go back in and fix it open a bug report that they can use now that really help them get through and like they can have a mentor and kind of get started so I think like promoting that as you go through if you meet college students promoting that open source involvement it's the easiest way for them to put something on the resume I mean if you don't have an internship if you don't have a job yet just start contributing code to open source for sure Thank you I think kind of I'm going to step away from the documentation back to the working things like Angular so I think the biggest thing we see is like we're talking about that delineation between the front end and back end developers where I consider myself more of a full stack developer I do UX wireframes things like that but I'm also in the database and I think that's starting to become pretty common part of it is the Drupal 7 model where kind of things get kind of wishy washy spaghetti code intertwined everything's kind of together and what I think the benefit of that is people having to do both is what you're seeing with these JavaScript frameworks is something that we've been seeing on the back end with things like Rails or database abstraction so you're dealing with like these abstractions on the back end that we've had for years the front end developers are now kind of catching up to this so these frameworks are all just abstractions so you do not have to write necessarily every single HTML element or something or you're using a template engine or Angular jQuery to do your animations because these things to do it all manually and responsive on 25 different screens is really hard it's a really hard thing to do so now we're seeing these abstractions kind of flow forward and so now you have things like Angular and jQuery where you can do these things write it you know what would have taken you two weeks to do maybe by hand can now be done in 15 minutes or an hour so you're really seeing this whole kind of you know the two are feeding into each other the back end developers are learning things from the front end developers and the front end developers are kind of teaching or the back end developers are teaching the front end developers all about these abstractions so you get these whole new sets of tools because of that you know mishy mushy kind of thing where we have to do both because then someone sees oh they're doing it this way you know over here it would be really cool if we had something like that for the front end I think I think that delineation is sometimes you know a little bit arbitrary and it kind of it can be good at times because you need people to specifically work on things but in other times having that wishy-washy situation may actually be a huge benefit you know a hidden benefit that we wouldn't see thank you just as a point I want something I wanted to say before and maybe chimes into the hey where does the front end and the back end I feel like for a lot of people and this is not to call anybody out here who may feel this way is back end is where the hard stuff is I don't do the hard stuff so if it's hard it's back end development if it's easy or it fits into my talent suite it's front end development because I'm a front end developer and this is what's natural to me and I think I do have a zinger for this to tie it all up so we're not leaving on like a bitchy moment but I'll let a couple of these guys here but the idea that the back and the front end have this clear delineation in Drupal and say I only live in the themes folder and these other guys live in the modules or you know whatever folder is a false one and it's not because Drupal is terribly over-engineered or mis-engineered because one would have to write just as much complex JavaScript for their front end app if they were writing an MPC app versus you know Drupal you don't have the luxury of just doing HTML even if you're working with Angular and so this idea that the front end and the back end and then there's a clear delineation of responsibilities and concerns is I think a false one going forward but go ahead so kind of going back to the I think this was the initial question we might have deviated a few times since then but what makes or potentially makes these external systems easier than Drupal or if they are I think for me is consistency and this is something we're definitely solving development is is it a template, is it a theme function if I want to change this markup the one that comes to mind is I think it's like a theme menu or theme menu treat basically you get a hard-coded UL with a string and no context for anything else and so you start having to get into some really hacky things where we're just kind of all over the place in terms of convention and a lot of these other systems offer whether it's an opinionated one or not offer one solution and that's something that it seems like doesn't seem we are really trying to fix in Drupal 8 but right now in Drupal 7 that's what's making a lot of these other systems a lot more appealing okay thank you kind of want to follow up on what you were saying so when I got involved with Drupal development it was a lot of here's a Photoshop file here's a model for how we're organizing the content and some poor soul is in between trying to migrate that process so obviously what Drupal is putting out comes first and then we get that into whatever presentation layer but it seems now for instance we went to a system where like hey we like this convention let's use this convention we're going to put together some starter themes that we're going to use with our clients and that started dictating backwards how we were organizing content within Drupal in the back end and then that's great until someone decides hey let's move to block element modifier and suit CSS and we're going to go in that model and all of a sudden we have to go back and that's kind of an issue we're having because conventions are great but they change constantly and I want the new stuff and so wait you can't bitch about conventions changing and yet want the new stuff at the same time right? I mean it's our own damn fault let me clarify best practices change and and now I mean that was great before this point where now it's kind of like we have to go back and re-approach the content because those conventions lock you in so what's the price you pay if you don't go to the new stuff I think if you don't go BEM what's the loss if you don't go BEM for example well I think but they're not building your projects I mean what's the loss you face by not going BEM here do you mean moving to some new radically different convention sure I think more than anything what we're finding is that we're trying to look at conventions as a way to best roll out new sites I don't want to say rapid development but kind of foundational development and then something comes along that kind of throws a wrench in it or you might be able to reorganize around even around a new convention whereas now because things have been moving back into the content so much it's like you can't okay I mean so yeah it's new toys you don't get to play with the new toys somebody else is playing with new toys and you're playing with your wooden ones yeah dude on the end here stand up yeah you all let them yeah go ahead yeah do you want to say something let's let some of these two guys alright right first and then left so left can you stand up in the front too yeah go ahead stand up so we literally have we have five more minutes and there are two very patient people behind Stolar which I would like to have them you have 30 seconds Jerry I was just going to bring up a completely different topic and we've been talking about a lot of front end back end and all of that and as someone doing front end development the back end was never my pain that's a great way to put it as someone doing front end development so it's something you do it's not something you are but go ahead so the back end has never been my pain point it's the back back end it's the infrastructure stuff if there's something I hate more than anything else it's being a system administrator and so tools all these new tools and everything that are coming out to support front end development which I think is fabulous and great that people are paying attention to it and that this stuff is happening but now with the task runners and the build tools and the package managers and the the continual integration and automated testing and stuff like that which all requires configuration and all of that and having to deal with that makes my head want to explode half the time sounds like you need a back end developer so I have to give this so I have to give this room up but there's anything I want you guys to think about I have a rhetorical question which is my total zinger but people are leaving which sucks but my zinger was if you think things have changed I want to hear people's opinions and I'm at this on twitter if you want to hit me E-A-T-I-N-G-S has Drupal changed have you changed has the game changed I'll leave it at that I just wanted to say one thing really quick this format was actually really cool so if you love the format this is normally called it wasn't one for front end I just want to say that I think something like this should be done every year I agree thank you there's a whole track of these