 So, uh, yeah, I'm Bhaskar from Offstack and I've been working on web technologies for year and a half now, the mobile web especially, and apart from that, I mean, recently I've been doing, yeah, so I mostly do the front end part of it, although, I mean, being a startup, we do all parts simultaneously. So, uh, and I did my BTEC from College of Engineering, and another thing to add, I haven't yet recovered from a very bad cold, so please excuse me. Okay, so, I guess I can begin. So first, I want to show you something that we built and we recently presented it at TechCrunch Disrupt 2011 in San Francisco. Let me show you a live demo of it. Yeah, that is our rendering of the TechCrunch website. I mean, uh, so this is a totally, sorry, this is a totally different experience. This is not a website per se, I mean, as in it doesn't have a horizontal scroll and you keep on going and all kinds of things. And it is a very, uh, what do you call a magazine like experience that, in the way that you go on flipping and you continue to read the content. I'll try to load if it, the 3G works. Aha, here we go. So, this is the article. Uh, let's get to it in a while. Okay, so, so here's what we see, a very, it's back on edge. So here we go. So, we have a complete touch-friendly experience, but specifically, it miscalculated the resolution or something. Yeah, I'll just show it from the iPad itself, the connector is pretty buggy. Okay, so, uh, this is our rendering of the, uh, of the TechCrunch website. Well, it's not working the way it is supposed to because it is on edge right now. So, okay, so when we are creating the touch site, we, uh, thought about, like, uh, we started from the scratch and we figured, tried to figure out how do we want to build it. So the most, the initial approach, or rather, the classical approach to the, to building the websites that you can call Web 1.0 was that you, you have a step, I mean, okay, uh, from here on, any example I'm going to take will always, uh, should be taken in the context of a dynamic page that is rendered on the server with some data that is dynamically changing every time. So, uh, in the, in the initial scenario when there was no Ajax and the Web 1.0, what used to happen was every request was a fresh request which the client made to the server, the server would take the template, take the data, render the template with the data and send back a full page which the server then, uh, sorry, the client then uses to load. Then, uh, you have to load the next page, you do the same thing again, where a template, uh, template and data is taken, rendered on the server, send back to the client. And this is repeated infinitely. So, uh, now the problem with this approach was for one thing it is, I mean, uh, it doesn't provide a very beautiful experience in the terms that the page reload and the whole flicker, it doesn't really give a beautiful experience. So, uh, what we started, oh, by the way, that the question you asked, it is a website. It's running on off our server. It's not a native app. Okay, uh, so, the next approach that is, uh, taking, I mean, currently I think more than 80% of the sites are running on this approach, uh, is the Ajax Web where the first time the client makes a request, the server sends back a full page, then the components on the page which are the scripts and the CSS and the other elements, they make requests for more data to the server. And the server sends back the, uh, data as needed. But in this case, uh, the data that is sent out the later times shouldn't be the complete page. It can be just a piece of, it can just be a markup for that, that can fill a particular element in the page or replace or add whatever, I mean, that depends on the use case. So, uh, the beauty about Ajax is, uh, it gives a much better user experience because the page doesn't reload and all. For another thing, it is much faster because much lesser data has to be transferred. It's much lesser overhead on the server because the server doesn't have to render the complete page. It can just send back the relevant data. So, uh, that is a couple of reasons that Ajax took off. Now, what, what, and this is the, the generic, uh, way of doing Ajax, which is rendering on the server. What happens is server takes the template and the data, it renders it on the server, creates the markup and sends it back. The markup can be a complete page or a part of it. What we try to do, we did, we try to render it on the client. Which means the server sends back an empty template, it's a, and it sends back the data in the raw form. And the client handles the task of rendering it and displaying it. Okay? So, uh, now, there are a couple of benefits to it. For one thing, on a device like the iPad, uh, there are, there are many parameters which the device knows instantly, which the server, for which you'll have to make additional requests to the server. For instance, the orientation. So, uh, the example, I mean, the way we built our system, uh, and the requirements that we had didn't allow us, didn't allow us to have a complete flow layout because it is separated into pages, so to say, or screens if you will. Uh, so we had to do the task of breaking the data down. Now, if we had, we do, if we had been doing that on the server, the server would need to either send out both responses, one for the ported, and the other for the landscape orientation in the beginning, because, or, uh, when the, when you reorient the device, this, uh, device would have to make another request to the server to do that, which, again, I think both of them are suboptimal because the data is being transferred twice. So, what happens when you're rendering on the client, the device knows the current orientation, and, uh, like I showed you on the iPad, it was running on the full screen mode, and then you can run it within the Safari. I'm sorry. So, uh, in that, if you run it within the Safari browser, the dimensions of, uh, the area available to the application to run changes, and, uh, which, which actually matters in our, uh, in our use case, which is, uh, a fixed layout, and, uh, the data has to be re-re-flown according to, I mean, your current orientation or, uh, the mode that your browser is in. So, all that was taken care of by the client, so the server can always send back a template and the data, regardless of what state the device is in currently. The client, which is the iPad or any other mobile device for that matter, knows the, knowing the current orientation and all, and, uh, given that these devices have pretty decently fast, uh, JavaScript engines right now, they can, they can process it much faster before you know it, the site is there. I mean, even when, when you re-oriented, you don't as much notice the, uh, the whole re-rendering, because there's no, basically no time lag. So what happens on the client rendered web? Initially, the client does the same, which is, make a request to the server when there is no, uh, no data whatsoever on the client yet. The server sent back, uh, loader, so to say, which is a basic page, which is sent the classical way, which, uh, by rendering the template and the data as, as required. And when that data, uh, that, that page loads, it's sent, the script fires, and they send requests to the server to get the new data, which might be, I mean, that depends on the, the use case, like in our case, a gesture, a swipe can tell the browser to load the next page. And when, when the swipe asks the browser to load, load the new page, uh, the browser makes a request to the server, which instead of sending the whole rendered HTML markup, it just sends back the data. Here's another benefit to it. Sorry. The template for a particular kind of page, say, an article, is the same across the articles. So it can be cashed on the client. So the first time you request a template, it is brought and cashed on the client, and then on the only, uh, the data is sent out from the server, which is JSON, which is, I think, the most compact and beautiful way of presenting data, and being that it is a native JavaScript object, it's much, uh, I mean, it's much less overhead on the client to render it as well. So client renders it, adds to the DOM, and the JavaScript takes care of showing the transition and all. So that is how, which you have to do data site. Okay. Uh, there might be a question and a couple of you, uh, you said, why not jQuery mobile? When we started, we thought about jQuery mobile. So, uh, there were a couple of, I mean, given that, I'm not saying that you cannot use jQuery mobile, but our use case did not as much permit us to do that because for one thing we had a very fixed layout, uh, which was given to us by the designers, and, uh, that layout had columns and all. Now, uh, there were a couple of constraints in the way the CSS3 columns are implemented right now. You cannot, uh, you cannot span multiple columns for any elements. Say, uh, you can't span an image or a title like, like it was done on the top side, on the top and then you start with the content and continue to reflow. So we realized that we had to do the task of breaking up the data into pages ourselves even if you want to use CSS3 columns or anything. So we just decided that, as, I mean, if we are going to do it, we might as well do the whole branding ourselves. Another thing about jQuery mobile is that it follows the classical approach in the fact that, in the way that it requests the whole page each time from the server. Then it, it has a very fixed layout where you have fixed IDs and, uh, identifiers for the various, uh, elements on the page. You break, then it gets the page, it breaks it down, and then it loads the appropriate relevant data into the relevant boxes and shows it with the transition. Now that was kind of counterintuitive given the fact that we had to control on the server and we could, I mean, while we could choose to send much lesser data, why should we choose to send the complete page each time. That was another thing. Then, yeah, it is. Once we, uh, yeah, so when we started splitting up the data, I mean jQuery mobile doesn't do it for you, so splitting across the pages and all, that caused us jQuery mobile, uh, to slow down. I mean, it was running its own, it does a bunch of things, uh, amongst itself which is, uh, it does the request in the backgrounds and all kinds of things and, uh, in addition to that, when we tried using the, uh, the, so there's this library called region.js that we used to split up the content. When, when we used to run that in addition to jQuery mobile, it, it would really slow it down. I mean, it was a really bad experience. So we chose to not go with jQuery mobile. And we started taking a look at, uh, the other possible options that we had. So, uh, for rendering on the client, we found a couple of other, uh, jQuery and JavaScript base libraries, but we ended up using Mustache because of a couple of reasons. Sorry. So your question is that, uh, how, how mobile Safari does it on complex templates? I mean, how efficient is it? Okay. For one thing, uh, like, right now we just have the iPad and given the fact that there are lots of Android devices coming in, the tablets and all. So once you expand this, I mean, the, with our approach, the problems that we had a fixed layout and the design had a couple of, uh, requirements to it which required data to be split up and all across the device, uh, I mean, across the pages and all, or screens as we called it. So, uh, doing all that on the server is kind of not possible. I mean, it is, for one thing, because the client knows where the data is beginning and how much is it occupying and all that. And even if we pre-determine it, pre-computed and save it in the server, the next time there's something changes on the, on the client, say the orientation or something. I mean, hundreds of combinations of the, I mean, this is our use case that I'm talking about, where you have to split the data yourself. And, uh, doing it on the server is just painful to say the least. So, we've got a little, uh, we've said that, uh, how long does it take for to give you a good transition then. So, what happens is, if you go from one page to another page to another page, it will be, it's actually very, you know, like, extremely fast because it's never in, this is the one that happens. It's very, very much. It's completely small. What we do is we do it in spite of the next one, then as, as soon as we despite all the years of data back, and the data's really small in this, so as soon as we strike up, I think it's completely small. Okay, so, uh, after going through the couple of options, we landed on Mustache because for one thing, on some, running some tests and benchmarks, Mustache had pretty good, if not the best, that pretty decent, uh, performance. The, very, I'm sorry, very big advantage that it is available in like 20 languages. So, you can, you can use the Mustache template on the client or on the server. I mean, you can use the same templates across the system. You can choose to render them in whatever language you choose on the client or on the server as you may please, as the use case may be. This makes it very fact flexible and also you don't have to maintain 20 copies of different languages to be rendered by different, uh, templating engines. And of course, it is the, the, sorry, the Mustache, uh, templating language is very, very similar to the Django templates that we use in our system, so it was a easy transition for us as well. So, uh, okay, so what are the actual benefits that we gain, I mean, what do we gain by doing client-side rendering? First thing, our servers don't have to worry about what device it is, what state is it in or, uh, I don't know, what orientation it is in or any of the other 20 configurable options. It always sends back the data, which is the JSON compressed in really small amount of data that is sent every time and everything else has been preloaded on the client that happens initially and then on, I mean, it's blaze fast because of the high powered, uh, I mean, the, the JS engines allow us to do that today. Then, uh, that allows the server to not worry about different kinds of devices or even different, I mean, you could power a native app and a mobile, uh, and a web app using the same backend framework because the, what has to be done by the data, I mean, what has to be done to the data has been determined in the client, so the native app can determine how to display it or whatever to do with it. And another benefit with that is we can cash the response, which obviously enhances the performance. Uh, the, I mean, all the data that is, because there's no rendering per per issue or per condition, the different, like even the template can be cashed at one place and the data in the other place and both are sent separately to the client and then the client handles that. So that gives us additional, uh, speed. It saves a lot on the server cycles. The server doesn't have to do the rendering each time for each page or each part of the page for that matter and of course we save bandwidth because JSON is like pretty small amount of data compared to any other format and we save it on the markup as well. And also the caching is done on, I mean, the template is cashed but the first time it is loaded. So next time on, it doesn't make another additional request for the templates as well. Okay, so this is how mustache looks like a template. These double curly braces uh, these these define a variable. I mean, uh, you can substitute these with the variable value. And the for for loop and if loop, there is same representation, which is hash within the double codes and hash is the opening block and slash is the closing block. So if it is if you have to iterate over a couple of like I'll just show you the data using which I've created this example uh, so if you have to iterate over a couple of values and uh, you have the same I mean, suppose it's a list or an array which has the same data structure. You could just do a hash on that, I mean, the array name and the children can iterate. And the other thing, uh, if there is no I mean, it also suffers the if, the same hash and slash. So as you see on the bottom, the blank which is, if it is not in the data, it won't just be there. So uh, for our kind of example, supposedly we have this data so you can take a look back at the template. So here is action and then we go uh, repeating on a couple of array elements which essentially are all JSON objects again. So what happens when you render it using the slash? This is what you get at the output. So much lesser data to be transferred much more of output that can be generated. And essentially they are logic less in the sense that what you can do about it, they are not as powerful as Django templates. But still if you, I mean, if you manage a data properly and if you want to give power to the browser, you can use the moustache templates. Not yet. We are actually we are looking into the Python implementation of moustache to try it on other apps as well. So I'll show you a quick maybe this looks a little better. So this is live version of demo of moustache.js. On the top, the first text area has the template that I've created just some text with a couple of cases where you have if and for and then you have the data and uh, so when I say render template, it generates the HTML out of this template provided data. Sorry. And here at the bottom is how it is actually looking, I mean, so on the top you see the HTML and at the bottom is the actual rendered HTML in the browser. It's a very basic demo. And it's pretty simple to use. You can just if you get both template and data, you can just load the moustache library and call moustache.2html and that's pretty much it. Yeah, so if is handled by the same hash and flash which is, I mean, the bottom one, it doesn't show up because it acts both as if and for. It depends on the data which you are iterating it on. And it is the same thing that you can do. I mean, it's logic-based. There's not much power to it. But yeah, one more thing you can do which is if you use instead of two, you use three codes. It allows you to put in what you call unescapedhtml. So that prints the original version of it. Sorry? Yeah, underscore. To underscore? Well, for one thing, I haven't used underscore myself. So sorry about that. But I think the motivation for us to use moustache was primarily the easy implementation similar to Django and multiple languages support which I guess we are definitely trying on different other platforms as well. Yeah. That, yeah, you can provide that data structure pertaining to the language and that implementation, I mean, that depends on the implementation on that language. I mean, this is just an example from our own code where we, I mean, how do we send back the templates initially? So I mean, and for the touch we, I mean, this is the very basic version where you only have an article layout and a content layout which is the grid that you saw. So we don't have many templates and those are very basic as well. So we initially, we just send them on the first request which makes it pretty fast. I mean, we don't have to keep requesting for them over and over again. And we send them back at once. So we just take the, we take the templates, we dump them into JSON and just send it to the client where it caches it and starts using it then on. You can, no, on the client you can just, I mean, JavaScript can just store JavaScript variable for that matter. And this is our data view which basically just takes the article object, dumps it into JSON. Now, for this we use our custom encoder that we have written. All it does is it calls a function on the model a method which takes the required attributes that we need in our in JavaScript and we dump them into a JSON object and send them back. So what we plan to do with this, what we have right now is for one thing we want to make it much more interactive where different, I mean you can customize the design and layout of the dot side. So the reader can make it, I mean to design it to his wish as much as possible. For another thing we are also thinking of trying out for the high end phones like iPhone and the Android phones which can support the similar functionality. We are trying to roll out a similar version of the site where rendering is done on the client. So, I mean, that saves the servers a couple of, I mean, milliseconds I guess, a microsecond for that matter. And it will use this similar layout and then eventually we might use I mean move to a layout where the same template is rendered for a device which cannot support JavaScript on the server. I mean, so a device which cannot support the JavaScript, the pages render the server and send back and the devices which have high end support for the JavaScript like iPhone they will receive the template and render themselves. So, thank you. Questions? Does it do any kind of HTML verification? No, it doesn't. It's a, you can, I mean, instead of HTML you can just put in normal text as well. It's a template it doesn't really care about that. It only cares about its own blocks, which is the quotes. Yeah. Okay, so use Mustache with Django will, I mean, I haven't implemented it but I'm assuming that obviously in the settings in Django to use the Mustache templating engine you have to use PyStash on the server and then use the same templates to do the rendering on the server. Yeah, the same templates would work. So, another question is can the game issue in the server also can you make it get it? Absolutely. Yes. I'll see you in a second. Thank you. Yeah. Yeah, we're doing it initially just because we don't have that many templates and they're pretty simple as well. I mean if you have a big framework of site or something like that, you can do it. Yeah. Yeah, we're doing it initially just because we don't have that many templates and they're pretty simple as well. Framework of site or something where you want to support like 20 layouts, you can send them one by one the way you choose. Yeah, so the idea is right, so we did a lot of things to make this a lot more like a native app. So if you don't see the browser, you actually won't realize that you're running inside a browser. I mean if you don't see the bar basically. But this is actually exactly running in Safari. 3G is pretty bad. But, you know, so that's it's not working because of the You're going to be switched, you're going to be switched you're actually going to be switched off of that. No, the techniques are the same. I mean, when you're using the app, you can see the services and the data is the same. So, yeah. Sorry about the hiccups and the demo. It's mostly because of the app, but, sorry. Freemong to render, what's the How? No, that's all our code. Yeah. The only thing we're using is we're using Mustache to do the JavaScript rendering and we're using jQuery which everyone does these days. Other than that, everything else is being done by Yeah, we're not? Absolutely. Oh, yeah, yeah, yeah. This is just one template that we've done for this is our default template, so to speak when we first launched we Sorry, bad luck. Yeah, this is only the default one that we've launched. So what we're doing now is essentially our the iPad template, the mobile template will all be in sync. So it won't matter the URL will remain the same. So, for example, if you're just, for example, say you're plugged in, right? You're already plugged in, right? Plugged in's URL is the same, plugged in. But you would if you were, so the way it works right now plugged in uses Mustache. If you hit plugged in from your mobile phone, you won't see the PC version. You'll see m.plugged.in which is rendered for a mobile, you know, for all kinds of We have some more for about $5,000. But now when plugged in goes right with this, if you hit plugged in from your iPad, you'll see this. And they'll all be in sync in terms of the way it works. And we're going to go after couple more different kind of templates. One for magazines and one that is more easy to just make a relation out of that. So we now have a couple of different options. This is completely different. This is all just I mean, ultimately the look that you might have seen is still not extremely well-finished. Yeah. That is still the same. But what happens in the jobs that's all, and the way it goes is all right. So the third party developers down the road, not yet. We don't yet have critical mass to open it up to developers. But what we would like is this whole theme is essentially three files. It's a theme.js, it's a portrait.cs, landscape.css, done. That's what the theme developer should have to write. And the rest of it is the glue that mobstack gives you and then the developers can just use the APIs to get their work done. So this is the weird amongst the probably there's only one other company that in the world today that can do this for publishers. And the way you do this is you just, I mean, people can sign up for a product. We're in private beta right now. But they can come sign up for this and then once it's opened up to them, their existing site automatically gets this because we have an integration JavaScript snippet. If you put that into your existing website, then anybody who hits your site from a mobile device either iPad or phone, they'll automatically see the mobstack rendered version. So that's how we integrate. So Pluggedin has that plug installed on his site and the Hindu has that plug installed.