 So a quick round of introductions. We're going to be talking about evolution of JavaScript frameworks. I think that's kind of in line with the topics that we've been talking about today, evolution versus revolution, and also the quirks about existing frameworks, et cetera. So let's see what we have for today. Before that, a quick round of introductions about ourselves. So this is Hari Krishnan, my colleague at Mavenhag. Over the past couple of years, over his career, he has built a lot of applications, most of which involved a significant amount of JavaScript in one form or another. He usually likes to talk about concurrency and performance and such serious stuff. But today, he's pairing with me on JS Talk, sparing you all the headache. And this is Dharampal. So for today, I thought this would be a better introduction for him. This particular book, it's his proud position. He claims that this was his second programming book that he bought. It's about JavaScript. It's 15 years old, by the way. And he's a big headphone aficionado. And this is his real collection of headphones. So let's talk about why we wanted to present about this topic today. Very quickly, it's like about two months ago, we were starting a new project. And we were contemplating which framework to start using. And as we already know, we have a plethora of frameworks to choose from. And we were completely flabbergasted at the choices. And we were going at what kind of frameworks were available five years before and eight years before and 10 years before when both of us started programming. It kind of gave us a very good insight into the evolution. And it was a good story to the entire timeline. As a developer, I always am interested in understanding the history and the context of things in which it is done so that I know where I'm going. So I thought that's a good story to share. And we put this presentation together. If that does not convince you, I thought we should put some Chinese props in here. This is a good one. Those who don't know history, I don't repeat it, which I guess might be happening right now. And another one that says, you can't know where you're going until you know where you've been. If that still doesn't convince you, we should probably definitely listen to Douglas Crockford. And in his talk, Crockford and JavaScript highly acclaimed. He says, understanding the context in which stuff happens is very, very important. If you haven't seen the stock, highly recommend it. Definitely watch it. It's a two-part series. OK, with that, before we start, this topic was presented in a different format. It was called Evolution of JavaScript in a different meetup. It went on for two hours, so we didn't want to do that here. We've kind of cut it short to JavaScript frameworks pertaining to web applications and tried to give context in that angle. And the categorizations that we've done are purely for ease of understanding the context. So don't go by exact dates and all that. So we are not professional historians. So quick show of hands. I know we're all users of Angular, Ember, and all that. How many of you have used CryptoKillers? Show of hands, please. OK, prototype? Dojo? GWT? DWR, anyone? OK, there's still one hand. That gives me some confidence this talk will be relevant. OK, so let's get started then. Right. So we all know the story of how JavaScript started in about two weeks. It was built in about two weeks at Netscape. The thing is, it was never really designed for building big applications. Or initially, at least, it wasn't designed for building big applications. You couldn't really design something that lasts in about two weeks. So the initial intention behind JavaScript was to enable web developers to build something like this. This is Apple HyperCard. What it is is a list of icons, widgets, just icons on a screen. And each icon, it had this little script, a little automation that runs when you click on the icon. That's pretty much it. And that was the intent for JavaScript. Netscape wanted the developers to be able to do something like that. And this is, again, a quote from the book that we showed earlier. This is a really old book, as I said. And one of the things that the author says is it's designed for simple, small programs. I know it's not visible to the back, so I'll just read it out. So he goes on to say it's well suited to implement simple, small programs. And goes on to give an example of what a program like that would be. For example, a unit conversion calculator between miles and kilometers or pounds and kilograms. And he goes on to say one more thing which is kind of interesting. Set programs can be easily written and executed at an acceptable speed using JavaScript. So the key thing to notice first thing, it wasn't designed for anything big. And it wasn't expected to perform. This is how JavaScript began its life. And this picture is, again, from the same book. It shows the kind of DOM API that developers back then had access to. So what it has is a document and a couple of very specific elements. So back then, on the document, there were these arrays of specific things. You had, for example, an array of forms. You had access to an array of images. You had access to an array of anchors. And even an array of plugins, but I have no idea what that was for. So under the form, you got access to a specific list of HTML elements again. And a typical enterprisey usage for something like this was, you'd use it to write form validations. Very simple form validations on the client side. And back then, it was usually to avoid an extra call to the server rather than from any thought about UX. So don't bother reading the code. I'm just gonna highlight the stuff that's relevant. So if you see, the form over there is being accessed using a hard-coded index. It forms of zero, find me the first form. And then we go over every element in the form. Check if it has a value. If not, gather whatever doesn't have a value. And then use an alert box to display the message. And the result of that would look something like this. So that's a page. That is showing an alert box telling you which form, which fields you haven't filled yet. I mean, that's an alert box. Horrible, right? But this was acceptable back then. This was the state of affairs. This is how we did things. And this is, again, not that far back also. I mean, this is around 2000s, 2001. And then on top of it, if you took all that effort to write your scripts, client-side validation, so whatever else that was, at the end of the day, you couldn't rely on functionality being provided by JavaScript. By default, browsers didn't necessarily enable scripts. And it was a fairly common thing to disable scripts. This screenshot is kind of a little recent. I mean, this is from IE seven or eight or something like that. But this was still the old dialogue was something similar. In the high security mode, it would just disable JavaScript. So end of the day, you had to plan for JavaScript not being run on the client-side browser. And basically JavaScript wasn't important. That was the key thing. And again, yeah, the picture isn't showing well because we had to zoom out a bit. But I'll just show you what Hari is pointing to. So this was an era when there was a debate over whether JavaScript really was an object-oriented language. If you looked around the internet, particularly people coming from popular languages of the day, something like C++ or Java or even C-sharp at that point, but JavaScript itself is pretty weird, right? Like you can feel some of that even today. But for somebody coming from a traditional language, it was absolutely baffling. There was no way to, it just wouldn't make sense. It was just not right. So the thing that Hari is pointing to is a word that says object-based. So people categorized JavaScript as this language that was object-based. And as far as I know, that's the only language that ever was categorized under that category. I can't think of another language that was called object-based. So, and of course, frameworks. I mean, if JavaScript itself isn't important, why would you need frameworks, right? All right. So now comes the era of Web 2.0 and rich internet applications. This is essentially like, you know, brought to the fore by Gmail coming out in 2004, with this particular UI. I don't know how many of you remember. It was the first time there was a desktop-like interaction on a web application and the full-player page reload was not happening, right? This caught on quite well with a lot of the people and everyone wanted to use Ajax essentially at that point. And XHR, even though it was around since 97, really only got leveraged from this point onwards. But that's, it's not very easy, right? You look at XHR code. It's intentional that I put a lot of code in there. It's not meant to be read, but that just gives the idea of the amount of boilerplate in there. Even if I highlight the most important ones, still quite a bit. And the first, I saw is the fact that you need to do an if check between ActiveX and XML HTTP request based on the browser. And if you got past that, you still had this problem, which is on ready state change. Ready state four is for data ready. And that's not very readable, is it? There were still more issues, right? One was the browser checking for features, which was slightly alleviated once you got to feature checking. Feature detection was enabled. You could actually check if XML HTTP request existed. But even then, the if checks were not going away. It's just the conditional itself was changing. Well, even for this particular era, frameworks, we were kind of crying out for it because we started writing a lot of JavaScript and things were getting out of hand. But maybe at this point, we still did not have many frameworks. So around this time, people started taking JavaScript seriously a bit. I mean, people started writing more and more JavaScript and filled the pain of not having good abstractions and all of that. Just to reiterate, one of the major issue was, of course, brotherhood and compatibility. I don't know how many of you remember seeing a bat like that on a website. There were badges that said, we are best with IE, we are best with Nescape. And the badges kind of remained on until initial versions of Firefox came. I mean, I have seen badges that said, we are best with Firefox, which was kind of ridiculous. So the problem was, of course, all the brothers had their own way of things. These incompatibilities, they haven't gone away. They are still around. Just that it was a lot worse back then. And so this, for example, is, if you had to select some text in our text box, you had to focus on selecting Nescape, but you could just select in IE. So you had to account for both of them. And Nescape had layers, IE had divs. And if you're writing any code that used any of that, you had to check for it if you wanted your page to render correctly on this thing. And here's a more recent snippet. So this, okay, let me remove the highlighting. Don't bother reading again. But the thing is, that's the jQuery ready function. This is what gets run. If you're writing jQuery, you may be used to putting your JavaScript in a closure that make sure that your JavaScript is run after the DOM is built, right? And the jQuery ready basically does this in order to determine when the DOM has been loaded. Of course, this is all standardized now, but this code is still around. And I'm just highlighting some of the comments over there. The comments basically talk about differences in the browsers and stuff. Look at the last one. It says, if IE and notaframe continually check to see if the document is ready. I have absolutely no idea what that is. But, well, that's a little funny. Okay, the next set of issues were to do with the JavaScript syntax. Just the fact that JavaScript was not familiar to a lot of them, a lot of the people. Or it didn't fit in with the existing patterns, people that were used to. This happens with any new language, but with JavaScript, people that were using JavaScript to write simple script, they almost never had to go and do OO or even to learn that JavaScript could do OO. So for them, starting with OO for the first time, it would still feel weird. So this is, for example, one way to create a class in JavaScript. I mean, I myself remember feeling the first time I saw a code like this. I was like, why would I use a function to create a class? I mean, again, back then I wasn't even thinking in terms of JavaScript. I was just retrofitting everything back into the languages that I knew. So, using a function to create a class, weird. And then, of course, there was another way to do that. You attach your methods to your prototype instead of defining it in your constructor function. You could define object singletons, which you could then use as types. I mean, it's a singleton, I know, but back then at least I couldn't distinguish the difference. This was like a long time ago. Similarly, one more. So basically, at least four ways in which you could define your types in JavaScript, which was, again, a bit baffling. And, of course, the biggest culprit of all. This is determined by the color context. I mean, in just about any other language, right? This is kind of, I mean, you guys already know this, so I don't necessarily have to say this out again, but the fact that in an event handler, this could change to the window because that's where the call is originating from. That was baffling for people that were starting off. So, this is what the initial set of frameworks tried to address. Right, and considering these were the factors in the environment, a few frameworks came out to address the issue. First one being Dojo. I remember having done this kind of UI without any frameworks, right? And that's really, really painful. And when Dojo came out with all the widgets, especially this particular widget I really like, it just worked, and it was much more simpler to use this. It had its quirks. It did not perform well if the list got really long and all that, but who cares? It was much better than what was already available. It was a very good step forward. Dojo also started doing something about the class declaration and object creation aspect. To standardize it, they started giving like some level of abstraction around it. And of course, the XHR, Ajax code, we started getting a little bit of abstraction here. At least it reads more like business right now in the sense that you don't really worry about the ready state, et cetera. So, some improvement, right? Prototype, of course, again, another way of abstraction around creating classes. And prototype was obviously most famous for Ajax.request, really, really intuitive and simple at that point in time. If you guys remember, prototype also was in philosophy very similar to Ruby, which is why if some of you are like Rails developers from back then, you would recollect that prototype was the first JavaScript framework packaged with Rails. However, just to summarize this particular era, the focus of the frameworks that came out was mostly on creating abstractions over inconsistencies. It was not about better code organization. Code was still dirty, still non-maintainable, not extensible, little difficult, right? Also, there was another school of thought at that point in time, which is, people are like really, really getting frustrated around writing JavaScript with all these inconsistencies. So what do you do? Stop writing JavaScript. Instead, use stuff like GWT, right? Cross-compile to JavaScript. It was an interesting idea, but I mean, it was like kind of weird writing HTML, I mean, Java, and then cross-compiling it into something else. It worked for some time, but not sure if it caught on really well. And then direct web-remoting was an interesting approach to abstracting out the Ajax details itself, wherein a DWR would allow you to call server-side Java functions as if they were local to you in the JavaScript file, right? It was interesting at the most, we can say. And then this happened. The ubiquitous dollar, right? I mean, just to give you a tidbit, dollar was first used in prototype, but it became more associated with jQuery later. So two things that jQuery offered was easier DOM manipulation and CSS electors. Absolutely cannot deny it. It's like, even to this day, like the gold standard of how you can abstract things out, right? However, it did not solve the code structuring problem. Still were writing, you know, largely ad hoc scripts. jQuery plugins were also quite, you know, it's just like JS code, right? It's not like modules or anything. It did not really fit in a very good way. With that, that's the next era. So the next era was when we started tackling the code structuring and stuff. By the way, if you've been noticing, we've been putting all these pictures of creatures over there and all that on our title slides. So that's in theme with the evolution theme that we have picked for the talk. And we call this, we picked an amphibian for this because, at least in our minds, this was a really big step up. Like, just the way an amphibian had to crawl out of the water and figure out how to stay on land, which was a pretty steep jump. At this point, you started organizing code better. Again, we're not saying that nobody wrote good code at this point. We are mostly talking about, you know, the typical affairs back then. Because I remember seeing Selium code back then and this was, again, after prototype and stuff, but that was actually a really good code base. That was on that, initially, got me started with proper over in JavaScript. So, yeah, with MVC frameworks, amphibians, this gave us some interesting frameworks. But before that, going with our biology theme, biology 101, whenever a change happens, it's because of a mutation. And mutations are largely categorized into two groups, endogenous and exogenous. Endogenous being something that's inherent and exogenous is an external factor. So, let's look at some of the factors that drew JavaScript framework evolution around this time. So, one was the JS engineers. So, there was V8 and this had a pretty big impact. I mean, this started off node and everything. But the thing about V8 was it proved that JavaScript, you know, didn't have to be slow. It proved that JavaScript, you could run pretty serious. You could write a big code base and expect it to perform and write it all with JavaScript. That was, I think, pretty impressive. And obviously, everybody else caught on and, again, I don't know the internal timelines. It's possible that everybody else was trying to achieve this. But in my mind, V8 sticks because that was the first one to roll out because very shortly after, Spider-Man Key came out with its performance numbers and they kind of mapped V8, P2V8 and whatnot. And then there was Chakra that mapped the performance again. But I remember V8 and that kicked off Node.js. So, in general, this was the era when we started seeing very performant browsers, JS engines. You could write very serious code with JS. And the other thing was, of course, the notion of a single-page application started getting prominent with Gmail and stuff. The idea being giving a desktop-like experience to your web application users. There were also ideas like rich internet applications, which was basically a mishmash of online or offline modes storing local state and making online calls only when required and all of that. But, essentially, the web was taking the center stage. This was the point when you kind of thought twice about whether you really need to build a desktop application. So, all of these factors resulted in the initial set of MVC frameworks. So, I'm picking Backbone here because that's what I like, again, personal preference, not to say that anything else was bad or anything. I remember using Bit of Knockout and there was even this thing called SamJS and stuff that I used. And there were a lot more. There were like absolutely a lot more. But I'll just show you a little example from Backbone. This is the canonical to-do from Backbone. And the key thing to notice is... Okay, so there is like a to-do collection to handle a collection of to-dos, which refers to a model, which is a single to-do with a couple of attributes. And your collection points to a URL and all you have to do in order to fetch your to-dos is say collection.fetch. Notice how I'm not making any Ajax requests. I don't care about the details anymore. This is a significantly higher level of abstraction from making raw Ajax requests, processing it and then parsing JSON and creating objects, whatnot. All of that is handled. Could be magical, but I think this was kind of the right level of abstraction. And of course, this Backbone also had its views with the templating system, again, a very basic templating system that could be fit out if you wanted and stuff. But see how events are... The view declares events. It declares events. It doesn't bind to them. It's not imperative. And so, and there's a little bit of two-way binding going on over there. Like the view fires an event to update the model and whenever the model changes, it fires events that the view listens to and then updates itself. So, this was like, yeah, this is how we wrote code in this era. So, a couple of other things that happened around this time were there's HTML fire and everything, but we won't get into that. We are trying to focus only on the web development aspects, web applications, the typical enterprise applications. So, the other thing that was interesting was modular JavaScript. This was around the same time frames and there was a specification called asynchronous module description. I remember using ReactJS that did this. So, this is essentially the same as what is getting into ES6 now as modules. Essentially, the idea being you have well-defined modules that expose, you have control over what you expose to the people that depend on the module and proper dependency management. All nice things from, if you've used something like maybe not something, people would be familiar, but this was the first time this kind of got into JavaScript. And, yeah, of course, packet management. Again, thanks to V8 and the node, we had NPM and now we have board and stuff. The strange thing is JavaScript being as old as that is. It's very strange to think that I didn't have proper package management for a really long time. I mean, Ruby had gems, Python with pip, you and Perl had like Cpan and stuff. But JavaScript for a very long time, I really find this bit strange. Right, so with that, we evolved to apes, right? Client-side application frameworks. We thought apes might fit this because the amphibians came out of the water, went onto the land, now the apes have climbed the trees, but that was the analogy here. So with that, I'm just picking AngularJS and Kin here. I'm not going to go into code here because most of us know how to do it. But what I find a little strange is sometimes when someone asks me about AngularJS and what is it, the first answer probably comes out as like it's an MVC framework. But it's a little bit more than that. What we've seen is Angular bringing in the declarative aspect of things to JavaScript programming and also around data binding, which all of us know very well. The part I really was impressed about with Angular is the dependency injection. The reason DI is really important is because it lets you write more maintainable code and extensible code. And by design, dependency injected code is testable, right? I think the most JavaScript code I've written with test coverage with Jasmine specs is probably with Angular till date. I have to check out the others, but this was very, very significant for me. Services, another concept which is coming down from server side programming into the client side programming aspect, right? So these are all good ways of writing maintainable and extensible code. And it's good to see that they're coming into the JavaScript framework side. And more concepts, of course. However, where are we headed next? We do not know, right? Like the previous talk, which was brilliant and we just saw the amount of difference we have between us, right? We still want to explore other frameworks. And the probable reason why we have so many such a plethora of frameworks is because we probably haven't hit that right card till now. And we have to get to that point. So which is why I thought I'd label this a missing link. And I'm just hoping that we are headed in the direction where we get to libraries which lets us write more extensible and modular code and focuses more on the code organization itself other than just abstractions, really. So with that, thanks a lot for listening to us and we hope we have wound up fast enough for lunch to be served at the right time.