 Sorry for this technical talk. I was hoping this would be more fun, but then that's what I can come up on a short notice. So we're going to discuss how we are really developing JavaScript web applications in today's world and what can be done to resolve that. So new apologies to all the Rakhisavant fans. This is how we are doing JavaScript development. Looks hot on the surface, jQuery and all that. All that animations and all that effects and all live validations, but not really maintainable. You know, it's like, and what you'd want to really do is have this as your web development workflow. People may not be interested that much on the first look, but then it's really maintainable and saleable and you know, works well for the long term. So this is straightly, you know, picked up from Zaka stock. This is how you should be doing JavaScript applications. It's based on a module theory wherein everything that you want to do is a module. Everything is defined into single responsibility, object or module wherein you can just describe the module without using and or or. You know, so everything like your login, your login view, your login model, your, you know, any model, any view, any controllers, any routes should be a module, which is the modules that you can see in yellow. And there is an application core. There is a sandbox, there is a base library. Base library is your jQuery or dojo or YUI, whatever you prefer to use. There is your application core. We'll talk about that in a minute. And there is a sandbox. So the theory is that each module doesn't know about other modules. The modules are very loosely coupled. None of them talks to each other. They are cleanly separated. And there is no communication directly between modules. That's first thing that has to be understood. Second, each module is a single responsibility module. So if it does handle more than one concern, it's you're doing it wrong. It should only handle one concern and that also improves your testability of the code. So one concern per module, and all the communication that happens between modules is through a common sandbox that's available to the module. So only sandbox knows that there are other modules. No module of your app knows that there are other modules. So advantage of this approach would be that if a module fails, the rest of your app is still working. That is one advantage. Then the sandbox only knows about application core and modules. The modules do not know about application core. So if you want something to happen on an application level, that is not directly accessible by modules. Modules, how to notify that to your sandbox and sandbox in turn, will notify that to your application core and that decision will be taken by application core. So application core acts as a mediator and separator of concerns. Whatever you want to do on an application level should be forwarded to application core. Sandbox acts as a facade. So I'm talking about using design patterns over here. Sandbox acts as a facade, which is exposing application core on an API level, not really exposing all the details of application core. And application core in turn just works as a loader and offloader of modules. So no module is loaded on its own. The application core decides, depending on the context of environment, which module to load and which to offload. And base library is separated from your application core. So that you can hotswap your base library any time. Say for example, you're using jQuery, Ajax and you now want to use web sockets for communication or for that matter, any other communication technology, you should be able to hotswap it without actually changing your modules. So no module should have direct references as far as possible to important components of your base library. So that's on some sort of scalable architecture. I think that's it, if you have any questions. I don't think we have time for questions.