Angular, Ember, Meteor, Backbone, the front-end framework space is a busy place indeed. You'd be forgiven for feeling a bit overwhelmed and unsure where to start, but more importantly you're likely to miss an important alternative: to ditch your frameworks altogether and go it alone. It's not for everyone, but this approach can be valuable and rewarding - not just for you but for your clients as well. This talk will cover all the basics you need to build a complete single page application entirely from scratch (well almost). Instead of getting bogged down in the pros and cons of framework use we'll demonstrate practical solutions to common problems, and even see how we can avoid some problems altogether.
 Okay. So my name is Pete Smith. I'm an associate of a consultancy called Equal Experts. We're based in London. If you fancy working in London, drop a line. I don't normally do a corporate spiel but I like working for Equal Experts. It's a good crack. That's what I usually say. So I've been a web developer for almost 10 years. So I've done a lot of work in the kind of JavaScript front-end space. And I'm here to talk to you today about frameworks or rather what you might be able to do if you wanted to explore, rolling your own JavaScript and leaving the frameworks behind altogether. And I'm talking about no jQuery, no Angular, absolutely nothing, just working with the raw DOM and raw JavaScript native browser kind of technologies. Most of what I'm going to talk about is fully ES, ECMAScript 5.1 compatible. So stuff that you'll find today in your browser. There's one tiny little bit which is going to be a little bit more advanced and more modern. But most of this stuff you can go away and use this today. So I've got a kind of reverse agenda here. I'm going to talk about what I'm not going to do first. I'm not going to evangelize. I'm not going to go on and on and on about why you should or shouldn't use a framework. I'm not going to attempt to build my own framework. And I'm also not going to solve all the problems that come with trying to write JavaScript from scratch because I want you guys to go away and play around with some of the samples and the demos that I look at and kind of discover this stuff for yourself. And obviously there will be far too much of that for one talk anyway. So here's a slide with some things about why you might want to use a framework. It boils down to frameworks are great when you don't have a lot of time. If you want to get your MVP out the door, you need to hire people who already know how to work with a certain framework. Then frameworks are great for these kind of reasons. Here's a slide about why you might not want to use a framework. This is in the corporate kind of sphere. Kind of I like this quote. I'm not quite sure where it came from about you can't perform delicate surgery even if you do have the best Swiss Army knife available. So if you really need fine grain control, maybe you have a very specific problem domain that can benefit from that kind of being able to control every nuance of your code, then going alone, building your own JavaScript in a mature organization that has the time and the effort to spend on it can be really beneficial. But this is what I am going to look at in this talk. I'm going to do this introduction. The vast majority of this is going to be a live coding session. So I have spent weeks making various sacrifices trying to appease the demo gods in the hope that this will all go smoothly. But inevitably something will go wrong. So please don't shout out that I've missed a bracket somewhere but I've got a plan. It's fine. And then we'll kind of do a quick recap and if we have time I'll look at a sample app that I've kind of built with all of the different technologies we're going to look at. So I did talk, I want to talk a bit more in depth about the personal reasons for trying to write your own JavaScript without a framework because it's all well and good trying to evaluate things in the corporate sphere. But there are reasons why you as an individual might want to do this in your own time for example. It's a great way to learn how frameworks actually do things underneath. It gives you a greater understanding that allows you to work better within a framework in the future. It gives you a greater understanding of how they achieve their goals and what their guiding design principles might be. But importantly it allows you to kind of, you can look at a framework and you'd be like, ah, why did they do, why have they taken that approach and then you can kind of try something yourself and you realize that the performance sucks. It's awful and you're like, ah, okay, this makes a bit more sense now. But most importantly it's great to question the status quo. This is how innovation in our industry happens. If we never always just accept what we're given, we just use the frameworks in the arrangement, the default configuration then, you know, we're just going to be stuck with the same technology forever and if you actually go ahead and say, oh, well actually I think I can do better than this. I think I've got a better idea and I'm going to give it a go. And that's how things in our industry move forward. But most of all, rolling your own JavaScript can be a lot of fun and that's the kind of message that I want to focus on today. So before I get to the real meat of the talk, just a quick disclaimer. Things like security, build tooling, data binding, never try and do these things yourself. There's absolutely no point. Security, you will just leave a massive hole in your application, build tooling, this is no point, it's already been done, we have gulp and grunt and these things all work very well already. And data binding, there are just far too many little edge cases and things that you end up faffing around for a long time. So there's absolutely no point trying to do any of this stuff yourself. So we're going to start looking at the live coding demos. So I'm going to do three demos for you today. I'm going to do data binding. I'm going to look at templating and I'm going to look at routing. So data binding, again, this is more, I know what I said, but it's more focusing on you get to learn where these nuances are, you get to learn where the edge cases are and why certain approaches are taken. The main thing I'm going to stress here is everything you see is going to be very paired back. It's going to be stripped down. It's not going to have any syntactic sugar. It's not going to have any kind of quality of life bits and pieces. So a good example is in the data binding example, I'm not going to have any special attributes or anything, no DOM part, you know how Angular will parse the DOM first to discover where all your relationships between your data are and to see which elements you're binding to. There'll be none of that. It's all going to be explicit, done with code. So let's say we're going to start with data binding and I'm just going to set out some goals so you know what we're aiming for and what we're going to expect in this demo. So we're going to achieve the main objective, of course, we're going to be able to propagate changes from the DOM to the model and also vice versa. We're going to write explicit syntax, as I mentioned. We're going to use a plain JavaScript view model so no knockout style observables or anything like that. We will bind either to variables or functions. I'm not going to bind to getters and setters for reasons you'll see shortly. And where there's a dependency chain, we're going to represent that explicitly. We're going to have to actually say that this property depends on this one. There's been no automatic dependency detection. And right at the end, I'm going to have a quick look at two-way binding. So this is the starting point for my data binding demo. As you see at the top, we have an input element called name with a default value of Pete. And then we have a paragraph tag with an ID of greeting. And slightly further down, we have a view model. So I've got a reference here to this lib common. I just want to open this up and show you what's inside this because there are a few bits and pieces that I have prewritten in here. Things that just kind of, because we're not using jQuery, these are a few short hands that will make things a little bit more familiar when, not so much for me when I'm typing, but for you guys when you're looking at the code. So we've got a ready function, a click function, a for each kind of iterator, a map function first, various different bits and pieces that you would kind of will help us to generate the code. I just want to draw particular attention to this compose function because I use this quite a lot. It's very, very simple. All I'm doing is passing in an object, enacting a function on that object and then returning the object again. So whenever you see compose, that's basically what that's doing. It just allows you to shave a few lines of code off here and there that will make things flow a little bit more easily. So back to our data binding. So the kind of syntax that I want to use is going to look a little bit like this. I'm going to say data binding dot from value. I'm going to say view model. I'm going to say I want to bind from the name element to the name property on the model. So very simple. That's the first thing we're going to do. So here I have my from value function with the same parameters. And the first thing we're going to do is get a reference to the element. You can do that with a really nice, instead of jQuery, obviously, we've got a very nice built in function here called query selector, which is on document. You pass the element selector into that. The second thing we need to do is define a function which is going to act as our event handler. So this is very simple. When the element changes, what we want to do is to simply set the model property, as I do there, number lock, to be the element's value. Then we wire that up. So that's not, we've got the function already. The reason we've got the function is already is because we want to call it straight away so that as soon as we invoke our data binding, then the value is going to get set. So I'm just going to put a quick alert in here so we can see what's happening before we carry on. I do have a license, but I forgot to put it in before starting the demo. So this is going to, this is going to be quite embarrassing. Never mind. So data binding, Pete, when that changes, the demo gods are angry. So there we go. So initially when the page loads up, we have the initial value is Pete, so we get a ping for the data binding. We change it to Pete. I know the JavaScript alerts will be a little bit small. There we go. So we've now bound that property from the input element to our model. So the next thing we want to do is to bind back from the greeting function to the greeting Pete tag. So again, our syntax is going to be very similar, but we're going to say data binding to text. So that's going to go from greeting to greeting. So now we implement the two texts. So the first thing we do again is get a reference to the element. Now things get a little bit trickier because obviously we're working with a plain old JavaScript model and we don't have knockout observables to help us. We don't have any kind of extra fancy bits and pieces. So what we actually need to do is we need to swap out our property and we need to kind of wrap it with a little bit of extra functionality that essentially emulates the features of a knockout observable. So I'm going to call this function called ensure wrapped to make sure that it's wrapped and we're going to pass the model and the property name. So our ensure wrap function is going to look a little bit like this. Model property name. So first we're going to take a reference to our property or our member, which is probably a better name. So the two different cases we're going to be dealing with. The first one is that this member is a function. So we say if type of property is a function. So we may have already wrapped this property before and the way we will tell is we will have a little, just a Boolean on there called wrapped. So if it's already been wrapped, then we return it. Otherwise we call the wrap function past the property and the model. So our wrap function is going to look a little bit like this. Well, very much like this. We'll set the wrapped Boolean so we can tell in the future. We have a list of actions and we have an update function. So when the update function is called, this is the mechanism by which we will propagate the change that's occurred and each action will represent an element in the DOM that needs updating. So we will first of all just get the results of the, obviously we're passing in a function. So we'll just get the result of that function. Because we're not invoking this function as a member of the original object, we need to bind to the model to make sure that the value of this is going to be correct. Then we want to iterate over the actions and simply invoke each one with the result. Hopefully that makes sense. You can see that in action very shortly. So if it doesn't make sense now, it will become hopefully very clear. So the second option is that we are dealing with a regular field, a variable such as name. And in this case, we are going to replace the name variable on the model with a getter and a setter. So we can still provide a function to wrap because the getter, obviously the getter function is then, you can represent that as a function and return the original value. So first of all, we're just going to check if we've already done that. Much the same way we did with the function. We can say if getter will be null if we haven't already done this. So if getter and getter.wrapped, if it's already wrapped, then we simply return it. Otherwise, we want to call this function called object defined property. Now this is in ES5.1 and what that will do is that we'll add a getter and setter to the model with the given property name. So we just want to make sure if our getter was null, we just want to make sure we create one. So what we want to do is we want to wrap a dummy function that simply returns the value of a property. At this point, we capture a closure around the value of property. So property at this point is going to contain the value of the name. So in this case, Pete. And so once we've captured that as a closure, we'll always be able to refer back to that. So retain that reference to that underlying variable. We will specify our getter. In the set function, we simply update property to be the new value and then we call getter.update, which will propagate the change. So whenever we assign a new value to name, the getter update function will be called and that will propagate the changes to all of our actions that we've got set up. And finally, it will just return the getter. So continuing the implementation of our two text, what we want to do is basically now say property.actions.push function new value and say element.textContent is equal to the new value because we want to bind the element text. And then finally, we just want to call property.update to propagate the values initially. So we just expose this from our module and fingers crossed. Hello. Line eight. Never mind. Very slight bug. Yeah, there we go. So there we go. So now we've got our greeting ptag is populated according to our text box and our value of the model. But if we try and change this now, then nothing happens. That's because we don't have any dependencies set up between the name and the greeting. So the way I'm going to do that is just to say explicitly add the dependency on the view model between. So I want to say that greeting depends on names. We have name changes, then the greeting should do as well. So let's implement that function. So I say we get a reference to our property like we did before. We get a reference to our dependency. Never spell that one, especially in a demo. So we say that dependency has an action. So when the dependency changes, we simply update our property. And again, always make sure we just update it the very first time the page loads and the dependency is added. So now the demo gods are happy finally. Excellent. So at this point, I just want to mention about two-way binding. I'm just going to add a quick little button up here. So it will just be buttons called it's me. And it basically just reminds the demo that it's me. It's Pete. So the click handler, we'll just add for that. It's just a function which says view model dot name is Pete. So we can see that the greeting tag changes, but the text box does not. That's because we only have a single direction of binding. Now the two-way data binding, love it or hate it, is actually kind of a bit of a weird one because you'd think that two-way data binding might be quite complicated to implement and you might have to unwrap yourselves from like cyclic dependencies and all sorts of things. But actually, two-way binding is just two lots of one-way binding. If I clone this here and now say that I want to bind back from the model to the text box, just add a two and then go in and I'll just clone our two text as a two value. So we just change that and change that and then make sure we've exported it. Then now things change in both directions. So two-way data binding, actually dead easy. So that was the routing demo. So hopefully that made sense. That was good fun. It's also worth noting how we've just done that in about 15 minutes and that was a little bit under 100 lines of JavaScript. This is actually the largest demo in the sequence. So these things are actually, although it's very kind of rough and ready, we've actually done what we set out to do. We've achieved all of our goals. So now we're going to have a look at templating. What are the goals of our templating demo? We want to have some reusable templates that allow us to stamp out different bits of functionality. We want to repeat that process in a single case and also in a repeating case. We want to do a kind of foreach over a bunch of data in our model. So what we're actually going to use, this is the one bit of the demo that is not ES5.1 directly compatible. We're going to use web components. Now I'm not going to go into a huge amount of detail, but web components basically provide you with a new tag called template. So gone are the days when templating was complex and difficult. Now, there is, and you can do it with a few lines of code. So I'll show you that. We're also going to support data binding within our templates because if we don't, then they're going to be pretty useless, let's be honest. So back to the code. I'm going to close these down. So first thing I'm going to do is I'm going to define the template tag. So this is a template called hello. And all this is going to do is going to have a p tag and it will say hello and then we'll have a span within the p tag, which will be the target where we're going to render the data. That's where we're actually going to make use of the templating. We'll also need somewhere to put it. So let's just add a little div here called hello target. So we're going to use a fluent syntax, a fluent DSI API type thing. It's going to look like this. So we're going to say our hello is a single template and what we're going to do is we're going to tell it where to read the template content from and we're going to give it an initializing function. That will take a reference to the root element within the template. So this is the p tag and we will also get our data. So I'll say we're doing things explicitly. So when the template initializer function is called, this happens when the element is first created as a new copy. So we need to make sure that we're setting the data. So we say use our docum- p.query selector that we saw in the previous example and we just find the spam and set the text content to be our data. So now we have a template. We need to kind of actually stamp it out and I've write it to our target. So we just say hello dot render. That's our data. And we say render the data to hello target. So that's the syntax that we're going to build. So inside our template, so I've already got a few little bits and pieces set up here in the templating library. You can see we have a constructor and we have a kind of a little mini object to represent a fluent template. All we're doing there is we're looking in the document to find the template that we've told it is going to exist and then we read the content from there into the template property. So the render function is obviously part of our fluent DSL and all we're going to do in that is say keep a reference to the data and return it just so we can then chain on and continue doing things with our template. So the create element is I guess the meat of our template. This is what's going to take that snippet of content, actually reintroduce that as a clone to the DOM and then place it in the target location eventually. And the way we can do that is we say define element is we call this thing called document dot import node. We say we're importing a node with the contents from our template. I can't remember what true. I think that's make sure it's a deep clone. So once we have our, so that now means that the template tag is a protected space. It basically nothing inside the template tag will execute on page load. Nothing will actually show up in the DOM. It's basically just a DOM container. So document dot import node does is that actually produces a document fragment that although has not yet been added to the DOM, it is alive and it is kind of a true part now of the page. So what we want to do is we just want to invoke our initializer function which we'll set up now that we've got it in the page. We can do all the data binding and we're going to make sure we target the root node so that all of our rest of our functions work properly. And then we're going to return the element. Brilliant. So that's the meat of our template binding engine done. So now I'm going to define the single template. And that's a function that takes the template selector and an initializer. And so here's where we're going to see the first use of compose because we're going to compose this single template from a fluent template. And then we're basically going to give it a function to operate on our template immediately and then return it. And what we're going to do is attach our two method which is the missing piece in our fluent DSL. So we add our function which is literally going to take a target selector. We'll get a reference to our target. And we're going to say target dot append child and we're going to call this dot create element and pass it the data that we specified earlier. So very straightforward. As soon as we've stamped out that element we can then add it to the DOM and Bob's your uncle. So let's just make sure we've exposed the single and run a quick JS lint just to see if anything really obvious is missing. It looks okay. Let's find our templating. Something really obvious was missing. Now we can see that we've got hello, Pete. And if we go back and add another one, you can say hello audience. And we get that comes up underneath. So we've taken the value. We've mixed it with the content to produce some new content. So that's pretty cool. But now we need to have a look at the repeating context. We need to be able to take a list of things and kind of stamp all of those out in one go. So I'm going to define another template. This one's called list item. And this is literally going to have a list item in it. And the target in this case is going to be a unordered list simply called list. What we're going to have in addition to this is we're going to have an input element with a text box that will allow us to add new values to our list. And a button that complements that called add button that will actually set up our event handler. So we need a little view model. And I've got one that I prepared earlier. I have a view model with one property. It's a data array and it has three items in it. I've also wired up a click handler for my add button. If you notice what's actually happening here is we're not just adding stuff to this array. We're not pushing stuff to this array. We're actually using concat to create an entirely new array. That's because the data binding that we're going to introduce later obviously relies on the setter firing and obviously it's an array. Otherwise that wouldn't happen. So that's again an example of a simplification. You can see how that could be extended in the future. So we're going to create our list item. This time it's going to be templating dot render. Sorry, repeat not render. That's list item. This will take a function that gets a reference to the li and in this case data is going to be one of the entries in our array. So all we do here is we say li.textContent equals data. And then when we come to use this we'll just say listItem.renderViewModel.data to list. So very simple. And actually the implementation of this is even more simple because we've already got the part that will stamp out an element. We just need to basically do exactly the same thing as we've had before but now we call it repeat. Because we are going to be, we're doing things very simply as I said. So what we're actually going to do is every time we bind to the value of the array changes what we're actually going to do is tear everything down and just render it again. Now this may seem like quite an inefficient way of doing things but actually if you think about something like react it's not very difficult to see how instead of just tearing everything down we could maybe keep a little tree structure, our own virtual representation of the DOM that we could then use to determine which elements we should pull out or which ones we should keep. So again it's kind of very simple but easy to see how you could extend this to provide even deeper functionality. So we're going to just wipe out our target, set the inner HTML to nothing. And now we're going to loop over our data and we're going to call a function for each item. Because of the way the for each function is going to get executed again it's not going to be executed as a member of its original container so we need to bind the value of this to ensure that things stay working as they should do. So what we're just going to do is instead of create element on this.data which is the overall array we're just going to give it the individual item. So everything else should work as expected. Again we'll just do a quick check to see if there's anything I've missed. I think it's fine. Look at that, that worked first time, that's brilliant. So you can see we've got our items have been rendered out into a list and if we try and add a new one, oh no, it doesn't work. But actually that's a deliberate mistake because obviously there's nothing saying that when the array changes there's nothing telling this to update the DOM. So what we need to do, I'm using a slightly more advanced version of the same data binding library add before. This one has a function called observe. So we just say I want to observe the data property of the view model and I want to give it a function that when the value changes I want to render my list. And obviously it will tear down the list, render a new one and instead of view model data we just need to give it the change value. So this time we can add as many as we want and everything works splendidly. So that was a bit shorter than the last one but very simple, also quite a lot of fun. And we achieved all of our goals, we had the reusable template, we had the C repeating template, did some cool stuff with web components and we did the data binding. Okay, so final demo. Although this one comes with a disclaimer. I've left this one to the end because this is, stuff's going to get a little bit technical at this point so I do apologize. I'm going to start applying some basic functional programming techniques which I'll explain very shortly but just kind of be prepared for this one to be a tiny bit mind bending. So we could simply have a big dictionary or a map of all of the kind of routes we expect of maybe a regex representation of our client side routes and then we could just have a function associated with each one. Use regex to extract the parameters of if we have like slash items, slash ID, we want to display a particular item for my catalog, we could use regex to extract those values, that would be quite simple but it's also quite boring and it doesn't scale very well when you have hundreds of routes because you have to go all the way through every single entry on your routing table before you can figure out exactly which one you're matching. So I'm going to show you a new concept which I call graph based routing or you can kind of think of it as routing as a state machine. It's actually a lot simpler than it sounds. You store your representation of your route as a graph. So that being a series of nodes, the circles connected by edges, the lines. So we can see if we are going to, if we're coming in and we say slash API slash products slash ID, each section of the route I'm going to call a segment. So the route is composed of segments separated by slashes. So we take the first segment and we see, okay, so that is equal to a constant value that I expect which is API. So that match is made and you can then move on to the next node and the next one and in the case of where it's an ID, for example, you would say I'm expecting an alphanumeric value as opposed to just a string constant. So essentially means as we traverse the graph, as we move from state to state, we have a set of other potential states that can come next. So instead of having to consider an entire routing table, all we need to do is say, okay, so once I've matched API, now I know that I either expect products or customers and you don't need to worry about anything else and it becomes quite efficient. So as the segments are matched, they're consumed and even possibly captured for future use as parameters. So in this demo, I'm going to implement a very simple graph-based routing engine. So the goals are to be able to capture any number of parameters in any of our segments and execute a handler. So we're going to wire this up to the hash change event in the page. So we could go as far as actually doing proper history API-based routing, but I've kept this simple because this will work with a static page and hopefully it might be something that more people are familiar with if you've never done history API before. Does anyone know that you can do operator overloading in JavaScript? Has anyone ever seen this done? It's kind of hacky, but it's also kind of cool. So I'll show you that shortly. We're going to work with routes that are composed hierarchically. It kind of means that we will be able to define the items part of our route first and then say, actually, items then has this and this, so we can actually, we don't need to represent everything really long every time. We can compose these things really nicely. And we're going to work with immutable data structures because it makes the algorithm much, much nicer. This is one of the functional aspects I was talking about. So what will essentially happen is we will determine a path through the graph based on matching algorithms for each node and we will create a sequence from those and then left-fold across and we'll end up with a handler and a series of parameters that we can invoke. Very simple, really, honestly. So let's have a look at that now. Okay, so I'll actually start by showing you what this looks like, what the end result of this demo is going to be. So we're going to have a little kind of H tag at the top. And I don't know if you can see really the top bar is just going to change. When I click go somewhere, you can see we've now got hash slash items. When I click go somewhere else, we just have hash item slash two. So I've already got this wired up to work with the hash change. That's the kind of boring stuff. I've got this navigation.js here. This will all be online afterwards. So if you want to delve any deeper into any of this, then feel free. So we've got this stuff wired up. So this is my click handler. This is my on hash change. So what we're going to do is when the hash changes, we want to execute the routing engine and we pass it the hash, which is basically the part of the URL that we're interested in. So this is what I want to draw your attention to most of all. This is the syntax of how we're going to define our roots. So we can see we have items and item and then favorites. And hopefully it's easy to see how we're, so this is how we're kind of composing these hierarchically. So we say that items is the base node. The starting point is always going to be the hash. We'll always have a hash and a slash. So that's our base node for starting this whole process when you looked at the graph before. That's the first node. And we say after the base node, we expect a constant node of just items. So that's a constant block of text that is items just matched explicitly. When it comes to an item, we say that we expect the first part, the items, and then also an alpha numeric set of characters. So the matching function for alpha numeric is different for the matching function from constant. And then right at the end, we define a set of handlers, which call the set title function, which will change the contents of that h tag. And you can see the operator overloading in use there as a kind of shorthand way of saying the slash, which basically this whole concept came about because I was like, that would be a really cool way to define roots. And then I backfield everything else. So let's have a look at our, so this is what we're going to start off with as a base for our routing demo. And you can see initially we've got a kind of little JavaScript object that represents a root node at the top there. And as you saw in the example, the root node has a series of edges represented as an array. These are the places it can go next. And we have a match function and an action function. So the main thing we're going to need to do when, as we are traversing our graph, we're going to always need to, when we given a certain root node, we're going to have to be able to determine which root node is next in order to build a sequence from the graph. So we get in a list of segments. So this is, obviously this is going to be recursive. So this is the list of segments that currently remain yet to be processed. So there's a possibility, there's a possibility that the segments are going to be empty. This might be the end of the routing process, in which case we literally just return null. Null is going to be the way we indicate to the engine that we're finished with routing and we can recurse back up the stack. If it's not null, then we basically want to find the first, oh, what did that jump over there? That's annoying. The first edge that is a match for the next segment in the list. So the first function just will return the first thing in that array for which this function I'm specifying here is true. So we want to say return, so if the edge is a match for the segment. So very simple. We either return null or we iterate over all of the edges and find the first one that the match function returns true. So I'm just going to skip over these next few methods just for the time being. Just to show you an example, so we're going to implement the constant node. So the constant node just takes the static template that we're going to match against and we're going to return a compose of a new root node and then perform an action on that. So we're going to give this root node a match function. So the match function will take the current segment and we will basically just say if the segment is equal to the template, then it's a match. So that does our constant node. And as we mentioned, our base node is always going to be a constant value equal to hash. So we can just go here if our base node equals constant hash. In fact, let's stick that down there. So that's the match function of a node. That's quite straightforward. Of course, we had another function here and that is the action function. Now what we do with the action function is this is what allows us to capture. So basically whenever that node is matched, the match is successfully made, we then execute the action. And this is what we're going to use for our parameter capture. So I'm going to define the alpha node down here. I've got a little shortcut for it. So I've done the same pattern as before. I've composed a root node and I've given it a match function. In this case, the match function is now instead of just a constant comparison, this is a regex that will just match letters or numbers in repeating any number of letters and numbers. The alpha node kind of constructor will take the name of the parameter that we want to capture. So this is what our action function will look like. So again, the action function will take the current segment and what we would do, we want to return a new object and what we want to do is we want to set a property or variable on our new object according to the name we've asked for and we just want to set that to be the segment. And now you can see why the compose function is so lovely and saves, that would be like five lines otherwise. So again, we want to just expose this. So we can see that we've got our, all of the kind of node structures that we require in order to actually do this. But if we look back at our, let's get rid of that, and that we look back at the syntax that we asked for. And we need an execute function that's actually going to kick all of this stuff off, that's actually going to start the traversal of the trees, of the graph and perform our routing. This is going to be our entry point. So we want our execute, this is just a function that takes essentially a URL, in this case we bring it from the hash, but it's still what we're interested in is the URL. And we basically say we want to get the result of the traversal of our graph is base node, dot traverse, we'll start from the base node and we say URL dot split. So we split the URL into its relevant segments. And then we say, because it's not always necessarily going to be a handler, if you didn't specify one, then this could be null. And so we just want to say if there is a handler in our result, then we want to, those, we can just go result dot handler and invoke that with result dot parameters. So we are using this, so the result is going to be one of these, going to be a traversal result that's composed of parameters and handlers. So obviously we now need to implement our traverse function. This is the bit that's going to do our recursion, it's actually going to produce this left folding kind of behavior. So the first thing that we need to do is we need to execute the action function of the node that we're currently on in order to see if it's going to provide us with any parameters or any other side effects, for example. The beauty of this is that action function can execute any arbitrary code you like. It can do some crazy things. Same with the match function. You could have this match on the time of day, for example, or like the operating system of your user's computer. Any kind of crazy stuff you can put in this match function, not just string matching. So I want to say the result is a new traverse result and this is a combination of, I want to execute the action function. Instead of just reading the segment at this point, I'm going to do a shift. So this actually pops the very first item off in order to then effectively consume that segment. So I have to double check my brackets here because this is one of the main problems with my thing. So we create a traverse result based on the result of the action and the handler if it has one. So we also then need to figure out what the next node in the sequence is going to be. So we call find next match. We pass at the list of segments. So now, remember that the next match in the sequence could be null. But what we want to do is if we do have a next function, because we're dealing with immutable data structures right now, if a future action function is going to return us some parameters, each one is going to do so with a separate object. So we need to take the objects and combine them into one. So create a new immutable data structure based on the result of the next match and the next one and so on. So basically, if we do find a next node, we want to say a result extend the result, sorry, traverse, the result of traversing the next node and so on. And that's our point of recursion. And we pass the segments to that again. Otherwise, we've reached the end of the chain. Our next is null and so we just dump the result back down the tree. And the only other thing we have to do is implement the extend function for our traverse result and that is literally returning a new traverse result. And we have, so this is a JavaScript extend. If you know jQuery, you'll be used to this kind of syntax where we look at this dot parameters and combine that with the other dot parameters. Panther, that would be exciting, wouldn't it? Where's the bracket there? And so the only last part that we also need to do is, so if I've defined an item, if we look back, I've defined a handler on items and I've also defined a handler on an item. But if we do go all the way through and match the alphanumeric part as well, then obviously we don't want to execute the handler against items. We're only interested in the last handler we come to. So what I'm going to do is when I give the handler to the traverse result, I say if the other one has a handler, then use that. Otherwise, fall back to the handler that we've already got. So that's the kind of immutability in play, but it allows us to do some really kind of concise bits and pieces. So the final piece in the puzzle is we need to be able to construct the graph in the first place using our fancy operator overloading. So I have condensed this down into a little function that you can go away and look at called operator overload that takes the type of things you're expecting between your operators and a left and a right. So and these are just the operands that you're going to be dealing with. So in this case, we just want to return a compose. It's important that you always return the rightmost operator so you can then kind of otherwise the thing will never progress. And all we're going to do is say that the left dot edges should now be attached. So that's building up our graph using the operator overload. So that will be our left hand operator, that will be our right hand operator and will result in items now having an edge that points to our alpha node. And then to actually enact that, we go return expression dot evaluate. Again, if you look at how this works, we are expecting the define takes a function which will then be invoked in order to construct the graph. So we need to evaluate this with we invoke the function and give it our base node. And then we just need to go routing dot execute execute routing dot define is define and a quick JS hint just to see if there's anything that is completely missing. Oh, retron retron is not defined. No, it wouldn't be. What line is it highlighted there? Return. Okay, so this could be tense. That was never going to work. Didn't export constant. Oh, yeah. There you go. Ah, never mind. I only get one. There was something there. Never mind. Now we can see when we go to items, the items handler is executed. And when we go to items two, then the handler is executed again. So if we just have a double check of what the handler is doing. So, yeah, that's what we'd expect. We'd see the item and then we've got params dot id coming into that handler. And so, yeah, that's cool. That's exactly what we'd expect. But let's just test this favorites route down here because if we go items slash favorites, then we should see something different. So let's just try that in there. And ah, so that hasn't quite worked. What we've done is that is now said, oh, I'm expecting an ID which is any alphanumeric set of characters and that's picked that one up in preference to our constant. But we can fix that really easily because we're just matching the first one that we come to. And so this will now put the constant node ahead in the list of edges. And if we go back and then try favorites again, that's items. Now we get favorites. So we've basically produced an entire client-side routing engine in a little bit over 70 lines of code which I think is pretty cool. It would have been even cooler if I'd managed to get through the whole thing without making like a tiny little syntax error. But again, I think that's pretty cool. So that was our routing handler. We've a routing engine and all of our goals achieved. So let's say a little bit technical but hopefully it made sense. And I'm doing pretty well on time. So just before I wrap up, I'm going to show you, I basically put together a, so I kind of took this on, these demos were what I could do in the time. And then I took this on and actually built an entire to-do list application out of all of the bits and pieces that you've just seen. So here you can see that we've got a list which is the target for our template. We have a button that allows you to add a new one. Our list item in this case is much more complicated. We've got like a little field set. We've told it it's hidden and we've got the ability to edit and remove and all sorts of things. You see I'm brought in all of the JavaScript and these are all kind of like, there's much more, yeah, a little bit further along implementations. So here's our view model. We've got an ad click and you can see that actually we have this in our item, we have a link. So we're actually using routing as we click on each item in our to-do list. We actually use the routing to actually navigate between them. We've got some routes to find down here and so if we reach the items route then we're going to just collapse all the elements in the view model. And this is our template, template and dot repeat. You can see we've got a whole bunch of stuff in here. We've got like binding to a link, href, we've got binding to a show hide. And see these are all things you could, you can just go on and on with this. You can think like, what do I want to bind to now? You can just keep adding little bits inside the to and the from and I've even got a to strike through here as you'll see. So let's just have a quick look at how that works. Let's make this bigger. So here's our framework list to-do list. We can add an item. If we check the box, we get the little strike through comes up and off. You'll notice if we now click that we've now got slash items slash nought in the address bar, we can change the name of it and you can be like do demo and you can add another one. Now edit this one. We've got item slash one and you can say like, wow, wow, the audience and then you know like, question mark, question mark, question mark. Can you tell what's coming? See it. And for example, you can then just remove them and you know add another one and tick them all off. So that's just- I just wanted to show you that quickly because that's kind of the closest thing to a real world example that I've kind of got but it shows you that that stuff actually you could build an application out of this stuff as long as you know the happy path is there. So I'm just going to sum up as we're almost at the end of the session. But I thought that was pretty simple. Maybe not so much the rooting part but you know we've actually implemented three elements of single page applications like I've done that in front of you today and admittedly I had a bit of practice but it's not rocket science. It's actually quite easy to understand but there are a few problems. Now these implementations have a lot of flaws. Security, none. Test coverage, zero. Performance, we didn't measure it but presumably it's not great. And no error handling, nothing. So we have no quality of life bits and pieces. Literally this only worked because we knew exactly what we were doing and we were following the happy path all the way through. But the good thing was that most of it as I mentioned before is ES 5.1 compatible so you could feasibly use this as long as you don't have to support IE8 which incidentally you should not. The main thing is that hopefully we learned a lot doing this. I know I did as I was preparing all these demos. You know I hadn't anticipated when I started having a look at data binding I never intended to look at that but actually I was like actually you can do some of this stuff. You wouldn't be able to build a fully fledged implementation but you would eventually. But you know everything is very simple. If you leave out all of the extra bits and pieces like the DOM parsing and the automatic dependency management then you can clearly see how stuff kind of hangs together and works. And it's really extensible. You can see how with the to-do list all I did was added a few more twos and froms and then we kind of actually ended up with something that really worked. But most of all it's not magic. You know frameworks they may be complex they may contain a lot of code but you can look into them. You can open up the code. You can read it and you can reason about what they do and gain a greater understanding by doing so. And I think that's the key message I want to instill here is that you know actually with the some of the stuff we implemented we actually avoided lots of like nasty little problems with. We didn't do any of the complex stuff but we still achieved our goals. But you can look into these things yourselves and you can understand what the frameworks are actually doing and who knows. You may even be able to contribute back to them if you can see an improvement. You probably shouldn't write your own framework but I encourage everyone to contribute to an open source project if that kind of is something you're interested in. So I have a few other libraries that are kind of slightly more mature. I didn't talk about dependency injection but I have this thing called DIY. There's no docs for that but it's kind of a fun approach in JavaScript. I'm not sure you should really use it but it might be interesting to look at. I have a, if any of you are ASP.net developers I have a graph based routing implementation for the server side as well which is called superscribe and a JavaScript version of that as well. So if that interests you go and have a play and let me know how you get on. Thank you for listening. I hope you've got something out of this talk. Remember that the red and yellow buttons are broken today and thank you very much for listening. This is the code on GitHub and I'm here with equal experts so if you fancy a contract in London look them up. Thank you very much. I'll be around at the whole conference so just come and find me.
 Okay. So my name is Pete Smith. I'm an associate of a consultancy called Equal Experts. We're  based in London. If you fancy working in London, drop a line. I don't normally do a corporate  spiel but I like working for Equal Experts. It's a good crack. That's what I usually say.  So I've been a web developer for almost 10 years. So I've done a lot of work in the kind  of JavaScript front-end space. And I'm here to talk to you today about frameworks or rather  what you might be able to do if you wanted to explore, rolling your own JavaScript and  leaving the frameworks behind altogether. And I'm talking about no jQuery, no Angular,  absolutely nothing, just working with the raw DOM and raw JavaScript native browser  kind of technologies. Most of what I'm going to talk about is fully ES, ECMAScript 5.1 compatible.  So stuff that you'll find today in your browser. There's one tiny little bit which is going  to be a little bit more advanced and more modern. But most of this stuff you can go away and  use this today. So I've got a kind of reverse agenda here. I'm going to talk about what  I'm not going to do first. I'm not going to evangelize. I'm not going to go on and on  and on about why you should or shouldn't use a framework. I'm not going to attempt to build  my own framework. And I'm also not going to solve all the problems that come with trying  to write JavaScript from scratch because I want you guys to go away and play around with  some of the samples and the demos that I look at and kind of discover this stuff for yourself.  And obviously there will be far too much of that for one talk anyway. So here's a slide  with some things about why you might want to use a framework. It boils down to frameworks  are great when you don't have a lot of time. If you want to get your MVP out the door,  you need to hire people who already know how to work with a certain framework. Then frameworks  are great for these kind of reasons. Here's a slide about why you might not want to use  a framework. This is in the corporate kind of sphere. Kind of I like this quote. I'm  not quite sure where it came from about you can't perform delicate surgery even if you  do have the best Swiss Army knife available. So if you really need fine grain control,  maybe you have a very specific problem domain that can benefit from that kind of being able  to control every nuance of your code, then going alone, building your own JavaScript  in a mature organization that has the time and the effort to spend on it can be really  beneficial. But this is what I am going to look at in this talk. I'm going to do this  introduction. The vast majority of this is going to be a live coding session. So I have  spent weeks making various sacrifices trying to appease the demo gods in the hope that  this will all go smoothly. But inevitably something will go wrong. So please don't shout  out that I've missed a bracket somewhere but I've got a plan. It's fine. And then we'll  kind of do a quick recap and if we have time I'll look at a sample app that I've kind of  built with all of the different technologies we're going to look at. So I did talk, I want  to talk a bit more in depth about the personal reasons for trying to write your own JavaScript  without a framework because it's all well and good trying to evaluate things in the corporate  sphere. But there are reasons why you as an individual might want to do this in your own  time for example. It's a great way to learn how frameworks actually do things underneath.  It gives you a greater understanding that allows you to work better within a framework  in the future. It gives you a greater understanding of how they achieve their goals and what their  guiding design principles might be. But importantly it allows you to kind of, you can look at  a framework and you'd be like, ah, why did they do, why have they taken that approach  and then you can kind of try something yourself and you realize that the performance sucks.  It's awful and you're like, ah, okay, this makes a bit more sense now. But most importantly  it's great to question the status quo. This is how innovation in our industry happens.  If we never always just accept what we're given, we just use the frameworks in the arrangement,  the default configuration then, you know, we're just going to be stuck with the same  technology forever and if you actually go ahead and say, oh, well actually I think I  can do better than this. I think I've got a better idea and I'm going to give it a go.  And that's how things in our industry move forward. But most of all, rolling your own  JavaScript can be a lot of fun and that's the kind of message that I want to focus on  today. So before I get to the real meat of the talk, just a quick disclaimer. Things  like security, build tooling, data binding, never try and do these things yourself. There's  absolutely no point. Security, you will just leave a massive hole in your application,  build tooling, this is no point, it's already been done, we have gulp and grunt and these  things all work very well already. And data binding, there are just far too many little  edge cases and things that you end up faffing around for a long time. So there's absolutely  no point trying to do any of this stuff yourself. So we're going to start looking at the live  coding demos. So I'm going to do three demos for you today. I'm going to do data binding.  I'm going to look at templating and I'm going to look at routing. So data binding, again,  this is more, I know what I said, but it's more focusing on you get to learn where these  nuances are, you get to learn where the edge cases are and why certain approaches are taken.  The main thing I'm going to stress here is everything you see is going to be very paired  back. It's going to be stripped down. It's not going to have any syntactic sugar. It's  not going to have any kind of quality of life bits and pieces. So a good example is in the  data binding example, I'm not going to have any special attributes or anything, no DOM  part, you know how Angular will parse the DOM first to discover where all your relationships  between your data are and to see which elements you're binding to. There'll be none of that.  It's all going to be explicit, done with code. So let's say we're going to start with data  binding and I'm just going to set out some goals so you know what we're aiming for and  what we're going to expect in this demo. So we're going to achieve the main objective,  of course, we're going to be able to propagate changes from the DOM to the model and also  vice versa. We're going to write explicit syntax, as I mentioned. We're going to use  a plain JavaScript view model so no knockout style observables or anything like that. We  will bind either to variables or functions. I'm not going to bind to getters and setters  for reasons you'll see shortly. And where there's a dependency chain, we're going to  represent that explicitly. We're going to have to actually say that this property depends  on this one. There's been no automatic dependency detection. And right at the end, I'm going  to have a quick look at two-way binding. So this is the starting point for my data binding  demo. As you see at the top, we have an input element called name with a default value of  Pete. And then we have a paragraph tag with an ID of greeting. And slightly further down,  we have a view model. So I've got a reference here to this lib common. I just want to open  this up and show you what's inside this because there are a few bits and pieces that I have  prewritten in here. Things that just kind of, because we're not using jQuery, these  are a few short hands that will make things a little bit more familiar when, not so much  for me when I'm typing, but for you guys when you're looking at the code. So we've got a  ready function, a click function, a for each kind of iterator, a map function first, various  different bits and pieces that you would kind of will help us to generate the code. I just  want to draw particular attention to this compose function because I use this quite  a lot. It's very, very simple. All I'm doing is passing in an object, enacting a function  on that object and then returning the object again. So whenever you see compose, that's  basically what that's doing. It just allows you to shave a few lines of code off here  and there that will make things flow a little bit more easily. So back to our data binding.  So the kind of syntax that I want to use is going to look a little bit like this. I'm  going to say data binding dot from value. I'm going to say view model. I'm going to say  I want to bind from the name element to the name property on the model. So very simple.  That's the first thing we're going to do. So here I have my from value function with  the same parameters. And the first thing we're going to do is get a reference to the element.  You can do that with a really nice, instead of jQuery, obviously, we've got a very nice  built in function here called query selector, which is on document. You pass the element  selector into that. The second thing we need to do is define a function which is going  to act as our event handler. So this is very simple. When the element changes, what we  want to do is to simply set the model property, as I do there, number lock, to be the element's  value. Then we wire that up. So that's not, we've got the function already. The reason  we've got the function is already is because we want to call it straight away so that as  soon as we invoke our data binding, then the value is going to get set. So I'm just going  to put a quick alert in here so we can see what's happening before we carry on. I do  have a license, but I forgot to put it in before starting the demo. So this is going  to, this is going to be quite embarrassing. Never mind. So data binding, Pete, when that  changes, the demo gods are angry. So there we go. So initially when the page loads up,  we have the initial value is Pete, so we get a ping for the data binding. We change it  to Pete. I know the JavaScript alerts will be a little bit small. There we go. So we've  now bound that property from the input element to our model. So the next thing we want to  do is to bind back from the greeting function to the greeting Pete tag. So again, our syntax  is going to be very similar, but we're going to say data binding to text. So that's going  to go from greeting to greeting. So now we implement the two texts. So the first thing  we do again is get a reference to the element. Now things get a little bit trickier because  obviously we're working with a plain old JavaScript model and we don't have knockout observables  to help us. We don't have any kind of extra fancy bits and pieces. So what we actually  need to do is we need to swap out our property and we need to kind of wrap it with a little  bit of extra functionality that essentially emulates the features of a knockout observable.  So I'm going to call this function called ensure wrapped to make sure that it's wrapped  and we're going to pass the model and the property name. So our ensure wrap function  is going to look a little bit like this. Model property name. So first we're going to take  a reference to our property or our member, which is probably a better name. So the two  different cases we're going to be dealing with. The first one is that this member is  a function. So we say if type of property is a function. So we may have already wrapped  this property before and the way we will tell is we will have a little, just a Boolean  on there called wrapped. So if it's already been wrapped, then we return it. Otherwise  we call the wrap function past the property and the model. So our wrap function is going  to look a little bit like this. Well, very much like this. We'll set the wrapped Boolean  so we can tell in the future. We have a list of actions and we have an update function.  So when the update function is called, this is the mechanism by which we will propagate  the change that's occurred and each action will represent an element in the DOM that  needs updating. So we will first of all just get the results of the, obviously we're passing  in a function. So we'll just get the result of that function. Because we're not invoking  this function as a member of the original object, we need to bind to the model to make  sure that the value of this is going to be correct. Then we want to iterate over the  actions and simply invoke each one with the result. Hopefully that makes sense. You can  see that in action very shortly. So if it doesn't make sense now, it will become hopefully  very clear. So the second option is that we are dealing with a regular field, a variable  such as name. And in this case, we are going to replace the name variable on the model  with a getter and a setter. So we can still provide a function to wrap because the getter,  obviously the getter function is then, you can represent that as a function and return  the original value. So first of all, we're just going to check if we've already done  that. Much the same way we did with the function. We can say if getter will be null if we haven't  already done this. So if getter and getter.wrapped, if it's already wrapped, then we simply return  it. Otherwise, we want to call this function called object defined property. Now this is  in ES5.1 and what that will do is that we'll add a getter and setter to the model with  the given property name. So we just want to make sure if our getter was null, we just  want to make sure we create one. So what we want to do is we want to wrap a dummy function  that simply returns the value of a property. At this point, we capture a closure around  the value of property. So property at this point is going to contain the value of the  name. So in this case, Pete. And so once we've captured that as a closure, we'll always be  able to refer back to that. So retain that reference to that underlying variable. We  will specify our getter. In the set function, we simply update property to be the new value  and then we call getter.update, which will propagate the change. So whenever we assign  a new value to name, the getter update function will be called and that will propagate the  changes to all of our actions that we've got set up. And finally, it will just return  the getter. So continuing the implementation of our two text, what we want to do is basically  now say property.actions.push function new value and say element.textContent is equal  to the new value because we want to bind the element text. And then finally, we just want  to call property.update to propagate the values initially. So we just expose this from our  module and fingers crossed. Hello. Line eight. Never mind. Very slight bug. Yeah, there we  go. So there we go. So now we've got our greeting ptag is populated according to our text box  and our value of the model. But if we try and change this now, then nothing happens.  That's because we don't have any dependencies set up between the name and the greeting.  So the way I'm going to do that is just to say explicitly add the dependency on the view  model between. So I want to say that greeting depends on names. We have name changes, then  the greeting should do as well. So let's implement that function. So I say we get a reference  to our property like we did before. We get a reference to our dependency. Never spell  that one, especially in a demo. So we say that dependency has an action. So when the  dependency changes, we simply update our property. And again, always make sure we just update  it the very first time the page loads and the dependency is added. So now the demo gods  are happy finally. Excellent. So at this point, I just want to mention about two-way  binding. I'm just going to add a quick little button up here. So it will just be buttons  called it's me. And it basically just reminds the demo that it's me. It's Pete. So the click  handler, we'll just add for that. It's just a function which says view model dot name  is Pete. So we can see that the greeting tag changes, but the text box does not. That's  because we only have a single direction of binding. Now the two-way data binding, love  it or hate it, is actually kind of a bit of a weird one because you'd think that two-way  data binding might be quite complicated to implement and you might have to unwrap yourselves  from like cyclic dependencies and all sorts of things. But actually, two-way binding is  just two lots of one-way binding. If I clone this here and now say that I want to bind  back from the model to the text box, just add a two and then go in and I'll just clone  our two text as a two value. So we just change that and change that and then make sure we've  exported it. Then now things change in both directions. So two-way data binding, actually  dead easy. So that was the routing demo. So hopefully that made sense. That was good fun.  It's also worth noting how we've just done that in about 15 minutes and that was a little  bit under 100 lines of JavaScript. This is actually the largest demo in the sequence.  So these things are actually, although it's very kind of rough and ready, we've actually  done what we set out to do. We've achieved all of our goals.  So now we're going to have a look at templating. What are the goals of our templating demo?  We want to have some reusable templates that allow us to stamp out different bits of functionality.  We want to repeat that process in a single case and also in a repeating case. We want  to do a kind of foreach over a bunch of data in our model.  So what we're actually going to use, this is the one bit of the demo that is not ES5.1  directly compatible. We're going to use web components. Now I'm not going to go into a  huge amount of detail, but web components basically provide you with a new tag called template.  So gone are the days when templating was complex and difficult. Now, there is, and you can  do it with a few lines of code. So I'll show you that.  We're also going to support data binding within our templates because if we don't, then they're  going to be pretty useless, let's be honest. So back to the code. I'm going to close these  down. So first thing I'm going to do is I'm going to define the template tag. So this  is a template called hello. And all this is going to do is going to have a p tag and it  will say hello and then we'll have a span within the p tag, which will be the target  where we're going to render the data. That's where we're actually going to make use of  the templating. We'll also need somewhere to put it. So let's just add a little div  here called hello target. So we're going to use a fluent syntax, a fluent DSI API type  thing. It's going to look like this. So we're going to say our hello is a single template  and what we're going to do is we're going to tell it where to read the template content  from and we're going to give it an initializing function. That will take a reference to the  root element within the template. So this is the p tag and we will also get our data.  So I'll say we're doing things explicitly. So when the template initializer function  is called, this happens when the element is first created as a new copy. So we need to  make sure that we're setting the data. So we say use our docum- p.query selector that  we saw in the previous example and we just find the spam and set the text content to  be our data. So now we have a template. We need to kind of actually stamp it out and  I've write it to our target. So we just say hello dot render. That's our data. And we  say render the data to hello target. So that's the syntax that we're going to build. So  inside our template, so I've already got a few little bits and pieces set up here in  the templating library. You can see we have a constructor and we have a kind of a little  mini object to represent a fluent template. All we're doing there is we're looking in  the document to find the template that we've told it is going to exist and then we read  the content from there into the template property. So the render function is obviously part of  our fluent DSL and all we're going to do in that is say keep a reference to the data and  return it just so we can then chain on and continue doing things with our template. So  the create element is I guess the meat of our template. This is what's going to take  that snippet of content, actually reintroduce that as a clone to the DOM and then place  it in the target location eventually. And the way we can do that is we say define element  is we call this thing called document dot import node. We say we're importing a node  with the contents from our template. I can't remember what true. I think that's make sure  it's a deep clone. So once we have our, so that now means that the template tag is a  protected space. It basically nothing inside the template tag will execute on page load.  Nothing will actually show up in the DOM. It's basically just a DOM container. So document  dot import node does is that actually produces a document fragment that although has not  yet been added to the DOM, it is alive and it is kind of a true part now of the page.  So what we want to do is we just want to invoke our initializer function which we'll set up  now that we've got it in the page. We can do all the data binding and we're going to  make sure we target the root node so that all of our rest of our functions work properly.  And then we're going to return the element. Brilliant. So that's the meat of our template  binding engine done. So now I'm going to define the single template. And that's a function  that takes the template selector and an initializer. And so here's where we're going to see the  first use of compose because we're going to compose this single template from a fluent  template. And then we're basically going to give it a function to operate on our template  immediately and then return it. And what we're going to do is attach our two method which  is the missing piece in our fluent DSL. So we add our function which is literally going  to take a target selector. We'll get a reference to our target. And we're going to say target  dot append child and we're going to call this dot create element and pass it the data that  we specified earlier. So very straightforward. As soon as we've stamped out that element  we can then add it to the DOM and Bob's your uncle. So let's just make sure we've exposed  the single and run a quick JS lint just to see if anything really obvious is missing.  It looks okay. Let's find our templating. Something really obvious was missing. Now  we can see that we've got hello, Pete. And if we go back and add another one, you can  say hello audience. And we get that comes up underneath. So we've taken the value. We've  mixed it with the content to produce some new content. So that's pretty cool. But now  we need to have a look at the repeating context. We need to be able to take a list of things  and kind of stamp all of those out in one go. So I'm going to define another template.  This one's called list item. And this is literally going to have a list item in it. And the target  in this case is going to be a unordered list simply called list. What we're going to have  in addition to this is we're going to have an input element with a text box that will  allow us to add new values to our list. And a button that complements that called add  button that will actually set up our event handler. So we need a little view model. And  I've got one that I prepared earlier. I have a view model with one property. It's a data  array and it has three items in it. I've also wired up a click handler for my add button.  If you notice what's actually happening here is we're not just adding stuff to this array.  We're not pushing stuff to this array. We're actually using concat to create an entirely  new array. That's because the data binding that we're going to introduce later obviously  relies on the setter firing and obviously it's an array. Otherwise that wouldn't happen.  So that's again an example of a simplification. You can see how that could be extended in the  future. So we're going to create our list item. This time it's going to be templating  dot render. Sorry, repeat not render. That's list item. This will take a function that  gets a reference to the li and in this case data is going to be one of the entries in  our array. So all we do here is we say li.textContent equals data. And then when we come to  use this we'll just say listItem.renderViewModel.data to list. So very simple. And actually  the implementation of this is even more simple because we've already got the part that will  stamp out an element. We just need to basically do exactly the same thing as we've had before  but now we call it repeat. Because we are going to be, we're doing things very simply  as I said. So what we're actually going to do is every time we bind to the value of the  array changes what we're actually going to do is tear everything down and just render  it again. Now this may seem like quite an inefficient way of doing things but actually  if you think about something like react it's not very difficult to see how instead of just  tearing everything down we could maybe keep a little tree structure, our own virtual representation  of the DOM that we could then use to determine which elements we should pull out or which  ones we should keep. So again it's kind of very simple but easy to see how you could  extend this to provide even deeper functionality. So we're going to just wipe out our target,  set the inner HTML to nothing. And now we're going to loop over our data and we're going  to call a function for each item. Because of the way the for each function is going  to get executed again it's not going to be executed as a member of its original container  so we need to bind the value of this to ensure that things stay working as they should do.  So what we're just going to do is instead of create element on this.data which is the  overall array we're just going to give it the individual item. So everything else should  work as expected. Again we'll just do a quick check to see if there's anything I've missed.  I think it's fine. Look at that, that worked first time, that's brilliant. So you can see  we've got our items have been rendered out into a list and if we try and add a new one,  oh no, it doesn't work. But actually that's a deliberate mistake because obviously there's  nothing saying that when the array changes there's nothing telling this to update the  DOM. So what we need to do, I'm using a slightly more advanced version of the same data binding  library add before. This one has a function called observe. So we just say I want to observe  the data property of the view model and I want to give it a function that when the value  changes I want to render my list. And obviously it will tear down the list, render a new one  and instead of view model data we just need to give it the change value. So this time  we can add as many as we want and everything works splendidly. So that was a bit shorter  than the last one but very simple, also quite a lot of fun. And we achieved all of our goals,  we had the reusable template, we had the C repeating template, did some cool stuff with  web components and we did the data binding. Okay, so final demo. Although this one comes  with a disclaimer. I've left this one to the end because this is, stuff's going to get  a little bit technical at this point so I do apologize. I'm going to start applying some  basic functional programming techniques which I'll explain very shortly but just kind of  be prepared for this one to be a tiny bit mind bending. So we could simply have a big  dictionary or a map of all of the kind of routes we expect of maybe a regex representation  of our client side routes and then we could just have a function associated with each  one. Use regex to extract the parameters of if we have like slash items, slash ID, we  want to display a particular item for my catalog, we could use regex to extract those values,  that would be quite simple but it's also quite boring and it doesn't scale very well when  you have hundreds of routes because you have to go all the way through every single entry  on your routing table before you can figure out exactly which one you're matching. So  I'm going to show you a new concept which I call graph based routing or you can kind  of think of it as routing as a state machine. It's actually a lot simpler than it sounds.  You store your representation of your route as a graph. So that being a series of nodes,  the circles connected by edges, the lines. So we can see if we are going to, if we're  coming in and we say slash API slash products slash ID, each section of the route I'm going  to call a segment. So the route is composed of segments separated by slashes. So we take  the first segment and we see, okay, so that is equal to a constant value that I expect  which is API. So that match is made and you can then move on to the next node and the  next one and in the case of where it's an ID, for example, you would say I'm expecting  an alphanumeric value as opposed to just a string constant. So essentially means as  we traverse the graph, as we move from state to state, we have a set of other potential  states that can come next. So instead of having to consider an entire routing table, all we  need to do is say, okay, so once I've matched API, now I know that I either expect products  or customers and you don't need to worry about anything else and it becomes quite efficient.  So as the segments are matched, they're consumed and even possibly captured for future use  as parameters. So in this demo, I'm going to implement a very simple graph-based routing  engine. So the goals are to be able to capture any number of parameters in any of our segments  and execute a handler. So we're going to wire this up to the hash change event in the page.  So we could go as far as actually doing proper history API-based routing, but I've kept this  simple because this will work with a static page and hopefully it might be something that  more people are familiar with if you've never done history API before. Does anyone know  that you can do operator overloading in JavaScript? Has anyone ever seen this done? It's kind  of hacky, but it's also kind of cool. So I'll show you that shortly. We're going to work  with routes that are composed hierarchically. It kind of means that we will be able to define  the items part of our route first and then say, actually, items then has this and this,  so we can actually, we don't need to represent everything really long every time. We can compose  these things really nicely. And we're going to work with immutable data structures because  it makes the algorithm much, much nicer. This is one of the functional aspects I was talking  about. So what will essentially happen is we will determine a path through the graph  based on matching algorithms for each node and we will create a sequence from those and  then left-fold across and we'll end up with a handler and a series of parameters that we  can invoke. Very simple, really, honestly. So let's have a look at that now. Okay, so  I'll actually start by showing you what this looks like, what the end result of this demo  is going to be. So we're going to have a little kind of H tag at the top. And I don't know  if you can see really the top bar is just going to change. When I click go somewhere,  you can see we've now got hash slash items. When I click go somewhere else, we just have  hash item slash two. So I've already got this wired up to work with the hash change. That's  the kind of boring stuff. I've got this navigation.js here. This will all be online afterwards.  So if you want to delve any deeper into any of this, then feel free. So we've got this  stuff wired up. So this is my click handler. This is my on hash change. So what we're going  to do is when the hash changes, we want to execute the routing engine and we pass it  the hash, which is basically the part of the URL that we're interested in. So this is what  I want to draw your attention to most of all. This is the syntax of how we're going to define  our roots. So we can see we have items and item and then favorites. And hopefully it's  easy to see how we're, so this is how we're kind of composing these hierarchically. So  we say that items is the base node. The starting point is always going to be the hash. We'll  always have a hash and a slash. So that's our base node for starting this whole process  when you looked at the graph before. That's the first node. And we say after the base  node, we expect a constant node of just items. So that's a constant block of text that is  items just matched explicitly. When it comes to an item, we say that we expect the first  part, the items, and then also an alpha numeric set of characters. So the matching function  for alpha numeric is different for the matching function from constant. And then right at  the end, we define a set of handlers, which call the set title function, which will change  the contents of that h tag. And you can see the operator overloading in use there as a  kind of shorthand way of saying the slash, which basically this whole concept came about  because I was like, that would be a really cool way to define roots. And then I backfield  everything else. So let's have a look at our, so this is what we're going to start off with  as a base for our routing demo. And you can see initially we've got a kind of little JavaScript  object that represents a root node at the top there. And as you saw in the example, the  root node has a series of edges represented as an array. These are the places it can go  next. And we have a match function and an action function. So the main thing we're going  to need to do when, as we are traversing our graph, we're going to always need to, when  we given a certain root node, we're going to have to be able to determine which root  node is next in order to build a sequence from the graph. So we get in a list of segments.  So this is, obviously this is going to be recursive. So this is the list of segments  that currently remain yet to be processed. So there's a possibility, there's a possibility  that the segments are going to be empty. This might be the end of the routing process, in  which case we literally just return null. Null is going to be the way we indicate to the  engine that we're finished with routing and we can recurse back up the stack. If it's  not null, then we basically want to find the first, oh, what did that jump over there?  That's annoying. The first edge that is a match for the next segment in the list. So  the first function just will return the first thing in that array for which this function  I'm specifying here is true. So we want to say return, so if the edge is a match for  the segment. So very simple. We either return null or we iterate over all of the edges and  find the first one that the match function returns true. So I'm just going to skip over  these next few methods just for the time being. Just to show you an example, so we're going  to implement the constant node. So the constant node just takes the static template that we're  going to match against and we're going to return a compose of a new root node and then  perform an action on that. So we're going to give this root node a match function. So  the match function will take the current segment and we will basically just say if the segment  is equal to the template, then it's a match. So that does our constant node. And as we  mentioned, our base node is always going to be a constant value equal to hash. So we can  just go here if our base node equals constant hash. In fact, let's stick that down there.  So that's the match function of a node. That's quite straightforward. Of course, we had  another function here and that is the action function. Now what we do with the action function  is this is what allows us to capture. So basically whenever that node is matched, the match is  successfully made, we then execute the action. And this is what we're going to use for our  parameter capture. So I'm going to define the alpha node down here. I've got a little  shortcut for it. So I've done the same pattern as before. I've composed a root node and I've  given it a match function. In this case, the match function is now instead of just a constant  comparison, this is a regex that will just match letters or numbers in repeating any  number of letters and numbers. The alpha node kind of constructor will take the name of  the parameter that we want to capture. So this is what our action function will look  like. So again, the action function will take the current segment and what we would do,  we want to return a new object and what we want to do is we want to set a property or  variable on our new object according to the name we've asked for and we just want to set  that to be the segment. And now you can see why the compose function is so lovely and  saves, that would be like five lines otherwise. So again, we want to just expose this. So  we can see that we've got our, all of the kind of node structures that we require in  order to actually do this. But if we look back at our, let's get rid of that, and that  we look back at the syntax that we asked for. And we need an execute function that's actually  going to kick all of this stuff off, that's actually going to start the traversal of the  trees, of the graph and perform our routing. This is going to be our entry point. So we  want our execute, this is just a function that takes essentially a URL, in this case  we bring it from the hash, but it's still what we're interested in is the URL. And we  basically say we want to get the result of the traversal of our graph is base node,  dot traverse, we'll start from the base node and we say URL dot split. So we split the  URL into its relevant segments. And then we say, because it's not always necessarily  going to be a handler, if you didn't specify one, then this could be null. And so we just  want to say if there is a handler in our result, then we want to, those, we can just go result  dot handler and invoke that with result dot parameters. So we are using this, so the result  is going to be one of these, going to be a traversal result that's composed of parameters  and handlers. So obviously we now need to implement our traverse function. This is the  bit that's going to do our recursion, it's actually going to produce this left folding  kind of behavior. So the first thing that we need to do is we need to execute the action  function of the node that we're currently on in order to see if it's going to provide  us with any parameters or any other side effects, for example. The beauty of this is that action  function can execute any arbitrary code you like. It can do some crazy things. Same with  the match function. You could have this match on the time of day, for example, or like the  operating system of your user's computer. Any kind of crazy stuff you can put in this  match function, not just string matching. So I want to say the result is a new traverse  result and this is a combination of, I want to execute the action function. Instead of  just reading the segment at this point, I'm going to do a shift. So this actually pops  the very first item off in order to then effectively consume that segment. So I have  to double check my brackets here because this is one of the main problems with my thing.  So we create a traverse result based on the result of the action and the handler if it  has one. So we also then need to figure out what the next node in the sequence is going  to be. So we call find next match. We pass at the list of segments. So now, remember  that the next match in the sequence could be null. But what we want to do is if we do  have a next function, because we're dealing with immutable data structures right now,  if a future action function is going to return us some parameters, each one is going to do  so with a separate object. So we need to take the objects and combine them into one. So  create a new immutable data structure based on the result of the next match and the next  one and so on. So basically, if we do find a next node, we want to say a result extend  the result, sorry, traverse, the result of traversing the next node and so on. And that's  our point of recursion. And we pass the segments to that again. Otherwise, we've reached the  end of the chain. Our next is null and so we just dump the result back down the tree.  And the only other thing we have to do is implement the extend function for our traverse  result and that is literally returning a new traverse result. And we have, so this is  a JavaScript extend. If you know jQuery, you'll be used to this kind of syntax where  we look at this dot parameters and combine that with the other dot parameters. Panther,  that would be exciting, wouldn't it? Where's the bracket there? And so the only last part  that we also need to do is, so if I've defined an item, if we look back, I've defined a handler  on items and I've also defined a handler on an item. But if we do go all the way through  and match the alphanumeric part as well, then obviously we don't want to execute the handler  against items. We're only interested in the last handler we come to. So what I'm going  to do is when I give the handler to the traverse result, I say if the other one has a handler,  then use that. Otherwise, fall back to the handler that we've already got. So that's  the kind of immutability in play, but it allows us to do some really kind of concise bits  and pieces. So the final piece in the puzzle is we need to be able to construct the graph  in the first place using our fancy operator overloading. So I have condensed this down  into a little function that you can go away and look at called operator overload that  takes the type of things you're expecting between your operators and a left and a right.  So and these are just the operands that you're going to be dealing with. So in this case,  we just want to return a compose. It's important that you always return the rightmost operator  so you can then kind of otherwise the thing will never progress. And all we're going to  do is say that the left dot edges should now be attached. So that's building up our graph  using the operator overload. So that will be our left hand operator, that will be our  right hand operator and will result in items now having an edge that points to our alpha  node. And then to actually enact that, we go return expression dot evaluate. Again, if  you look at how this works, we are expecting the define takes a function which will then  be invoked in order to construct the graph. So we need to evaluate this with we invoke  the function and give it our base node. And then we just need to go routing dot execute  execute routing dot define is define and a quick JS hint just to see if there's anything  that is completely missing. Oh, retron retron is not defined. No, it wouldn't be. What line  is it highlighted there? Return. Okay, so this could be tense. That was never going  to work. Didn't export constant. Oh, yeah. There you go. Ah, never mind. I only get  one. There was something there. Never mind. Now we can see when we go to items, the items  handler is executed. And when we go to items two, then the handler is executed again. So  if we just have a double check of what the handler is doing. So, yeah, that's what we'd  expect. We'd see the item and then we've got params dot id coming into that handler. And  so, yeah, that's cool. That's exactly what we'd expect. But let's just test this favorites  route down here because if we go items slash favorites, then we should see something different.  So let's just try that in there. And ah, so that hasn't quite worked. What we've done  is that is now said, oh, I'm expecting an ID which is any alphanumeric set of characters  and that's picked that one up in preference to our constant. But we can fix that really  easily because we're just matching the first one that we come to. And so this will now  put the constant node ahead in the list of edges. And if we go back and then try favorites  again, that's items. Now we get favorites. So we've basically produced an entire client-side  routing engine in a little bit over 70 lines of code which I think is pretty cool. It would  have been even cooler if I'd managed to get through the whole thing without making like  a tiny little syntax error. But again, I think that's pretty cool. So that was our routing  handler. We've a routing engine and all of our goals achieved. So let's say a little  bit technical but hopefully it made sense. And I'm doing pretty well on time. So just  before I wrap up, I'm going to show you, I basically put together a, so I kind of took  this on, these demos were what I could do in the time. And then I took this on and actually  built an entire to-do list application out of all of the bits and pieces that you've  just seen. So here you can see that we've got a list which is the target for our template.  We have a button that allows you to add a new one. Our list item in this case is much  more complicated. We've got like a little field set. We've told it it's hidden and we've  got the ability to edit and remove and all sorts of things. You see I'm brought in all  of the JavaScript and these are all kind of like, there's much more, yeah, a little bit  further along implementations. So here's our view model. We've got an ad click and you  can see that actually we have this in our item, we have a link. So we're actually using  routing as we click on each item in our to-do list. We actually use the routing to actually  navigate between them. We've got some routes to find down here and so if we reach the items  route then we're going to just collapse all the elements in the view model. And this is  our template, template and dot repeat. You can see we've got a whole bunch of stuff in  here. We've got like binding to a link, href, we've got binding to a show hide. And see  these are all things you could, you can just go on and on with this. You can think like,  what do I want to bind to now? You can just keep adding little bits inside the to and  the from and I've even got a to strike through here as you'll see. So let's just have a quick  look at how that works. Let's make this bigger. So here's our framework list to-do list. We  can add an item. If we check the box, we get the little strike through comes up and off.  You'll notice if we now click that we've now got slash items slash nought in the address  bar, we can change the name of it and you can be like do demo and you can add another  one. Now edit this one. We've got item slash one and you can say like, wow, wow, the audience  and then you know like, question mark, question mark, question mark. Can you tell what's coming?  See it. And for example, you can then just remove them and you know add another one and  tick them all off. So that's just- I just wanted to show you that quickly because that's  kind of the closest thing to a real world example that I've kind of got but it shows  you that that stuff actually you could build an application out of this stuff as long as  you know the happy path is there. So I'm just going to sum up as we're almost at the end  of the session. But I thought that was pretty simple. Maybe not so much the rooting part  but you know we've actually implemented three elements of single page applications like  I've done that in front of you today and admittedly I had a bit of practice but it's not rocket  science. It's actually quite easy to understand but there are a few problems. Now these implementations  have a lot of flaws. Security, none. Test coverage, zero. Performance, we didn't measure  it but presumably it's not great. And no error handling, nothing. So we have no quality  of life bits and pieces. Literally this only worked because we knew exactly what we were  doing and we were following the happy path all the way through. But the good thing was  that most of it as I mentioned before is ES 5.1 compatible so you could feasibly use  this as long as you don't have to support IE8 which incidentally you should not. The  main thing is that hopefully we learned a lot doing this. I know I did as I was preparing  all these demos. You know I hadn't anticipated when I started having a look at data binding  I never intended to look at that but actually I was like actually you can do some of this  stuff. You wouldn't be able to build a fully fledged implementation but you would eventually.  But you know everything is very simple. If you leave out all of the extra bits and pieces  like the DOM parsing and the automatic dependency management then you can clearly see how stuff  kind of hangs together and works. And it's really extensible. You can see how with the  to-do list all I did was added a few more twos and froms and then we kind of actually  ended up with something that really worked. But most of all it's not magic. You know frameworks  they may be complex they may contain a lot of code but you can look into them. You can  open up the code. You can read it and you can reason about what they do and gain a greater  understanding by doing so. And I think that's the key message I want to instill here is  that you know actually with the some of the stuff we implemented we actually avoided lots  of like nasty little problems with. We didn't do any of the complex stuff but we still achieved  our goals. But you can look into these things yourselves and you can understand what the  frameworks are actually doing and who knows. You may even be able to contribute back to  them if you can see an improvement. You probably shouldn't write your own framework but I encourage  everyone to contribute to an open source project if that kind of is something you're interested  in. So I have a few other libraries that are kind of slightly more mature. I didn't talk  about dependency injection but I have this thing called DIY. There's no docs for that  but it's kind of a fun approach in JavaScript. I'm not sure you should really use it but  it might be interesting to look at. I have a, if any of you are ASP.net developers I  have a graph based routing implementation for the server side as well which is called  superscribe and a JavaScript version of that as well. So if that interests you go and have  a play and let me know how you get on. Thank you for listening. I hope you've got something  out of this talk. Remember that the red and yellow buttons are broken today and thank you  very much for listening. This is the code on GitHub and I'm here with equal experts  so if you fancy a contract in London look them up. Thank you very much.  I'll be around at the whole conference so just come and find me.
Lifestyles_of_the_rich_and_frameworkless_0_1883.png Lifestyles_of_the_rich_and_frameworkless_1884_10763.png Lifestyles_of_the_rich_and_frameworkless_10764_13259.png Lifestyles_of_the_rich_and_frameworkless_13260_13307.png Lifestyles_of_the_rich_and_frameworkless_13308_16079.png Lifestyles_of_the_rich_and_frameworkless_16080_16127.png Lifestyles_of_the_rich_and_frameworkless_16128_16319.png Lifestyles_of_the_rich_and_frameworkless_16320_16415.png Lifestyles_of_the_rich_and_frameworkless_16416_16847.png Lifestyles_of_the_rich_and_frameworkless_16848_17195.png Lifestyles_of_the_rich_and_frameworkless_17196_25787.png Lifestyles_of_the_rich_and_frameworkless_25788_25907.png Lifestyles_of_the_rich_and_frameworkless_25908_26003.png Lifestyles_of_the_rich_and_frameworkless_26004_26303.png Lifestyles_of_the_rich_and_frameworkless_26304_26771.png Lifestyles_of_the_rich_and_frameworkless_26772_28463.png Lifestyles_of_the_rich_and_frameworkless_28464_28715.png Lifestyles_of_the_rich_and_frameworkless_28716_28967.png Lifestyles_of_the_rich_and_frameworkless_28968_29039.png Lifestyles_of_the_rich_and_frameworkless_29040_29087.png Lifestyles_of_the_rich_and_frameworkless_29088_29867.png Lifestyles_of_the_rich_and_frameworkless_29868_30635.png Lifestyles_of_the_rich_and_frameworkless_30636_30923.png Lifestyles_of_the_rich_and_frameworkless_30924_31403.png Lifestyles_of_the_rich_and_frameworkless_31404_31499.png Lifestyles_of_the_rich_and_frameworkless_31500_31739.png Lifestyles_of_the_rich_and_frameworkless_31740_31787.png Lifestyles_of_the_rich_and_frameworkless_31788_32123.png Lifestyles_of_the_rich_and_frameworkless_32124_32423.png Lifestyles_of_the_rich_and_frameworkless_32424_32483.png Lifestyles_of_the_rich_and_frameworkless_32484_34043.png Lifestyles_of_the_rich_and_frameworkless_34044_41303.png Lifestyles_of_the_rich_and_frameworkless_41304_42143.png Lifestyles_of_the_rich_and_frameworkless_42144_42191.png Lifestyles_of_the_rich_and_frameworkless_42192_42239.png Lifestyles_of_the_rich_and_frameworkless_42240_42335.png Lifestyles_of_the_rich_and_frameworkless_42336_42455.png Lifestyles_of_the_rich_and_frameworkless_42456_42539.png Lifestyles_of_the_rich_and_frameworkless_42540_42671.png Lifestyles_of_the_rich_and_frameworkless_42672_42827.png Lifestyles_of_the_rich_and_frameworkless_42828_43043.png Lifestyles_of_the_rich_and_frameworkless_43044_45335.png Lifestyles_of_the_rich_and_frameworkless_45336_45383.png Lifestyles_of_the_rich_and_frameworkless_45384_46067.png Lifestyles_of_the_rich_and_frameworkless_46068_46235.png Lifestyles_of_the_rich_and_frameworkless_46236_46295.png Lifestyles_of_the_rich_and_frameworkless_46296_48899.png Lifestyles_of_the_rich_and_frameworkless_48900_49031.png Lifestyles_of_the_rich_and_frameworkless_49032_49079.png Lifestyles_of_the_rich_and_frameworkless_49080_49127.png Lifestyles_of_the_rich_and_frameworkless_49128_49187.png Lifestyles_of_the_rich_and_frameworkless_49188_49643.png Lifestyles_of_the_rich_and_frameworkless_49644_50531.png Lifestyles_of_the_rich_and_frameworkless_50532_51047.png Lifestyles_of_the_rich_and_frameworkless_51048_57971.png Lifestyles_of_the_rich_and_frameworkless_57972_58103.png Lifestyles_of_the_rich_and_frameworkless_58104_58295.png Lifestyles_of_the_rich_and_frameworkless_58296_58595.png Lifestyles_of_the_rich_and_frameworkless_58596_58763.png Lifestyles_of_the_rich_and_frameworkless_58764_77603.png Lifestyles_of_the_rich_and_frameworkless_77604_78515.png Lifestyles_of_the_rich_and_frameworkless_78516_78779.png Lifestyles_of_the_rich_and_frameworkless_78780_78827.png Lifestyles_of_the_rich_and_frameworkless_78828_79235.png Lifestyles_of_the_rich_and_frameworkless_79236_79343.png Lifestyles_of_the_rich_and_frameworkless_79344_79415.png Lifestyles_of_the_rich_and_frameworkless_79416_79631.png Lifestyles_of_the_rich_and_frameworkless_79632_79691.png Lifestyles_of_the_rich_and_frameworkless_79692_79739.png Lifestyles_of_the_rich_and_frameworkless_79740_79823.png Lifestyles_of_the_rich_and_frameworkless_79824_79871.png Lifestyles_of_the_rich_and_frameworkless_79872_80003.png Lifestyles_of_the_rich_and_frameworkless_80004_80123.png Lifestyles_of_the_rich_and_frameworkless_80124_80579.png Lifestyles_of_the_rich_and_frameworkless_80580_80951.png Lifestyles_of_the_rich_and_frameworkless_80952_81335.png Lifestyles_of_the_rich_and_frameworkless_81336_81395.png Lifestyles_of_the_rich_and_frameworkless_81396_81611.png Lifestyles_of_the_rich_and_frameworkless_81612_82079.png Lifestyles_of_the_rich_and_frameworkless_82080_82379.png Lifestyles_of_the_rich_and_frameworkless_82380_82463.png Lifestyles_of_the_rich_and_frameworkless_82464_84767.png Lifestyles_of_the_rich_and_frameworkless_84768_85091.png Lifestyles_of_the_rich_and_frameworkless_85092_85211.png Lifestyles_of_the_rich_and_frameworkless_85212_85415.png Lifestyles_of_the_rich_and_frameworkless_85416_85583.png Lifestyles_of_the_rich_and_frameworkless_85584_85715.png Lifestyles_of_the_rich_and_frameworkless_85716_85859.png Lifestyles_of_the_rich_and_frameworkless_85860_85931.png Lifestyles_of_the_rich_and_frameworkless_85932_86027.png Lifestyles_of_the_rich_and_frameworkless_86028_86459.png Lifestyles_of_the_rich_and_frameworkless_86460_91007.png Lifestyles_of_the_rich_and_frameworkless_91008_91595.png Lifestyles_of_the_rich_and_frameworkless_91596_91923.png