 Hi, so my name is Raj, so I work as a digital analyst from Microsoft, it's kind of funny actually, I was coming, I wanted to see where this place is, so I was going to look it up on my phone, so I put, you know, on clear drives, I put the address just next, and it gave me an address in Shanghai, China. Wow, we're all going to China for China It was only about 4,009 to 6 kilometers. So one thing John mentioned was that, you know, how many of you here are Chau's Sympathics, right? How many of you are not? So we have a couple of people here. You know what, this is probably the wrong session to start, if my objective is to convert you into an addict, because I'm going to tell you about things that are probably not so great about Chau's Sympathics, right? Things I do to watch out for. So that's what, this is about Chau's Sympathics, this kind of language that people either can go absolutely fall in love with, or they hate it's guts, right? And there are some good reasons why people hate it too, I mean, I love the language. There are some pretty amazing things that you can do with Chau's Sympathics, that you can find it hard to do with other languages, especially if you're coming from a static programming language background, like C++, C++, Java or something like that. There are things that you can do with Chau's Sympathics that you pretty much can't do anywhere else. So those are the good parts, right? So, in fact, Douglas Crawford, who used to work for Yahoo for a long time, and now we use Chau's Sympathics. So he's written a book called Chau's Sympathics, the good parts, right? And there's another Chau's Sympathics book, it's very popular called Chau's Sympathics, the definitive guide. There was this funny joke about that, you know, if you look at Chau's Sympathics, the definitive guide, it's about that thing, right? It's a really big book. And if you look at Chau's Sympathics, the good parts, it's about that thing. So people ask, wow, so what is the rest of Chau's Sympathics, right? So it's a good book, you should read Chau's Sympathics, right? It kind of helps you to focus on what Chau's Sympathics is really good at and, you know, let that keep you pretty secure in your web apps. So in this session, we'll be looking at three Chau's Sympathics, over 15 minutes. Some of the things that you might want to watch out for. There's not much information in the slides. We'll try out some scripts in the browser and see what these Chau's Sympathics are. So that gets started. The first thing I kind of want to talk about was about this concept of the fact that you can read periods, right? So JavaScript, in many ways, is a very permissive language, right? You can pretty much do whatever you want. And unlike static type languages which insist on giving you build errors, right? If something doesn't work, it points it out. It says you made a mistake, go fix it, right? JavaScript is not so finicky about that. If something is not right, it'll say JavaScript is most likely to achieve something and keep going, right? So which can be a good thing, but there are scenarios where that tends to be a very bad thing. One place is variable leakage, right? So what I'll do is I'll probably launch a little console here. So this is basically a console where you can type a little piece of script and experiment with it. For example, I can just type a little tool here and hit the commenter and just run the script. So you can write a little bit of script and there's a print statement here that you can do that and how it comes on the right-hand side. If there are script errors and stuff, they show from the bottom right-hand side. So when you talk about variable leakage, what do we really mean, right? So it turns out to be surprisingly easy to make this error, right? So let's say, you know, I have a variable here called backload, right? Something. Later on, you know, what do you think is going to happen if I did something like that, right? Or let's say, that's another thing, JavaScript is weakly typed. So one thing can be a string at one point later on it can suddenly become a number or a date or an object, right? So what do you think is going to happen in this case, right? You have two different ways. Yeah, I mean, pretty much, so if this was C sharp or Java or pretty much any other language, just kind of keep that language, you're going to get a compiler error, right? And the reason is because, you know, there's a typo here, right? The variable is not the same. You change the variable name, right? Now, in JavaScript, unfortunately, that's, nothing is going to happen here. So I have a little error console here, right? I'm going to go ahead and bang it over. Then, you know, it prints too, right? No errors at the bottom right-hand corner. So what happened to this assignment here, right? What do you think is going to happen if I say print window.danjlore, right? Without the variable. See that prints power over there, right? So this is a, this is a culture, right? This is a way of, you know, you can accidentally introduce variables to the tools. So essentially what happens here, when you say banglore equals bar, right? The JavaScript front-end goes and looks up to see if this variable has already been defined. So in this case, no, it's not been defined. It happily goes and adds it to the global scope, right? And that's not a good thing, typically. You don't want something like this to happen. First of all, obviously, you know, the biggest problem here is that there's no error, right? And your program would just keep working. You know, 3,000 line JavaScript program, and you have this little error sneaking in somewhere, right? Can you imagine how much, how difficult is it to figure out this particular part? So that's the problem here. And how do you deal with this particular thing? There are a couple of things that you can do. One is, so in JavaScript, there's this concept of an immediate function, right? You know what an immediate function is. Sometimes it's called as a self-exaggering function, which is technically incorrect. You create an anonymous function and it's immediate, right? So basically, typically it's an anonymous function. It doesn't have to be an anonymous function, but it really does. And it's a function that you define and even both at the same time, right? So something like that. And so it can define a function here, and you call it immediate, right? So immediate function. So, you know, it executes that function. And if you find it here, I called it instant immediately, right? So this is one thing that you can do. Define all of your code, right? Even if you're writing it in the global scope. Let's say you mark up right at the top. You have putting script, you know, type equal to JavaScript and then you put it there. Put it inside the immediate scope. Even if it's running in the global scope, put it there. Basically, the benefit here is whatever variables you introduce, right? You declare a variable. But default code would get out of your global scope. And everybody knows global variable is not a good idea, right? All kinds of funny things can happen. So you typically want to limit the scope of the symbols that you introduce in your program. And this is one way of, you know, immediately doing that. But this still doesn't solve the problem of accidentally introducing the global scope. Like if you say the workload is, it should still go ahead and add the thing to the window object. So with ECMAScript 5, right, ES5 standard, there's a spec part of that that was introduced was something called a strict mode for JavaScript, right? So it's pretty cool, actually. All you need to do is, you know, in your functions, just go ahead and put this little string there, string declaration there, right? Use strict in the global scope. The nice thing about ES ECMAScript 3 is that ECMAScript 5 is that many of the features, many of the enhancements in ECMAScript 5 were introduced with backward compatibility in mind, right? So this piece of code here will run perfectly fine on ES3 engines as well, right? ECMAScript 3 engines as well. In fact, pretty much except for some minor, some few exceptions like property syntax or, you know, some of these access protection methods like, you know, please and see, things like that. There are some methods which are new in ES5 for which you do need a ES5 engine for your work, but a vast chunk of it works either without breaking your code or you can backfill it with library code, right? The capabilities can be provided to a library for ES3. So here, this particular line of code will run perfectly fine in ES3 engines, but you benefit automatically on ES5 engines where Strip Mode basically causes your script to run with some different semantics, right? Basically, most scripted rooms. So what's going to happen is, you know, let's try that same example here. So I have Google's Bangalore. So I say Bangalore equals this bar, right? So I say window. You know what? So, you know, right at the bottom right-hand corner, you can see that the same code throws in error code, right? Variable undefined in Strip Mode, right? This is the exact same code, right? The only difference is we have a new Strip at the top. So the same code here with the typo produces an error in Strip Mode, which is good to what you want. Basically, in Strip Mode, you cannot arbitrarily use a variable without clarifying first. So it enforces that you declare your input you use. And any error that you catch during, you know, obviously everything here is at runtime, but at least you see the error, right? That's good, other than it might present itself as a permanent error. So use the Strip functions and use Strip Mode, right? So closely set. Good question. Do you have to do use Strip in every function or can you do it globally? Yes, you can do it globally, but in general, it's probably not a good idea. See, for example, before you include any JS file, I mean, the use Strip applies for one translation, not translation unit, but it's what they call it in JavaScript, like one file, right? So when it is parsing that file, if you put use Strip at the top, then it applies for the entire file. It's top of the JS file, top of function, then that function. So you have code that is from a library that is not Strip Mode compliant, and then your own code, and you don't want that to start throwing more kinds of errors. So typically for your own code or new code that you write, you absolutely should use Strip. For legacy code, if you see in a library, you might want to be a little bit more conservative there. What browser support do you use? So all modern browsers, so all web pages, versions of Chrome, Firefox, Opera, Safari, all support. IE supports it from IE9, what if I make a typo and say use Strip? In your script. If I write it on my side, I can write it on my side also. You're saying put a typo here? Yeah. Then use Strip mode over here. So that's the problem with back porting. Back porting. The Strip motion is to make it a sub-year, or it's an entire year. So earlier you had to pay attention to every single line of script, every single line of script. Sorry? I'll make a script per pipe. Per pipe, exactly. So that's much better than the entire pipe. So JavaScript basically has that functions property, right? The voice team will do this. Is this also voice chip? The use script. The use script has to be the first line in landscape. Yes. It cannot be second, third, then it doesn't apply. Yes, good point. This has to be the first line in landscape. What is the performance of back porting? Uh, measure. I don't know. I haven't really done a performance analysis of Strip mode because it's not from Strip. But I would imagine it shouldn't be, shouldn't impact your performance. It's what my expectation would be. But you think the quality points actually would sense to use your Strip. Absolutely. Absolutely, yeah. I mean, given in production code. Correct. Given that it's back port compatible, it's not going to break your apps. You could use it. And you can use this to kind of melt your app. In your development environment, you can use a modern browser. Right. And if it runs fine, then chances are it won't find out what the process is. Where you do JX-Lint. Correct. JX-Lint. Yeah. So this is like, like, you know, a little bit of JX-Lint inside the language itself. It's part of the standard. So this is? Curitically, I think Strip mode will be faster. Sorry? Curitically, Strip mode will be faster. Because now your compiler and everything knows that what's going to come in. And there's even a little double check that's going to happen if you don't use it. Yeah. I mean, it could be. I mean, you could debate about that. I mean, I guess his concern is that now the engine has to perform these additional checks. See, earlier there was default behavior. So this Strip mode is not just about variables. There are, you know, many more other checks that are made. So in this case, earlier it just added a variable. Now it has to go through an error. And there are other checks that has to be made. So the concern was about the performance in fact of these additional checks. But then, you know, these days, most JASCII engines are smart about how they run JASCII, right? They typically compile it and they make it into a new code and things like that. And maybe there you could potentially get some benefits out of making some assumptions, especially with inline caching, right? So things like that, maybe there are some performance benefits by using Strip mode. I don't know. I mean, there could be benefits from a performance method. So that gentleman talked about variable scoping and boosting. In fact, that's the next culture they wanted me to talk about. So again, you know, if you're coming from a Java, Java C++, C-shanaut or some static type language background, then this is something that you might find surprising, right? So in Javascript turns out, maybe you don't know what you can do is, you can do an example and see what you can do. So let's say I define a function here. And you know, let's say I have some if check here, right? The actual check doesn't matter. So var i, and then I say, I say equals 10, right? And let's do it differently. Let's say i equals 10. And then I say print i, right? So what's going to be the output of this? Obviously, I have to call this function. So what do you think is going to be the output of this little script? So how many of you say 10? So how many of you say I'm defined null error? It's not it. So it's kind of a javascript, right? You never tell what's going to come out. So 10, print 10, right? So initially when I saw this code, right, I was like shocked because this is very complicated. Pretty much every other language, this would throw an error or javascript, very permissive, so maybe we'll just put it down and define. But that's how it happens, you get 10, right? So that's the funny thing about javascript, right? It's about what defines scope, right? Pretty much the only thing that defines scope in javascript turns out to be a function. In fact, in the previous gotcha, one of the things that I was saying is that you can put all of your global code inside an immediate function. And I was saying that the reason that you would want to do that is because you restrict the scope of all your global to that particular function. So another reason why that turns out to be a good idea is because functions are the only thing that defines scope. So what happens here is, in languages like C++, curly braces defines scope, right? So if you define something inside the curly braces outside of it, it's not accessible. Not in javascript. So in javascript, essentially what this function becomes, it becomes something like this, right? So this is what, so here the behavior is pretty self-evident, right? You declare it here, you're assigning it here, and then you're printing it here. So that's very clear. But if you declare it inside here, it's probably not quite so clear. So this concept is called as variable posting, right? So what javascript runtime does is when it is executing or passing a function and running it, it's going to take all the symbols, all the variables that are declared inside that function and move the declaration, not the definition or assignment. Those things remain where they are. The declaration to the top. It will drop that that particular scope. So that's essentially what happened. In fact, this is the thing that actually makes something like this possible, right? So do you think this will work? And calling the function and then defining it. It does work, right? And the reason why it works is because of this. So in this code, this whole thing has been defined here. So it takes this whole thing, puts it in the top. So it basically transforms this code into what I've done earlier. So it takes this, puts it in the top and puts the declaration and the invocation at the bottom. It's debatable, you know, whether this is a good idea or probably this feature was introduced to make this kind of thing possible. But probably it's not such a great idea, right? I think it's always safer to declare and define things first before we can use them. So this is the main hosting. So how do you deal with it? Declare everything on the top, right? There's no magic things for this. So there's no strict mode thing that you can do to magically fix this. You have to declare everything in the top of that particular engine scope. In ES6, I think they kind of deal with these kinds of issues with the different kinds of syntax. In what the LED keyword, I think that defines, allows you to define a scope where the variables that you define there are restricted to that scope. Probably you have to spend some more time waiting those things up. But with ES5, this is a structure that you have to think about. ES3, you know, all of the versions. The last thing I wanted to kind of talk about is about prototypes, right? The last option. So JavaScript is a prototyping inheritance language, right? There are a lot of frameworks out there that try to kind of mimic what you are able to do with inheritance with languages like SQL's first one, right? See, inheritance in languages like SQL plus ESHA or Java are implementation inheritance. That's what you have to do. Then you can override it or you can completely replace it with your senior subclass and things like that. JavaScript is not that, right? Inheritance in JavaScript is not implementation inheritance. But there are libraries which try to simulate that, right? So that people are coming from a static language background can be comfortable here. But I think it's important to realize what JavaScript inheritance, how it works. So it's very simple. Basically, it's called implementation inheritance, right? The idea is, let's say you have some object here, right? Let's say a person. And here I have name, I have age, right? Now, think of this particular object as being a prototype, right? This defines what objects that inherit from this object are going to look like. So that's another point of the difference, right? With implementation inheritance, the entity that you use to inherit from stuff is a type. Types inherit from other types. In JavaScript, that's not the case. Here it's instances, right? There's no type. Everything is an object. So what you can do here is you can create an instance which inherits from another instance, right? So you can do something like this. I can say person2 equals object of real or person. So in this case, what essentially happens is P2 is a new object, right? And P2's prototype is person, right? So think of a prototype as being this hidden member inside an object. So let's say I say P2.name equals bar and I say print P2.name, right? And that turns that. So essentially what happens here is when you say P2.name, P2 itself does not have that defined in that object. So the runtime would go and inspect the prototype. So if you find out what is P2's prototype, that's person. So if you go here, person, person does have a name. In fact, if I run this like this, right, then you get P2 and then you get bar, right? So in this case, P2 didn't have that property. It went and looked in the prototype, got name and then printed through and then you obviously assigned and then printed that. So this is how the prototype works for P2 and you can add more stuff. In fact, if you want to add additional members, you can do that right here. You can say, you know, gender. I think it's a value, right? So now I can say print P2.gender. So it runs F. So you can actually extend it. So when you say P2 is a created by a person, person is a prototype of P2 and then P2 has some unique members. One is called as gender and you can keep extending that. Properties, additional members inside P2. So this is great. Now the gotcha is this, right? So imagine that in a prototype or let's try something here. So we have P2.name equals bar and then I say print of P2.name, great. What do you think is going to happen if I say print person.name? Any guesses? So here I'm assigning this to bar. This should print bar. What is this going to print? Poo. Let's find out. So it prints poo, right? And that makes sense because this is another instance, right? So created P2 comes in opposite of create. This is a new instance altogether. So modifying this instance should not affect this instance. So that makes sense. This is good. And this works as we expect. So when you say P2.name, actually the property gets created on P2 directly. It doesn't go and modify the prototype's name, right? So what happens if I say something like this, right? I have an address object here, right? And I say street, P1, series. I can go and say print P2.adress dot street, right? And that works. So let's see one is printed. Now the reason why it's printed is runtime would go and see P2 has a property called address. No, it does not. It goes and checks P2's prototype. Does it have a property called address? Yep, it does. So it touches the property and that has an ST property on top of that. It works, right? Now let's say I want to change the city on P2.adress.city. So I'll take this and print city here and then I print person.adress.city. So in this case, what it is going to have? Yeah. So that turns out to be the dot channel. Now you can notice what I changed here is P2 but person city also has changed. Right? So both the P2 has changed and the prototype has changed. So if you want to take it, yes, why this happened? Yeah, so essentially it's shallow property but see if you think about how the JavaScript engine works, right, it makes sense because here when you say P2.adress so this part alone, right this is a fetch operation, right? We're not assigning anything there. It's just saying get me the address object on address property on P2. Front-time person checks as P2.adress no, it goes to the prototype, gets the address there and it returns that. Now when you say dot here, the object you're operating on is the prototype's address, right? It might not be evident by looking at the code. Hold on a second. I'm using P2 here, right? I'm doing P2.adress. Why is it going and changing person.adress? Turns out because so basically when you have an object inside your prototype, you're assigning values to it, it's essentially like a shallow property as you said, right? So when you say name, age, fine, right, no problem. When you assign to it, it creates a new property for P2.adress but if it's an object and it's a problem so how do you deal with this? So you know you pretty much do deep loading yourself Front-time doesn't support this some libraries out there that come with some variant of cloning function. Writing a generic cloning function turns out to be very complicated. So if you have a pretty good snippet, I would say on the depth-out overlap I can put it up once on data to our site or whatever and you're also looking at it. Sure. Yeah, it does pretty and then most of the edge cases also go into the pool. Yeah, so this is something that you have to watch out for in case you have a deep object that is inside your prototypes, right? So that's pretty much it. This is what I wanted to talk about. Yeah, exactly. Thank you. So that makes the prototype almost useless. Everything that I want to create will end up just work with it. Yeah, that's kind of interesting in the language itself. So if you want to use prototype inheritance that has been done this, the way it is right now in ES5 you will have to take care of cloning itself. Does the coffee script eliminate these kind of issues in the screen? Not to familiar coffee script. I hope that this is handled. There is already no coffee script and it will run in there. I think what I would like to do would be all the variable declarations right? I don't know the ES6 spec that has any proposals for filling this issue. Who will be the compliance of different prototypes for ES5? Because ES5 on JavaScript has such a thing of is used in Q as two scripts is there in Windows, is there browsers available on a JavaScript engine. So where can we check up on this? So this is pretty easy nowadays where compliance pages, chart sheets, whatever. So, see with ES5 it was by design like I was saying earlier a lot of functionality in ES5 can be provided through libraries. There are a lot of polyfill libraries available on the modernized beta page where you can find backfills for ES5 features, but not all of them. So it's stuff like you strict there is no way you can provide a backfill. So I had a little slide here that showed kind of the if I can find it so I put together a long pen. So this kind of shows the IE10 platform for even three days. This kind of shows the ES5 compliance across different browsers. It's very old right, 5.7, Chrome 14. What is Chrome version now? Like, 175. So this is very old. But this shows ES5 is sweet from if you go to ECMAScript the ECMA side. So it has about 11,016 test cases right, it's a huge amount of test cases. And this graph basically plots how many test cases failed across different browser in JavaScript engines. And that back from Chrome 14 was kind of lagging behind. I don't know what's the status right now. I'm sure it's better. But you can see that the worst performer is still only 427 of failed test cases which is mid-school compared to 11,000 test cases right. So with all modern browsers compliance is really stellar for ES5. But what about other rendering is a huge script is supposed to be ECMAScript 11. We'll have to see that. I mean the script the suite is completely free for anybody. So you can download run it here and see what happens.