 Good afternoon. I hope you all enjoyed your coffee and your short break. I have the pleasure of introducing Jesse Beach. One of the overarching themes of the front-end track this year is pushing boundaries, going beyond Drupal and taking what is already a powerful tool and pushing it to become even more. So, naturally, I reached out to Jesse because he's one of the people who have been pushing Drupal. You saw Dries' keynote this morning. You saw the accessibility. Maybe you saw the toolbar. And this is the work Jesse has been working on and taking an already complex system and then pushing it. And yesterday, I was tweeting with her and she was at the sprints. And, naturally, she was in the hard problems sprint, cracking the problems that nobody else can. So, without any further ado, introduce you to Jesse Beach. So, how many people here are front-end developers? Fantastic. I am too. Excellent. I was hoping I could get a lot of people in the room. Front-end developers. So, the name of this talk is evolving front-end development, but it's a bit of a pun. Because front-end development is something that we are evolving in Drupal. We're making it better, but it's also something that evolves around us. And I'd like to refer to this field as dancing on the tip of a hurtling rocket. Because as front-end developers, we're in a field that changes what feels like almost daily. So, I absolutely love the web. This picture, to me, just expresses the feeling that I have almost every day when I get to sit down and write code. To invent things and to make content findable. But the front-end is also a place of mystery and, in fact, terror some days. I feel like I'm presented with problems very often that I don't know how to solve. That require me to dive into forums and lists. So, I wanted to kind of get a sense of how much information is out there that a front-end developer might possibly have to know for becoming an expert. So, I counted all of the specifications and the recommendations out there in the W3C that you might one day have to read or have to be familiar with. Things like, you know, CSS3, CSS2, the acrimascripts, but also, you know, really esoteric ones like geolocation or web workers. And it ends up being a lot of documentation. I mean, just for JavaScript, there are over 80 things you might have to read and they're not exciting reading, to say the least. And as I was counting those numbers, I got this tweet from Kevin Suttle. Talking about display properties that I hadn't known about up to that point. And I just had this moment where I was like, and now there's something else I have to go and research. Like, I have no idea what indent edge reset is for display mode. And I felt like I understood CSS completely up to that point. I also put together a list of responsibilities that a front-end developer might have and went and counted all of the different libraries, the third-party libraries that you might have to someday evaluate or understand to know, like, should I go with Angular or Backbone? How are we going to do our behavior-driven development? You know, any type of responsibility that you have as front-end developer is probably already represented in some library. And there's probably 15 of them that do the thing that you need to do. And it just creates a lot of noise in the front-end development space to understand, you know, how do you choose the best path to get your job done? So I tweeted out this list and I asked for input from people that follow me. And Mark Drummond responded that of the list of things that I had put up as responsibilities for front-end developer, I forgot crying. And I had to agree with him. When you look at this list that has like 60 responsibilities, it feels completely overwhelming. So whereas some days, you know, I feel like this most days, there are definitely some days where I feel like this. Looking at, you know, how we as front-end developers complete the requirements that we have to do and how we do it in the best way possible that makes our users as successful as possible. So during this talk, I really want you at the end to feel good about what you already know as a front-end developer and to understand that there are areas that we all don't understand. Within this community, we're constantly learning from each other. In the group plate itself, we're trying to build in support structures and features that allow us to develop, you know, as quickly and to the best practices possible. So we have to talk about doubt. Doubt to me is something that I feel every day. And I like to express this because I think too often we get the sense that people that we aspire to or esteem know a lot more than we think they do. I certainly feel this. When I look at someone like Leveru, I get the sense that I just don't understand CSS given, you know, the types of things that she's doing in her research. So a really good example of, you know, this kind of fundamental moment of doubt that we experienced came during the development process of Drupal 8. So in 2011, Drupal kind of opened its arms wide to outside libraries. You know, we pulled in Symphony, we pulled in Guzzle a little bit later on, but we also pulled in some things in the front end. We pulled in two libraries. One was Create.js. Create.js is a library that essentially looks to the page, finds anything that's editable, makes that editable, takes those changes, saves them, and provides them through an API for you to push back to whatever, you know, system you have behind that to save that content. In our case it was Drupal. So this allowed us to very quickly, you know, short-circuit that piece of the puzzle that we were trying to solve for in-place editing by giving us something that understood the DOM, understood it semantically, and then gave us information about how users were editing those pieces. Create.js was also nicely coupled with a front-end editor that we wanted to put into core, Aloha. Aloha was being developed as an HTML5 standards first in-place editor, just like CK Editor, a tiny MCE. We had this crisis moment in late 2012 when we had been pushing forward with Aloha Editor. We knew there were some gaps in the functionality that they supported. One very striking gap was the fact that you couldn't use Aloha on the back end, on a back-end form to edit your content. And we kind of had the sense that we were going to have to solve that problem in the future. But then out of the darkness of their closets where they were developing, the CK Editor folks emerged with not only an in-place editor but an editor that could work on the back-end that had 10 years of development behind it and had excellent support for accessibility. They also came to us with about four developers in two weeks of their time to make an integration with Drupal. We reached this point where we had to make an incredibly painful decision to break the ties with Aloha, the relationships we had formed, and to also give up in about eight months of work that we had put in up to that point and essentially take a dive off a cliff and take a chance that we were going to make the right decision to switch editors essentially while the plane was in mid-air. So I want to take this point just to mention, and this is something that I think about as a front-end developer every day, that behind every line of code there's a fragile ego seeking affirmation, you know. We write code because I think we love it, and when someone else loves it as well, it's a good feeling. I know that someday as I'm not the best at being a positive force in development, specifically when people mess with my passwords, not making or allowing me to make my passwords as strong as I'd like them to be. I actually think about this tweet a lot when I'm just about to rage on somebody for doing something stupid. I step back and say, you know what? I've probably done something stupid like that as well. All right, anyway, so back to Create. We pulled out a lo-ha, we replaced it with Seek Editor. The reason that we had Create in Core now was becoming less and less salient, and we were running into problems with the model that Create has for editing content in place. They have a field-based model, so you edit one thing, you make a change, you save it, and that change gets pushed, you know, back into your content management system. We were trying to move to an entity-based editing model where you'd edit multiple fields in the front-end, get all those changes into a package, and then push that change back into what maps nicely to a revision on the backend in Drupal. The problem was that the model inside of Create was almost impossible to change, and I personally sat there for about 48 hours coming up to a weekend trying to decide if I just didn't understand it as well as I could. You know, was I not understanding this library, was I really not do what we needed it to do? So I spent a weekend looking at the possibility of running through this code, essentially bypassing Create and getting to the point where I could edit something on the front-end of Drupal and save it on the backend without Create doing anything, and I managed to do that. So with that very hacky prototype in place, we looked at some of the other factors that affected this decision, and being the commit history of Create up to the point in April where we were faced with this decision to pull it out and build our own code or to keep it, and we had to recognize that there just wasn't the activity in this project that we had hoped was going to be there, especially because there are other CMSs that were supposedly using this piece of code. So around April last year we made another decision to jump off a cliff, essentially invalidate 10 months of code that we had put into place at that point, rip it out and write our own. And this to me was probably the scariest decision I've ever taken as a developer, because we didn't know if this was going to work. We had no idea if we were going to, you know, bog ourselves down in custom code and then have to backtrack or, you know, waste time that we could spend developing other things, fixing our bad decision. And I've kind of come to this place with front-end development where the strike that I'm anticipating, the sting of that decision, I find is never as bad as I think it's going to be, because the time that you spend, you know, building out one approach to a solution is often the time you need to understand the problem. So for us, the 10 months that we spent integrating Create and Aloha Editor was time for us to really understand what in-place editing meant in Drupal. So when it came time for us to build our own version of Create, you know, it really only took about five weeks. And this comes down to this idea of confidence in front-end coding. So when I'm feeling a lack of confidence, let's say, I like to think about World of Warcraft. So do we have any World of Warcraft players in here? Any recovering? So I'm a level 55 hunter. I got out of Warcraft just out of grad school where my addiction started. And I remember something very specific about Warcraft when I'm feeling that I don't understand a problem. So when you're fighting a monster in Warcraft, you have the monster up in this little circle, and you have its power represented by a number. And the color of that number tells you your chances that you're going to be able to either defeat it or not. So yellow means that you've got a pretty good shot as long as you're clever. Red means that you're probably not going to survive, but lucky you might make it through. And if it's the skull, you just run. So for me, the skulls are anything to do with PHP and Drupal. When I see that, I just want to take off. But anything to do with JavaScript is kind of a yellow at this point. And what happens with the monsters in World of Warcraft is as you level, they become relatively easier to tackle. You know, every time you go up to 81 and 82 is not that bad. When you get to 84 and 82 is boring. So I've read this in a blog post and I wish I could... I think it might have been Sarah May who said this. Wish I could remember. But she says that for expertise really comes down to the number of tricks that you develop over time. A seasoned developer just has more tricks that they can bring to bear in a problem. And one of those tricks, just to give you an example that I have, is jQuery underscore data. So this little method, which is extremely poorly documented, I think I've found it like looking through the jQuery object one day, allows you to pass in a DOM element into the first argument. And if you want, you can ask for the events. You can just pass in the element and get an object with the events key back. But it'll tell you on any particular DOM element in the page what events are associated with that DOM element. What this allows you to do is to say, well, I have an A tag that has a click event on it and it's messing up. I can go through and tunnel back to the function, right click on the function, get back to its declaration in the file and figure out what's causing the behavior that's, you know, the mystery. And before I knew about this, I would go from the other direction, you know, grepping the code base to find something that looked familiar to get back to the bad behavior. So this is a, you know, just a little trick that I've had over time. And the other bit about expertise that I've learned is that edge case awareness is something that you kind of develop intuitively. And to give you an example of that, I see a lot of new developers in Drupal who don't realize that this attached behaviors method is going to be called over and over and over again on a particular page load when an AJAX call is made. Any time that there's new DOM elements coming from the server side into the page that need to get re-initialized, this method gets called again. And it's the source of a lot of trouble because if you have code in there that gets declared, variables that get declared, they all happen, that all gets run again. And until you realize that you just have to run jQuery once to prevent this sort of re-initialization, you end up, you know, banging your head on Drupal and then like a level six monster becomes nothing when you're up in an 82. So I was trying to think of some tips for honing personal value, sort of personal value and expertise as a developer and I just put up the list of things that I'm working on right now. But I think they have a lot of value for developers as you're coming up and the one thing that I've really learned to value is writing tests. They're really painful. If you follow me on Twitter, you'll know the day that I'm writing tests because I am just a whiny, whiny son of a gun. But once you have them, they're amazing because you can make changes and not have to worry so much about what you're breaking. I'm currently reading a lot about performance in JavaScript just trying to understand how do you make a loop more performance. And the things that seem to be surfacing within the front-end worlds that I think will have value going forward are the basics. Like we're coming back to the basics after a decade of abstraction and libraries on top of those, like DOM methods, the query selector and query select all that find things on the page. What in the past would have been something that we would have worked with jQuery for are coming back because the browsers and the user agents we work in actually support them. And I had the opportunity last Tuesday to meet Brendan Eisch in Douglas Crockford at the TC39 meeting in Boston. They're talking about the ECMAScript 6 specification that should be coming up pretty soon. Sorry, it was a big moment for me. Brendan Eisch was the guy who invented JavaScript developed like 16 years ago. So my recommendation to you as if you're like sort of a novice front-end developer is really focus on the basics of ECMAScript 5 and 6. I know there's a lot of talk about the copy script and stuff like that, but knowing the basics allows you to understand those structures in those high-level languages in a way that allows you to become a better developer. And then although I love SAS, I can't say enough that when I have someone come up to me and say that, and this happened at a Drupal meetup in Boston the other day, she said, I kind of know CSS, but I really have to learn SAS. And I said to her, you don't really have to learn SAS. You really have to learn CSS. When you get good at that, SAS is going to be the thing that makes you a better developer. And then working with someone who's better than you is probably the best way to become a better developer. But I've also found, and there are many people here who will agree with this, that mentoring someone who isn't good yet is probably the best way to get better. And then the pithiest and best piece of advice I have from my, she's not really my mentor, I follow her on Twitter, she's really quite good, it's just try hard shit. So if you don't know how something works, and I tell this to my JavaScript students all the time, you can't break a page. You can only break it for that one refresh. All right, so we've talked a bit about how to become a better developer. And I find that one of the shortcuts to becoming a better developer is to talk to people who already know what they're doing. But in our industry in particular, we seem to have a lot of what I call celebrity developers who gain a lot of the oxygen in the room. They really kind of steal the spotlight. And this becomes a problem because the problems that we focus on as a community tend to be the most rarefied and important, but somewhat, I don't want to say insignificant to downplay the problem, but they're very particular. So let me give you one example. We have 20 million high-density screen devices sold in 2011. This was by Apple, so we have high-density screens on laptops, iPhones and whatnot. In that same year, there are about 6.5 million Americans with visual impairments that lived in the United States, so either completely blind or somewhat visually impaired. I had this tweet come across my Twitter stream. If you're into front-end development, you probably follow Brad Frost. You probably hear about these responsive patterns days. So we have responsive patterns with Brad Frost sold out over the weekend. He agreed to add four more seats. Fantastic. How many of you can imagine a tweet like this? Accessible authoring tool patterns with awesome dev, sold out over the weekend. And then she agreed to add four more seats. Fantastic. I personally can't imagine having an accessibility event be as popular as we might imagine, responsive web design or some sort of semantic authoring tool. But the thing is, if we look at our user bases, we find that there are a lot more people than we might realize who are accessing content that we're trying to provide to them in ways that are not visual, that have nothing to do with responsive screens. So in 2012, the WebAIM survey surveyed 1782 visually impaired individuals and asked them, how do you access the internet? How do you access information? When they asked them about mobile devices, what they found is that 72% of those visually impaired people access the internet through a mobile device. Of that 72%, 58% access the internet through an iPhone. So that's, if you do the numbers, 6.5 million visually impaired people, 70%, 52%, you end up with like 2 million people in the United States potentially are using their iPhone with your slick and squishy responsive web design with absolutely no need for that slick squishiness. They're going right past it to the content through the screen. But what I don't see in our industry is the type of interest and enthusiasm about that kind of content access that we have for these sort of high profile things like CSS3 and animations, gradients and responsive web design. So Nathan Smith is a fantastic person to follow on Twitter. He expressed the sentiment that I was feeling as I was writing this presentation that, concepts of responsive web design and AJAX have come in and killed as a strong word. And you'll notice that Ethan Marquette gets a little incensed at the bottom there. Nathan apologized a little bit. But they've overshadowed, let's say, progressive enhancement, which really underlies responsive web design. I mean responsive web design is progressive enhancement for visual interfaces. So let's take an analogy to understand what progressive enhancement really means. A Drupal Gov days a couple months ago, Catherine McNally was talking about accessibility. And one of her examples was this idea of an elevator. So let's say you're a developer who's building elevators. You have to be sure that your elevator, this slick, futuristic transportation method is 100% safe. It can't fall. It can't stop. When your elevator breaks, you've essentially trapped people inside of a box that they have no way of getting out of. In contrast, if we look at something like an escalator, it does the same job, carries people from one level to another. But when it breaks, it becomes a flight of stairs. You can still get to the top of that conveyance without needing outside assistance. And I've been working on accessibility up to this point for a couple of months, but this analogy really struck home for me about what progressive enhancement is. It's starting with escalators, starting with stairs and building the escalators on top of them. It's making sure that the fundamental pieces of our interfaces are going to work when everything breaks down. So personally, as I think about the front-end development space, I'm trying to distill it down into the primary values. One of those is content. So to me, what we do as developers is provide content and we provide access to that content. That is essentially the value that we provide as professionals. There's information out there. We're making it possible for individuals out in the world to get to that content, no matter what means they have available. If they're sighted, they're not sighted. If they can only use their tactile sensory inputs. And I really have to remind myself all the time that the page is not the content. The page is one of the means that we use to present the content. So by training, before I got into development, I was a linguist. I focused on studying languages of the world, what we call topology, or comparative linguistics. And I wrote a grammar of verbs and noun declension in a now extinct Native American language. But the thing that struck me, I think as a freshman one day, was a professor who focused on child language acquisition. And her thesis was that we don't know of an upper limit for children and the acquisition of language. She was personally studying children acquiring four languages at once, English, French, American Sign Language, and Kipakwa Sign Language. And what she proved to us over the course of a semester was that the human capacity for language is not expressed or bound up in any of the medium or the media that we use to express it. So specifically, language is not speech. And we can see this in the way that a child learns how to babble and sign language. So that child wasn't saying anything with those hand movements. They were like, you know, ma, ma, ma, ba, ba, ba, as it's learning to articulate. This professor said to us that, you know, there's a common held misbelief that if you teach a child sign language, it's going to learn how to speak sooner, learn how to communicate sooner than it would if it were taught spoken language. But the reality is that the child is incapable of producing spoken language until about two months after it's capable of producing signed language. What you're doing by teaching that child sign language is you're accessing the capacity for speech or for language that exists there already, you know, at the age of eight or nine months. They're already capable of producing, you know, words and babbling. You can just get to that capacity faster through hands. So I'd like to take this analogy from my past life and bring it forward to the current. I understand that the content that we're providing to end users is like our capacity for language. It exists, and we as professionals are simply providing the means of getting to it. We're, you know, teaching our users to speak. We're teaching them to sign through the interfaces that we build. And I personally break the delivery of content down into four different areas. The first and most important to me is accessibility. And I don't define accessibility as simply non-visual interfaces. I lump visual interfaces in that category of accessibility. Because what we're doing is making content accessible to visual people. As a profession, we tend to think about our interfaces as visual things. We get caught up in responsive web design. We get caught up in high density scalable images. It's probably true that the major percentage of our user base is visual. But at the same time, we can't focus on that exclusively. It's like building, you know, an apple tree that only a 10-foot pack of Durham standing at a time length of the 4-foot trunk is able to access and saying that those are the users we're going to support. The rest of those people on the ground can figure it out for themselves. The other aspect of content is findability. And what this essentially comes down to is the URL. So if you remember back in 2010, when Twitter broke the Internet, they introduced the hashbang pattern into their URLs. And they turned what was a findable, locatable resource into a hidden resource. They took a tweet that you were able to, you know, address through a single URL. And turned it into something that had to be interpreted by a user agent in order to get that content. They broke the Internet. Yesterday, I had someone come up to me here and say, we have to build for Drupal 8 a completely separate content administration layer in backbone or Angular, what have you. And just rip out the theming layer. And I said, yes, I totally agree. And then I asked, but the one problem I have with that solution is what happens when you go to node one if we rip out the theming layer? How do we provide content to someone who is arriving at our website through a stable URL that perhaps hasn't gotten into our application yet that we built on top? And I think we always have to remember as front-end developers that it's the content that we're getting to the end user. All the goodness that we sprinkle on top cannot make that, you know, cannot undermine that basic tenant. So another piece of content is personalization. And this is something I think that's coming up more and more in Drupal development. I'm certainly getting pressure from people above me at Acquia to work on this. The problem with personalization is it conflicts with performance. So in Drupal 7 and into Drupal 8, we had this situation on node pages, especially lists of node pages, where you were told, you know, how many comments in a particular node you hadn't read yet. This is a really interesting piece of personalization, because when you're on a list of ten nodes, you can know immediately how many you have to drill into to see comments. The problem arises is this information is specific to you, how many things you've looked at already. And once we get into user-specific information on a page, we've got into user-specific cache, right? We can only cache this item and reuse it for you, personally. So Wim layers spent quite a bit of time over the past five months figuring out a way for us to provide this information to the end user in a way that doesn't make the page itself from the server unique, essentially, you know, providing the information on the client side. And then the other aspect of content delivery is speed. We have to get information to people as fast as possible, but we're also limited by the devices and the user agents that we're working with. So something that I think just came to my attention within the past couple of months is that a mobile device spends about 450 milliseconds before it's even gotten any information from the server, just establishing communication between your device and the server. So about 150 milliseconds to send out, 150 to get a response, 150 to say, I got your response, and then we get data. So as we're trying to make Drupal 8 faster, we're very aware that we have these very hard limits sitting just underneath us. If we make a page load in 20 milliseconds, it's still going to be 470 on your phone. OK. So with that incredibly long preamble, let's look at some of the things we're going to get in Drupal 8. Personally, the thing that I'm most excited about in Drupal 8 is REST built right into core. I've tried to install services module, maybe like 510s in my life, and I've never succeeded in getting it to work. REST for me works right out of the box most of the time. And sorry, I just like that picture a lot. When I think about HTTP methods, I think about throwing fish and how like if someone threw a fish at me, I'd be like 403, not accepting that. All right, so here's a bit of a video. I'm using Postman to do a post into my Drupal installation. We're going to create a node with some data. We've got a title and a couple other things you have to send to it. We get a response back, 201, this thing was created. Inside the headers that we get back, we're told the location of that new piece of content we just created, and we can go look at it. So we get that piece of content we just created through an HTTP method back as JSON. And if we look at an installation that had no content up to that point, we see that we now have a new node. So you can imagine what this means for your front end applications. You can very easily create content, update content, delete content. We're working at the moment on a backbone module that extends the backbone model for you and creates the syncing endpoints to update things like nodes and pages and articles. A layer that automatically understands the structure of that data that is coming back from Drupal and will allow you to simply extend the Drupal backbone module extension of the backbone model. There's a lot of very similar words. So we're getting backbone with Drupal. This was an incredibly contentious decision when we decided to go with backbone. It took months of back and forth to get this into core. But once we got it, we really took off and started using it heavily. I think there are many good examples inside of core right now of patterns that we're developing that take this idea of content, sort of capital C content, and expose it to the end user through whatever medium they're most comfortable with. Specifically, we've broken the interface into visual and oral components that are all driven from a common backbone model. So this model stores the state of the application, so the state of your toolbar or the state of your contextual edit links. And it expresses that state to the end user in whatever form they're most comfortable in, specifically with the oral. When we have something like the open or closed state of the trade change, we're able to express that out to a spoken user agent. At the same time, we express that state of the model out to the visual layer, so the screen, by opening or closing that drawer. And this leverages some bits we've gotten to core here, the Drupal announce bit. So again, we're thinking with backbone in a content first way and using it to enhance the experience. I know you've probably heard about twig templates a bazillion times so far, and it's only Tuesday, and you're only going to hear about them more. The only reason I really bring it up at this point is because I need to tell you about something we're not going to get later on. But for anyone who hasn't heard about them, because you've been under a rock perhaps for the past 12 hours, the twig templates on the server side are brought in from the symphony import, and they allow us to expose content to end users without using PHP, so you don't have things like database access in a twig template. And we also have a kind of a common syntax, this percentage syntax that a lot of other templating languages use. So if someone coming in from a different project using smarty templates, I think, uses the same thing, they're going to recognize this syntax and be able to use it really quickly. And then the fourth bit in Drupal 8 for front end developers that I'm completely excited about is something I'm personally naming the semantic application layer. So this comes from work we've been doing in the accessibility side. We're taking in this technology called accessible rich internet applications. It's acronymed as ARIA. And we're taking this capability that was meant to provide a way to express the semantics of an application to a screen reader. And we're using it to drive the semantics of the application for everybody. Essentially it's a way of describing the state of your application through a layer that is agnostic to the means of presentation. So if we look at a quick example, I've got a Drupal 8 page. And you're going to recognize ARIA in the role attribute. I think WordPress introduced this like four years ago in their standard template, and we put it in since. This is essentially telling a user agent that this piece of HTML is going to act as something else rather than the native semantics. It's become a bit redundant because we have things now like the nav element. We just got the main element. But it's not redundant for pieces of HTML that don't have native semantics yet, like content info or application toolbar group. So what we're doing on the semantic application layer is we're taking a concept like active, and we're encoding it instead in this ARIA pressed attribute. So when something is pressed, we switch the Boolean in this attribute from true to false and false to true. And the fact that it has a class active is just an artifact of the visual presentation layer. We're not using that class to drive any of the behavior. That class appears because of the state that we're representing farther down. And this is a really big mental change because in the past what we normally do is we create a class, we put it on the DOM, when we want to know what state that piece of DOM is in, we go get its classes and say, do you have an active class? Well, you do. You must be in an active state. Let me do a bunch of stuff here that responds to the fact that you're in active state. We're doing all that stuff, and at the end, we're throwing the class on. We also have ARIA to change, again, this role. An A tag that's acting as a button, we say, hey, user agent. This is not really an A tag, this is really a button. And when you have a spoken user agent go through the DOM, instead of saying link, it now says button. And with the ARIA pressed attribute, it says button active. I'm not sure if this is gonna be a thing yet, the semantic application layer, but if you all start using that word, I think we're gonna make it a thing. It's kind of like fetch. We're gonna make it a thing. Okay, so all the good stuff we're gonna get, there are big gaps in what we're going to get in Drupal 8 in terms of frontend support that are going to have to be filled in the contrib space. To me, the most important one is this idea of a big pipe. So if you're familiar with Facebook, they have this capability of taking all the requests for information that come from their page, bundling them up, sending them as one request back to their server, processing all those requests, bundling them back up again and sending them back to your clients where they get disassembled and then passed to the different pieces on the page that requested that information. For us, we're essentially making a single request per piece of information. Do you need to know if your comment, if you're no need to comment link? Do a request. Do you need the submenu items from your toolbar? Make a request. It's not that bad now. And we're taking steps for the requests that we know about to make them less aggressive. So we're only making them when something in the cache changes. But going into contrib, I have this fear that we're going to see our pages get really greedy for requests from the server. And I'd like to see us as a community focus on how we solve that problem. Some sort of common system where I can register the fact that I need data with a controller on the page and it takes care of fetching it and giving it back to me in an efficient way. All right, so the twig templates, is twig sharing, get it? We're not going to get sharing of twig templates from the server side to the client side, which means as a developer, as a module developer, you define what a node is supposed to look like. You provide that template and then you get to the client side and you have no idea what that definition is on the client side. It's a very tricky problem because in order to get that template from the server side, we have to run through the entire process of determining what template to get. Do you want the one from core or from a module or from your theme? And then we have to check access. We have to run all the alters and everything until we figure out what that template is and then give it to you. And then you're kind of still responsible for formatting the data correctly to pass into that template. It's a tricky problem and at the moment, we just don't have a solution. We're still using the old Drupal 7, Drupal.theme, create a string, pass it up to whatever your caller is. We also didn't get themagnostic layouts. That means that when you put a block in a region, that region is still associated with a theme. We don't yet have a construct that is theme independent where you can specify regions, responsibility, block placements and then share them across themes. I really see this as something that would have made composable front-end applications a lot easier if we were able to request large chunks of the page to slot in on our basic piece of content. And we're also not getting some sort of conditional asset loading. So this would be a library like require or YupNope that checks the feature capabilities of the user agent before loading the JavaScript or the code that's going to respond to that feature. At the moment, it's still Drupal 7. We statically define all of the code that you might possibly need. We run through the library dependencies and you get this big chunk on the front-end even if your user agent doesn't support any of the features that that code drives. We could vastly reduce the amount of information we're sending if we had a way of holding off on requesting assets until we knew what the user agent was doing really quickly when we run through this. So I wanted to end on another linguistic thing just to kind of get your minds warmed up for the rest of the conference. Metaphors to me are an incredibly powerful tool for anyone, for designers, for developers. They define the way that we understand a problem. So let's take a problem like time, a problem you didn't even know you had. When we think about time, we think about moving into the future, right? We move forward, the future's ahead of us, the passes behind us, we're constantly making progress, the drop never stops. So down in South America there's a group, a linguistic group of people called the Imara and for them they have a completely reversed model of time. For them, moving into the future is moving backwards. And everything that you know, everything that you can see is in front of you, that's the past. This is encoded into their language directly. So when you ask them how was the movie they say, or when was something they'd say, well it was in front of me a couple of days. To them, the things that we can see are the things that we know. And when I first learned about this group of people, it completely floored me that something as fundamental as our concept of time is completely arbitrary, it's plastic, it's the outcome of our society and our language, the constructs that are built for us. And when I'm thinking about front end development, I like to come back to this example because it causes me and pushes me to question the fundamental assumptions we have about what we're building. I didn't arrive at accessibility because I wanted necessarily to make things accessible. I arrived there because I was starting to question the infallible and sort of omnipresent nature of these screens that we were working with. I was wondering, is there some other way that we, we're going to be delivering information in the future? And it just happened that accessibility is a model and a way of thinking about content that is going to prepare us for a future of auditory interfaces, you know, screens and devices that we talk to rather than interacting with our fingers. So just to sum up, big points, content. Content is the primary asset that we're working with as front-end developers. Access is the thing that we as professionals provide, be that visual or auditory. And we're building escalators, we're not building elevators. When you build something, ask yourself, when this breaks, what is it going to look like when it falls backwards? So just to sum up, if you're interested in backbone and learning more about backbone in Drupal 8, I recommend the talk right after this one in the North Hall by D Lancer. There's a buff where we're going to be talking about the backbone module in Drupal specifically happening on Wednesday at 3.45. And if you are interested in helping out with any of the front-end code, come to the sprints on Friday, and I will be there as well. There we go, thanks. I guess people ask questions at this point to have them. On your earlier sort of points that you made about having unique URLs, having web-accessible content and using backbone, say you were building a Drupal site that used Drupal as a back-end and backbone as a front-end, would that be something you'd just say never do or other ways that you could make that better, that you could do it differently? Because some cases, JavaScript web apps seem to work very well for certain things, but I definitely see your point that it's not necessarily the most accessible, the most web-friendly way of implementing it. Yeah, so it can be accessible. JavaScript doesn't mean inaccessible. 98.6%, 98.4% of people that access information through a spoken user agent have JavaScript enabled, and it's actually 0.2% more than the general population. So you have a better coverage in JavaScript with blind people. What makes it inaccessible is when you change things on the page without telling someone about it. So just changing a class on an element isn't going to be apparent to someone who doesn't see the color of that element change. So you have to be expressing these changes through this semantic application there that I'm talking about, so using ARIA. And then to address putting some sort of backbone front-end on top of Drupal, I love that idea. I would rather be doing front-end code in the browser than kind of half-composing it over in the server and sending half of it over to the browser. I think the thing we really need to solve is what is the layer just underneath there before the JavaScript runs? We wanna make sure that the constant items, all the nodes and the entities in the site have some sort of representation, which may be completely bare bones, maybe a header and some navigation links and that item, no sidebars, no related nonsense. Do all that in your client. But we need something there. So when Google comes by and crawls that site, it has to find some semantically significant piece of information. And I think Drupal is well-poised to be the system that kind of sits in that middle, produces semantic output, but just enough to get you to that point and then says go, go build your crazy interactive thing. Cool, thanks. Oh my god, he's really, he's like doing the stair climb. With the semantic markup of the area roles and that sort of thing, is there like a standard that we should be following? I know there is for the, it's usually targeted at screen readers and that sort of stuff, but I really like the idea of actually using it for just everything on the page and maybe having something like when you build a view in Drupal, usually you just have a little custom class that you can put in, but maybe having a role that you can put in there or for JavaScript events, for triggering, for telling something to the screen reader, is it something, because the HTML of five ones like the nav and the header and the footer, I just don't think they're enough and usually end up just running out of them and just doing section class this, section class that. And I think the area roles seem to be much better way of doing it. Is there like a standards move in to use those as semantics and ignore the rest of them? Yeah. There is a standard, if you Google Aria, you'll find it. The language isn't completely built out. Like I often run into a point where I can't find an attribute that describes well the thing I'm trying to do, so I try to do the best that I can with it. It's always evolving, but it's not an open set. You can't just invent Aria hyphen something and expect it to do anything. And even the user agents, like JAWS and voiceover and Chromebox, they're still developing support for it. And blind people are, people that use screen readers are still learning how to use this stuff. It's kind of new. But I think on a project like this, we should be pushing that sort of, the envelope of that technology because it is the adopted standard in the accessibility world. And it's something that we can co-opt in a really good way, like you were saying, to define the semantics. I don't think it's been explored completely yet, in terms of performance, in terms of just the edges of how you can cementically describe your application. But I think it has more promise than just using arbitrary classes. So I'm kind of committed to finding out what are the limits of it. Go forth, enjoy your coffee.