 Thank you So this is an intentionally provocative title because I found that I have more fun and talks if they're At least half discussion rather than talk. So here's the plan You know, I'm gonna start out by making a statement. I'm gonna follow that up with a question and then You know complete it with an entirely incomplete answer Followed by heckling and and what I'm hoping is that I can get through those first three things in about 15 minutes Leaving a full 15 minutes of heckling Or if you guys do your jobs correctly There will be just a constant stream of heckling and that will be much more fun. Yeah, I was looking at you Dr. Nick to I'm you know So here's the statement is that web apps do not work the same way they did in 2004 Yes You know and So if I you know still today if I were trying to describe sort of how a web app works I probably would say something like well, you know You make a request to the you know when you log in you make a request your browser makes requests for the server And it returns a response with a bunch of HTML and then the browser Renders that HTML and probably embedded in that HTML or a bunch of anchor tags that become links and have URLs Associated with them and when views are clicks on one of those your links then it makes another request for that URL and The browser gets a whole bunch more HTML and it renders and we've got a new page Right is that approximately how you know you guys would describe how a web app works? I mean there's forums and stuff too, right? That's the you know So so me too, but it's lies at least for for the web apps that I build now It's lies and increasingly for the web apps that people are building. It's lies That's how it worked in 2004. That's not how it works in 2010. So a lot of web apps now You know You make a request to the server you get back a huge wad of JavaScript and maybe a little bit of HTML And then that's it that sits there in the browser for the entire session, right? You don't click on a link and go to a different URL and get back a bunch more you HTML you click on a link and that has some JavaScript handler that maybe fires off a background request that gets back a bunch of Jason right and You don't have this kind of big URL structure of your app at least not in any form that the server sees You might change the URL and the location bar, but actually it's all done through location hashes, right? It's after the the hash in the URL. It's not something that ever goes into the request So examples of apps that work this way new Twitter Which just came out like yesterday or whatever? Google instance search Which is you know also quite recent? Tremly which I just have up there because it's an app that I built last year etherpad Which is awesome Gmail is kind of the canonical example of an app that works this way And for a lot of these it's not just that they're more responsive When when they're they work this way or that you know, it was a little easier to build or whatever When they work this way, it's that they truly couldn't have been built in the other way Right Google instance search wouldn't make sense as a kind of traditional multi-page web app Right, I mean you can kind of think of the original Google search There's a multi-page web app because each time you hit search or page through the results You were actually taken to a new URL and you know It is a newer request in the browser fully re-random page, right? Etherpad, you know, I don't know how many of you guys use etherpad It's sort of disappeared when it got acquired by Google, but but it still exists. It's open source and it's up there It's an awesome app. It's like some need to edit on the web You could not do this without having a huge amount of client-side JavaScript, right? And Gmail you probably could build, you know another way, but it does feel much better and more responsive having built that way Let's take new Twitter as an example when and and I should add as a disclaimer Although I do know work at Twitter. I had absolutely nothing to do with new Twitter But I think it's totally awesome and was built the way that web app should be built Also a disclaimer nothing I say is necessarily the opinions of my lawyer blah blah blah Even though I'm gonna use them as an example, so let's actually look at what happens with new Twitter So here's a search on new Twitter for go-go root co And there we go rotten fruit basket at my feet and if I click this What's gonna happen is we're gonna get a request that returns a bunch of JSON, right? And everything I do here, you know, I click here I'm gonna get another request with a bunch of JSON, right? And that's all that's going on This is a big JavaScript app that every single click that you do the entire time You're using new Twitter is just making another request for another JSON file that it's then gonna use to you know Add stuff to its UI, right and you can see the URL here. This is the URL, right Twitter calm period is the URL There are no other URLs in this app I mean there are background ones, but not once the user sees or cares about right everything else is just after the hash So no matter what I do here, that's gonna be true, right? So that's a fundamentally different way of building web apps then the way that we are all probably used to building web apps and Let's get that keynote here So why did I mention 2004 2004 is when base camp and rails came out, right? 2004 is the world for which Rails was designed and when the fundamental design decisions that went into rails were made and those fundamental design decisions I would say, you know have continued to this day, right? You can't change the fundamental design decisions necessarily without rethinking from the ground up when those design decisions were made This was the world that we build web apps in and that is not the world that we are in now And certainly not the world that we're gonna be moving into 2004 is also interesting because Actually someone was doing web apps that way back then And that's Google because Gmail came out in 2004 and Gmail blew me away and probably blew a lot of other people away, too But the reason that no one else did it back then is that it was really really hard to do and Google had the resources and the guts to do it But very few other people did and that's changed and it's changed for a few reasons a couple of things that I think have been especially essential one is jQuery or You know other JavaScript frameworks like jQuery, but I think jQuery deserves kind of a special call-out jQuery removes a huge amount of the pain of doing cross browser JavaScript development or in a huge amount of pain of working with the Dom and so on which doesn't have very good APS to begin with The other thing I think that deserves a special call out is Chrome Not to say that everyone necessarily uses Chrome because the market share is still relatively small But Chrome acts as a huge force pushing the rest of the industry to catch up and with their JavaScript implementations It's important to remember the JavaScript in 2004 was a really slow language, right? All the implementations of JavaScript were quite slow probably slower for example, even than MRI is At running dynamic languages these days. This is just a chart I pulled from the language shootout, you know V8 the JavaScript implementation in Chrome runs up to a hundred times faster on some goofy benchmarks than MRI does Right, but in all of them it's a lot faster, right? so You know you can you can think about the amount of data that you're transferring Between your your web app and the browser and it may actually be faster Rather than doing a bunch of computation on the server to send it down to the browser where they have a fast execution engine They can do a bunch of computation for you rather than your slow pokey execution engine that you have on the server side, right? I'm serious if you're doing like a bunch of statistical analysis on the data or something You may actually be better to do that in JavaScript on the client than you are to do it in Ruby on the server Which is goofy, but it's interesting And just this is I love the URL of the site. This is are we fast yet comm? This is Mozilla's page where they track their JavaScript implementation, but it's just up There's an example of how sort of Chrome has pushed the rest of the industry to make their JavaScript engines faster and faster And I use doing the same thing and I unite to try to catch up with the awesome small-talk engineers that built the a So here's the question The question is how should we change the 2004 design that is to say rails and rails like frameworks to work for 2010 web apps and You know as I promised I do not have an answer for this, right? I have one tiny partial incomplete tiny piece of an answer to this that you know just so that I'd say something interesting But mostly this is just a question and if we think about sort of model view controller, you know model It's interesting to talk about the no sequel stuff because I think the way people think about models is changing But that's totally out of scope of this talk, so I'm just gonna ignore it View you know you can think about no HTML, right? These apps are no HTML apps in the sense not obviously that there isn't HTML involved in some part of the process But in the sense that the server side the web framework sitting on the server is not generating HTML It's generating JSON most likely as what it you know serves to the browser, right? And so what's the view doing right? There isn't really a view You know ERB templates or whatever template system you use It just doesn't make sense in this context of what you're serving is basically a data structure rather than a view So so sort of the notion of view has to go out the window and controller What I lost my controller slide fun Well, anyway, there's supposed to be a slide in there that says controller and no URL Right because if you have for example with new Twitter where the only URL in the system We're the only user visible URL in the system is Twitter comm slash then you know where your roots, right? Where are all your controller actions? I mean, maybe you have some eight some for an API somewhere But the idea of clean URLs is irrelevant, right? Because there is exactly one URL and that's slash So so the whole you know kind of structure that that the framework builds up around controllers Doesn't necessarily make any sense anymore. So, you know, we have to reconsider model We've thrown away a view and we maybe need to throw away controller Maybe it's time to rethink the framework and that's kind of the question that I'm putting is you know What what can we do? To to build something that that recognizes sort of these realities of how we do web apps now For the incomplete answer, I just want to talk about basically one trick And and it's a useful trick, but it's just one trick And I'm going to switch to a text editor to talk about it so People who've seen me talk before may know that I hate templates But you know you can imagine Let's say, okay, you know, I have this bottle and getting a bunch of Jason from the server And then I'm gonna you know build a UI on the client while I'm used to doing that with templates So I might do that with templates on the client side. So let's say I'm just trying to render a list of items and For each of them gonna have a link and when you click on that link something happens with the item It doesn't really matter right so with a template you probably have something like this And this is kind of a vaguely mustache like theoretical template, right? and And the thing that I hate about this among other things is that we're still dealing with Marshalling things to text and back right and this is one thing that that I always sort of went on about when I was talking About seaside is that you shouldn't have to constantly be worrying about okay? I have this object and basically I want to deal with an object and now I have to find some way to Represent it as you know an idea or something and then a second later, you know I'm gonna have to do another manual look up from that idea back to the object Right, but that's what's going on here if you have a template You've got to boil it down to text and so I've got to say okay You know what's this items ID and then when that handler actually gets triggered? I have the idea now I have to somehow find a way to pull back the idea, right? If we're all in JavaScript, you know, it should be obvious that we really don't have to do this and And we could for example build this just in jQuery, which is this top thing Just build the DOM elements directly right rather than having a template and the nice thing about that is I can be in this for each Loop with the item and I can attach the handler and I have a closure right where I can see the item And so my handler can just directly refer to the item You know the particular item in the loop and I don't have to worry it doesn't even have to have an idea I don't have to worry about how I map this to some ID or some kind of textual application and back I just use the object and my handler is going to get the object directly and that's great And that's really nice to write that way and it's actually one of the major benefits of doing this job is good stuff now I would clean up the you know building API here and have something maybe a little nicer this down below is sort of Something that I'm hacking on it's totally incomplete But a possible API for doing this kind of thing and the details don't really matter But it's just to show that you don't have to use the kind of somewhat verbose jQuery stuff directly Okay, this is nice. There is a huge problem with this So it turns out Every other browser can do this really really quickly right creating DOM elements is totally fast and fine You can like have a huge page and you build it up done element by done element. There's not a problem You can't do this or rather if you try to do this and I eat it is going to be slow and so Unfortunately unless you can just say, you know, none of my users are going to use IE this doesn't work Or if you can say my pages are going to be small and not have very many elements But that's not you know necessarily, you know, if you have one big canvas or VML or whatever the IE equivalent Yeah, VML Element and you know, maybe it'll work, but if you've got a fairly complex actual HTML page IE 9 at least a belated beta that I've tried. This is still a problem Right, they just for whatever reason they cannot make inserting DOM elements into the page fast and it's like it's not like a little slower It's like a hundred times slower than the rest of the browser's right and so the one little trick that I wanted to share with you guys is How you get around this and for IE and all other browsers inner HTML is still fast, right? So you can build up text And and add that to the current DOM quickly But now we're back to text and templates and now all that ugly stuff, right? And so the trick is that you still have a builder API just like this one. I was just showing you, right? And and as you are building up your DOM, you're not actually creating DOM elements You're just creating little snippets of text But every time you have a handler that you need to like associate a closure with something You don't actually put that into the text instead. What you do is you? Auto-generate an ID and you assign that to the element, right? So, you know this list item doesn't need an ID, but I'll just give it an ID a numeric ID and As you're doing this you build up an object that says okay. This ID has these handlers, right? And then at the end Once you've got this snippet and you've used inner HTML to install it into the DOM Then you just go back and you fix everything up Right, so you iterate through your map of sort of deferred handlers and you get the elements by ID And then you stuff the handlers into them, right? And that, i.e. and all the other browsers can do quickly And so, you know, it turns out that you can sort of have the best about both worlds in that you can use the speed of Sort of concatenating together a bunch of snippets of text and HTML using inner HTML While still letting you build your handlers that have all of the references to local scope And have this kind of much nicer programming model So I think that that's my 15 minutes of talking time and now I have my 15 minutes of heckling time I may have, you know, might be 2010, but but anyway Please I'd like to open the floor to questions or you know rotten eggs Yes It's not a full answer, but what do you think of frameworks like Sammy to try to organize the You know anchors on the JavaScript side more into URLs Sammy. Did you say Sammy s a mmy? Oh pretty much Sinatra in JavaScript, right? so Yeah, I don't know And and I will have to look at it more because I'm not familiar with it or not But so Sammy is not to run JavaScript in the sense that it's trying to do the same kind of URL routing stuff But yeah, the local has changed. Yeah, so that's something that definitely needs an answer and that might well be a good one You know, I should say that what I'm doing for now is I have rails on the back end, right? So I'm still using kind of controller stuff that I think is not necessary I'm not using active record because that's not you know The models I have don't map to that So, you know, I'm I'm slowly building up incomplete answers to this and that's one that I'll definitely look at Yeah, hey, so I don't know if you saw this but in my blog post where I announced that I'm moving to sprout core I actually cited this talk. Yes, you cited the version of this talk at Django con when I had even fewer answers So I actually agree with the core. I'm gonna happen if that's okay. Yes, please So I agree with the core of this argument that we need better answers on the client side I don't agree with two things about the rail stuff. Well, three one, I guess maybe Django people aren't thinking about this, but we really are And two, I don't agree that the design principles are fatal I think I've said this to you before but the reason for that is that a lot of once you it's true A lot of stuff has to be on the client. That is the next thing, right? But there's things that still have to be on the server like authentication Payments thinking yes, and these things are good to have a framework and they also interact with HDP, right? So yeah That that the thing that we actually spent all the time since rails 1.1 on has been improving HDP support And that's also what we're spending time in rails 3.1 on so even if you don't use the view layer at all Which I am going to find myself doing less and less having essentially a rack plus plus But way better than rack plus plus right like actually something that is really that has a really awesome HDP API is really valuable So I agree and I would be perfectly willing to believe that everything that's been done since rails 1.1 is still useful but what I would like to see is actually throwing out the rails 1.1 derived stuff and You know, I mean the the the basic underlying stuff of using controllers Right if you can imagine a rails that threw out view and controllers and still had, you know All of the other support stuff that you're talking about that's great But then what you need to do also is you need to you know Try to build something that gives you the same level of support for this model of web applications that rails did for the 2004 model of web applications, right? And that's the that's the real pull, right? It's not so much that you know half of rails is now useless, which I would say is true But is less interesting. It's that we need to replace that with something else, right? Yes And that hasn't yet been done, right? And so that's when I say it's obsolete It's not so much that you know We need to throw it away is that we need to build something new and you know It's really easy for me to stand up here and say that right but hopefully I'll do some work on actually doing that Now that I'm actually working in Ruby again, which hasn't been true for about 10 years The third thing is the request response cycle is not obsolete, right? If you have HTTP you still have request response, so I don't think controllers are obsolete I think active record it could be obsolete in a lot of cases, especially with a lot of web services And I think the view layer is obviously obsolete But having a thing that takes a request and returns JSON is is the rails controller model So I think that seems okay. Yes, although it's assuming you know one of the fundamental design decisions around rails I think I would say is Sort of the URL routing model, right and that I think is no longer necessary Interesting right clean URLs who cares what I would say is the same thing I said last time which is sure, but it I don't see any win in Actively making that ugly right so rails is a bunch of work to do that. It doesn't really matter Maybe yeah, but so this this partly just comes down to I mean again We've had this discussion before but it's much more fun to have it in public you know It comes down to whether you care that there's a bunch of stuff in your framework that is no longer useful and Whether you believe that that actively gets in the way And I believe that it's important to strip things down to the core of what you're actually using Rather than to have stuff and I think that that probably leads to more interesting developments Right if you take the step of throwing away of using controllers Then there's sort of a vacuum there that you're going to be actively working to fill and if you just say well Okay, I just won't use that part of the framework then You know the potentials for surprising elegance probably are less we should probably let someone else Yes, I think that I know you do such an excellent job. I just want to say I think that's true Okay, thanks for giving me a chance to talk, but I'm pretty much going to say the same things from a different angle Yeah, as the small talk people know very well the model view controller paradigm is very old And it's not supposed to be just applicable to web applications. I believe it actually started with desktop applications I might be wrong on that but whether or not rails does a good job of mapping those That design pattern correctly has nothing to do with whether or not it's an applicable design pattern for example You were saying that the the back end is essentially API application on these on these Ajax heavy applications of the modern world Still has to exist. It's it sends over JSON instead of HTML That's just another form of the view right where they're not we're going to be using Templates for that view. Maybe they should be presenters instead that transform the stuff into JSON It's simply good decoupling to change to have something in between the model And what is going to be presented to the front end? Do you see what I'm saying? Yeah controller is simply the orchestration layer and I believe that the For a web application having good routes there Even if it's just for API is very important for people being able to discover your your API in the back end and make use of it So, I mean I Definitely agree with you that the model view controller paradigm as a kind of overarching design is still very much useful here, right? What I'm not sure is if the specific implementation In rails and I think MVC gets I mean it can mean so many different things, right? MVC as sort of used to talk about rails like web apps actually has very little to do honestly with MVC as the kind of desktop UI paradigm You know started in small talk. They're very very different things And but you know it's still useful architecture to think about I Disagree that it's useful to think of the JSON as a view I think it's much better to think of the JSON as a representation of the model Because well when you're exposing a public API There's been many times when I've written API applications where I end up finding myself putting logic in the model layer about what what aspects of the JSON should be visible to the To the application using the API and I think that's a poor design I realized that that should actually pushed into the view and controller layers Sure, so whether or not that's actually in the model objects or whether or not that's in a layer above it But I mean I think the more interesting thing from my point of view is that on the client side You have you know it may be a view with respect to the server side with respect to the client side It's definitely a model because one of the things that one of the advantages of this style of application is that you Have this one JSON model that you can actually build many client side views on top of it, right? So you have this piece of JSON and if someone wants to switch from seeing you know a list view to a detailed view if the JSON that's available to it is rich enough. They don't have to make any request to the server, right? They're just representing that same bundle of data in a different way And so I think it's it's a mistake to think of it too closely as a view and you're gonna end up having more Request than you need and you're gonna end up having more logic on the server than you need And you could just be doing this stuff and doing it much faster remember on the client And also you know without the network traffic, which is useful and obviously there's a there's a balance there, right? I mean if you have security issues, you know, you don't want to expose your entire model Obviously, you don't want to allow arbitrary rights to your model, you know There's still lots of stuff that's gonna have to happen in the model on the on the server But I think you at least need to be thinking about kind of NBC on the client, right? I have this JSON model and I have multiple views that look at it and I'll interact with it Yeah, I totally agree that the API should be considered sort of the model layer of a larger Orchestration, but even that layer it's talking HTTP. I feel needs the the MVC model inside of itself Thank you very much for your talk. Hi. Thanks for the talk I think it's really timely and this is where everything's going so I'm glad this is now The message is starting I think get out bigger but talking a little bit about the message I'm a little hesitant on some of the words used in the slides and I want to be maybe a little bit Easier for people to I think swallow So I think that big disservice that happened in our community in a large was the no sequel term Because I think it drew this really big division between people who are using relational databases every day to get their job done And have absolutely no problem doing it and then oh But I feel like I should be doing the same because I should no sequel So I would throw out that we should use less MVC less HTML and not necessarily the word no because it's a lot of other people Have pointed out there's still a huge room for rails and a lot of these Frameworks that coexist to help push this package to the client And I don't want to draw a division to have people go down these routes and throw away a lot of stuff We've been doing so I'd rather see more of a evolution than a revolution Totally I think this is gonna happen anyway, but it's kind of a messaging marketing point that I just want to bring out And as you know, so I'm a pragmatist. I'm still using rails on the server, right? So I mean, I'm saying it's obsolete I'm still using it right so this is this is an intentionally provocative talk And I'm intentionally using but Twitter is already I mean, you know put the meme out there and it's gonna Propagate so it's already happening and it's good. I think we should be talking about this But as we proceed I really as a community, I want us to think more about less not no Great great less HTML all that back. I'm happy to adopt that as a motto But thank you. Yeah, good points. I enjoy the conversation. Thank you So I have more partial solutions. Yes, great So one of the problems that people have with this is how does SEO work? What about my layout the initial page rendering and there's a project out there that I'm not responsible for but someone did That's awesome, which is called the ruby racer which binds the v8 Runtime to ruby. Yeah So you can do is you can have v8 running on the server side and pass it your ruby objects And then you can run all of your templates Which will then you only have to run once and if they're string interpolation templates or builder templates either way those functions That turn data into presentation You can run that then on the server side and have that SEOable and crawlable and indexable and Serve clients that don't support JavaScripts like blackberry phones and whatever else you need to so I don't think there's a great project out there yet That has like used JavaScript for your views right server side, but there's definitely infrastructure there for interested parties to make that happen Yeah, that's really interesting and definitely one thing that I've been struggling with Is that as I kind of move code back and forth between the server layer and the client layer because you sort of don't necessarily know when you're starting a Project what code is is going to want to be where it's really annoying to have to port it back and forth between Ruby and JavaScript, right? And you know, I haven't taken the step of just saying oh, well I'll just use no JS and write it all in JavaScript partly because I find it kind of a pain to write JavaScript It's a nice language, but I'd rather write Ruby or small talk But anyway, so those kinds of solutions are interesting and kind of bridging that gap a little bit I wanted to give a shout out to my buddy super Chris Nelson. You can find him on github He did a project where he wrote a little rack app that Bypass the controllers in the the restful controller where you kind of assume the crud and assume the certain routes It would inspect the URLs and just pass it right straight to the models and then just return JSON back out Okay, so it was a really thin layer between allowing you to use like active model with whatever And use rack to just hit right on to the hit right onto the models And it worked out really well to have a rich Java JavaScript client with Ruby for the server I should ask how many people are building apps in this style right now Yeah, right, so everyone has this problem more or less Rich, I think you're living in a bubble. Oh I work at Twitter, of course, I know It's a really loud bubble, but No, if you look at the sheer number of web applications, they're gonna be built in the next three to four years That is that this pattern will be a major subset of if The frameworks we're building don't support the vast majority of those other ones. It won't be used So I'm not I love this model of program. I really do but realize that in enterprises and Organizations that are trying to use this technology to replace the access database over there or the Lotus notes application That was written over there. They're not going to go to this model yet So why not right? I mean because the answer could just be that we don't have the framework support for it yet It's hard enough for them to get actually doing HTML. I Mean believe it or not, it seems It's obvious that this model with proper framework support is harder, right? I mean this this sounds sort of like the argument, you know I mean, but they're made six years ago that you know Well, no one's gonna use this Rails thing, right because that's right, but the transition from something like You know something with job job of templates to Ruby and Rails is actually straightforward. Yeah It's a different language. Yes a dynamic language or anything else like that But all that aside the paradigm is very similar, right to doing something with hibernate models. Trust me I don't want to go there. I'm just saying that You know from a paradigm perspective. It's very similar. Yeah to go to something where well What we're doing is we're actually going to push all this into the view and we're going to do all this stuff with Now realize Microsoft who introduced a lot of this stuff as much as we bang on them but the ability of actually doing asynchronous requests was because of them and You know, they were building really robust client-side applications a long time before any of this stuff you know and They tried to push this model and everyone pushed back because they understand this kind of server-centric model It's the mainframe mentality, right? This is client server computing For some reason IT loves mainframe programming and we've all been developing mainframe applications for the last five or six seven years That's what the web's been about. Yep. It's Right now we got to go back to to client server computing and then everyone goes Oh my god client server computing is hard and eventually the paradigm well I mean, I think it's swinging that way just like I did in the 80s But I think it's going to swing back eventually and fortunately to this kind of server-centric model But right now I'm I'm hoping that I'm just saying from the vast majority of people that will be building web applications I believe in the next three to four years. They're going to be traditional web applications. I'm talking about the number of apps I'm not talking about yep Twitter and you know these other sites that people use every day I think they'll move more to this model But you don't see the other ones They'll never use the other ones, but they're there and they're being built And we need frameworks that do that and if that framework can also support this model, too It won't be optimal, but if you could actually support both I think that that is high value because then you give people an ability to say hey We can transition you using say rails to this model and now we can transition you here. So Yeah, I mean What you say makes sense. I Generally dislike sort of that kind of compromise solution I would rather see something that is only useful to the small subset of people that are sort of on the bleeding edge And you know if ignoring the enterprise is wrong. I don't want to be right No way, how's that work anyway? But Yeah, you know so so so my my aesthetics are towards Pushing the envelope and and sort of figuring out what the people you know the people in this room probably You know enough people put up their hands saying we're building apps this way that I think there's a need for Framework support for this and yes if we can sort of make it backwards compatible and still work You know well enough with the old stuff. That's great. That's a win But this is sort of the you know Again the argument of whether or not whether or not we actually can get there without throwing out the other stuff And and I would argue that you know the most interesting new designs happen when you go back and throw away the old Design decisions because your constraints have changed and so I'm loathe to continue to take on the constraints that that I'm sort of hoping that we're rid of but You know that's I Live in a particular world and that's what makes sense in that world and I recognize that there are other worlds that I've been Actively running away from where where that doesn't work. I I need to put in here Yeah, put an end to this fascinating conversation We're a little over time. Yeah, do you have anything in conclusion? No, no, we're good. Thank you very much