 Hi, my name is Dhananjay and I'm going to talk about Sproutcore and specifically to start with, I'll be touching upon how to build really fast applications. So before I start, I just wanted to know, like, how many of you have heard about Sproutcore? How many have you used Sproutcore? So that's good because the session is for beginners only. So how do we build blazing fast web apps? So these are the things which we will do to build up blazing fast web apps. So first of all, it will be make your code faster so that you can do by, like, optimizing your code by probably merging your images, reducing the code size, maybe changing on the database, maybe doing, writing a lot of custom implementations. So that would be one thing which you will target to make your web app faster. Second thing which you would want to do is you would want to reconfigure your server. So probably you might want to load balance it. You might want to increase the resources on the server. You can apply cache, cache on the web server, which is going to cache the files and serve it up. So you can do it reconfiguration of the server. If you do that, you can, again, enhance the performance of the web app to some extent. Then other thing which you can do is you can use CDN, which is content delivery network. So this brings the content near to the user. So this really helps in the performance because content is near to the user, but, again, it's pretty expensive. So you can do all this. But the problem is most of the web apps spend 80% of the time outside the server. So that means whatever optimizations you are doing is you are doing on the 20% itself. 80% of the time the web app is out of your server. It is actually in the latency. User is doing something. So really, your app is not in the, no, not in your server for 100% of the time. It's just the 20%. So all the optimizations which you do will impact 20%. But what about the 80%? So let's see how this really works. So say you have a server, you have an app which is deployed in, say, Bangalore. And you have a client who is accessing the app from somewhere far in France. Now you have optimized your server. You have done all that, what you would, what we discussed in the previous slide. And you have got the response of sub 100 milliseconds. So getting that response is really not easy. But if you have got it, you must have done a lot of custom coding. And if all the responses are sub 100 milliseconds, that is really a good achievement. And if you're able to do that, that's really good. So now the, now when the request comes from the client to the server, just because of the latency of the network, this is the latency which you are going to see, which is maybe in the range of 250 milliseconds. But this is just not the latency. So this is the latency which is ignoring the latency of the Wi-Fi or maybe a network package drop. And this also ignores the latency which is due to TCP IP protocol, which is a slow start protocol. So what does that mean is if your request size is more 100, 800 bytes. So that request is going to be broken into two packets. And the client will send a packet to the server. Client will send nothing else until it has got some response from the server. So that means there will be two trips of 250 milliseconds each. So really you're looking at the latency of 500 milliseconds. And after that you have like no processing of the browser, all that is there. So you're looking at, just to get one asset, you're looking at the latency of one second, more than one second, to get any asset from the server. So this is the typical web application in which you will have your data and your business logic, everything on the server. You have everything on the cloud. And to do anything interesting, the server has to give you something. So you are 600 milliseconds behind the server. So the paradigm which I'm going to talk about is web client applications. So what is web client? So basically in web client you move a lot of business logic to the client as much as possible. So what we are looking at, we are actually taking a step back. So we used to have client server apps earlier. We went to NTR. Now again, we are coming back to the client server app in which we are making the client a thicker client. So we are pushing as much business logic to the client. This is truly possible now. There's no reason it's not possible. It was probably not possible maybe five years back due to browser limitations, JavaScript limitations. But as of now, JavaScripts are very fast. Browsers are pretty capable now. So once you have business logic on the client, you can have it. In reality, we are going to see how you can replicate the data. You can start replicating. You can start copying the data from the server to the client. So once you have both of the things on the client, you are cutting the latency totally. Now you don't have any latency. So that is the response. That is the 80% of the time which you are really saving on it. So what is a web client? So business logic of the client is moved, business logic from the server is moved as much as to the client. After initial page load, so once you have the page load, initial page load, only interaction which happens with the server is just the exchange of the data. So web client will provide you very rich interactions because you have everything on the client side and it will be more or less, it will look like a desktop client. So it will provide you a very rich interaction. It will really highly perform it because you have very minimal latency. The bandwidth requirement will reduce drastically because now you are just getting the data. You're not getting any markup anymore. Whatever the markup you required is already there. And since you have business logic and data both on the client, your app can run actually in the offline mode. So this looks like a desktop client. This is a mail client, but actually this is a web client. And this is built using Sproutcore. This is MobileMe's web mail. If you look at the interaction, it's pretty rich interaction. It will work completely like a desktop client. So this is an example of desktop client. This is another one. This is the calendar app, which again uses just your client side coding. And it's a web client. It's running in the web browser. So you can have this kind of rich interaction. It's truly possible. So how do we build actually web clients? So I just wanted to pause. So I'm making sense. Do you have any question? In case you have any question, you can just stop me and ask. So see, web client, I'm not talking anything new. So if you have attended a session on Backbone.js, they also talk about the same thing. So they are also moving towards client, which is a single page development. Again, here in Sproutcore also, the development is single page. OK, so introducing Sproutcore. So Sproutcore is under development since last five years. And it became really popular when MobileMe adopted it. So MobileMe has some six very rich desktop looking applications which run on the browser. So they adopted it. And even Apple contributed a lot to Sproutcore. And since then, it has been on a really fast pace. As of now, there are like more than 100 active developers. There's a company itself called Strobe, which is backing development of Sproutcore. So Sproutcore is a HTML5 app building framework. So what that I mean is HTML, the code which you write is actually pure JavaScript. You can use all the HTML5 elements like your Canvas tag, vector graphics. You can include any library which you want. In fact, Sproutcore actually uses jQuery internally. You can use any library. You can easily plug in. You can use flash anything. So whatever you want to do with HTML5, you can do it. It has modern approach to web development. So we saw typical web apps have this kind of model which we have discussed that all your business logic is there on the server. So this is a new paradigm of development. And the architecture and a lot of design decisions have been taken from a very powerful framework called Cocoa. So anybody heard about Cocoa framework? So Cocoa Touch is one, which probably you must have heard. Anybody else? Cocoa? OK. So Apple uses Cocoa framework for developing its desktop clients. It's really powerful. And if you see native iOS devices, iPhone devices, they're built using Cocoa. So Sproutcore developers actually had a very good background of Cocoa. So they took a lot of good features, good concepts from Cocoa to say that they haven't taken some of the libraries like Capituno. They have also taken from Cocoa. But they have actually replicated to a very large extent. Like they have even replicated the syntax, which becomes really difficult to understand. So Sproutcore has just taken the good features of Cocoa, like features like binding, observers, computer property, data schemas. We are going to touch upon all that. And it is really optimized for cloud. So with cloud, you get actually latency. So your APIs are actually asynchronous. They take care of the latency. So if your data comes in, they're capable of handling the latency. And they're capable of giving a right kind of display to the user. So all the APIs across the board is actually optimized for cloud. They can actually live with latency. It's compatible with all major browsers. It is not compatible with i6. But i7 onwards, all of them, it is compatible with Opera and Chrome, Safari, Firefox. It's compatible. OK, so this is actually the evolution of the web apps. So earlier, we had just server-generated web apps, web pages, which was just a bunch of static pages, which is living on the server, user clicks it, you get it. Then came Ajax. So developers started putting some interactions on the client and made the experience better and response faster. As of now, a lot of us are using actually widgets. So widgets is like your tiny application, embedded in your main application. So widgets is like jQuery calendar or jQuery table, sitting on or maybe graph, sitting on this thing, maybe interacting with the server using Ajax. So a lot of us actually use widgets. But again, you have to understand there's separate applications. And they have become more complex when we actually get into web client. So building a web client kind of application is really tedious. It really actually is difficult. So Sproutcore is there to actually help us. So this is the stack of Sproutcore 1.x. So 1.x series, as of now, Sproutcore 1.6 is out. And 1.7 beta is out. So this is a tool stack. So when you download actually Sproutcore, you just not get a typical single one JavaScript file like jQuery and you just include it. You get a complete set. It comes with the build tools. And it comes with a complete framework, which is runtime, data store, foundation. On top of it, we have desktop and it has support for mobile. So build tools is actually in web development. When we think, OK, we have to do JavaScript development, we really don't think that we need build tools. But if you think about we have to develop a desktop client app, maybe a Java Swing app or maybe a Cocoa app, you will require build tools. So build tools do a lot of things. So they are actually used both at the time of development as well as at the time of production. So when you are actually developing, as soon as you refresh your page, build tool kicks off. It compiles the code, it puts in missing resources, puts in missing code inserts and all. So all that is required. And you will be 100% sure that your code really works because it's the same build tool which is used for production. So if your code is perfect and is working in the development mode, it is sure to work in the production mode. Runtime actually, OK, runtime gives you a very key concept. Yeah, so build tool comes with the complete installer. So you have installer for both Windows as well as Mac. So you can actually visit spotcode.com and you can install the installer. So it gets installed. Internally, it is actually Ruby code, Ruby scripts, which keep on running. So when you build, when you say Unix and all, it's because you must know, right? So even Ruby people must be familiar. It's actually Ruby scripts, not Rails. So. So you need Ruby. Yeah, correct, correct, correct. So Runtime gives key concepts like bindings, computer properties, which we are going to touch upon. Then we have Datastore. So as I said that now the complete data is replicated on the client side. So Datastore manages the complete data in a very structured manner. So we're going to touch upon all of them. So Foundation provides you a way of handling user events. Desktop comes with a lot of views, a lot of ready-made views. So if you are building a desktop client, you will get a lot of views. Like you will have ready-made table view. You will have a list view, a grid view you will have. A lot of views, like tab view, split view. I'm saying a lot. And then it has added support for mobile also, where it has added touch features. So if you deploy it on a mobile device, you can have no touch interactions. OK, so the framework size is somewhere like 500 kb. But when it gets compressed, it becomes around 100 kb. So that is still on higher side. We'll discuss about now what are the ways. Going forward, what is the roadmap. And to this mix, you can actually add any of your JavaScript library. So you can simply add it. You can just simply plug in and you can use it. OK, so these are some of the key concepts. So it has MVC. So as in Backbone.js, there's MVC. So we have MVC here also. So I'm going to touch upon just a few key concepts. There are lots, but these are really key. And if you are going to try, you should actually at least have some understanding of that so that it is a little easier for you to understand. So MVC, data model, binding, computer properties, and KVC. So MVC is actually model view controller. In Backbone.js, it is model view collections. But here we have model view controller. Now this model view controller is not same as what model view controller we are used to. The server kind of stuff in which most of the model, model view, and control all of them actually reside on the server. But view is just a static page which comes to the client. So here, when I say client MVC, all three layers are on the client itself, model view controller. You can have server MVC also. But the view part, client MVC, everything is on the client itself. So view just worries. View is actually a dumb display thing. So view just worries about how to display the data. That's it. It doesn't have to worry. Again, this is a little difference with Backbone.js in which view is a little smarter. But here, view is dumb. You just tell us what to display, and it will just display it. So when I say MVC, so these view, when I say view consists of two parts. Actually, one is the JavaScript object hierarchy, and the other one is the DOM. So when there is a change in the view, the view takes care of updating the DOM, and then you see the changes. So manipulating the DOM actually is really hit on the performance. So all the manipulation is done on using the objects. And when, at the time of updates, it is done. It is done on the DOM. View takes care of that. Model is the data model, a structured data model, which has to be there. Controller again, connects the model with MVC. And here again, in our world, typically we have just one controller. But here, one particular area of the screen you will probably have one controller managing that. So you end up having many more controllers, just not single, just not one. So we'll have many more controllers if you're developing a significantly complex app. So data store, so data store API is really powerful. It's really rich. It has a proper structure to replicate whatever the data is there on the server. So when I'm saying copying data from server to the client, it's the meaningful data which is required for the client. It's not that replicating everything. It's just the meaningful. Whatever you want to show, you cache it at that point of time. And data stores provide that model object. It provides way to query what you need. And it also provides a connector in which you are going to connect to the server. It provides the connector. And all the transactions are actually asynchronous in that. So once you have app loaded, everything is asynchronous. You don't have any page reloads on anything. So Sproutcore can work with any kind of backend. So you can have Java backend. You can have Rails backend. It can work with any kind of backend. The data format which it understands inherently is JSON, but it can work with XML also. But you will have to pay the price of that conversion. You'll have to convert XML again to the JavaScript object. You'll have to convert. So you'll have to pay the performance. So there's no reason to have XML as a transaction format for the data exchange format for the data. This fixtures is really a good concept of Sproutcore. So when you start developing the app, you will have a server team which will be lagging behind. So then what do you do? So you need to have some data to work with. So fixtures are a nice way. So you can define all your data, all your data here. Your static data here. And your app will completely work with it. So once you have your server ready, you can eliminate fixtures very easily without any problem. Maybe 1% change you'll have to make in the whole application to just take care of some of the latency. So Sproutcore does not have any dependency on JavaScript. You can use, I'm sorry, on jQuery. You can also use Prototype.js. They may be independent, but the build which you'll get, it will have jQuery in it. You can replace it very well and replace it with anything else. You can use maybe Prototype.js also. Sproutcore 1.x, that's not possible. We'll see how it can be done. So with 1.x series, it's really not possible to just use a little component of that. So when you're developing, as we saw, the MobileMe apps. So when you're developing a Sproutcore app, you're giving the complete control of the browser to the Sproutcore. So your whole app is running there on the app. You cannot have a widget kind of thing that you embed a little portion of the web app somewhere. You cannot have that. So with Sproutcore 1.x series, you will have to give up the complete control of the browser. You will have only Sproutcore app running at that point of time. So the idea is to create a framework so that you can develop thick client app, web client, which will run on the browser, a very rich interaction. So next concept is binding. So this is really key. And this actually reduces the code a lot. This concept makes coding really easy. You can do a lot of things with very less number of lines of code. So now this is a typical calendar app. So you have a calendar list. And then you have a detail of a contact. So in a web app, if somebody changes a selection, he makes a selection on something. So what you will do, you will first of all register an event to handle that selection. Then if you have got the selection event, then you will go and find each and every element of that on the detail span. And then you will update it one by one. So there will be really a lot of lines of code which you have to write. If we are using SproutCore, so SproutCore, so for this list, you will have probably a contacts view. You will have a view for this. So when the selection happens, this selection will be propagated to a controller called contacts controller. So contacts controller is a controller which will be managing this list. So this view is getting data from this contacts controller. And also, any selection changes and all, it is registering. So any selection in this contacts has been bound to contacts controller. So now we will have another controller which will be actually, which will manage the details part, the details of the contacts. And the selection of contacts controller will be actually bound to the content of contact controller. Am I making sense? Change which happens here will be propagated to contacts controller. So contacts controller selection property will be bound to selection of this contacts view. So any changes on selection here will be propagated to selection of contacts controller. And the content of the contacts controller will be actually bound to the selection of contacts controller. Am I making sense? This is contacts controller and that is contact controller. So they are two different type of controllers. They are like under the list. Yeah, so they actually, when you get into, there are different type of controllers also. So this contacts controller will be actually an array controller. So there are three type of controller which comes actually with Sproutcore. Contacts controller, array controller, object controller, and tree controller. So this will be an array controller. Now contacts controller will be an object controller. So content of contact controller will be bound to the selection of contacts controller. This content will be propagated to the view. This is a detailed view. So the content of this detailed view is bound to the content of contact controller. So you see this chain happening. So model is like, see model is behind. So as of now, somehow contacts controller has got the data. Just assume that. Somehow contacts controller has got the data. And your data is nothing but the model. So when the data comes from the server, it actually gets stored on the model. Then it is actually populated into the controller. And then controllers are actually bound to views. So once this object contacts list item view understands that there is a change in the selection, it will update the DOM. So we saw all that binding. We saw so much to do. How much lines of code do we need to actually do all this? So this is just four lines of code you would need to establish the bound bindings. So establishing binding in its proud core is super easy, actually. It's just one line of code which you will use to establish the binding. In the contacts view, you see the content binding. So that is the content of the list which is there, which is bound to the contacts controller. And after that, the selection binding, so any selection changes on the view is actually bound to the selection of the contacts view. So establishing the binding is just a matter of one line of code. Why do we need to explicitly define the binding? See, you would need, see, there's some changes. For example, in that app, you have made the selection change, right? Now the details of the contacts have to change, right? That pain has to get refreshed, right? See, you have made some change here. You have made a selection change from hand products on the gas. So this part has to change, right? Did you take the binding for that? It's not time. So you don't actually. So that binding mechanism is already inbuilt. So you just have to write one single line of code to use it, OK? And super fast, there's no performance yet. Rather, updating the DOM the way typically you would do, in which you have to find each and every element, updating that would be tedious. And that will be time consuming. So yeah, so you have to establish the bindings to get the selection change, reflection happening on this. You have to establish the bindings. OK, so we saw that we have established the bindings on properties. So there's something called computer properties, in which it is just more than a simple property. Like, for example, you have a full name, OK? Now, from server, you are getting record for, say, first name and last name. Now, you want a full name, and you want to show on the UI the full name of it. So there, again, you want to bind it. Now, you cannot bind to two objects, OK? So because the value cannot bind to, you have to just bind to one. So in that case, you will write a computer property and computer property is dependent on first name and last name. So if they change, the value of full name is going to change. And once you have defined the computer property, you can use it as normal property, as just some standard property. You can use it. You can bind it. You can set it. You can do anything you want. OK, so this is a concept like this is called KVC, it's key value coding. So these concepts are actually pretty much taken from Koko. So if you have some experience with Koko, probably not. You would actually understand it better. So this is key value coding. So in JavaScript, to read a value, you will just say object.name. To set a value, you are going to say object.name is equal to some name. But when we are using KVC or in Stroudcore, you really shouldn't be doing that. You cannot do directly. You have to use the getters and setters. So this is the way you are going to really change the value or read the value. Because that is the only way in which Stroudcore's notification engine will get to know that what's going on. OK, so if any property is there, which you want to bind it, which is not private, so you are going to use this kind of getter and setters. OK, so these are some concepts of key concepts of Stroudcore. So what's next, actually? So I just want to touch upon Stroudcore 2.0. So as you were asking, can we just use a small portion of it? So with Stroudcore 1.x series, you cannot actually use it. But with Stroudcore 2.0, you can use it. And it's actually in works, but it will be out pretty soon. The beta is going to release within a month. And the final version would be maybe around a couple of months. So these are some of the features of Stroudcore 2.0. So key concepts are the same, but the framework has been changed a lot. The framework has been broken into small pieces. It will be available as a single JavaScript file. So the way you would embed jQuery or any other JavaScript library, you can start using Stroudcore just as a single file. So you just have to embed it. You don't need to have all that mechanism of build. You don't need to download the complete stuff. Like, core of Stroudcore 2.0 is just 40 kb. And if you compress it, it will be around maybe 10 kb. It's a really lightweight. So if you don't want view part, you just want the core engine in which you should be able to do bindings and all, you just download the core. It has been made modular. It has been broken into different sections. Data source will be another section. Your core engine will be another section. Your view will be another section. So all this you can just include as library. So you can just use it. And it's really geared towards mobile. So the paradigm which we talked about with all those features in which it will behave like desktop client and it will have all its business logic and data on the client itself. Stroudcore can be easily used on mobile. In fact, a lot of companies are using for mobile development. There were some challenges with 1.7 because of the size. There are some techniques to actually overcome that. But Stroudcore 2.0 is really bottom up. It is completely geared towards mobile. So to start with, it has gesture recognition. It also has Stroudcore UI which is actually native controls of mobile devices also. It can be used for desktops. So Stroudcore 1.x series is very good for desktop apps if you want to develop it. But as I said, there's some limitation for mobile because of the low resource on the mobile devices. But high-end mobile devices like iOS, iPad, Stroudcore 1.x is being used to a large extent. And there are ways to actually, you can actually define a blacklist in which you don't want, the files which you're not using, you don't want to load it. So you can define a blacklist. So in that way, you can reduce the load size. So 1.x can also be used for mobile, but there's some limitations. So going forward, actually 2.0 is the thing. And there's a lot of push. The whole company, the Strobe, almost 40 developers are working day in, day out on Stroudcore 2.0. It has also a mustache tag. It has handlebars. It has theming, state charts, all that. So you can plug in any JavaScript library. There's no one knows. That is true for 1. Yeah, yeah, yeah. So plugging any library is actually true for 1.x series also. But here, again, you will be using just as any other JavaScript library. But you will have a lot, many, whatever you want to use it. You will also get the build tools with that. But you will have to download it. So you will choose what you want to use. Then you start using it now. And you send it to the developer. Hey, you can start. So I'll point out some preferences. So you can start using it. It is available. In fact, the Transform.js and all, you can really do a lot of cool animations and all. It's already there. You can start using it. You can use it. Actually, I myself don't use Eclipse for JavaScript development. I use TextMate, which is much lighter. Eclipse, I find it a little heavy for JavaScript development. For server side, I do use Eclipse. Yeah, yeah. So you can use Jasmine. And you can also use Sproutcore itself as a testing framework. So you can use that also. So all that is there. Stools. So whatever you build with Sproutcore, you can actually deploy on mobile devices. So have you heard about PhoneGap? So OK, so you will see PhoneGap is a really cool thing. So you have so many mobile devices. You can run web apps on that. But when it comes to the browser app, you will have to go to the native. But you use some library, like maybe Backbone.js or maybe Sproutcore. You use it. You develop one single HTML JavaScript app. And then you can use PhoneGap to convert it into native apps. So you just do one development one time using your HTML5 and JavaScript and use PhoneGap to convert it into various versions for various devices. So you get native apps, which actually you can put it on a store also, iPhone store and market on Android. You can put it there. OK, so how do I learn Sproutcore? So see, when I started, I actually started learning JavaScript at that point of time. So if I can learn, everybody can learn. It's not that hard. I've been working since last four years. And I find it very, very useful and easy to, I would not say easy, but it's learnable. And it's not that hard. And with Sproutcore 2.0, there's a lot of push for documentation, good documentation. And there's a lot of help. These are the resources which you can, so Google groups, you should definitely subscribe, because that has a very rich information source for information that Sproutcore.com has this. Then we have guides on Sproutcore.com. And then we have guides on Sproutcore 2.0.com. So that is for 2.0. So there you will have step-by-step instructions to build a sample to-dos app with all the features, with all bindings, controller, model, everything is there. So you have a step-by-step description. So you can visit these sites, guides, actually, to build that. Then wikis.sproutcore.com has a lot of resources. But when you visit it, you will see it marked as deprecated, because the push is towards 2.0. But the key concepts remain the same. So there's a lot of learning which can be done from there. So Backbone, I would say it's similar. I would say it's similar. But there's a lot of paradigms are really cool, like bindings and all. So if you look at Backbone, Backbone.js, if you have to establish the binding, you have to do a lot of work. But here, it's really super easy to establish the binding. And it's very fast also. If you try, then only you will know. So look-wise, modular-wise, it is similar to Backbone.js. And Sproutcore 2, actually Sproutcore 1.x has a lot of APIs. Like it has complete stack for view. So if you are building a desktop client, you will actually, if you use that, that will be a great help to you. Backbone.js doesn't have it. So there is, if you have any, I'm saying, if you want to live chat with people, there's a lot of Sproutcore developers which are there on FreeNode IRC channel of Sproutcore. And there's a lot of videos on Vimeo.com. So if you have any questions. OK, so Cappuccino also works in the same model. But if you want to use Cappuccino, you will have to also learn a language called Objective J, which is an abstraction on top of JavaScript. And as I told earlier also, they have taken even the code syntax from Coco. So that makes it very cryptic. So paradigms more or less same. But here, when you are dealing with JavaScript, you are actually dealing with pure HTML JavaScript CSS, which actually we understand. We understand what it is. But when you go to know something new language, it will have its own problem. So yeah, so it's an open source. And it's free to use. You can use it. So they have a company, they charge and support and all. They have other actually stack also. But SproutCode is completely free. And it's open to community also. If you want to contribute, you can contribute it. There's a lot of actually code on GitHub also. Sample code, a lot of demos, a lot of things are there. You'll have to just find it. So as of now, jQuery can be used. And so CoffeeScript is actually, yeah, so it can be used. Yeah. OK, so thank you. So if you have any other question, you can send me a mail. And this is my Twitter handle, so if you want to tweet. OK, thank you.