 So the title of the stock is Ajax's history and there is a byline which has been in real-time apps in JavaScript but there is also a very controversial and controversial title Ajax's history. Now the reason for that is that JSFOO happens to be a democracy and once I submit my proposal I make sure that it gets voted. So I have to you know have these kind of stupid tricks in games where I don't have to have high-catchy titles. I have to make a few other promises and it happens, it works. If I make these promises my proposal gets voted. So yeah, I have this chance to speak and so I just have this title slide up again and now how many of you were here for Kaushik's presentation after lunch? Okay, so that's like around 40-45 percent, which is great So a lot of what he said is going to be covered again but what I'll do is I'll try to not get into the you know, mucky details of it I'll try to give an overall picture of what I think is happening with web application development and I have this theory which I'll present a little bit and then there'll be some demos and then an open discussion and a Q&A session. So let's just have a quick look at the story of the web. In the beginning websites were nothing more than one-on-one mappings with file systems. I had a server which exposed a folder and that folder had a static HTML or text file, the binary files and in my browser, I used to visit a website which used to just list that directory out to me or I could, you know, select a particular HTML and that would be my website. Of course thus we had HTML files which could link to other HTML files and and thus there was a concept of a browser from web as as the user went from one location to another and then at some point of time there were smart programmers who, you know, discovered that HTML content doesn't have to be static. It can be dynamic. So there were server-side applications that used to create content on the fly and these server-side applications had access to databases, they had access to file systems and other services on the server so you also had various concepts of sessions and redirects and stuff. So basically you had everything in place which allowed you to build complex web applications and much of that is still around. But if you really think about it, this paradigm of web applications was still the same. You had a user who used to go to one location, then used to click a link or submit a form and then go to some other location. So it's still the same paradigm and then somewhere down the line Ajax happened and everybody knows or let me put it this way. Now Gmail wasn't the first Ajax application out there but it definitely was a flag bearer, at least for me personally. The first time I learned of Ajax was when I used Gmail. So what did Gmail do? It had that funny, funny feel to it. It didn't feel like a real website when I was first using it. They inboxed a red tab, used to just update on its own or if I wanted to open a mail in a new window that used to not happen. It used to just open there and I couldn't get a new tab, a new window open. And basically what Gmail did was it pioneered the use of asynchronous JavaScript in a fully production consumer driven application. And you basically had very rich client application. You had various attempts at frameworks such as Flix or Silverlight which was basically the same thing. It was not JavaScript but it was like running on top of a plug-in. But again it was asynchronous running on the client. And then on the server you had RESTful API and SOAP services. And that was the paradigm. Now is this a real shift from the way we've been making web applications? Probably, but I'd say still it's still the same paradigm where you have one request being created by the client and your server is responsible to create a response for that one particular request. And that response goes to just that one client. Nothing is changed. Okay, so a user is not triggering an action or maybe he is. But still, the response is getting created for one client. And this is a JPEG or a JPEG that is stored on the internet so credit to whoever first created it. And this shows how typically JPEG's web application would work. Of course, XML isn't mandatory, it can be JSON or text or whatever. But yeah, so the paradigm as I would put forward still says the same. And now here comes the part that I first introduced to you. I think there is a real evolution that's going to happen in web applications. It's going to be very different from what we have been doing so far. And what is that evolution going to be? I don't know. So it can be something completely unique, like out there. So what did Goship talk about? What has been the buzz around Node.js? It's basically been real time applications. It's been web sockets or Ajax long coding or whatever I think or flash sockets or whatever comic technique you want to use. The idea is that the server would contain or the server would create a permanent channel with every client. It's permanent, which means that the server can push anytime it wants. Second, no longer does the response from the server be dependent on a user action. What does that mean? It means that the server is no longer dependent on a user action to send some data back to the client. Which means that okay, it can still work with the user action. So let's say I click on a button and the socket sends me some data. That can still happen. But what can also happen is that the server can read something on some third party API, maybe the Twitter stream, and then decide to push something to a client. Or maybe there's a front running on the server or there's some third party app running somewhere and the server can actually really decide if it has to push data to the server. This is a huge, huge change from what we have been doing so far. Finally, now this is where things get really interesting. The server not only has a channel with each client, but the server can identify each client. It knows that this channel is for Amit. It knows that this channel is for Raji. It knows exactly which client it's talking to. And which means it gives us the application creators this capability to stream data to either one particular client or all clients or a select group of clients. So you can create some very nice logic and very nice interesting business cases around it. So what I'll do is now I'll quickly demo this application that I've been building. And after the demo, I'll quickly show you another small demo after which we'll get into the code. And then we can just open it up for Q&A. Alright, so I'll start with the demo first. Let me get my browser up. And like if you have your laptops on, you can just try this out yourself. So the URL would be review19.com. Let me see if I'm connected. Give me a second. Okay, so I can just take a quick poll. How many of you have been web programming on the web? You've been creating web applications for the past two years. Alright, almost everybody. Five years. Alright, even more. Let's say ten years. Alright, same hands again. Let me just take a wild shot. Maybe fifteen, twenty years. Alright, there's a hand there. So I have no idea what the web was back then. So you can just ask me for a second. But yeah, let me see if I can get it back up. Alright, so the URL is review19.com. It is yet another project collaboration demo. So sorry for creating yet another similar software into Google. Okay, but definitely it was. What I'll do is I'll try to simulate. So what I'll do is I'll try to simulate two users using this application. Let me just get my phone board up. I'll log in as myself over here. And I will need somebody to volunteer their email address so that I can sign up and log in as on their behalf through this. So any email address? Quick point. Kiran? Kiran at ASCII.com. Kiran? At ASCII.com. Password 123, use 123. Okay. Okay, so Kiran's user account has been created. Let me just log in. This window is me. And this window is Kiran. Now what I'll do is I'll have Kiran create a project. Let's say the project is JS for Chennai. So I have a project created here. And let's say Kiran wants to add me to the team. So let's say he wants to add me. So he's adding a new team member. Watch this space closely now. Watch this space closely as Kiran at the new team member. The project shows up. Completely real-time, the server just decided to push it to me. Why? Because I'm part of history. So let me enter this project. And let me go to the board as Kiran. And let's say Kiran wants to add a new show. It is invite some speakers. And he does this. He creates this. Again, it shows up for more. So what's happening here? Every time Kiran is taking some action or every time I take some action, what happens is the action gets relayed to all the team members. So if you go back to this presentation, this is what's happening. So my application is logically deciding what the team members are. And it's pushing selectively to them. So this is how deep this sync is. So let me go here. And let me just table this part again. So it's updated over there. Now this happens for every field. So it shows up. It shows up. It shows up. Again, if I add the task. And this is basically what Bosch spoke about. And this is basically what this application implements. It's real-time. It's using the same socket IO abstraction. Underneath various transports can do the thing we don't care because I'm a product developer. At this point, I don't want to think about what's happening underneath. I want to just talk about functionality. So here's what we have. We have the capability to push selectively or to everyone. So this is something that server-side applications didn't have so far. Now let me just demo some more stuff that this application can do. So you can basically track things around and it gets reflected. Straight forward, very simple. And the code is also very simple. I actually built this application around November or December last year. And I've been a long-time programmer. And for all long-time programmers, we don't know JavaScript very well. If you've been working for more than 8, 9, 10 years, you probably learned JavaScript when it was something else. And then you had to re-learn JavaScript. So I shouldn't be doing this, but if I just show you the code, you probably want to laugh at me and want to throw shoes at me. This is what the code actually looks like. You can't see it. But yeah, so it was horrible code. And I wanted to, of course, refactor it. I also wanted to do things. I knew that I cannot build a product in this market. But I really liked what I did. So what should I do? I like the technology. So what I wanted to do was I wanted to extract out a framework or a platform upon which you can build various vertical apps. And those vertical apps will have the same real-time capabilities that this single app has. So let me just show you that. Before I show you the code, I'll just run that refactor version of the application. That's still work-in-progress. So I don't know how much sense it will make, but I think it's just best to show you. So the stack is fairly simple if you're interested. I start my Mongo instance. Let me find... Let me zoom in. Sorry? This is not interesting. So there are seats here if you want to come and really watch something that's not interesting. So what I've done is I've just started my server and my app. Now what I actually want to do is demo the app itself. It should be the code that it's running on. So I have the application running on my local server. And now the project management module is still there. And this is basically the same thing. It still does the same thing. The same thing that we saw. But we also have another module out there which is a decision-making module. It is loosely based on SAP Streamer. And let me just take a preview. So this will let families or businesses or teams decide on certain decisions during the time. And they can be distributed around the world and it lets them do that. So it lets them do that through allowing them to share their opinions, have goals, have a pros and cons list, have scoreboard and so on. What I will not do is market my product. So I'll just turn it off. And I'll take you to the code. So what I want to show you in the code is how the application which was once just a single application is now a platform and lets you do some interesting things. Now this is a typical express token IY. Now what do you expect in my app.js? In any case, this is the number. So now you are seeing the file structure again. This is a typical socket IY express app. So what do you expect in my app.js file? It's okay. Alright. The standard stuff. Basically the standard stuff. I am requiring express. I am requiring socket IY. I am defining my route somewhere and I am doing a bunch of other config stuff. And something interesting. I have defined the modules. Is the font too small? Yes. I don't know what will be the setting right now. So would you mind coming forward with the if you really have interest in it. Or I can just figure it out. Give me a sec. There are empty seats in front. Can't see it even from here. I'll just try again. I'll just take the font. Everybody can't see the seats. The many seats. That's much better. So Right. So we have a pretty typical a typical express socket IY application except the concept of modules is being introduced. I am keeping it extremely simple at the moment. I just have an array for all the module names that I want to include. So where are these modules as such? Let me just walk you through my code. So here's what I have. For every module I've got a package. Or in JavaScript I've got a folder. And every module internally has a model file and a software file. I'm trying to keep the application as very simple. So it just has two modules. A model and a software. So as you would guess the model talks to the database and exposes an API that you want to use. And software basically exposes events or trigger events with the client. So let me... Now, what's important is that every module also has a client side aspect to it. So where does that go? That goes pretty much over here. So oops, not strategy. So here's my projects module on the server. Here's my projects module on the client. And it's, you know, the typical common JS AMD module. So that's what I've done over here on the client. And again, the API is defined as required. And a bunch of things happen. Now, here's the cool part. Every module will work independently and doesn't have to have any dependencies outside it. And there is a bunch of glue port that ties all these modules and creates one single app out of it. So if you're interested, I can walk you through this glue as well. So we already have an app for our modules. What do I need to do? Any socket IO users over here? Okay, so what do you want to do if you have modules? What would your modules be? You want basically socket events enabled, but you want to distribute them across logical business units. So let's call those units modules. Let's say you have a project management software and you have a user management and you don't want to mix up those two. Don't keep them as separate as possible. So we have different events. So we'll designate one set of events for users and other set of events. Exactly. So going by what he described, the events for users is defined in sockets to JS that belongs to users. And the events for projects is defined over here in socket, the JS for projects. And we have this little glue in my app.js which basically hydrates through each module available and includes it. That's about it. Now I'm expecting the sockets file to expose an initialized method. And it does that in which whatever module-specific things have to happen. So this is the way the app is laid out. It's pretty simple, but to be very honest, it's nothing fancy, except that it wasn't done before. I hadn't seen any example of it being done before. Now, of course, there may be a few frameworks out there that do it. But when I started on this, there was nothing, so I had to just tie some glue and break my code into what was done. So what I want to do now is I want to just have an open discussion if possible. And what I want you guys to focus on is either you can ask me questions on what I've shared so far. Or what I want to stress on is what do you think? Do you really think that these kind of applications is a new evolutionary step? Is it something forward? Is it something very different from what we used to do? If yes, why? If not, why not? And if yes, what would you do with such kind of power? So it's just an open mic now and anybody wants to take this. 10 minutes. 10 minutes? Alright, so there's lots more that I can show you if you're interested. What is done, actually? What you just said. You said the server knows it and it pushes the chain immediately. So how would this activate? You showed a lot of lines. I think it's what, actually. So I'll just try and explain that. When I click Submit, what would happen in an application? The change is submitted to the server. A request is created and whatever I fill in in these fields is part of that request and a get or a post is made on the server. And what happens on the server once it gets this request, if there is an update on the database, it will now have something that has to be done and it will see only from the client. And it creates a response. And it creates a response. Now what happens is, or pretty much the same, depends how you as a programmer would be using. What happens in socket IO is socket IO is just an abstraction. So when I say socket IO, I obviously mean everything else. But what happens in socket IO is when I click here, I as a client-side programmer can image an event. That event can be, say, create a new ticket. The server will receive that event. Or if I have a programmer application, such that some other client wants to receive the event, it can. So every server or every client can decide which all event wants to listen into. How does that happen? So just watch this code here. This is the event handler when a project creates an event This particular server-side module has decided to listen into that. So it says socket.on when it is this event, do whatever you want. Now, something very funny can happen. Let's take the example of ticket creator. Once it is created the ticket, the server then wants to decide what it should do next. It doesn't have a response to say. It can do whatever it likes. It can do nothing. It can create every client or it can implement specific client or it can trigger some third party servers. You have this power right now. So let's say here, in my case what happens is the server also after creating the ticket decides to trigger an event. Now that event is captured by a client. Let me just show it up for you. Where are we saying that this method has to listen to the new event triggered by the server? Let's take it specifically when this event is triggered by any other client or the server to do this. Now, this register socket event is again some kind of clue that is specific to my framework. It is not socket IO stuff. So I just avoid it. So what happens if you follow the trade, if you follow the trade of register socket event you will find somewhere my object saying that on this event you have to do this. So that's what it is. And it's kind of very liberating. You can create whatever you like. There is no forced paradigm where you have to create a response for one request. This is where a lot of creative things will happen I believe. And hopefully this is just one force. One instance or one process. But if you can scale it horizontally it's not enough. It's the limitation. I don't know the talking part. I'm not asking you to do this but in terms of current BUS objects versus this which one scales better? Could you repeat the question? The question that he is asking is if he built this application with Ajax or if he builds it with WebSocket which would scale better. Why don't you try and answer that? What do you think happens in the case of Ajax? An entire HTTP request is created. An entire HTTP response is created. And if you have to relate to let's say I have 10 team members I have to create 10 responses. Now HTTP responses are quite large. In this case I'm just going to send the data that was passed. Nothing is old in server right? Old Ajax. Nothing is old in server. WebSocket holds something in server right? Push it. In Ajax you don't hold anything in server right? WebSocket needs to hold something in server right? To push it to the client. In Ajax you don't keep a full of requests. There's no like this 10 designing ID or memory you're getting and nothing else. WebSocket needs to ask something like why is it right? There can be 10 C. 20 of 10 C. I have a versus team channel open but it makes it to every client. And that would model an history of no test that is if it's plenty of clients going to access the server, how much it's going to open in the parallel way? There is no limit because you can scale horizontally you can have as many as you want. That's the question whether it's better in Ajax or better in WebSocket. This thing you think Ajax can't do. So there is actually no interest that you can see. Diode faces looking down. Any other questions, any other thoughts? Thank you very much. We are free to go now.