 So, the engineering have been programming for the past twenty-twenty-two years, and continue to enjoy programming a lot. Today I'm going to be talking a little bit about JavaScript in the context of the overall ecosystem, characteristics about it that I find interesting, and a little bit about, you know, specific characteristics of the Java language in terms of details, looking at a little bit of code as well, so it's kind of a little bit of code and a little bit of context setting. I think I'm going to find a stuff. So, I have no slides today, just a card deck. So, how many here think JavaScript is a very clean language? How many think it's a wonderful language? And do you see the paradox in there? Just, you know, JavaScript is a terribly interesting language, that's for sure. There's very little things about, that you can say about JavaScript, you know, that are centrist views. You typically end up being at extreme, either it's good or it's bad, or it's wonderful, or it's not so good, or it's, you know, oh-oh. But, you know, it elicits real reactions. What I'm going to try to do is try to mute some of those reactions of mine. I'm not going to try to go overboard in terms of pro-Javascript or, you know, the other direction in terms of being anti-Javascript. But really try to take a look at the language without really bringing in too many biases or too many extremities into the picture. Having said that, I'm not really a JavaScript programmer myself. And in the sense, today I don't code a whole bunch of JavaScript except an occasional web page. So you might find, you know, occasional issues in the code or stuff like that, please excuse me. This is not the language I use day in, day out for my work. But just a little bit of, you know, history of JavaScript, what happened was in 1995. Brendan Eich was asked to create a complement to Java for the next year browser. Java was a full-blown language. Pretty much everybody wanted to imagine or did imagine that Java will be the language for the browser. History went in a completely different direction. But they needed something to kind of glue together the Java and add a little bit of the dorm elements. Brendan Eich created it and wrote the first version in 10 days flat. I think he talked about, you know, there being a specification, not being a specification. I mean, writing a new language in 10 days flat, I mean, you have an idea of the amount of errors thought that would have gone into it. I mean, I'm sure all he was probably struggling with was the deadline. And it was initially called LifeScript, but then they decided it's not such a nice name. And let's get God a waiver from Sun for the use of the trademark Java and, you know, essentially ended up calling it JavaScript. I'm told Gosling wasn't too happy with that decision. Instead, the trademark is owned by Rekul. Sorry? JavaScript trademark is owned by Rekul. Oh, okay. So anyway, so that's a bit of a history of, you know, essentially what happened with JavaScript. But the vision then was the browser would be owned by Java. I mean, then there's HTML, then there is JavaScript for the blue kind of stuff. And, you know, Java applets were imagined to be the thing where, you know, you would have Java on the client and something else on the server. And Java applets being mobile. Waitings turned out that didn't quite play out that way. But JavaScript stuck. And it soon started getting used in other contexts and it started really getting competition in the context that it was already entrenched in. I worked with something called Livewire in 1996. And that was the second web app I created. And that was a server-side JavaScript. I wrote it in 1996 on Netscape Enterprise Server. And it was today what you can do in Ruby or PHP or Python. In 1996, I wrote the app, which was very, very well-received for the Internet. It was our internal bug tracking system. And people are just amazed. I mean, the fact that we suddenly moved from a static browser, static HTML into a dynamic environment where, you know, the browser could actually interact with backend databases. And what played a big role there was JavaScript because the entire server-side infrastructure was JavaScript. I don't know how many of you would know about it, but it was an environment called Livewire. It was a part of Netscape Enterprise Server. And you could write server-side applications back then. Node.js came in way, way, way much later. Unfortunately, Livewire didn't really catch up much. And in the meanwhile, JavaScript started getting competition on the client thanks to something called MiniScript. Again, a quick attempt to, you know, let's get something out to start competing with JavaScript. That didn't do too well. So we basically didn't do too well. Java, which was supposed to be really, you know, enjoying that space, didn't really occupy the client space that well. What we were left with was JavaScript was essentially a monopoly. And it's been that way since. And that's something that's really helped JavaScript all along the way. There have been times that have been really good for JavaScript and there have been times which have been not so good. In the times that have been not so good, the fact that it had absolute monopoly on that particular environment helped it stay alive. It helped it, you know, kind of bounce back. I mean, if cat has nine lives, I have counted JavaScript for at least three lives so far. So let's see how many more it gets. Okay. So one of the things at that particular point in time I really got into, and this was 96, was I being a big OO fan then. I still am actually, really wanted to explore what JavaScript could do in terms of object orientation. And mine, I was in for a big discovery case. I mean, this was completely surprising. I was completely knocked off the level of the kind of OO. I had never looked at a prototype-based language before. I didn't even know frankly what it meant. So I was just looking at the implications of what it meant and really played around with it. And all you could realize was that coming from a C++ world then and suddenly into this environment that you could practically do anything. You could rewrite an object's hierarchy on the fly, on the run. You could add attributes to it on the fly. You could add an attribute to an object. You could add an attribute to the class. You could change the inheritance hierarchy. You could pretty much do anything you wanted with any part of that RAM memory space. And you were the boss. You could do whatever you wanted in there. And there was an amazing learning about JavaScript. I don't know how many people actually know about the amount of rewriting. Bit of programming is not necessarily good, but the amount of dynamic reorganization you can do of the internal memory, not memory, the variables and the structures in JavaScript. It's incredible. And when I started learning that, I was really amazed. We built some good client-side applications. We actually built a model view controller on the client side using JavaScript. And what really helped there at that particular point in time was the fact that once I kind of created through the way the OO was structured, I could get amazing capabilities by writing relatively small amounts of code. So just a little bit of what kind of OO exists in JavaScript. So I could have something like this. Is this visible? So let's say I have this function person. And sorry, running too many languages. So what's this? What did I do here? P is a function, and I just ran that function. There's nothing there in that. So it didn't return me anything. But I could just do this. And what did I do here? I created an object of the type person. Is it mind-blowing? I don't have the word called class. I mean, there is no, you know, this is all that was really required to create an object. It is simultaneously an object and it is a function. So I can now start, you know, doing stuff with this. I can say function person. I can give it a name. I will do this. I will say nA. Oops, how do I get this here? How do I make it an attribute of that particular? Can create an attribute dynamically. Does it have any method here? No. I can try to look at some other arbitrary attributes which don't exist. p.foo doesn't exist. p.foo equals bar. Here I am able to add an attribute to the object on the fly. And then essentially what I can do is p.greet. So now I can say p.greet and print out hello. And I could instead also say, So you see, this is an exceptionally believable language. You can take it like a clay and mold things together pretty much the way you want it. There is no compiler wanting to stop you. There are no constraint to stop you. There are no, I mean, it's simply a substantially constraint free environment. I can keep on doing this again. I'll do a little bit of what I really wanted to talk about here was this is a really constraint free environment. Which is the other language where you could do this kind of stuff. Today, I think a lot of this can be done in Python and Ruby. But there's still most of that cannot be done that I can talk about. And which is where we get into prototypes and stuff like that in Python and Ruby can't be easily done. JavaScript to me amongst all the languages that I have worked with is the most constraint free of all, which also makes it the most unsavageable. Decided which way you want to take it. But the fact is you can't ignore it because it occupies one extreme space in terms of the kind of programmatic paradigm. Not paradigm environment, it presents you. It gives you a constraint free environment. It makes you the master of the world and say now you do what you want. I trust you and it's up to you. And that's a very, very defining characteristic of JavaScript. In some shape, it's probably hell because it made people could learn JavaScript or start using JavaScript very, very rapidly. I don't remember the exact quote but I think Dr. Stockford once said JavaScript is one of those languages where people don't think they need to know the language before they start coding. There are actually two languages like that. Anybody who wants to take a guess is Phil P. But people can get in jumping and start writing code and that's a part of what made JavaScript successful. Like it, not like it, it made JavaScript successful because it got people in very, very quickly. So you might be an HTML programmer, you might be actually a graphic designer who's doing Photoshop PSDs but you could still write a little bit of JavaScript without really knowing a lot about programming. So anyway, we'll just go on with this a little bit more. And I'm going to say now equals new version n to the list of things. And if I try to do this, it won't work because I had added a method on the object instance and I did not add the method on the class but I never declared a class. Why do I add it? It's fairly straightforward to add it. You basically say person.prototype.grid equals function and console.log. Now I can go back and try to read on the p2.grid. What happened here? I have already instantiated the object p2. Later on I changed the class but it inherited it. How did that work? Because essentially what JavaScript does is it maintains a set of internal pointers made to my prototype, my prototype to its prototype and so on and so forth. You can add stuff anywhere you want along the way and that certainly becomes dynamically visible. You can change the function to do something completely different. You could change a function which saved the world into launching a new missile. It's not going to stop you. It doesn't make judgments about what you are allowed to do or not allowed to do. There's more stuff here I can talk about in terms of how the inheritance works and how the inheritance of prototypes and structures and everything else. Let me go to the top. Later on maybe we can talk about you a little bit. This gives you a flavor for what is the nature of object orientation of JavaScript and the amount of freedom it gives you. It really gives you a tremendous amount of freedom. And its OO is very unique in terms of being a very prototype based object orientation. There's no glass structure. So JavaScript was popular. It was popular as if it was popular for the HTML scriptedies. And people were using it. This was the days when you had the link tags running all over the place. And it was competing with VBScript and it was competing with Java, Java lost very quickly. VBScript took some time. But over a period of time, VBScript was also on its way out. And JavaScript was very, very boring. There's no mention of JavaScript per se. Why would you want to really talk about that language? No industrial articles, anything about that. And people were talking about browser being the next OS. And what was the big constraint then? JavaScript and HTML just couldn't handle it. I mean, they just didn't have the capabilities of being the next OS. It just wasn't there. For better or worse, Microsoft wanted to introduce something called XML HTTP request. JavaScript needed a gift. This was one that was delivered to it right away. Bag, you know, added speed to the switchboard. Suddenly, Ajax became fashionable. And because Ajax became fashionable and you had a monopoly here on the browser, JavaScript had a pretty much dominant monopoly. You know, nobody else could really come there. So then JavaScript had, you know, you had to find ways to make JavaScript really leverage Ajax. Everybody wanted rich clients, right? I mean, they still wanted. And they still are not happy about it. So for the last 15 years, people have been unhappy about the level of rich clients support. They still are. Nothing has changed. JavaScript is much, much more capable today in terms of in combination with HTML and CSS than it was there. I mean, today you really can talk about a lot of rich clients. Another spoilsport was there. You had different browsers, essentially, too. And, you know, they had different agree on each other in terms of exactly how JavaScript should be. Even for the same browser, sometimes the versions couldn't agree. And, you know, you had really people, when you said at that point in time with history, you talked about JavaScript and, you know, JavaScript, everybody would just say browser issues. And we had this, you know, line which still continues today in many websites. This site optimized for Internet Explorer. What it meant was my site cannot support Netscape and or Firefox in terms of its requirements for JavaScript. I don't, my JavaScript only for IE. I tested only for IE. And, you know, live with it. Because the developer couldn't spend so much time, you know, trying to, you know, debug all this stuff. But eventually people wanted it. You know, consumers got more powerful. Any consumers as opposed to just enterprise consumers. And they started, you know, I want to use Netscape. I want to use, I want to use whatever. And browser incompatibility is a common issue. That's where other libraries started stepping in. You had, I remember something called Dojo, which was pretty hot then. And eventually something became much hotter. They handled the JavaScript browser incompatibilities very nicely. JQuery along the way actually introduced some very, very nice ways to structure your code. It's got very functional structures. But it did that quite nicely in terms of its selectors and in terms of how to manipulate the DOM objects. I mean, the DOM was not exactly the most amenable and the easiest to use construct. But JQuery kind of, you know, took away all the rough edges. And, you know, it really helped in terms of making sure people could use JavaScript and build reasonably rich Ajax applications on top of JavaScript that would run on top of all browsers. JavaScript was again popular worldwide. And essentially people didn't really mention JavaScript while you saw in blog post and web page. And articles then were the Ajax. Ajax, RCP, and JavaScript was essentially the lexical framework like that. In the meanwhile, now JavaScript is with a, you know, standard calling called ECMA. People debate a lot about, you know, what should be in JavaScript standard, what should not be in JavaScript standard. One of the things that's happening is now JavaScript, suddenly people are realizing, oops, JavaScript is no longer just a browser-client environment. It's a full-blown language. It needs, you know, capabilities that should be there in full-blown languages. And you're seeing more and more of those kind of getting introduced. But just to kind of give an example, here's some stuff from. I just gave a talk on functional programming. And this is another piece of code which, you know, kind of talks about the functional programming characteristics of Java. Amongst a few languages, it's not great, but it's still starting to have those capabilities. In terms of here, I can, you know, you talk about math, reduce, filter, everything. Essentially, functional constructs, which are there as a part of JavaScript. Just as an example, I kind of, you know, created a set of objects that are called items. And your task is like this, okay? You have to run through this list. Here on the right, let me show you this. These are your equalities, even. Your status, shift and pending. What you need to do and write the code for is to say, pick up all the items which are status in shift state, okay? Multiply the rate by their quantity. Because these are essentially invoice items, you want to create a invoice output. Based on the tax code, apply a particular tax rate, which I have, you know, showed here. And then compute the total invoice amount for me. Now, there's various different ways I could write this code. And how would you write this code? You probably have four loops. One for loop for all this, then there's a condition for checking the status equal to pending or shift. But then after that, you would have a visa to go get the tax rate. Then you would, in the next line, compute and add everything together. The total amount for that item. Then you would have another for loop. Then you would have a counter, which would start off with zero and keep on adding values to it. Then you would have a summation accumulator, counter is not right word, accumulator. And in the end, you would come out of that for loop and take the value of the accumulator and print it and say, this is the value of the invoice. Turns out, there's another way to write it, which is these three lines. I don't know how many, maybe many of you do write it that way. Maybe many of you don't write it that way. But JavaScript can allow you to write it that way. I don't know how many knew that. JavaScript has got enormous amount of functional features. Some of them in the standard, some of them in the upcoming standard. There are a lot of them which are not actually there in the standard version. So you won't get them on Node, but you will get them on the Firefox version. Many, many, many more functional kind of stuff. But they will eventually be there. And this is exactly the code I talked about. Let me explain to you what it does. It takes this list of items. It says, I want to filter it using a callback function, which says, callback is a long word, using a function which says, is status shift. After that, I want to map it with another function to say, give me the total amount for that particular line item. How much I have to charge the customer. Once I get that, and this is all changing, if you see the dots here. You can call reduce to take that in all these amounts and pull them into one single value. Just a quick question. If you were to write this code, how many of you would have preferred this kind of an approach today? Wonderful. I'm very pleasantly happy. I would say surprised, but I'm also quite happy that people are really using it. But JavaScript is adding more and more of these capabilities. So, filter is a built-in method on arrays. Yes. There's a whole bunch of other stuff that is not there. And by the way, I can't understand exactly which version has it and which version doesn't have it. This works on the node version, the current node version. It's easy to add shims for all of this stuff. Sorry. Because it is going to modify the prototype, right? No. But otherwise, there are a lot of other things, like iterators and generators, which you can't just hold on. They are coming in a future version. I think the script versions have it, have them. The node version doesn't have them. How many of you are aware of the yield? What? Y, I, E, and A. But in Python, not JavaScript. JavaScript, in the standard, I think is expected to get a yield, which is essentially a generator. How many more can send in a value to a JavaScript generator using yield? You could actually do that. And that's also okay. This version doesn't have this stuff. I was writing this before yesterday, it won't run because the current node version doesn't have that stuff. But I've told it's all on the way. So anyway, there's a bunch of capabilities. I had them noted somewhere I need to look it up. Other capabilities also that JavaScript is getting. So while it has a lot of capabilities, I think as a full-blown first-class language, I think it's getting many, many more. And they are all kind of on their way, which makes it a dynamic and growing environment. Environment for the language. Any questions so far? What are you doing on time? Sorry, one second. I'll be back in 15 minutes. Okay. Sorry. Yeah. This approach looked like same as Erlang, I think. Erlang and Trolog kind of thing, that you create a database and then you query on that database. I think Trolog has this kind of database. And Erlang, I think, has seen that kind of functionality that provides you with the question language. I think it has similarity to Erlang in terms of the fact that these are essentially functional constructs. You will find map filter and reduce and or fold, fold or fold L. You know, almost all the languages that support some kind of functional programming constructs. This is not like Erlang. It's not like Prologue. Prologue is something very different. It does backward chaining. It does... Let's not get that. This is not Prologue. Definitely not. No, we're close to it. Instantly, jQuery does backward chaining. Sorry? jQuery does backward chaining. Okay, I didn't know that. So you can go up the chain from here, down the chain. Backward chaining of logic? No, in the sense that... No, he's talking about domain names. Domain names. Domain names. No, no. Trolog does backward chaining of logic. Backman chaining of logic. Okay. Okay. So it actually works your logic backwards to kind of find out, what should be the incoming values. Oh. Prologue is a completely different volume. I know. And get mixed up with some database stuff. I get mixed up with... I think that's called Erlang. I think that's... Erlang? No, no. This Mac filter reduce is lingua-fantra for functional languages. Yeah, yeah. Doesn't matter whether it's Erlang, Scala, Haskell. Yeah. I've got... There's a database, and then you do something on that database that you created in first place. So that, I think, that was kind of philosophy of same prologue way that of generation language. That you have a database created before and then use that database to extract the queries. Okay. What I meant by database was I was representing this here in this structure. What I meant was this. I assumed that these were records coming out of a database. That's all. Hey. So JavaScript was interesting. Again, thanks to RCP and thanks to Ajax. And then it again became boring. Because not much was happening. And one fine morning, what happened? And suddenly, everybody got excited. And frankly, I haven't quite figured out completely how that correlates. I mean, why did Node make such a big difference? I haven't figured it out. But I'm sure there are good reasons. I'm not questioning that. But what was Node really at the end of the day? It provided an excellent positioning for JavaScript, which separated from all this other wannabe scriptedies which were trying to build essentially PHP or Rails of Python applications to say, I can build highly concurrent applications for you. Whatever that meant. The point is, the highly concurrent threshold at which this kind of stuff makes a difference is so high. 95% of us won't ever need it. It's really, really high. Normal languages can go to reasonable levels of concurrency without really having to try to implement reactor patterns and event loops and all that kind of stuff. They are really important. They are really useful by concurrency to know thoughts about that. But they get required at a reasonably high level much, much, much further down the road. But JavaScript was back on the server side again and that's what I like because I always related to the fact that Livewire never quite made it. To me, if Livewire had made it, I would never want to Ruby Python and PHP perhaps wouldn't have made it. Livewire would have kind of dominated the scene for some reasons, which are essentially all about enterprise politics, Livewire really didn't do it. But JavaScript was server side again and that was exciting because JavaScript no longer was a monopoly in one area but then a non-competing party in another. It actually could compete with other languages in the server side and not give it a... to be able to do that. Just some... I think it's one of the significant event that shaped JavaScript's evolution which is the introduction of Gmail and Google Maps. Until then, XML history request was seen as a way of refreshing little parts of the page. But what Gmail and Google Maps did is they introduced the idea that you could have a client side in the browser. Those two were the first ones they introduced the concept and then of course Chrome made it possible with V8, which was a super fast engine. Right. A solution about why Node got famous or why JavaScript got that much server side and the reason of why Node is here is because JavaScript is so ugly that it cannot provide recent input-output operation no stoppage of input-output operations so anything could... no restrictions on any input-output output so that anything could do get as asynchronous in that sense. So ugliness of the JavaScript provides the way to do asynchronous programming in the same way. Example, here's a Ruby. It's very clean language and it do not provide the input-output. It provide restricted input-output in that sense. JavaScript has a very short... I think Douglas Gropford said about this. You used about Douglas Gropford lectures there was second lecture talk where he used the same words where he was, I think, referring previously. Second lecture, I think, that was in second lecture. So the main reason is ugliness of JavaScript that provide Node.js to be built on that. I have taken the talks, some talks of the Node.js make-up, I think. You know there was a guy sitting behind who was almost showing his face. Sorry, what was that? There was a guy sitting behind showing his face today. So, you talk about JavaScript being ugly for whatever... it's got an exceptionally low learning curve and that's a characteristic of JavaScript that actually makes it beautiful in many, many ways. But I forget where I picked this off. I think it was from Netcraft or something like that. This was probably a weak old image and I didn't, unfortunately, I was confused. I just saw typed down with so much stuff I didn't get actually time to do the research of this image in detail. But this struck me. Let me tell you what the axes are here. The x-axis, left-hand side is used by fewer sides right-hand side is used by many sides and the y-axis, lower down is used by low traffic sides and as you go up, it's used by high traffic sides. I don't know quite frankly the methodology of how they got this data in the first place. So, trade this as completely for what it's worth. But it's interesting to see where the position node.js really occupies used by high traffic sides. I don't know how many high traffic sides are out there using it. And Netcraft must have studied and done some kind of research to kind of reach there. I don't know that methodology, unfortunately. But it's interesting that, you know, that's where node.js find itself. It's not surprising, but if I took guess I wouldn't have imagined that. It's GitHub and Stack Overflow person. Sorry? It's GitHub from GitHub and Stack Overflow person. This one? Yeah. So the interest in GitHub and Stack Overflow have decided where we do it. No, that was a different one. That was a Red Monk survey, right? Oh yeah, sorry, sorry. This is Netcraft survey, right? That's an actual website measurement. Can you zoom in a little bit into that? Sure. It's one bit. I actually have the Red Monk image in the subsequent year, but anyway. So let's continue. It's just an interesting position. There's another image I had here. Why is it not running up? Yeah. And, you know, there's a growth of node.js websites. Hell you go. But if you look at the x-axis numbers, you know, it kind of puts it in perspective. 0.005, 0.007. It still has a long, long, long potential node. But it's going. So that's the node for you. I mean, you know, the node was, node took off, node excited people, node got, you know, people really talking about it. All the cool, suddenly, you know, I started noticing some degree of cultural similarities between Ruby and JavaScript. You essentially had a lot of the coolness factor to it. Ruby as of 10 years ago and JavaScript as of 2 years ago or 1 year ago. But anyway. And the next other thing that really started was happening was now people started talking of unifying client and server programming. Where, you know, you write a piece of code. You shouldn't have to worry about, you know, where it's getting executed. I might, you know, put a, run a SQL query from the client and it will actually, you know, move it back to the server and run it on the server. Frankly, I'm, you know, I've come from the DCE, Encina, Orba, and Decom days. I am very suspect when, you know, something like that people start talking about. I'll keep my fingers crossed. It's a terribly, terribly hard thing to pull off. Let, you know, when you try to abstract away the network, it's really hard. But at least JavaScript has gone far, far further than anybody has gone, you know, in the past. I was at PyCon India last week, and I think Jacob Moss basically talked, he was the writer of Django, and he talked about Meteor being an example app, which is, you know, an example of the kind of apps will be going forward. And Meteor is a Node.js-based framework, and it does rich interactions and, you know, allows one great word of both client and server. I mean, that's one idea. But again, JavaScript might show, and the JavaScript ecosystem might show some kind of leadership. So I can wrap it up in two minutes, or I can wrap it up in 10 minutes. Sorry. You can do the 10-minute version. Sorry. No, actually, no, sorry. I thought you were still waiting. I didn't realize. My apologies. So anyway, where is JavaScript heading? I'm a Tolkien fan. Unfortunately, you know, the word kind of comes to my mind, the one link to bring them all, and in darkness bind them. I sometimes fear that JavaScript might actually be successful at that. I fear it for a different set of reasons. I am a polyglot. I love different poly, you know, programming languages. I love them all. You know, love to work with a number of them. This single language of client and server, and that's all I need to do. It scares me. And that too. Oh, by the way, here's an interesting thing for you to kind of do. On Google, search for two mandatory words. For example, the first, the double quotes, say I want search results with JavaScript. And second, within double quotes, say WDF. And look at the kind of number of search results Google shows up. Yes, I tried it with about 15 word languages. Anyway, we also get guess, which was the number one language that came up. JavaScript was second, by the way. But they are closely competing with each other. And then to imagine that, like we're just going to be unifying client and server and, you know, taking out a network latency. I was scared. But, you know, that could happen. I mean, it's getting successful, right? And people are talking about, again, you know, people are talking about composing network applications, which is really strange. I think sometimes people are really getting ahead of, you know, what's feasible. Composing network based apps. I mean, you can talk about it. It's not that clean, even if you had Node.js. I mean, to me, probably somebody wanted to do it online as the best, best infrastructure to be able to do that. Nobody's going to be doing it online. But concurrency is going to be an important aspect as we go forward for some of the applications. It's going to be overwrite unnecessarily for many other applications. But that's part of the directory. But yeah, Node.js I imagine will be a big player there. Along with a whole number of other stuff, at least in my mind, there's G event, and there's Outland, and there's Tornado, and there's actual Rails. So, you know, everybody will have these reactor-based implementations. I would imagine that Node momentum would probably carry totally for so long. And eventually, you know, these languages will compete with each other. But the unification of a single language on client and server, the fact that it has a monopoly on the client, and the fact that it's, you know, continued to bounce back at least twice in the history, seems to be a big thing. You know, I think keep on bouncing back again and again and, you know, doing more. Thank you. What about things like coffee screen, mobile... Oh yeah, important point I missed. I think you talked about, you know, these being competitors. I actually start, you know, thinking, you know, really... Actually, it's not original thought. I read it. I saw it somewhere, so it's not mine. But JavaScript is the byte code of the web now, instead of Java. So you could have office script and closure script and whatever you wanted, but the byte code that ships over the wire is JavaScript. That's one way to really look at JavaScript and say JavaScript is really the byte code. Just like Java today, the JVM is now the infrastructure when you have Scala and Poja and everybody else writing on top of the JVM. JavaScript will probably also provide that kind of an ecosystem. Do you think it has better chances of doing that than something like a native client? Something like? Native client. If you look at what Google is trying with Chrome, what they've done is actually byte code which is sandboxed, which means that it's byte code runs at low level, but still runs with sandbox. I think JavaScript is probably a much better legal program. I mean, unified JavaScript generated from other languages like office script. You can take that as a way out of JavaScript and keep it as a byte code, but make it other languages. I frankly don't know. At this point in time, I don't know how Google is going to deal with what it's trying to do. Thank you very much.