 I don't know if you see those shoes are amazing great. I'm Mark Wunch. I'm from Gilt. My Twitter is at Mark Wunch so send me a toot. Geologic time scale. So the geologic time scale is this system of measurement that relates strict tritigraphy which is like the study of rock layers to time. Yeah disclaimer I am not a geologist. I am not an earth scientist of any kind. I've learned everything about this particular subject on Wikipedia so I'm now somewhat of an expert. This is a metaphor that I'll be using and that metaphor will be stretched to its limits. But like anybody who writes JavaScript professionally I am not without a lot of hubris so let's be careful. I really love this concept of deep time. So the earth is over four and a half billion years old. That expanse of time is so impressive and impossible to comprehend and modern web development is about what ten years old maybe. But we suffer I think as an industry of real short-sightedness and so this is the second backbone conference and I'm very excited to be here and honored to be here but really we're just discussing this really small sliver of technology just like this one tiny layer and in the tiny moment in time and at this conference you're going to hear a lot about implementations and you've heard a lot about certain processes and patterns to follow and you'll hear more about that tomorrow. But what I would like to do now is invite us all to take a big step back and take a really top down view of web technologies and what what brought us to this place today. I work at Guilt. Guilt if you don't know is an e-commerce company. We sell shoes and stuff. We do flash sales. So what that means starting at noon Eastern time usually we sell a limited amount of inventory for luxury goods fashion at a steep discount for us a small period of time and I'm going to use Guilt as a case study because I work there but in my time there we've also tried a lot of different approaches to building web applications. So we have our website which is you know I guess a traditional e-commerce experience or a traditional e-commerce technology stack. We have some experiments this is Guilt live which is live.guilt.com which uses real-time web sockets to update what people are buying so you can see what people are buying right at that minute right at that second I should say and finally our mobile web application which is like a single-page app and all of these use backbones and backbone that singular in various capacities. So Guilt is at scale and what you would say is at organizational scale so there's about 60 engineers contributing to this experience and what I hope to answer today is what influenced us at Guilt to turn to specific technologies one of them being back home. So today I'm going to talk about stratigraphy so studying the layers of the Guilt tech stack. I'm going to talk about this technology it's called asynchronous JavaScript and XML maybe you guys have heard of that one. So we're going to talk about that in the context of a particularly tough problem which is the problem of pagination. I'm going to talk about robots and code that we write for robots. I'm going to talk about templates and how we use templates to keep the balance between robots and humans in check. I'll discuss a very serious and important architecture very serious business called models views and whatever and finally I'll close by attempting to predict the future as I said before hubris. Stratigraphy so I'm going to start by talking about the strata of our web application and in a business like Guilt these layers of technology form sort of one on top of the other and by examining a cross-section of that system we can infer a lot about the past several years of modern web development. What's interesting about stratigraphy is that it's bounded by a set of laws or principles so the first one is the principle of superposition and this one it is simple what's at the bottom is older than the things that are at the top pretty simple and you can see what's at the bottom of your web application you just do a git log reverse and in this case it actually doesn't help very much import from subversion so so I guess this is like pre Cambrian era or something this is in 2008 but I guess that's old enough to call legacy now the principle of original horizontality this states that layers will tend to deposit horizontally so guilt like many businesses started as a Ruby on Rails application yeah and with Rails back then you got this thing called prototype I want to take some time to give lots of respect to prototype.js yeah in many ways so ahead of its time and it's so impressive and it doesn't get the love and it doesn't do you get the love it deserved back then because like most people jQuery was becoming preferable and so we went through this painful process and I don't know how many of you went through this process of replacing prototype with jQuery it was painful and what we've created here is what they call in geology and unconformity so the layers are no longer continuous which brings us to the principle of lateral continuity the technology layers continue to build up and we continue to modify and chip away at certain areas and update others and you get to something like that so this was our system about two two and a half years ago and you can see that things are no longer deposited horizontally so the principle of lateral continuity states that at some point these layers were continuous but something happened some technical erosion so the deposit of this technical sediment continues until we reach where we are today and you can see there's backbone in there and I don't know there's some coffee scripts in there sure I don't know what MPM is doing there but okay and if you cut the top layer you're standing on the top soil it looks like a modern web stack but as you observe cross sections from different angles you see a peak at something older more hidden something that's been buried so in order to get a truly comprehensive understanding of the full front-end guilt technology stack this is just the front-end by the way you need to hold all of this in your head and that's daunting so you might call this technical debt that's a nice term for it but part of scaling a business at a technical organization is confronting the legacy of these layers hidden beneath the surface so I want you to keep this layer cake in mind as I continue and as we talk about scope and applications growing often what we mean is we're adding layers to the system and sometimes we induce technical erosion so think about maintainability keyword maintainability now here's a good question why do we need all of these technologies why why didn't one work for us what is so hard about the web that we introduce layer after layer of technology and complexity it's Ajax the Ajax is the fundamental piece of the modern web experience where would we be without asynchronous communication between the client and the server probably not here at this conference but for something that's so core and so basic we really only recently begin to grasp the best way to do Ajax communication I think that Ajax helps a lot to do with the strata we saw earlier and each one of those technology layers has an opinion about how to manage this client-server communication so I made a point earlier to draw your attention to the original usage of the term Ajax there used to be that you used Ajax to do these naive remote procedure calls with XML anybody remember those days show of hands yeah it wasn't great but it worked your HTTP calls that look and still look kind of like this so get and we have a URL called add to cart get add to cart this is not idempotent this is not restful it's not ideal but it works and worked does anybody remember RJS yeah this is kind of crazy so you make an Ajax request and you get back a dynamically generated JavaScript snippet and you still see this a bunch if it's not RJS it's not great but it worked here's something you still see from time to time and we still see it get all of these examples are not like we think of these things as a ancient history but the recent so the server tells you this was successful but the content of the response tells you it wasn't it's not ideal but it works and so all of this comes back to maintainability and I'm going to touch on this point a few more times all of these Ajax approaches though maybe on appealing are still Ajax what makes us uneasy about those approaches is that we say they are unmaintainable we question their maintainability and dealing with a large system means that you come across previous approaches we're maintaining it feels like a burden and that's why you keep adding new layers so let's continue so we did it we're successful we got a restful API that brings back a JSON response and now what do we do with that so it used to be you know when it was Ajax with an X with XML you would you would just take that markup and dependent to the DOM and worked okay now we have these client-side templating languages so when we're using JSON you could either concatenate a bunch of strings together or you apply that JSON object to a template and I just want to point out which is more complex so on one hand you take a bunch of DOM markup you get from the server and do inner HTML or something like that on the other you do some non-trivial parsing of a templating file and a templating language and then apply a JSON document to that and then apply that to the DOM and I like client-side templating I think it's awesome right there's no no argument there but it's just we've introduced complexity and if we want to pick a templating language that's a new layer we have to think about so I just want to pose that question rhetorically is that a win and every piece of technology results in some kind of trade-off one last bit of technology I want to address in the world of Ajax is this little JavaScript call right here which is awesome but it's one more layer of complexity and the important thing that I want to point out here is the word state as in the kind of mutable state you must maintain and if each one of these pieces in our strata have different opinions about Ajax there's something else to have an opinion on and history the history API brings so many improvements to the Ajax user experience it's unquestionable but I think it's a good transition to what I think is probably the most challenging user experience puzzle front-end engineers have to work out I think there is nothing more difficult than implementing your own infinite scrolling pagination mechanism there are so many trade-offs to consider there is no one-size-fits-all solution and just about every implementation the night I think you know just think about this for a second every implementation has just one kind of bug or one kind of user experience quirk that makes it awful right like it once you experience that bug you're like this is terrible flip table so so let's talk about this problem a little bit more in-depth so you start with pagination this works pretty well right but there's too many pages and I said there's too many pages like imagine like an infomercial there's too many pages so and your user analytics shows that nobody is going past page two or three so you decide okay well we need to try infinite scrolling and we've done this at guilt we made that same decision and you end up with this huge queue of trade-offs and choices how to load the pages in a memory efficient way how to manage the page states so everything works how to get the content from the server do you even attempt a custom solution or do you go with what Paul Irish did for you it's a total mess it's analysis paralysis so read this blog post the hope everyone's read it it's really good at explaining the complexities of good infinite scrolling but it requires this architectural consensus and remember we have layers that are really old it's not always possible to get that kind of consensus and even after you implemented infinite scrolling it might not be the best thing for your users at guilt we've tried several different implementations of this pattern with the products so I'm going to show you what the most recent one look like look like this we're back to where we started yeah we found that a better experience is to try to get the user to see less of the thing we paginated through so you use tools like filtering use tools like search that's a better user experience and I'm going to come back to this but it's important to understand how the choices in UX and user experience affect the technology stack so how do those choices affect maintainability another thing that we have to factor into our technical decisions at guilt is we have to think about robots robots that spider the site so guilt gets a not insignificant portion of its revenue thanks to search engine optimization so Google Facebook we have to make sure that our data is available to them a colleague suggested that what we ought to do is build one version of the website for robots and another version for humans which isn't a bad idea but it goes back to that question of maintainability so this is what it looks like when I browse guilt comm in links if you know what it's like to be if you want to know what it's like to be a robot try using links so you can get insight into your help how your pages work making our site work for robots is a requirement for our business therefore serving HTML for from the server is a requirement but what about single-page app experiences users love this stuff if SEO is a priority can we do this without sacrificing too much maintainability I recognize that this is a client-side application conference and it seems strange to talk at length about server-side rendering but enabling SEO and web spiders is something that the web is really good at and it'd be a shame to lose out on that and I think we can strike a balance between the robots and the humans but it takes technology applied at the right level so I'm going to talk about templates now I think there's a lot that can be done in the templating layer of an application stack that allows us to get the benefits of a rich client-driven application without hamstringing the server-side so there was this thought when node.js came to prominence that if you write a server in the same programming language as the client you get this sort of boost in efficiency and maintainability I think the dust is settled and I don't think that's correct so I disagree with that but if you think about a web app framework either client or server-side so much logic gets buried in the templating language so here's an example this is JSP nobody likes JSP nobody it's nearly impossible to reason about what's happening in the server-side of a traditional web framework without diving into the templating layer and when it's JSP you want to avoid that as much as possible so this is Hilt JSP I don't even want to begin it's like quicksand and then on the client side we have something different and at guilt we use handlebars.js and handlebars is awesome right but as long as we have this mismatch between our client-side templating layer and our server-side templating layer which is an unconformity there's very little sharing we can do between those two layers so at guilt our preferred web stack is Scala and the play framework which we're big fans of so I wrote a handlebars implementation in Scala we call it Scandalbars internally it's open source and we use it in production for more and more things our navigation is rendered with Scandalbars more and more of our products are rendered with Scandalbars and the reason I chose to do this is so that we can decide we can make a decision when appropriate whether or not to render something on the server side or the client side so we can use one template to render on the server side for robots or for users who hit a URL for the first time or we can serialize those same Scala models into JSON and send them down into the client where the same template renders them client-side so we can leverage the same templates everywhere and choose to make rich single-page user experiences where appropriate our templating layer now acts as one continuous uniform layer instead of being broken up into different stratum so it's not foolproof it's a Scala implementation of a JavaScript code base but it works pretty good let's talk about backbone backbone is great because as we've heard it helps you reason about the concerns of your application this is a tweet I wrote quite proud of this tweet if you can't read it MVC stands for model view computers so the truth is it doesn't matter what the letters mean or anything like that arguing about the M's and the V's in your architecture doesn't really do anything of value who cares so at its worst backbone provides too little opinions about how your code should be structured but at its best it can act as this tunnel it connects these packed layers of technology and backbone provides us a mechanism to mine our legacy technology stack because it's not so opinionated as to require a tectonic shift in our architecture on the server side so let's go back to this pagination example so we'll now use scandal bars and backbone when the user hovers over the next action we make an Ajax request back to the server to get the next page we expect Jason back from the server we have the same templates on the client side as we do on the server side so those templates come are rendered based on this Jason and they're stored in memory as a backbone view in this case and then when the user does click when the mouse down action occurs the newly rendered page is already in memory you know from the whatever many milliseconds of hover state and then we just replace the dump and in this way our application can either render server side or client side so if you're rendering on the server side and you have a bookmark to page to you'll get page to really fast because it's rendered from the server if you click the next page you're going to get that rich fast single page like experience that's how we use those two things together so what we ask of backbone is this this is what we expect from any JavaScript application framework I think can it give structure to web apps and that's the point it gives you a backbone to work with can it bring some sanity to the complex client server calls can it effectively manage page state by page state I mean URLs can map URLs to state can it provide rich experiences without sacrificing search engine optimization doesn't have a footprint that's small enough for mobile I didn't talk a lot about mobile but it's important and doesn't make my life easier arguably the most important thing and I think the answer is yes but it takes work it takes effort unlike some more opinionated solutions like maybe angular or ember backbone is viscous it's like lava it conforms to the shape of its surroundings so you can get all of these things but it might take more effort so remember how I keep harping about maintainability yeah I've talked a lot about maintainability and how layers of technology are added to ease maintainability but maintainability offers no intrinsic value to users or to your business the relative maintainability of the code is of no interest to them maintainability can only provide velocity which allows you the programmer to deliver value at a greater rate flexibility on the code of the up on the code on the other hand is related directly to the programmers ability to provide value ad hoc as needed I think backbone might sacrifice relative maintainability for flexibility I like that trade-off so those things designed for maintainability large frameworks often end up buried under those things that prove flexibility so if you think about the civilization civilizations of code that guilt has buried you have rails you have prototype you have Java flexibility wins so given a constellation of technical choices backbone was the best choice given at that precise moment in time but the right path is not always clear or easy and sometimes you have to go through hell to find it so a guilt some colleagues of mine have created their own JavaScript and VC framework it's a contentious decision and we're watching that play out technical erosion will take its course there's also a big push to use angular or ember or something more rich we have to battle to prove that flexibility wins and hopefully I've done that I'm not informed enough about angular to really weigh in but I hope that we continue to choose the path of flexibility in our front-end technology all right it's kind of dark last couple things let's talk about the future so having observed the strata of guilt front-end stack I'm going to try to predict where I think we will see more movement more shifts in our geological foundation a reminder that modernity what you're standing on now is the top layer and there's layers beneath you so where will we be I think more tools like marionette or chaplain will become more prominent and we'll see more like them the back plugs that was new to me really impressive so backbone is so lightweight it's a kernel it's a kernel for modern web development and because of that I actually think we'll see more robust frameworks written on top of it I think Brian talked a little bit about this dependency management and build tools will become a standard tool in everybody's library I think Sam alluded to this modules and components are the future so at guilt we built this build system for front-end packages before bower emerged and bower is really appealing there's this thing called web jars that are emerging out of the JVM that look really interesting as well there's so much more room here to grow and as applications increase in scope we'll have to figure out how to isolate front-end dependency graphs it's a very hard problem is the Dom good enough so I was talking about this with you guys earlier it's Tom de la Huiz so there's this idea that there's this cohort of JavaScript developers who know nothing beyond jQuery and I think jQuery is waning in its relevancy I think the Dom has improved as browsers get more modern and influence the standardization process more and I think the Dom can be really powerful mobile but I think we're going to have to face some uncomfortable truths regarding mobile performance I don't know if you've read this blog post why mobile web apps are slow it's it's really good everybody ought to read it mobile and desktop web will converge and we're seeing that already a guilt I'm on the mobile team a guilt pretty recently so one last prognostication someone controversial there's a reasoned argument to be made that static typing works better in larger organizations so with a dynamically typed or gonna type dynamically type language you have to depend on test coverage to make sure your app works test coverage is so important because it enables continuous integration which enables continuous delivery which means you can press a button your application is on the internet distributed to millions of people but tests can fail tests require in order to get to that level the continuous delivery level you have to have a really good testing infrastructure and that means people have to write tests which means you have to enforce really good test writing practices and even then they can fail a statically typed language enforces API contracts like free tests so type script is a language coming out of Microsoft that's a typed super set of JavaScript it looks really interesting and at guilt we're keeping a close eye on it I should mention I sell some t-shirts there's a backbone and angular and Embers shirt gang of four t-shirt these shirts are great for summer wear transition well into the fall season once again my name is Mark lunch thank you so much so I ended early but I plenty of time for questions hi have you solved the problem of duplication of URLs with the backbone router and then URLs are your forcing out on your server side to share my guys also have you did you guys evaluate mustache as a templating language before you chose to go with handlebars sure I'll answer the second question first which is did we evaluate mustache before choosing handlebars and the answer is yes mustache is arguably more language agnostic and that's because it's stricter it's it's a very strict logicless language and the downside to mustache for many engineers is that it's so strict it is logicless so it's like a double-edged sword and there was just we couldn't keep people from using handlebars on the client side there are scholar implementations of mustache but the handlebar handlebars can provide that that the sort of logic you need without being a burden but there are parts of handlebars that are like a true foot can so yes we did the other question was related to sort of the complexity of duplication of routes between the backbone router and a server side router so we have solved that because we do not use backbone router so one of the things that play provides is a Java play framework which is the framework we prefer provides sort of a JavaScript API to get information about routes so we just use that API and that tells us how to get in practice it's it's not so hard we we don't do we don't do enough complex state interactions that require a new URL state of a new URL basically means that state has changed and we don't do enough of those state transitions to really warrant something like backbone router yeah over how long did it take um guilt's tech stack to evolve from the beginning as you said to now and were there any major you know forks in the road that you might have done differently amazing question so the answer is is guilt was founded in 2007 so that's what six years it's nothing it's like a blink in the eye in that time we've changed our primary programming language three times so is there something we would have done differently yeah maybe maybe we would have started with the JVM earlier there was a really contentious decision so just before you I've been a guilt for three years there was a contentious decision when we moved from Ruby to to JRuby and then to Java we moved to you know just hopefully Java without all the crap but it's hard to get that was very contentious moving from that point I think that's the biggest shift but yeah guilt has like has like has is like a microcosm of like a 20 year technology company like but it's been I think a good thing because we've been able to move quickly and yeah we have these layers which you know are technical debt but there's something I think we're getting rid of a lot of that debt and there's some things that are okay to just be maintained it doesn't hurt anybody then answer your question hi do you use handlebar helpers and if so how do you manage the logic on that server side and on the client side okay great question handlebar helpers an effective foot cannon for handlebars so what's what's what's what will make you just blow your foot off with handlebars helpers is that there they can sort of act when they're tied to a global scope they're bound to the handlebars object in JavaScript which is it's less than ideal and they can manipulate all kinds of things so I I try to stress to avoid them and only use them when absolutely needed and there are cases when they are needed and in that case yeah Scandal bars does support helpers obviously you you do not it's not the same language you have to implement them in two different things and Scandal bars because it's a different programming language in a different environment has constraints on what a helper can or can't do but a good helper should fit into those constraints I'm working on a sort of rewrite to the parser and to some of those parts to make it a little bit more palatable because the transition from JavaScript to Scala is not the easiest one to make and I'd like to make that a little bit easier but Scala is a functional language and so can can have helpers so yeah we write helpers for both the client side and server side anybody else so you were saying that Ted script is kind of a stand-in for testing somewhat does that mean is there a place you're using as a replacement for testing no no so the type script is a statically type language uses a compiler and that compiler checks types so you have to declare this is this returns a string and the compiler was say you tried to do something where that wasn't the case you're wrong but it's but as any statically type language via type script or Java or Scala is not the compiler is not sufficient alone to replace tests the compiler just writes tests that you don't think about and enforces API's so rather than making something that might not be test writing code that might not be tested the compiler will say by the way you violated this contract that this API was saying so that's all of this I think that's just the benefit of static typing in general not really to be honest I have it's not something I've really dug in deep about is there anything is something specific that you found in yeah I don't have anything person like per se I don't know the memory footprint or the CPU like effect that handlebars has never really profiled handlebars but in general yeah I I'm with Nicholas Zakas like I think I don't know if I pronounce his name right but I think less JavaScript it can be better and the templating layer is probably a really good layer to push a lot of this complexity yeah I can answer your question unfortunately but now you've got me very curious the question was how do you evaluate how much logic to put into handlebars and when is when is too much too much so the answer is I try to constrain it so that I put as little logic into handlebars as possible and the way we try to do this is in the Scala in the server side we have these view models basically what what do we need to render a template what what do we need just to render that template and hopefully the view model encapsulates most of the logic and then that we have sort of another API in backbone in a backbone view that sort of replicates the methods but can be basically hydrated from a serialized view model from the server so the answer is we try to limit the amount of logic as much as possible now that's not always easy because people just want to take whatever objects they have and put them put them where they need to go and in that case they'll hit the pain or anybody like you you know when it's painful because all of a sudden you're calling all of these weird methods on an object and you're violating I believe the law of Demeter Demeter the one that says don't don't talk to your friends but you can talk to your that one you're violating that yeah you can't talk to your friends friends social contract but you know it like because it begins to get painful and any refactoring of that model breaks okay thanks everyone