So now we're going to talk about how you use JavaScript in a browser. As I said before, this is just only one of the possible ways that you might use Java. But this is pretty much of what we call vanilla Java or basic Java, or Java without view, or Java without jQuery, or Java without node. This was the original JavaScript purpose. It was to be in the browser, augment HTML. So here we have a happy little bit of HTML. We've got some HTML, we got a body, we got a paragraph tag, and we got the script tag. So the script tag says, "We're moving out of HTML syntax and we are then writing some JavaScript code, and we are talking to the document." The DOM is in a sense to that part of your browser, that's the pixels you're seeing. So this JavaScript code can write to what you're seeing on the screen by going through this variable called document, document.write, writes onto the screen. So if you take a look at this code, it's coming down. Its outcomes, the total outcomes, the body of the paragraph comes out then it drops into JavaScript, and then this little string gets written out and then it goes back in. The noscript tag is in case there's no JavaScript, which is really rare these days, and then the paragraph comes out. So the point is that, this has created a three-line web page. The first and the third line come from HTML, and the second line comes from JavaScript. Not that this is a particularly useful example, it just points out that JavaScript has access to the screen when it's running inside of a web page, that's powerful and we're going to drive a truck through all that. So whenever I learn a new programming language, the first thing I got to do is print a debug statement. The debug statement is called alert, and you say, alert, you put a string in it and it stops the program and you have to press Okay then it continues on. So that way I'm like, "Did that code run or not?" I just put a little alert "Hello World" in there, and then poof up it goes. Then just pops up a little dialogue and you press Okay, and it continues. So that's really quite nice. So here's a little example of that, where we're cruising along, the paragraph is written out. One of the things that you'll notice, is that this alert box actually stops the JavaScript. So we switch into JavaScript, the browser is still parsing the page and you'll see sometimes little spinner is still spinning. So it stops, it puts up the alert dialog box, here I am, and waits until you press Okay, and in a sense, your browser is paused at that point. Because literally, it doesn't know what you're going to do in this JavaScript has every right to change every bit of this page because the JavaScript is in the page using the document. So it pauses until you press Okay, and then it picks back up and then it will write "Hello World" and the second paragraph will come. But alert, you just stick it in your JavaScript and whatever is happening, bang, it stops right there and everything stops. So it's pretty cool thing. So you can't use it too much, you can't use it in a loop and if you do it too many times, your browser will like, "Why is this page throwing up so many alert boxes?" But in a pinch, it's the simplest thing. So there's three ways to get JavaScript into your web page. One is inline in the document, and that's what I just showed you with a data data script, data data slash script. We've done this before, it's part of an event an HTML tag, I'll show you that. Or you can put the JavaScript in its own little file, usually ending in.js. So here's the second one, this is the one where we're putting in a onclick method. So we've been doing this, we've been doing onclick methods, where we'll have an H ref, and then onclick, and then say something. In this one, this part here in the middle, that is just JavaScript and that's why it has semicolons to end each line. White space doesn't matter, this isn't Python, don't need new lines, etc. So when we clicked on this "Click Me" button, that is going to start running this code. Now, the page is already fully rendered and the "Click Me" button is waiting to be clicked and on click, that's when a click happens, event-driven programming then it runs the alert pauses, I'm going to change change the color there, it runs the alert. How come I can't get it to be yellow? There's yellow. Clear it, go back up, and be yellow. Thank you for being yellow. So you click on it, it runs this JavaScript which runs the alert, which pops the box up, then you press the "OK" and then it continues on this code. Now, the return false is telling the anchor tag not to follow the link. So that basically says, "I the on-click method have processed this particular click" So that's what the return false does. So we basically just have JavaScript in the middle of a tag that's triggered when an event happens, so event-based programming. The other thing we can do is we can make this in a completely separate file. So we're going to have this file called script.js. Now, it doesn't use a script tag because it knows that it's JavaScript. So that's just code. This happens to be one line that's got a document.write Hello World. Now we embed it with a script tag and a slash script, but now we just say source equals script. It pulls it in, it loads, and runs, and parses that whole thing and as a side effect, it writes out one paragraph, hello world, and the second paragraph. Of course, usually, this isn't doing work, usually, this is defining a bunch of functions that we're going to use later. So usually, this script.js is a function, function, function, function. So we're loading a library of functions that we're going to use later, but I just put this document write so you can see when it's happening as the document is loading. So in any programming language, we can make errors as a programmer. We can make syntax errors. The problem is, when you're looking at a web page and in that web page there's a JavaScript syntax error, they decided a long time ago not to bother the poor user with a JavaScript syntax error. Because really, the person, unless you're writing it in the first place, the person looking at the screen of Amazon.com or dr-chuck.com, I've got a syntax error in dr-chuck.com, why tell you that there's a syntax error? So what it actually does is it just like, "Well, I guess I'll stop running the JavaScript because it's got a problem but I'm not going to tell the user which means my page is broken and I don't even know that." So it stops and so a syntax error has happened and it just stops the execution. So let's take a look at a little example here, a little example where we have two chunks of JavaScript. We come in and we get the first one and this first one has a syntax error. That means the alert is not going to work. Now, what happens is it in effect ignores everything after that point. If it's executing through a script file, it might be defining a bunch of functions. If it finds a syntax error a third of the way through, the other two-thirds don't matter because it has stopped parsing that file until the end of the script tag. Then, when it sees a new script tag, hope string is internal, and it starts parsing it again. So that's why when this page runs, you see first paragraph, this goes blows up, which means it skips down to here, then you see two paragraph come out and then you see the alert second time. You never see any of these alerts because that error is on the first line of the JavaScript, which invalidates the rest of the JavaScript, but until another script tag. Sometimes, what you're doing is you likens including one library and other library and another library and another library. If you have a syntax error in that library that you're including, most of that library won't actually be activated. But it doesn't mean if you have like five libraries that you're loading with five script tags, just because the first library has a syntax error, it can still load the other four libraries, but it pumps, there could be hundreds of lines of code here and it all is for not because it saw a syntax error and ignored the rest of it up to the end of that script tag. Now, the end user can't see the air. So when you're doing software development, you've got to put in extra effort because when you're like writing code and hitting "Refresh", well, yeah, that's the user hitting the "Refresh" in the browser but if you're writing JavaScript, you want to see what's wrong. So we have places that we have to look to see if there are actually JavaScript errors in our code. Once we start developing JavaScript, I assure you that there will be errors in your code. There's always errors in my code. So all of these situations, whether Ellie browsers, Firefox, Chrome, Safari, they all have a web developer console that you unlock, there's always one of these tabs that says Console. Console is all the error messages that are coming up. So if you made that same bit of code and you had the console turned on, you would see a happy little error that says syntax error on line 3 of that file. I mean, it would just run, the okay is the later in the file, but it will tell us that. You'll find that once you start developing JavaScript, you're making a big mistake if you don't have this little developer console open almost all the time, at least to the JavaScript console because that's how you debug your JavaScript. It'll literally just silently, you're like, "I changed something and nothing happened. I'm going crazy." Well, look at the console. You changed something but there was a syntax error above it and so it didn't matter what you said after that. It really ignores everything after that. That's why it's so important to have a debugger console doing all the time. Thankfully, all modern browsers have a good debugger console. In the old days, Firefox is the only one that had a thing called Firebug, which was this console but you had to install it and add it. A person wrote it as open source project and it got so popular that people just put it into the browsers rather than making you install it. It was pretty cool. Back to debugging, there is a function called console.log and it allows you to log variables, strings, and whatever. Unlike the alert, it just shows up in that console. So you can put it inside of a loop. You don't have to press "Okay". It doesn't stop anything. It's really more of a debug print. In this particular example, it just runs, it doesn't stop. The alert stops everything. I use the alert like, "What is going on?" But if I'm really debugging something like in a loop, I'll use console log. It comes in, console log comes out. It says alert, I clicked on it so you don't see that. The second log comes out and away you go. This is a better debugging mechanism. If you look at systems that I've built, when I have a really complex JavaScript, I will sometimes leave console log statements in it. If you use Sakai and you're at a school that uses Sakai, and you do console log, you will see error messages in your production system that I left in there because of the parts of the code that JavaScript was so tricky. I want to be able to talk to you if your stuff breaks. I want any developer to be able to pop this window open and get a clue as to why some of JavaScript stuff is breaking, because there's just so much complex JavaScript in it. I'll leave a few little debugging clues. If you go into the auto grader, you can watch this. I just like debugging and it's not all that costly. I don't put a ton of them in because then it looks a little sloppy. But I do put a few console logs in. You can use a debugger. It's a full featured debugger, you can view the source, you can inspect. You probably by now have figured out how to do inspect elements, so you can look through that. What you're looking through there is the Document Object Model. But they also have a full featured debugger where if you're looking in the source code, you can go onto the line that you're interested in and click, and then that will set a break point. But usually the code's already executed, so you have to set the rate point then you got to refresh the page, and it remembers where you set the break point and then it stops. You set the break point and hit "Refresh." You'll figure it out because by the time it's all done, it can't go back in time. It's past that line so you have to see the line, set the break point, refresh the page, then it knows to catch the break point as it's going by rather than going back in time because it doesn't remember. They can't run time backwards, just forward. So that gives you a little sense of what it is like to do JavaScript in the browser. Now, we're going to just look at JavaScript as if it were a regular programming language. This applies whether it's in the browser, in the server, in view, or whatever.
