 Okay. Good morning. All right. People are awake. Good to hear that. Am I audible to everyone? Can you? Everyone see the screen, especially on the sides? So Google just called me last week and said, oh, there's an awesome thing happening in Bangalore. Can you get here? So threw this up in a jiffy. I am not going to be doing too many hands-on, a lot of code. We're going to be doing a lot of that. There's a hands-on workshop at the end of the day. I'm going to be focusing more on the story of why we developed AngularJS, what were some of the major thoughts and ideas behind it, touch up a little bit upon the major features that differentiate Angular from the rest of the frameworks out there, and then end with some basic thoughts and ideas that differ and ways you should be thinking when you're working with AngularJS. So that's kind of the agenda for this talk. Any time, if you have any questions, feel free to stop me, ask me, otherwise we'll spend some time at the end. Should be about 25, 30 minutes. Maybe quicker, maybe six. So should we get started? So for my start there, so that at least you know whether I should be talking on this, not talking on this, all that. So I used to work at Google back from 2007 to 2011. I was a software engineer there. Worked on a whole bunch of different projects before finally the last one, one and a half years is where I was working on something called Google Feedback. Google Feedback, I don't know if you've seen it, is that small little send feedback link you might see at the bottom of some Google products. Takes a screenshot, sends some feedback. And as part of that, when we were developing the UI to use internally, consumed those, and we'll touch a little bit upon that, we were developing AngularJS, and that's found out how I got involved. We were the first users, we contributed a lot to the initial AngularJS framework, and it went on from there. Left Google in 2011, came back to India and said, okay, I want to do something completely different. Ended up doing my MBA from the Indian School of Business in Hyderabad. One year program after that I decided I didn't want to be in business and came back to technology. I was working on solutions in 2012. Been working on my own products, a little bit of consulting and education on the side. During ISP also worked with grad on writing the book for AngularJS on with Coro Riley. That was a time when the docs were really, really bad, that has significantly improved now. So getting started with Angular has never been easier. And I do AngularJS workshops and trainings for corporates on the side of the enthusiasm, playing around, just trying out all kinds of stuff. So at Fundo we work on a heavily JavaScript staff. So by that front end is JavaScript, HTML, AngularJS, back end is NodeJS, MongoDB, all those kinds of things. So JavaScript, love it after adding it initially. So before we touch upon AngularJS and what makes it so awesome, I want to touch a little bit upon how it got started, what were some of the key drivers for AngularJS. So the AngularJS project really started in 2009, end of 2009, and we were working on Google Feedback and we were using something called Google Web Toolkit. How many here have used it or are familiar with it? So for those of you who have not heard of it, Google Web Toolkit was the promise that you write your entire application in Java, back end, front end. And GWT would take that Java, compile it down to HTML and JavaScript to make it really Ajax app. So you get the best of both worlds, you get type safety and Java and goodness, while you also get an Ajax app. So we were using that, and what we realized over six or nine months that we worked on it, that it's a great talk and principle, but in action it's a disaster. And our velocity and our product improvements really slowed down over time. And at that point we were evaluating what the heck do we do? Do we just go through it, battle it out, fight it and fight the good fight, or do we try something else? We were looking at flex, Ruby, Python, all these other things, and we saw that we liked a little bit of everything from everything. But nothing really had a concrete story. At that point, Mishko, our team went off for a month's vacation and said, oh, I'm gonna go learn JavaScript. And he goes off for a month and comes back saying, oh, now I've learned JavaScript and the best way to learn JavaScript is to write framework in it. So here's something I've developed in my spare time. I'm gonna call it Angular and we should totally use it for this production-ready project. Yeah, now Mishko. So that was our reaction. This is crazy. We had no idea whether it would scale or it would work. But then Mishko made a very bold claim. He said, what we took six to eight months to develop, he could redevelop it in AngularJS in three weeks' time. And that was a very bold claim. And, of course, our reaction was laughing him out, that's crazy, that's not going to happen. But what we did was say, okay, Mishko, you're not gonna let it go, so go off, prove it. Take three weeks, redevelop the entire thing and if you're done, we'll talk. Let's see where it goes. So he goes off for three weeks. Doesn't come back in three weeks. But after four weeks comes back with something that is 80-90% complete and... And at that point we said, huh, there might just be something to this craziness. And that's really where it started. We decided, okay, maybe there's something good and we started investing heavily. And so Google Feedback became the first AngularJS project in that sense. So how many of you here are familiar with AngularJS? Use that in your project, at least, or try it out. Okay, what about the others? Familiar with it? Kind of? Yup. So what is AngularJS? It is an open-source JavaScript framework. Anybody can look at the source code, do whatever you want, but it's pure JavaScript. There's no additional language or anything you need to learn. It is declarative. And this is one of the key philosophies behind Angular, that it is very declarative in nature. It leverages and uses HTML. You should be able to look at the code and figure out what it is you're trying to do. You should not have to dig in and use control app to figure out what part of your application triggers one. Looking and reading your code should be extremely simple. And it's not really an MVC framework. It's more of a model view view whatever framework. But it helps to think of it in an MVC framework. So there's a clear separation between your model, your JSON or whatever structure you use to represent your data, your views which are traditionally HTML, and the controller which is the business logic which decides what to do, how to interact, how to engage with the user. So there's a clear separation and this is extremely critical, especially when you're working with JavaScript. And it extends HTML. It's not trying to create something new, but what it's trying to do is teach the browser new tricks. The HTML spec has been there for years and it's almost not changed in 1995. You still have the basic input tag, bills, tables. But the new age web apps need a lot more. Date figures, slider, graphs. And these are things that HTML has no concept of awareness about. So Angular says let's take this and extend it by teaching HTML how to do these new things that you do need. And it's extension friendly as well. So in addition to extending HTML, you don't want to spend time redeveloping every single UI component or widget or library. There are some great libraries out there. You like with a bootstrap, maybe even J20 UI, high charts, fusion charts. These are great libraries and you should be able to use it and extend it inside of Angular. So Angular has this concept called directives, which allow you to take existing components and make them AngularJS friendly and make them declarative. And you'll see what that means in a bit. And most of all, it has a brilliant community. There are some great experts out there and it's a very vibrant active community. You have any problem? Put it on Stack Overflow. There's a Google forum. Twitter is awash with people responding to AngularJS queries. So it's a great time to be out there. If you have any issues, you're not going to be stuck for long. And all in all, that leads to an amazing framework to create awesome AngularJS applications, web apps, at the speed of light. The whole aim in Angular is to write less code so that you do more. So to go back to 2009, when Mishko had gone off on his promise and came back, he had promised a reduction in the lines of code. It's going to be so easy and fast in this amazing new framework. Now, everyone won't see this, but because we went from Java to JavaScript, the lines of code that we had when we re-implemented our entire project came down from 20,000 lines of code to 1,500. And that includes both templating and controller and business logic and styling. That was an insane reduction. Even if you move from pure JavaScript to Angular or some other framework to Angular, you are going to see a substantial benefit. And less lines of code is always good, who wants to maintain more code. The other thing was the faster development. I mean, since you're in JavaScript and HTML, all you have to do to try out the new feature, write the code, just refresh it in your browser, you're up and running. So the development cycle is significant in these speeds up. So coming from a heavily server-side templating platform, you're going to see improvements in your developer efficiency when you start moving to Angular. But the most significant thing, and this I won't stress enough, is the testability and maintainability. JavaScript, by nature, is heavily global-state friendly. You write these functions that are accessible from anywhere, and all of these interlinked, there's no way to maintain your dependencies, the order in which files load. And so it just is a pain to test. And Angular started with the focus on test-driven development. The whole aim that you should be able to write your unit test even before you write a single line of code. And so we developed Karma, and recently protracted, to make sure that testing in AngularJS is as easy as development. You can write these tests really fast. And these run even faster. So our development cycle, usually at least that fun, is we run all our unit tests every time we hit save in WebStorm, which is the IDE we use. And these execute so fast that they basically act as your compiler. Any typos you make, any changes to business logic that is against the flow, you immediately know the minute you hit save. And you can do that with Angular. Templating styling? Yes, it's pure HTML. It's beautiful to just be able to split apart your business logic and your functionality away from the template. You can take an HTML snippet, hand it off to your designers and say, okay, go make this look pretty. But I focus on the functionality of getting the data, putting it in there. You can easily separate out these two and work much more efficiently. And of course, integrate with other libraries. We didn't want to reinvent the wheel. Use the existing charts, use the existing date figures, or whatever you want. So the concept of directives, which gives you a clean way of wrapping these components in an AngularJS friendly manner at the same time making it declarative. So here's a quick slide that actually compares the lines of code that you would need to implement a simple to-do app across different frameworks. And on the extreme right, you have the pure JavaScript, Dojo, MVC, Ember kind of platform. And Angular, if you see the third one out there. So that's the kind of difference in spectrum across different frameworks. For the same app. So you're not comparing oranges to apples, you're comparing the same app. That's the difference. Less code, more focus on your functionality. Get rid of that crap boilerplate that you shouldn't be writing and focus on what you need to do. So as a developer, you're working with JavaScript, HTML and data binding. That is key. The amount of code you end up reducing and removing because of this concept of data binding. Data binding is the way of basically in your HTML, you state this place or this particular div or span gets its content from some JavaScript object. And then Angular takes care of keeping that up to date. You'll see some examples. Angular is the only framework which has a dependency injection system so allows you to state and maintain your dependencies. Figure out the order in which things should load makes it explicit what is needed to get a particular controller or a service to her. It's beautiful, especially if you're coming from Java, it's like home. Custom components, I've talked about this a little bit. Brilliant testing story and an amazing community. So an AngularJS app, you write insanely less code to get your work done. You focus on your code, not the crap. No boilerplate, no figuring out how do you get the data from your server into the UI, how do you get the data that the user has entered back to the server. You focus on the business logic, the validations, what data to send rather than how to funnel it back and forth. It's more maintainable, extensible, less code, more structured, more modular code, much easier to maintain. And component-friendly, you can easily create modules that you can use across projects. Once you have a stable set, the next project is just that much more easier. Well tested, robust, and you should be doing that too. And it's designer-friendly. HTML is great for templating and that's what it should be useful. And to use it, there are no server requirements. You don't need a Java server or Ruby or Python. Whatever you have, works great with it. If it talks JSON, even better. Even if it doesn't, if it talks XML, so it's pretty easy to integrate. So there are no dependencies saying oh, because I use this server or Tomcat or whatever, I can't use it. There's no such requirement. And it works seamlessly, even if you don't have a server. It's great for prototyping. And I'm assuming that all the future talks will talk a lot more detail about this, but starting an AngularJS project is trivial. You include the AngularJS source code and just mark out a section of your HTML that says this is an AngularJS application. And that's basically all that's required. After that, it's your code. If Angular gets out of the way and lets you focus on what you need to do. And this app also demonstrates data binding. So this is basically is this visible? So this basically has an input field backed by an Angular model called your name and displays or binds to your name saying hello there. So without any other JavaScript file, you basically have something that keeps the UI up to date as you type. The textbox is bound for AngularJS model as is the span below it. So when one changes, Angular takes care of updating whatever else depends on it. Magic, beautiful. And so, who's using Angular? Google, of course. A lot of projects. There are some great talks on how to build large scale projects. Double click for advertisers is one of the biggest ones that we know about. YouTube uses it for some certain projects like Leanback. Amazon's web console AWS functions are using AngularJS Netflix, lots of banks are now moving to AngularJS as well and a whole bunch of starters. And where they're going is making this faster better, so change detection integrating with the new ECMAScript standards, web components all these grand things that are planned for HTML Angular plans to integrate in a much nicer way. Logging, better data persistence so handling offline, sockets all of those will be coming in-built in the future with Angular 2.0. What have I personally used Angular for? It's amazing for prototyping. Taking an app, showing how it would click flow together, laying out the skeleton and saying this is how I expect the flow to happen. Beautiful, simple HTML simple JavaScript and really, really powerful. Also used it to develop some EPG applications, program guides something that shows a listing of channels having a live video player all these kinds of things mail applications similar to Gmail wedding and photography that was something we recently worked on as fun loop. E-commerce analytics, there's really no specific type of application that says oh this is what you could be using Angular for I've seen multiplayer online games using Canvas using AngularJS so there's no right or wrong project when it comes to choosing AngularJS it just seems to work all the places. So next I would like to switch from the features to more talking about what are the conceptual or thinking shifts you need when you work with AngularJS and these are quite profound because if you Angular is quite opinionated it says do it this way and life will be good don't do this way you're just gonna hate everything so there are some certain thinking paradigms that work in AngularJS and so there are many many best practices and all that but some really basic key ones that will make your life easier and just make it much more easier in the easy run early run and the first and foremost is that any AngularJS application is data-driven the model is the truth the data is the truth and that is what drives your entire UI so by model I mean simple JSON some data whatever might be coming from the server you might have some locally and you have a controller that takes that manipulates it formats it decides what parts to show and gets it to the UI which is the view the user sees it consumes it interacts with it and now when you need to make a change because the user has done something or because you've got newer data from the server the traditional approach is you try to find that particular UI element and change it that's what jQuery does that's what a lot of other people whereas in Angular the whole approach is that you update the model you change the data the UI should always be a reflection or because of a change in the data the UI should update itself automatically and that is a key thinking shift you should not be aiming to manipulate the UI but to change the data so to give you an example this is how your tasks would normally look if you're using jQuery or any bootstrap you'll have a bunch of URLs and allies you'll have the actual deals with the content and it is your responsibility to make sure the right tab is highlighted you select the right tab, you unselect the other tab, you show the right content you hide the other content there's a lot of business logic that happens you use it across multiple pages you have some JavaScript that triggers and watches and does all of these in AngularJS if you were to do the same thing it would shift substantially to something like this so the ng class the ng shows are what Angular calls directives it basically tells the html that it needs to do something so here it says oh show the content of tab 1 if tab 1 is selected show the content of tab 2 if tab 2 is selected the ng class says apply the class selected to this tab if tab 1 is selected again same question and it's all driven by the data the advantage of this is now if I want to switch tabs all I have to do is set the value of current tab to the new tab Angular would say oh current tab has changed let me figure out what in the UI needs to change so oh now this is unselected this is selected this is shown this is unshown all of that just be careful so a single line of code would make the UI completely up to date you never reach out from the controller into the view you change the data and that is a fundamental shift of course the better way to do tabs in Angular would be to write your own directive and you can write your own directors to tell Angular that in your html I really want to declare it saying I have a bunch of tabs as a title as a content even the business logic gets encapsulated inside these components and you can do that extremely easily the second major thing is that you should leverage data binding data binding is one of the most powerful concepts of Angular so again a traditional form application you have an input bunch of inputs and a button say you get some username and email from the server you can find these input fields fill in the value the user types in something you can get these values sent into the server so you have these getters setters all these kinds of things the angry way is to again make it declarator saying this input is backed by a model which is user.name user.email so ngmodel is a directive which tells that so now in my controller I can find the data that comes from the server to the user variable that automatically updates the UI I need to get the latest value from the UI I just refer to scope.user I just take it and pass it along no need to reach out into the view and that's the clear separation saying there's a view and the controller the controller never reaches out into the view is DOM manipulation a lot of people do it I used to do that as well you come in and you say there's a jQuery date picker or a slider that I want to use in my project so in my controller I start doing stuff like find that particular ID make it a date picker and you start doing these things in your controller and that is a fundamental known the controllers are never supposed to reach out into the view the angular way is again create a directive create a component that wraps this functionality so that my HTML can be declarative I should be able to look at the HTML saying this input is a date picker it's not a magical input type text that suddenly becomes a date picker it's a date picker that has a date format on select so it's very declarative it's contained and the advantage of this approach is anybody can easily use it to know or understand javascript or jQuery UI I might at some later point decide that I don't want jQuery UI I might want to switch to bootstrap so you have these components that you can switch the underneath without affecting the implementation so again modularization componentization is simple and you should be doing it fourth, someone somewhere must have said this but test early, test often, keep testing you're in javascript there is no compiler there is nothing that will tell you WebStorm has made life much easier if you're not using an IDE do use one but still there is a significant lack of a compiler and you don't want to wait until you open your application in the browser to figure out you have error you want it caught up front so that you can focus more time on productive stuff and you want to prevent reflections you're not writing these toy apps you're writing significant production level applications and these are going to go big complex so you want to catch them early and make sure that in the future no one violates a fundamental assumption of your project so you have this safety net of tests and you want to keep adding to it as much as possible of course this zen like point is when you can get to a point where you can guarantee that your application works and you can push it out immediately and with unit tests and protractor to write these end-to-end tests this is possible to handle you can get to a point where you can release a product within the day of finishing your application most importantly who here writes code for their comments comments, code sorry comments for your code how many of you keep it up to date exactly comments have a really bad habit if they're first written of course not many people write them but if they're written they have a horrible habit of getting out of date and so tests act as your specification and because they break when you change it you are forced to keep it up to date and AngularJS tests are written using Karna which uses jasmine which is a spec style of programming which basically gives you like a specification document for your application says oh my controller should do this, this, this and this this is how it should operate so it acts as a living briefing documentation for how your application should work what are the edge cases, when should it break all these kinds of things so great habit to write tests and the workshop should hopefully cover a lot of this the last most important thing is the separation there is a separation between your view and your code separation between your business logic and your presentation logic so Angular has this concept of services which are for business logic across your application how should I fetch data, where should I fetch it from how should I validate certain things which are independent of any particular UI now you do have presentation logic how should this be formatted which parts of this data do I show to the user, how do I respond to user clicks and these are the kinds of functions that go in your controllers so having that separation of business logic and controls again is another step to getting to a beautiful maintainable application so that's all I have time for quick thing of what I usually do I have been involved with for some time and after the book I have started one we do conduct workshops for companies and corporates so if you are getting started you need to understand how to work we conduct a dedicated hands on workshop, we do development consulting and expert consulting with Angular as well so that's my Twitter handle you can get in touch with me at www.sham.defundu.com so any questions yes so the so used it with a Java back in actually the GWT application transition from that used it with Python as well seems to play pretty well so is there any particular completely independent so the thing is Grunts are just build tools so all you need to deploy an AngularJS project is the HTML and JavaScript you put it in the right place and serve it you don't need any additional build tools but there is a little bit of Angular in there it got out there I have written shell scripts there are lots of like Grunts is just another AMP so you can use AMP as well I don't think anyone has done it but it's pretty straightforward and we can chat if you have particular concerns on how to yes I don't know whether it's fair to call it a workshop but so I have been working on Angular and really I'm not troubled with the whole data mining and the watchers especially the monsters and NGDP yes so I mean I didn't talk about it but generally speaking what are the best practices for like directives is definitely one of them where the scope gets captured but some of the there are definitely especially with NGDP see part of it is UI NGDP has some performance but when you get to 10,000 or thousands of thousands of rows there are multiple columns within that so one is does the UI need that much data do you want pagination or something like that the second is something called and a lot of it's there available in the open source community is the concept of bind ones see a lot of NGDP you're just trying to display data that will not change after you put in so there is a nice little hack which I think will be part of Angular 2.0 is the concept of bind one saying get the data out there then stop watching which tremendously improves performance so even for the electronic program guide that we have to do we had to display seven days of data cost 500 channels which if you use an NGDP is a disaster naive so then you start creating the directive to say look I don't want to overload the DOM to make a really responsive application you want to reduce the amount of DOM manipulation that happens so you have to do some performance optimization I don't know we can talk about it process where you manipulate the data on the course the data so does Angular provide any so Angular has a concept of filters which is one used for just display of data when you have emails or phone numbers or any dates for example you get a time stamp long time stamp you want to display them in a nice form so has this concept of filters you also have the concept of formatters for inputs like you said phone numbers and I want the dashes to be automatically added you can add these formatters to input widget so you can handle those as well the trick is to separate out the presentation from people's project so there is a tier separation we have to validate and we have to create our own management ok is there any right fit way of validating for any schema for a hash see that this is a structure that I expect these are the types that I want to put in the server you can let's talk offline about those that's what form management is for yes so there are multiple steps to doing it properly probably too much for an introduction talk nothing else thank you guys really useful for single page applications right is that like one of the main that is the main one because the whole point is you don't want a full page refresh like going from one page to the other there is really a smaller segment of the page so why get the entire HTML so there is a whole routing component that allows you to handle multiple pages without doing this page so that's a beauty that's in there it's best suited for single page apps it's almost I wouldn't develop a non-single page application I would not, I haven't found the use case to develop a non-single page application no it it's a URL that's not a good application no you would rewrite the URL so there is something called HTML5 mode which makes it look like a normal multi-page application again you're diving too much but if you want the full page reload and there is significant content changing then probably not a good idea because you're going to reload the entire controller and fetch the data and all so it's better suited for single page applications you can you can have just a small portion that's handled by you can especially if they use the similar data binding curlies and stuff like that templating whatever