[MUSIC PLAYING] DAVID J. MALAN: All right. This is CS50 and this is lecture 11,
so the end is actually quite near. And among the goals for today, and
next time, and our final lecture time together, is to start to tie things
together as far back as week zero. And in that spirit, I thought we would
begin by reflecting on this clip here, which you may recall
from a few weeks ago, wherein we tried to look in
popular media at the perception that viewers might have of
technology, if they relied only on shows like this, and on CSI, and the
like, where what you see on the screen isn't really technically accurate. And this is wonderful to say, but
most recently did Stranger Things 2 come out, which most of you are
probably familiar, and probably finished, if you're like me, on
Saturday after it came out on Friday. And on the screen-- let me say this, not a spoiler-- but I was so proud of
this particular show. But before we get there,
allow us to tease you with CS50's own take on that same show. If we could dim the lights. [STRANGER THINGS THEME PLAYING] OK, so that was mostly just
a set up for the following, and if you haven't seen Stranger
Things, or at least all of the episodes, I really don't want to
alienate the entire internet, let alone everyone in this room,
just close your eyes briefly, this isn't really a spoiler, it's all
technical, doesn't spoil any plot, but no one is going to
care in a few weeks time, so we thought we'd reveal this. So now's the time to put
your fingers in your ears and close your eyes if you don't want
to know that, at some point in the show, there's this scene, here. And of course, in every show
out there like CSI and Law and Order and the like, if you kind
of zoom in and enhance the screen, it's just nonsense, like a crayon
type program, like we saw from CSI. But I was so proud to see that, if you
actually zoom in on this screen here, you see this code, in a
language called Visual Basic. And even though we don't
teach Visual Basic, nor do many people use
Visual Basic as much anymore, can you glean what this programmer
was doing on the screen? What seems to be going on? AUDIENCE: Is it like getting a
four digit password or cracking-- DAVID J. MALAN: Yeah, it
was a program with which to crack a four digit password. And if you glean all of the
various loops in this structure, you'll actually see that it's trying
to come up with a digit after digit after digit after digit,
trying all of them, until finally, when it finds that
value, something interesting happens. And so now, those of you who have
your eyes closed and can hear this, you can take your fingers out
of your ears and we'll proceed. But perhaps the first example
in media of an actual program that works on the screen. So now, today, we look
back on a model we've been introducing for some time, MVC,
model, view, controller, which is just a fancy way of describing a
type of programming that's really popular in the web these days,
whereby you have a controller, which is the code that you've
been writing, in Pset 6, and now Pset 7, in application.pi. The fact that it's called application.pi
is just a convention in flask, but that's where all of your logic goes. Like the code that actually
drives your website. In what folder or files
are your so-called views? Say again? AUDIENCE: HTML? DAVID J. MALAN: Yeah, the HTML file. So in the templates subdirectory,
which is a flask thing also, you have a bunch of
HTML files, which are the views, the aesthetics, or the
presentation of your program's information. And then last week, did we introduce,
finally, the model, the M in MVC, which represents your
data, your database. Maybe it's a CSV file, maybe it's
in API, for getting stock quotes, maybe it is a persistent database,
wherein you store your users and stock portfolios and more. And together, these
three entities compose a pretty interesting application,
whether it is a Pset 6 or Pset 7 or beyond. But today, what we'll do is introduce
one more piece and one more language. I know we've discovered quite
a few languages thus far, Scratch, and C, and Python, and
SQL, not to mention HTML and CSS. But today, we introduce the last of
our languages in CS50, JavaScript. And you'll see that JavaScript is the
last of the enabling technologies that will allow you to build features
and tools very familiar to you nowadays on your phones
and on your laptops. And so, before we do that,
let me go ahead and pull up one example, via which
we can bridge last week and this, a final look at the
Frosh IMs website from yesteryear. And let me go ahead and run
this program as follows. Flask: run. This is Fosh IMs 4, available
in today's distribution code. And if I go ahead and open up this
URL, it's a very simple program, that I'll zoom in on, that
allows the users the ability to register and to see who is
registered and to register themselves. And if I want to go
ahead here and register, I'm going to see a form like this,
and I can choose from the dropdown my Harvard dormitory, and then
actually register my name. And then in very first version of this,
weeks ago, this program did nothing. We just threw the information away. Then we did something a
little more interesting, whereby we saved the data
to someone's email inbox, by just sending them an email, then
we added CSV files, which weren't bad, but what are downsides of
using just CSV text files? AUDIENCE: They take a
long time to search. DAVID J. MALAN: Yeah, they could
take a long time to search, because, especially as they grow
longer and longer, the best you can do is linear. You have to search the whole
file just to find one value because there's no data
structure there, it really is just like an array of lines,
if you will, a list of text that you have to search over. So we also don't have features
like select and insert and delete, these verbs, or operators, that
we actually got from a database last week, which allows us to do more
work, more easily, without having to write as much code. We can literally just
execute a SQL command, like select or insert or
delete, update or the like. So, how might we go about
building a piece like this? Well, recall, that if we go into
the source code for Frosh IMs 4, we'd have some entry
point, like application.pi, and a few different routes. And this might be familiar if you've
dived already into CS50 finance, the first of these routes, up top
though, just renders index.HTML, and that's where I see the menu. And odds are, an index.HTML
is just that bulleted list of three options, each of which
links to a different route. Then the routes do start to
get a little more interesting. And on the screen here,
on line 13 downward, is the logic, my controller
code, so to speak, that allows me to insert
a user into my database. And how do I do this? Well, on lines 15 and
16, I ask the question. If the requests method that's
just come in is get, what do I do? In English? Put up the register template. So show the user
register.HTML, using the using the render template
function, which we've used before to spit out HTML files. Else, if the user has
used post, that is, he or she has clicked a button,
presumably, and posted to this same end point, let's just
distinguish the behavior. If they've submitted a form via post, then go ahead and
execute these five lines here. And this line here, 18, if not request,
or if not request of name and dorm, that was just a way of saying if the
user forgot to give us his or her dorm or name, then render a failure
message, such as that and failure.HTML. Otherwise, if he or she did
give us the information, we can use CS50's execute method on this
DV variable, which we declared up here, we can insert into the registrants a
name and dorm's, specifically these two values, and then recall that
this colon syntax was new. It's just a convention,
in a lot of the SQL world, when you want to plug-in
values, rather than use PercentS, back from our
C days, rather than use curly braces from our Python F
string days, you instead just pass on two values via
these names like name and dorm. And then what happens here, exactly? If I go into this web
site, and I register David from St. Matthews, and click
register, because the application is running with flask, I'm
told that I'm registered. And how can I prove as much? Well, let me go ahead and
open up another terminal and go into today's source code
Frosh IMs 4, and then if I type LS, notice that this is what
composes this application. One of these files is Frosh IMs.db, and
if I go ahead and run this command line tool, SQL light, 3 on
[? Frosh IMs ?] db. I just got a command line interface. And you might not be comfortable
with this approach, and that's fine, but it allows you to do very simple
things like show me my schema. And I can see, from this textual
interface, what the format is of that database, it's just got
one table, called registrants, and then if I wanted to
see who is registered, maybe besides me, what can I type
in this command line interface? What can I type here? Yeah? AUDIENCE: Select star from registrants. DAVID J. MALAN: Yeah, select
star from registrants, semi-colon, and I see
a very text-based table showing me who is in the database. And thus far, it's just me. And I could tinker with
this at the command line, I could update and delete, and so forth,
but the key takeaway from last time, was that once you're a little
bit comfortable with SQL, you can begin to use
statements in SQL, put them between double quotes in Python,
and have Python execute those SQL queries for you on your database. And meanwhile, let's glimpse
at one other feature here. Before I registered a moment
ago, I had this dropdown menu. And I could have hardcoded this,
and that would certainly be fine. But if I wanted to actually
delete a user and, actually, let me show you this here. If I go into, what files is that,
that's in my templates directory. And so if I go to
register.HTML, here, I hardcoded all of those dormitories that
are available to Harvard students to register from. But what about my unregister page? Let me actually go back
and click unregister, and you'll actually see here,
I see kind of a prettier menu that's got the person's name and their
dorm, if he or she is registered. And I somehow want to
unregister the user. Well, if I go ahead and submit
this form, what value might I want the browser to submit
from the browser to the server? David? Matthews? David from Matthews? Something else? What should your instincts be for
when you submit something from a form to a server, when you
want to act on that data, like here, like unregistering the user? What do you think? AUDIENCE: ID number? DAVID J. MALAN: Yeah,
maybe their ID number. So, why? I have this string, David
from Matthews, why not just submit the string, David from
Matthews, look for it in my database and then delete David from Matthews? AUDIENCE: There could be
other Davids in Matthews. DAVID J. MALAN: Yeah, there's
ambiguity, potentially. If there's a couple or
more Davids from Matthews, coincdentally, you might end
up unregistering all of them, or both of them, or
however many they have. And so you want something
primary to identify users. And primary is an allusion to primary
keys, which we said last time, is generally a number, such as the
number one, which we saw a moment ago. When I looked at the contents of
this database just a moment ago, notice that David did indeed have
the unique ID, one, or at least we would see that it's
unique if we keep adding more and more users to the database. And so how did I go
about generating this? Well, if I go to
unregister.HTML, notice that I do have to use a bit
of one other language, it's not a particularly
fancy language, but it's called Jinja, the templating language. And notice what I did here. This is the form, unregister.HTML,
that the user sees when I'm trying to unregister someone. I have a form whose action is
unregister, the method here is post, and then I have the select menu. Select Name equals
quote/unquote ID, because I want to make clear to the server
that the value it's going to receive is called ID, and it's going to be
a number, like one or two or three. And then this is how,
now, I iterate over what? What am I doing in line 6 and 8 and 9? What's going on there in
kind of English terms? AUDIENCE: Number of
registrants in your SQL. DAVID J. MALAN: Yeah, I'm iterating
over the number of registrants I have in my SQL database. Well, it looks like,
and I'm just inferring, it looks like I have access
to some registrants variable, more on that in just a moment,
for registering in registrants, the syntax we've seen
before in Python that just lets you iterate over things in a list. And even though this is technically
Jinja, it uses some similar syntax. And what do I want to do on
each iteration of 4 loop, as I iterate over David
and Maria and Brian and Rob and whoever else is registered for
Frosh IMs For each of those students, I want to output open bracket
option value equals quote/unquote, and this is a bit of a
mouthful, but this just says, output the current
registrant's ID number, and the double curly braces is Jinja's
way of saying, take that actual value and plug it in between those quotes. Meanwhile, recall that an
option in a dropdown menu has two parts, its value
and then the thing that's between its open tag and its closed tag. So what I want the user to see here
is quote/unquote registrant.name from, literally, regristrant.dorm. And that was just a design decision. And it's that reason, for that
reason, that the format of this list is exactly that. So and so from such and such a place. And so the key insight via
which you can make that happen in application.pi, realize, is this. When I visit "/unregister" via "get,"
which is the default if you just visit the URL, notice that
I'm executing a SELECT, just like you proposed a bit ago,
SELECT star FROM registrants. But this time, rather than
just seeing it on the screen, I want to do something with it. So I take these rows that are
returned from the execute method and I just pass them
in to this template. And I could call it anything I want. I could have called it
rows or x or y or z. But I called it, a
little more conceptually, registrants equals those rows. So I'm essentially handing to the
template every row from that database table. And in this way in Pset
7, if you haven't already, can you begin to construct
the most dynamic of databases and the most dynamic of websites,
taking input from the user, saving it, as we did when I registered,
even deleting it or updating it by programmatically generating content. And this is the difference
between a static website, where if you look at it,
every day it looks the same. Because someone literally typed it
out, hard coded, and saved it forever versus a dynamic website, like
Gmail and Facebook and the like, that are obviously continually
changing with more and more content. And so underneath the hood of
Facebook and Gmail and other apps are databases like something
SQL based, using languages like Python and/or JavaScript and more. And so we'll begin to see
what other features we can now add to these kinds of websites. But any questions at this point on that
sort of model for creating a web based application? Anything at all? Yeah. AUDIENCE: How again does a
program know whether a request was submitted via get or post? DAVID J. MALAN: Good question. How does the program, application.pi,
know whether a request came in via get or post? Where is that information
stored or available? Does someone recall? I keep forgetting to bring
one more of these props. But recall that virtual
envelope, oh, here's one more, so recall that when a
browser sends a request, we sort of played along
by saying, oh, well, it puts a request inside of this
envelope like get me the home page. Or here is a photo or here is my
name that I'm uploading to the site. There is literally a
message in here, an HTTP message that says the word "get" or
"post," literally as its first line. And so the moment the server sees that
message inside the so-called envelope does it know if it was get or post. And realize, this is just me
being a little sort of tidy. There is no reason that we couldn't
define two routes like this. We could, in Flask,
have one route called register_form whose sole purpose in life
is to show the user the register form. So literally, the only thing it would
do, is let's see, def register_form, and it could literally return
render_template("register.html") Right? It can just blindly assume that
if the user visits register form, he or she got there by
via get, the default. And then, we could have
that user submit elsewhere if the route is actually register. The method for which, because
you have to explicitly say post if it's not the default for you. And then I say def actually_register. Here, I could now have
all of my database code that assumes that only if the
user has hit this endpoint has he or she submitted the form. And then I put all of my
database related code there. I point out that I'm just kind of
being a little tidy or a little anal when it comes to designing this. Because I just don't
like the idea of having like this end point and this thing. It's just two separate
things to think about. And also what the user sees is
not pretty, as pretty of a URL. It's not just /register, which
makes a little more sense. And so intuitively, this way, can
we have the user stay constantly at /register. But the website behaves
a little differently. If the request comes in by a GET,
show the user something, else, if he or she has submitted a form,
go ahead and do the database thing. So that's all. It's just me kind of compacting
two separate routes into one just to keep things tighter. Good question. Other questions? All right, so let's now transition to
a new world altogether of JavaScript. And even though it might
feel a little overwhelming, to date, that we've looked at
yet another language already, realize that the important takeaways
today are actually relatively few. We're going to see some familiar syntax. But there's a lot of shared features
like functions and loops and conditions and variables. All of those are present
in the same language. And syntactically, it's very,
very similar to C and Python. So that's one takeaway. And two, it's going to
allow us to explore really a different type of programming. Because consider what
we've done thus far. When we wrote programs in C, we
just started writing like #include. And then we had int main and so forth. And we just wrote our
programs top to bottom. We compiled them. And then we ran them. And they executed, essentially,
top to bottom, so to speak. We started doing that in Python, too. In Pset six, you might recall the
compare program or the score program. Those, too, you just wrote
Python code, top to bottom, and then executed those programs. But then we started doing something
a little different with Flask. In Flask, application.pi, when you
run it indirectly by typing flask run, does it ever quit? No, I mean, you see some
funky output on the screen, like some IP addresses and all of
the requests that are coming in. But essentially you see a
prompt that never goes away. Because essentially, built into
Flask, like any web server, is really an infinite loop. It's not a bug. It's a feature whereby
the program, once running, is just constantly
listening for HTTP requests. And any time your application.pi
gets an HTTP request, how does it know what to do with it? There is no main function. So if it's just sitting there waiting
and waiting for requests to come in. How does application.pi
know what to do and when? Like what's been going on all this time? AUDIENCE: By comparing the endpoints. DAVID J. MALAN: Yeah, that's it,
just comparing the endpoints. So inside of this envelope
that I keep grabbing is a request for a certain page. It's get/register or
post/register or the like. So as soon as application.pi
or specifically, Flask, the framework we are building
our application on, notices, oh, I see /register. Let me see if the programmer has
defined a route for /register using our "at" syntax, @app.route. Then, oh, that's the function that he
or she presumably wants me to call, upon getting that specific request. And it satisfies it by
returning some value. But then it goes back to just
listening in this infinite loop. And so this is an example of what we
might call event based programming. You're not just writing a program top
to bottom that just starts and stops. You're writing a program that's just
now always running unless you forcibly kill it by hitting control-c
or restarting the IDE or something dramatic like that. Otherwise, it's just constantly running. But the events that might come
in are a receipt of messages or HTTP requests like these. And similarly, in a
browser, it turns out there are bunches of
different types of events that can happen, not on the internet
per se, but just locally, here. Like, every time I click my trackpad
or mouse, that's an event, click. Every time I touch the
trackpad or move my mouse, that's an event, a drag
event or a mouse move event. Anytime I click somewhere on
the screen or select something from a menu or type in keys to
my keyboard, that is an event. So what we're going to
start to do today is wrap up the last of our user interfaces. The past few weeks, we
focused on the server. Today and next week we'll focus
on the client, the browser. And together then you can
have two pieces of the puzzle finally talking to one another,
listening for user input on the browser and doing something with the
user's input on the server. So let's make that transition. We began with Scratch, of course. We transitioned to C and
then Python and then SQL, which was a little different
syntactically, certainly. But it did allow us to
get data and update data. But today we'll focus
on this JavaScript. What is the relationship, technically,
between JavaScript, today's focus, and the language some of you might have
learned in high school, especially, called Java? Yeah. AUDIENCE: It's like [INAUDIBLE] DAVID J. MALAN: It's like what? AUDIENCE: [INAUDIBLE]
It's totally different. DAVID J. MALAN: Totally
different, exactly. It was really just a marketing thing. Java was very much in vogue at the time. JavaScript was a new language. And hey, why don't we name our
language after something else that's already pretty popular and
kind of ride that wave. But they are not the same language. If you know Java, you know Java. If you know JavaScript,
you know JavaScript. Syntactically, they're similar. But there's no fundamental
linkage between the two languages. JavaScript is a language,
now, that has historically been used in the confines of a browser. Which is to say, your Mac or PC executes
this language in your Mac or PC. However, it can be used
and it's increasingly being used on the server, as
well in something called node.js. But we're going to focus today and here
on out on its use within the browser. So fortunately, it's not all that
different from Python or even C. Here is an excerpt from
a function in JavaScript. What's familiar? Well, we have the keyword
function, which we have in Python. We have some open parentheses,
which we have in Python. We have comma-separated
lists of arguments, which we have in Python
as well as in C. Curly braces, which we have in C, but not
so much in the same way in Python. And so it looks like it's kind of
an amalgam of some of the features we've seen thus far. Indentation doesn't strictly matter. So now you're sort of on your
own again, such that good style means that you have to be indenting
proactively and not waiting for the interpreter to yell at you. But notice this, this is also
legitimate in JavaScript. And what just happened? Before. After. What is this second
version apparently lacking? AUDIENCE: A name. DAVID J. MALAN: A name. And it turns out, in
JavaScript, you can have, and it's a very common thing to have,
anonymous functions, functions that have no name explicitly, otherwise
known fancily as lambda functions. And they, literally, just have no name. Now, why that's useful, we'll soon see. But just realize, that's going to
be a feature that's also present, technically, in Java and can be
implemented in other ways in C. But it's very much a common
paradigm in JavaScript. So getting comfortable just with the
idea of your functions having no name will be a takeaway for today, as well. Variables, you'll notice this. And you can perhaps infer what this
does in English, even if you've never seen JavaScript before right now. What does this probably do? Say again? AUDIENCE: It's defining a variable. DAVID J. MALAN: Yeah, it's
defining a variable called i assigning it equal to 0. And maybe for the first
time it reads nicely. Let i equals 0. That's kind of wonderfully
stated, because that's exactly what you want it to do. What is missing though, from this
line of code that we did have in C? Data types. So there's no mention of int or float
or strings or so forth, explicitly. JavaScript does have types. But it, too, is loosely
typed as is Python. Whereby, there are types, but you
don't have to explicitly mention them. It's very context sensitive. And the computer
essentially figures out what data type is what from its context. But we'll have Boolean
expressions again, such as asking the question is i
less than 50, or more generally, is x less than y, where each
of those might be variables. Here is the do while loop. If you've been missing that in
Python, well, it's back in JavaScript. And we can do something here. And another little thing to
notice, do you capitalize or not capitalize "true" in JavaScript? Apparently you don't,
based on for inference. And so it's these kinds
of little things that, honestly, early on, might trip you up. And it's fine to get frustrated over it. But don't get discouraged fundamentally
by those kinds of nuances. It's just like if you know two romance
languages or two Asian languages and you occasionally confuse
a character or a word. That will happen inevitably,
now, in programming as well. Here is a while loop, an infinite
while loop in JavaScript, as well. Here is a for loop. Notice that it's almost identical
to what we've seen in C, except the lack of a specific data type. I'm instead just declaring i
implicitly to be an int in this case. And this will get a
little more interesting. We have similar syntax in Python. And it's almost the same in JavaScript. If you want to iterate over
the values of an array, you can literally say let value, where
this can be a variable x or y or z, of a keyword you literally
hardcode in array. It's going to be some array in question. And we'll see, wherein
we have actual arrays. That allows you to iterate
over the values in an array. JavaScript also has something
called an object, though. And Python has these, too. And we've mentioned them a couple times. Like technically, when you
declare the db variable for using CS50's SQL
library, that is an object. It's a variable that is an object type. So we've seen these. But we're going to see them ever
more explicitly in JavaScript, exactly what an object is useful for. Meanwhile, we're going to have
some, thankfully, familiar syntax. And you're going to kind of
revert back to your C days. Because elif is not a thing in
JavaScript. else-if explicitly is. So there's that little nuance. There's a declaration of arrays
which look quite like Python lists. So if you want-- and actually,
let me fix this to be consistent. Var is technically a keyword, too. But it works a little
differently than let. So let's just define this
as let numbers equals square brackets these numbers here. Notice the square brackets
means it's an array. But in JavaScript arrays can be resized. They can grow and they can
shrink, quite like what in Python? AUDIENCE: List. DAVID J. MALAN: List. And quite unlike arrays in C. So again,
there's just kind of these trade-offs. And again, it's fine to Google
these kinds of things like, can you resize arrays in JavaScript,
if you forget these kinds of things. But these are the kinds
of differences, when learning new languages, that
will eventually sink in. So here is an example of what
we'll call an object a.k.a. a dictionary or dict in Python. A dictionary, or more generally,
a hash table has keys and values. And that's it. You can have fancier structure. But at the end of the day, it's
just a bunch of keys and values. Different languages use different
syntax for these, curly braces or colons or equal signs or arrows
or other funky things. But the idea is the same. And in JavaScript, if I
want to declare a quote, like a stock quote to be a data
structure, like a struct in C, with three keys-- name, price, and symbol. I literally enumerate them here
with colons after the names. And then I put the values in quotes,
if they're strings, or no quotes, if they're not strings,
on the right hand side. So in the context of CS50
finance, a web-based application for downloading stock
quotes and more, if you wanted to get a piece of data that
represents Netflix's current stock price, you might get back
from the server something that looks a little bit like this. But technically, and not to throw
too much at us at once, technically, it's probably something in what's
called JSON format, JavaScript Object Notation, JSON format, which just has
some additional quotes around things, as here. But we'll see that actually
in use before long. And besides that, besides that, that's
kind of the essence, syntactically, of JavaScript. We're going to now see it's more
powerful features and its programming paradigms. But if you know C and if you know
Python, you kind of sort of already know at least the basic
syntax of JavaScript. You just now need to know how
and when and where to use it. But syntactically, before we
forge ahead, any questions? No? OK. So let me go ahead and do this. Let me go into the IDE and go ahead
and whip up a little example, here, that I'm going to go
ahead and call dom0.html. And we saw this term
briefly some time ago. But DOM refers to document
object model, which is a fancy way of saying the
tree that represents a web page. A web page, of course, might look,
super simply, like this in HTML. The hierarchy is there because
of the open tags and close tags. The indentation there is just
because of me, the human, wanting to be able to read
it a little more prettily. But this structure here in HTML
could be implemented in memory in any language using this
kind of tree structure. This tree structure is called
the document object model. And it's the right mental model,
the way to think about what a web page is underneath the hood. So why is this useful? Well, it turns out all this time
when we've been writing web pages, for the most part, we've
written HTML or we've written in Python that generates HTML. Or that's what you're in
the midst of doing now. But what if you want to change
a web page after the HTML has been written or sent to the user? You run it writing Python
code, don't have the ability to run Python code on your users'
or your customers' computers. Because it's only used on the server. It sends out HTML and CSS and that's it. You lose control over
the user's experience. Unless, in addition to the HTML and
the CSS that you're sending the user, you also send them some
JavaScript, an additional program written in this new language
that runs, ultimately, on their Mac or PC after
it's left your server. So let's see what this might mean. Let me go ahead and whip up
a little example like this. So dom0.html. We're going to have our usual DOCTYPE
at the top that says, hey, here comes HTML 5. Here's the beginning of my web page. It's good to have a head up here
with a simple title like dom0. The body of this web page is
going to be pretty simple. I'm going to go ahead and define a form
that has a unique ID called demo, just for demonstration purposes. Inside of this form is
going to be an input whose ID is name, so I can access that
too, whose placeholder, which is just the fancy gray text,
is going to be name, and then whose type is going to be text. And then I'm going to give myself
an input type equals submit button. So here I have, once I've saved
that, a pretty simple web page that simply has a very simple HTML form. Let me go ahead and run this. I'm going to go ahead and
do this by simply serving. By right clicking or control clicking
on my workspace and clicking serve, I'm going to see a very simple, ugly
web server whose sole purpose in life is to serve the HTML files I've written. And I'm going to go ahead
and click on dom0.html. So this is the file that I
just whipped up super simply. If I type something in
and hit submit, what's going to happen with the information? Nothing really. I haven't wired it to anything. I didn't have an action or a
method attribute on the form. I haven't finished writing this program. So what do I want to do
here to make this happen? I'm going to go ahead and do this. First, I'm going to go into
the head of my web page and instead of just having a title, I'm
going to introduce a new script tag. And as the name implies,
here comes a script. A script is generally synonymous
with like short program. The programs in a web page
can be written, these days, pretty much only in JavaScript. Back in the day, you
could use other languages, especially in Microsoft browsers. But for the most part, the world only
uses JavaScript in this context now. So inside of the script,
I can start writing code. In particular, I can do something
like this, alert("hello,world"); It turns out, alert is a pretty lame,
but a functional function in JavaScript that's just going to print
out an annoying pop up. So let me go ahead and
save the page, go back to my browser, reload, and there we
go, my very first interactive kind of sort of web page. That, really ugly, does this. It just says, hello, world. And I say ugly because it's
showing my domain name and my port. And that's just kind of lame and messy. But at least I'm conveying
some information to the user. So it would seem that
what a browser is indeed doing when it receives an HTTP
request is it's sending this file. And then when your browser receives
that file, it reads it top to bottom, left to right, and executes or
interprets every line of code. So it doesn't just make things bold
faced and centered and the like. It actually will execute lines
of code inside of script tags. So let's make this, now,
a little more interactive. Instead of just calling alert like that,
let's actually put it in a function. And call it function greet. Here are my curly braces
back in our C days. And here let me go ahead and
just say, hello, world, now. If I go and reload this page, am I
going to see or not see the alert? AUDIENCE: Not see. DAVID J. MALAN: Probably not
see, unless, for whatever reason, the browser runs the greet
function automatically. And it doesn't. It doesn't. There's no equivalent
of main in JavaScript. And it certainly doesn't mean greet. So nothing happens. But it is there. So suppose I want to now
connect these things somehow. What could I actually do? Well in my form, you know what, instead
of submitting to some end point-- like the action shall be to go to
register or something like that-- let me actually say this. On submit go ahead and call
a function called greet; So it's a little messy. And we're going to clean this up. But I've introduced a new HTML attribute
that literally does what it says. On submission of this form, call
this code, execute this code. And that code, defined up above,
is going to greet the user. So let's see. Let me go to this web page. And as always, reload the page
so that you see the latest. Let me go ahead and type
in my name and submit. And there we go, hello, world. And then suddenly the page resets. It actually reloaded itself. So let me actually clean
this up a little bit. After calling greet, I'm
actually going to return false. Because technically, I don't have
anywhere for the users name to go. There is no server. So I want to make sure that I've
disabled the built-in functionality of this browser. So that now, when I type in
my name and click submit, it still works like before. But notice, the web page stays the same. It didn't reload. It didn't take me elsewhere. It just stayed put. So now, I'm using the HTML
form as a local application and not really connecting it
to anything on the server. But this is a little annoying. And you might have wondered
why this does this. Most browsers do this. This eventually will get a little messy. It's kind of compromising a
bit of your privacy in forms. How can I disable this functionality
so that users' names are not remembered in text boxes? Well, if you've never known, we
can simply do autocomplete="off". And you might have seen
this already in Pset 7, or elsewhere on the web,
that's how we do that. And also let me go here
and reload the page. Notice that, how do I
interact with this form? I can't type my name by
default when I visit the page. Why? And that probably wasn't
good for my keyboard. What would you do in this case
to solve this stupid problem? Yeah, like click over here. And this is now an
example, albeit a tiny one, of a good versus a bad
user experience or UX. If the sole purpose of your
web page is for the user to type in his or her name, then why
are you doubling the number of steps so that the user has to click
up here first in order, then, to type his or her name? Why not just automatically
focus on the text box? And indeed, that is an operation in a
browser, to give focus to a form field. So in fact, if I go back to
my code here and I also add autofocus and just as an attribute. It doesn't strictly need a value
in quotes or with an equal sign. Now, if I reload the page with
command r or control r, notice, now, the cursor is blinking. The text box is blue on Mac OS. And it's ready to take
my name right away. So start to think about two
of these little subtleties, not just technically how
they work or how to do them, but also why you would do this. Like my rant the other day
about why a website can't accept phone numbers in different formats. These are the little things that start
to distinguish good code from bad code. And focus has another detail too. So if I hit tab, it's very
common, especially in Mac OS, it's super obvious, where things
become highlighted in blue. So you can tab around a user interface. Especially important for accessibility. So if someone is using a screen reader
because he or she can't actually see the words on the screen,
let alone the interface, using tab and a screen reader can they
actually be told what is on the screen. And that highlighting,
that so-called focus, has very real functional
value, so that they know exactly what will happen if they
start interacting with the website. Will the button get clicked? Will text end up in the box? It depends on what has focus. And only one thing can have focus
at a time, per those blue boxes. All right, so with that said, this
is not all that elegant right now. I'm kind of not
practicing what we've long been preaching about combining
one language inside of another. We started to go down
this road some time ago. I started putting CSS
in my style attributes. And then I put it up here. And then finally, I got it out of
there and put it into a separate file. So we're going to be on that
same trajectory here, too. But let me go ahead now and do things
a little differently as follows. It turns out that just putting code
inside of script tags like this isn't necessarily the best practice. We can instead-- because
it requires doing this. This is the ugliest portion of code. And it might not be obvious now. But bad practice, do not put code
inside of double quotes in HTML. Because you have one language
again inside of the other. It's not obvious what
this page is going to do when you glance at it at first glance. If you're collaborating
with someone, maybe you're the front end user interface designer. You're really good with design and art. And so you're doing the interface. And someone else is actually
writing the code and the logic. Because they like to do more
of the back functionality. You can't both really work as
effectively if all of your work is commingled in the same file. So we want to get this out of there. So how do we take a step toward that? Well let me go ahead
and create a new file. I'll call this dom1.html. And I'll start in the same place. But I'm going to go ahead and do this. I'm going to get rid
of this event handler and stop using that
attribute altogether. And I'm also going to
go ahead and do this. I'm going to get rid of my greet code. I'm going to go ahead and get
rid of the script tag, here. And just for now,
temporarily, I I'm going to actually put the script at the bottom
of the page for reasons we'll soon see. So in the bottom of the page, now,
I could do alert, hello, world. But that, of course, recreates
the same problem as before. I don't want it to just happen always. I want it to happen only
when the form is submitted. So how can I do that if I am trying to
avoid this messiness, this commingling of code and HTML? Well, it turns out that there
is a way to tell the browser to do something when something happens. Specifically, I can do this, document. And document is now going to be
a special global variable that refers to my web page, the
document that I'm writing. document.getElementById,
which is a long function name. It exists in JavaScript. And notice the capitalization
of the E and the B and the I, but not the initial g. This is conventional. In a lot of languages,
you don't capitalize the first letter of
your function but you do capitalize every word thereafter. Something called camel case, where
it's kind of going up and down and up and down. Because it's a little more
readable than all lowercase and certainly all upper case. So what ID do I want to get? I'm going to go ahead
and get the ID, demo. And we'll see what
that means in a moment. And I'm going to register
an event handler as follows. So let's finish this
thought in a moment. Where does demo come from? Where did we see that before? Yeah, a few lines earlier. I just gave my form an arbitrary,
but very unique, ID of demo. I could have called it anything. And I could have done this
actually in different ways, too. But this is just super explicit. So here, even if you've
never seen JavaScript before, you can start to infer this is
saying, hey document, hey web page, get me the element ById("demo"). So somehow or other,
this is a function that's going to go grab from the browser's
memory the square or the rectangle that I drew earlier. The reason that the DOM or document
object model is interesting, theoretically, is that with
document.getElementById, you have the ability to go grab
one of these nodes in the tree or one of these data structures in
memory and do something with it. Now, what are we going to do? Well, we're about to see. When I have access,
now, to this form, it turns out that forms, per the
manual for HTML so to speak, there are different
event handlers on submit, maybe on click, maybe on
mouse move, mouse drag. It depends on the element. But forms can be, of course, submitted. So literally, by saying .onsubmit, I
can now say the equivalent of call this function. This is just pseudocode. I now need to give this a function. And so I can do this
in a couple of ways. I can do it like this. So function greet is a function
that simply does say, hello, world. And now, at this point in the story,
I've defined a function up here and given it a name. And then here I'm saying, on submission
of the demo form, call this function. But notice the difference. It's subtle. I didn't do this, which is the norm. I instead did this. Why, though subtle, is
it probably important that you omit the parentheses? How to think about this? AUDIENCE: Because it doesn't
accept any arguments. DAVID J. MALAN: It doesn't
accept any arguments. That's true, but it's not
the reason for doing this. Good thought, though. Yeah. AUDIENCE: So maybe nobody can change it. DAVID J. MALAN: So no one can
change it, not there, too. I think anyone who has access to the
file can certainly change my code. So it's not that. AUDIENCE: Because you're trying
to send it to the output? DAVID J. MALAN: Closer. I'm trying to send it to the output. Not quite, but I think
we're on the right track. AUDIENCE: So it doesn't
call it right away. DAVID J. MALAN: Yes. So that it doesn't call it right away. Ever since week one of CS50, any
time we have seen a function name followed by open paren, closed paren,
maybe with some arguments inside, that has meant call this function
and maybe pass in these inputs. But that's not what we
want at this line of code. At this line of code, we want the
browser to know which function to call, not to call it right then and there. So we don't want that
function to be called as soon as we get to this line of code. Because otherwise, we're going
to see the alert, no matter what, the moment the browser reads
that line of code on the screen. Instead, we just want to
tell the browser, hey, just so you know in the future,
when the form is submitted, here is the name of the
function only to call. But don't call it now. And so that stupid, simple difference
actually makes all the difference in this case, functionally. And so now let me get rid of this. And leave the program as follows. So now let me go ahead and go back to
the web page, reload, click submit. And we see, hello, world. So the functionality
hasn't really changed. But at least I've made some progress. But I haven't done quite
as much as would be ideal. It would be a lot nicer,
I think, to do two things. One, this is kind of lame. I have defined a function called greet. And then I'm using that
function's name in one place only. That suggests I never really needed
this word greet in the first place. You know, it's fine. It's clear. It's correct. But you know what, I
remember from earlier that JavaScript supports anonymous
functions that don't have names. So how could I do this? Well, it turns out we can just,
in one fell swoop, do this. Let me go ahead and cut and paste that
and get rid of the excess white space now, get rid of the function
name, and now just do this. And just for clarity, let me put
the curly brace on the same line, even though it doesn't strictly matter. But this would be
stylistically more common. What am I doing now? This is now saying, hey
JavaScript, get the element called demo or with an ID of
demo and when it is submitted, call this function. Now, it's a subtle difference, again. Open paren, close paren, here,
does not mean call the function. Because it's immediately followed by
the curly braces, which means here comes the code that should be
executed when this function is called. It ends with a semi-colon not
because functions themselves need to end with semi-colons, but
this is all one long line of code that I've just indented now. Because we're declaring a function
and assigning it from right to left all at once. So a huge mouthful there. But again, none of the ideas
are new except for the fact here that functions can
be anonymous with no name. And you can pass functions
around and call them later. Any questions on this? Yeah. AUDIENCE: So can you remove
functions and instead just put equals alert, hello, world? DAVID J. MALAN: Good question. Can I get rid of the
function and just do this? Short answer, no. Because if I do this, this
is going to, just like in C, call this function, which is
going to display that alert. And then it's going to assign the return
value of that function, which I don't think it has one at all, to onsubmit. So this calls the function,
assigns its return value, which is technically undefined, to this. So nothing will ever happen if
you click submit thereafter. It's going to get called prematurely. So the way to avoid this is,
again, to define a function and then pass it in by its name only. Or declare it anonymously,
so to speak, like this. So that you're really just
telling the browser, on submit, call this chunk of code in
between the curly braces. And that's it. OK. So this is still a stupid demo. Because it keeps saying, hello, world. And yet, I have a form with which
the user can type in their name. So how do I get at that value? Well it's actually pretty
straightforward here, potentially. Let me go ahead and do this. Hello, I want it to say, David, if
I'm the one who types in my name. But of course, I don't
want to hard-code that. I want to somehow get the
user's name and plug it in here. So how can I do that? I can say let name equals document dot-- and just so we see where this is
going, getElementById maybe name. Because I have another ID. Recall, I had the anticipation to
write that line of code earlier. So get the user's name. And then it turns out you'd only know
this by seeing it before, online, or in class, .value will get me the text
that the user has typed in, and then semi-colon. And now here, just like
in C and in Python, I'm not going to want to do this. Because that's literally
going to say, hello, name. I want to plug it in. And I can do this in a couple of ways. Perhaps the most blatant is like this. And those of you who did
take APCS or the like might know what plus means in Java. This is just a coincidence
that it also works here. What does plus sometimes mean
in languages besides addition? AUDIENCE: Concatenation. DAVID J. MALAN: Concatenation. So in C, this would have
been a pain in the neck. Like, in C, this is
where you got to whip out like malloc or some really
big array on the stack and actually like plug
one name into the other. In Python, you can just concatenate
things using pluses as well. Or you can use f-strings
or format strings. In JavaScript, we can
just do pluses like this. And this will concatenate "hello,"
to the word name and print that out. So let's actually see what happens. If I didn't make any mistakes, when I
reload this page and type in my name and click submit, hmm,
what did I do wrong? What's that? I forgot to refresh it. I also forgot to change the
URL, which I just now realized. So now we're in demo1.html. So let's reload now, David, submit. And there we have David. And just for good measure, let's
go ahead and type in Maria, submit. And it does seem to be
changing dynamically. So that's a nice improvement
in that it's now doing that. Do we strictly need this variable? No, but if we have this variable,
notice we can do this, too. Just so you've seen this, in
JavaScript, for better for worse, now we have things called backticks,
which is the key on a US keyboard that's usually on the top
left just below escape. And if I have back
ticks here, guess what? You can do this, which is
uglier than Python's f-strings, but does the exact same thing. And again, this is the
kind of stuff where you can start to roll your
eyes as aspiring programmers. Where if one language does something
slightly different and you just have to constantly remember,
it's the same idea. It's the exact same idea. It's just different syntax. So this would plug-in the
name into those backticks. And this is called a template
literal in JavaScript. All right. Any questions on that thus far? All right, let me introduce one
final teaser, here, as follows. Let me go ahead and go into
our distribution code for today and open up, let's say, in
source 11, this directory here. And in a moment we'll see
all of the files in here and show a couple of examples here. So one, it's very common, of
course, to have web-based forms where the user may or
may not actually give you what you want him or her to type in. And so it's nice to
validate their input, like we've been doing on the server. But if you validate the
user's input and make sure that they've given you an email and a
password and a password that's the same and checked your terms and
conditions check box and so forth, you can do all of that in Python. And we've seen how to do
that in application.pi. But it's a better user
experience, UX, if you actually give the user more immediate
feedback, maybe prettier feedback, by using some colors and
highlighting on the screen to draw their attention
to what's actually wrong. With JavaScript, we
have that capability. Moreover, in JavaScript, we have the
capability to do something like this. So if I now run the web server
in today's distribution code and open up this URL, I'm
going to see a listing again. But I'm going to go ahead now
and pull up say ajax1.html. And here, I have a very
simple web form, not unlike, in spirit, what you
have in CS50 finance. But if I want to see what the
stock price is of Netflix, I can type that get quote and I can
actually get it in the client alone. I don't need to send
them to another route. I don't need to use Python, it
seems, to actually render a template. I can just interact with the
form directly and do this. And then lastly, just a tease, we
can do something like this whereby, if I actually con-- damn it-- if I actually
configure things correctly, we can actually get ourselves a
full fledged map using JavaScript. So that in the end, we can
use JavaScript and start to make interactive
applications, like this one here, using Google Maps' API so that
the user can click and drag and can actually interact with it. As by clicking on say,
Stanford, California, and seeing what's going on in the news
in Stanford, California right now by, again, writing code that executes in
the browser, talks to some other server, gets the data back, and renders it. So we've just begun by
introducing JavaScript to see the syntax with which we can do this. Let's take our 5 minute
break here and then actually start building some of these
things to see how they interact. All right. All right, we're back. And recall that the form that we created
a moment ago just looks like this. It's pretty simple, ugly HTML. There's no CSS. We're focusing only
on functionality here. I did, at least, give
autofocus to the email field, so I could start logging in right away. But I want to achieve this behavior. You know what, I don't
really want to cooperate. I just want to register
and see what happens. I want to validate this form. So here's one way. I seem to be using the alert
method and saying missing email. I'm not letting the
user actually register. OK, so let me slightly cooperate,
malan@harvard.edu, register. Missing password, it now says. All right, so let me go
ahead and give it a password. One, two, three, four, five, register. Passwords don't match. Of course they don't. Because I didn't type it in. One, two, three, four, five, register. Passwords still don't match
because I accidentally typed six. Register, check box
unchecked, and so forth. And only once I check that
box and now click register do I actually want the form to
go through to the server. So how do we start to
impose that kind of logic? We could do what you're doing or
have done in CS50 Finance, whereby you check on the server and make
sure that the user has given you email, password,
confirmation, and a check box. And if not, you show
them grumpy cat and you complain that they haven't cooperated. And that's all cute
the first time around, but it's not the best user experience. Because now the user has
to click the back button and they have to refill out
the form and then do it again. It would be nice to just
get more immediate feedback like we're getting here. And not necessarily as
ugly as this feedback, because this alert is really just for
debugging purposes, I would argue. But at least it's quick. And it's not even bothering
talking to the server. So here is the HTML with which
we might create that form. For the most part,
this is cookie cutter, whereby I'm disabling autocomplete on,
I was overzealous with my autocomplete. It's not strictly
necessary for passwords. Because browsers won't
do that by default. So really, I just want it to look
like this, which is even smaller. So I have a field called
email of type text. I have another field called
password of type password. I have another field called
confirmation also of type password. And then I have an input of
type check box called agreement followed by the submit button. So that's it. So how do I begin implementing
some of the logic we just saw? Well, let me do this. Down here in the script
tag, eventually we're going to factor this
out to another file, but for here, I'm going to do this. I'm going to go ahead and declare
a variable called form and go ahead and get via
document.getElementById("registration"). Why that? Well, notice that I gave a
unique ID to my registration form just because I want to be able
to easily get at it, as here. Then, I know that forms have submission
handlers, so I can go ahead and say, hey browser, on submission of
this form, go ahead and call the following function,
albeit an anonymous function. So all that remains for me to do is
to implement this anonymous function. What do I want to do when the
user clicks the submit button? I want to validate
their input in some way. So let me go ahead and
do it sort of logically. If this form's email field
has a value from the user that just equals quote/unquote,
then let me go ahead and alert the user that you
are missing email, semi-colon, and I'm going to return false. Because that's it. I'm not going to return true. Return true would mean, let
the user submit the form. Return false means, stop
submitting the form. Let the user try again. And so let's do this now for passwords. So how about else if the form's password
field has a value that also equals quote unquote, then go
ahead and alert the user missing an s, missing password,
semi-colon, and also return false. Next one is a little more interesting. Because now I can say else
if form.password.value. What do I want to say logically here? AUDIENCE: Dot length. DAVID J. MALAN: Dot
length, I could do that. So that's not a track I
currently have in the UI we saw. AUDIENCE: Can you find
some sort of confirmation? DAVID J. MALAN: The confirmation, yes. So it turns out the syntax
is the same as in C, not equals form.confirmation.value. Then, I want to go ahead
and say, I think I said, password, what did I say,
passwords don't match, semi-colon, return false as well. And then the check box
is a little different. I can say else if it is not the case
that the form agreement box is checked. And that's a Boolean that's
associated with a check box. And you would only know this from
the documentation for JavaScript. But the not inverts it. So if it's not checked, then
go ahead and alert the user that the check box is
unchecked and return false. But if none of those
conditions apply and we make it through this gauntlet
of error checks, what do I probably want to do down here? What do I want to return? AUDIENCE: Return true. DAVID J. MALAN: Yeah, return true. And that just means, hey browser,
do what you want to do by default. I'm done error checking the user. So there's some opportunities
for refinement here. I could say, I don't really need to
compare against the empty string. I could say, if there's not a
value, which is a little tighter. And I can say, if
there's not a password, so I could clean it up that way. I could actually use the string
length, which is a thing, too. So I could say something, if I
really wanted to be nit picky, else if the form's password
value.length is less than 8 characters, I can say something like
alert, password too short, which would be a nice check,
as well, and return false. If I really want to be secure, I can
make sure the user has a pretty random looking password, maybe with some
numbers or some special characters or some of those somewhat annoying,
but probably good, constraints, at least if you're using
a password manager. And this is how websites
do exactly that. But there's still an opportunity for
improvement here in a couple of ways. This code is, again,
commingled with my HTML. But this is actually an easy fix. Let me go ahead and copy all of this
code or highlight all of this code that we just wrote, cut
it out, and indeed I'm going to get rid of the
script tag altogether. And instead in the head as my
web page, where previously we've only ever put titles and maybe
some style or length tags for CSS, I'm going to go ahead and say
script tag the source of which will be form1.js for JavaScript. And even though this
looks a little weird, this is indeed the right way to do it. It's an open tag and a close tag. It is not valid, for
silly reasons, to do this. So even though this kind of makes
no sense, do this nonetheless. That's the way the world is. So let me create another file,
paste that very code I just wrote. Let me go ahead and unindent
it just to keep things cleaner. Actually, it's not
quite indented properly. Now let's do this once more. Let me save this as, what
did I say, form1.js, save. And now I have a better version of this. And what is the browser going to do? Well, just like when we've used
images in our web pages before, like the cat, by referencing an
image source equals quote unquote, so do we have a script source
equals quote unquote something here. So now when a user visits
this page, form1.html, the browser is going to read it
top to bottom, left to right. It's not going to see
any actual JavaScript. So nothing's going to
execute right away. But it is going to see this other file. And it's going to
recursively, if you will, download that file so that the web page
has access to all of the code therein. So that would be one refinement. And now we're back to what, I
would argue, is a better design. But there is another way to do this. And let me open up a
premade version of this. It turns out that some things in
JavaScript can be pretty tedious. Because the language, early
on, was pretty immature. And people were trying to get it
to do things that just weren't very easy to do in the language. And so popular libraries arose,
as was the case in Python as well. And here we have an
example called form2.html that actually uses a
library that, for some time, was one of the largest and
most popular called jQuery. JQuery is not a language unto itself. It's literally just code
that a bunch of nice people wrote to make it easier to use
JavaScript for certain things. The price we pay for that ease of
use is that some things are actually a little more syntactically
weird looking. And so we won't dwell too
much on the syntax of jQuery. But jQuery is the library for
JavaScript that Bootstrap uses. And you might recall Bootstrap
from the past couple of weeks. Anytime we've made prettier websites
than I'm typically capable of, when they have nice forms and
everything is nicely color coded and they resize nicely,
that's because we're using the Bootstrap
CSS library that also comes with some JavaScript
interactive features that require that you have jQuery
linked in your web page, as well. So that's why we'll use it here,
as well as to see the following. Here, now, is another implementation
of the same program in between script tags, for now, inside of my head. But I've done a couple
of different things. This line of code is perhaps the
weirdest looking at first glance, in part, because of this dollar sign. And we saw a dollar sign a moment
ago inside of those strings with the backticks. This one means something different. As soon as I import this file, which
is the latest version of jQuery, so it's hosted elsewhere,
not on my own IDE, it turns out that gives you access
to a global variable called jQuery, spelled like that. Back in the day though,
the people who wrote jQuery decided that that's a little tedious
if every time the users in the world want to use our library, they have to
type out this kind of long word jQuery. So it turns out they just created
an alias for it called dollar sign. And weirdly, in JavaScript dollar
sign and a few other punctuation symbols are actually legitimate
characters to use in variable names. This is not true in C.
This is not true in Python. But it is true in JavaScript, that even
though this looks funky to all of us, at least relative to the letters of
the alphabet, it's a valid symbol. It could have been fu or bar or x or y. So jQuery just kind of got there
first and claimed for the world, we shall use dollar sign for
all of our functionality. That's all it means. So what does this
functionality do for us? This is a mouthful. But let's see if we can
parse what's going on. Document is what, in your
own words, anyone's words? Yeah. AUDIENCE: The web page. DAVID J. MALAN: The web page. It is a global variable referring to
the very web page we're looking at. That's the so-called document. This syntax here, dollar
sign open paren, close paren, is the way in jQuery to
wrap, literally, the document with some additional functionality. So the browser gives you this
global variable document. And it's got some functionality
built in, like getElementById. And there's other stuff too. But we won't look in detail at it. This dollar sign open paren close paren
around it, takes that global variable and stuffs even more
functionality into it just to make it even easier
for us humans to use. One of the pieces of functionality it
gives us is this function called ready. And ready, a little unusually,
but similar to what we just saw, takes an argument as its input. And that argument is a function. The function that should be
called when the document is ready. That's it. Because web pages can
be pretty big, right? You go to cnn.com or Google
News or Facebook or Gmail, it kind of takes some number of
milliseconds or sometimes even seconds for the whole page to
load until you finally see the entirety of the web page. That means the web page is ready,
once you see everything on it. So the way you can say,
programmatically, hey browser, only execute the following code
when the document is ready, is with the line of code like this. And it's fine if you have to copy-paste
that for now until it sinks in. But that's all it's saying. Add some functionality to the
document, like this ability to wait until the web page is ready. And then when it is ready, call
this anonymous function i.e. this chunk of code. So what's happening below that? Well, it turns out, there's
just alternative syntax in jQuery for doing the
same thing we just did. Though cryptic looking, this
dollar sign with the parentheses takes an argument here that's
different from document. If you pass in a string,
that kind of looks like CSS, recall that we've used
CSS selectors before, where you can either have a tagged
name in your CSS file or hashtag something, which is the ID,
the unique ID, in a file. Or dot, which meant
a CSS class, vaguely. So look back at some of your CSS
examples if you don't quite recall. But in CSS, those are selectors. And this one just means, grab the dom
node whose unique ID is registration. jQuery syntax for that
same expression is this. So this line of code is
essentially equivalent to
document.getElementById("registration") And the reason that jQuery exists
is that they say in about half as many characters what it just took me
twice as many characters to type out. That's all. It's not a new idea. It's just more succinct,
if more cryptic. And moreover, if we keep going,
in raw JavaScript, it's onsubmit. In jQuery, it's .submit. Just because, why do we need
those two extra characters? We don't really. So that's all we're seeing here. So what actually
happens, now the syntax, admittedly, gets a little funkier. So we won't spend too much time here. But if you did not have the foresight
or for whatever reason did not want to give unique identifiers to
all of your form fields, that's OK. Because you can use
CSS-like selectors, fancier ones than we've introduced
in the class, that say hey, go look in the web page for the element
whose unique ID is registration. Look inside of it, it's
children or descendants, for an element of type input. And then, only grab the value of
that input if its name is email. So again, we won't dwell on this. Because there are easier,
simpler ways to do this. But with jQuery, you get the
expressiveness that we're seeing here. And all the rest of
the code on the screen simply does the exact same
thing using another syntax. So use this more as a crutch
when experimenting with, say, for the next project or
final project, jQuery, if you want to see analogues
from no jQuery to yes jQuery, but it does nothing
fundamentally different. It's just a different syntax. But there is going to be a more powerful
feature that we now get from jQuery. It turns out that when
you do visit websites like maps.google.com like this. This is not the whole world. At the moment, it figured
out that I'm in Cambridge. And it's showing me just a
little snippet of Cambridge. And Google also, even though
I'm only looking at Cambridge, also did not proactively download
pictures of the rest of the world and store them in my browser's memory. That's be pretty stupid. Because I rarely need to go
very far away from where I am. And even so, if I want
to go to like New Haven, I don't really need all of the
cities and towns between me and New Haven to be in my browser. We can just jump straight there. And you can kind of see
this artifact, as follows. If I click and drag really
quickly, what do you see happening? I should have gone somewhere
where there is land. What do you see happening on
the left, as I do this quickly? AUDIENCE: There is a delay. DAVID J. MALAN: Yeah, there's a delay. You see these gray
tiles, like placeholders, until eventually, they're filled in. Now why is that happening? Well, you know what, I'm going to
go up to my browser's developer menu, developer tools, which should
be a habit you're increasingly getting into when you want to understand
something or solve some problem or just learn out of curiosity. Let me clear this temporarily. But every time I click, whoa. Just clicking and dragging
induced, as of now, 89-- whoops, there there's my screen saver-- 92 more HTTP requests. So what is it that's being requested, do
you think, every time I click and drag? More images, more tiles, as
they're called in Google Maps. And so what is the
feature of browsers that allows them to go get more and
more data like this on demand? This is a technology or
technique called AJAX. AJAX is just a fancy way of
saying a feature in browsers that lets them execute HTTP requests
after the first one is all done. Which is to say, when you first visit
Facebook or Gmail or Google Maps and you get back a response from the
server containing the map of Cambridge, the browser, thanks to AJAX,
which is a more modern technology over recent years, has the ability
to send more of these envelopes out onto the internet saying, I need
the tiles for the northeast corner. Or I need the tiles for
the southwest corner. Send them back to me. So constantly, we're now up
to 651 additional envelopes came back from Google in order
to fill in all of the blanks as I sort of rapidly clicked and
dragged to different locations. And it doesn't have to be
graphical in this nature. We saw stock quote a moment ago. And that's, perhaps, an
even simpler paradigm, if I just want to get some
slightly additional information. So let's do that, let me go
ahead and open up ajax.html. And I see this form here. And now let me go ahead, as should
be, again, increasing habit, go to my network tab. And notice, just for good
measure, also get into the habit of clicking preserve log. So that just in case the web
page redirects or goes elsewhere, it doesn't delete everything
you were looking at. You still see everything. Let me go ahead here and type
NFLX for Netflix and get a quote. And notice, we saw earlier, the
response come back from the server. As of this moment, it's $198.41,
but how do we know that? Let me dismiss the alert
and focus down here. After loading this page, apparently,
it sent one more HTTP request, which was successful. Why? Or how do I know? Yeah, 200 OK. So Chrome is showing me that, too. And you can do this in Edge
and in Firefox and Safari. But frankly, Chrome is sort of the go
to browser these days for development. So I would encourage you
to keep using it for this. If I click on this, I can now see what
the request was and the response was. Here are all those headers. There's some cookies involved,
which are a result of the IDE and not my own code. But it's the response I care about. Let me view the source. And notice, a few things came
back, some of which are familiar, some of which aren't. Among the headers is indeed
200 OK, so that's a good thing. Notice what type of
content came back, though. In the past it's been text/html. But what came back this time? Yeah, application/json. Application is a little weird. It's not an application. It's not a program. But it's a format used by
programs, you can think of it. JSON is JavaScript Object Notation. So probably, what came back is something
with some curly braces and colons and quotes. We'll see in a moment,
47 bytes worth, in fact, and then some other stuff came
back from the server as well. So let me click on response. And what do you know, in
the response from the server is not another web page. There's no HTML tag, body
tag, head tag, or anything. It's just this text, but
in an official format. Open curly brace, close curly brace
means here comes a JavaScript object. What is an object? It's a hash table or a
dictionary with keys and values. What are they? A key is name. Value is Netflix. Price is a key. 198.41 is a value. Symbol is a key. Netflix is a value. And so it's just a way of
getting back one or more pieces of useful information. So how do I now do this and how
do I get the information back? For that, we have to
look at the code itself. So in ajax0.html, we
have this code here. In HTML form, that, just like
our very first example today, just simply hard-coded inside
of an onsubmit attribute, a quote function call,
and then return false. That is, don't reload the page,
don't submit the form for real, just call the quote function. Where is the quote function defined? At the moment, a little lazily,
it's defined in the same file. But that's fine. Because this is our very first. Notice that I have two
things for JavaScript. One, is jQuery, that library I
mentioned earlier, it has to come first. Because just like in C, you
need to know that functions have been loaded before you use them later. Then here comes my own
script, my own JavaScript. And here's my quote function. It doesn't take any arguments. Because we're going to get
those in code from the browser. And the syntax here is a little funky. But we'll distill it in just a moment. Dollar sign is synonymous with what? AUDIENCE: JQuery. DAVID J. MALAN: JQuery. So this is just a prettier or
confusing way of saying this. JQuery.getJSON. GetJSON is a function, or a method,
so to speak, whose purpose in life is to do that, go get me some JSON data. From where should I get it? /quote, which we'll see in a moment, is
a super short route that I implemented in Python on the back end. Though, it could have been
implemented in any language. This looks a little cryptic, so we'll
come back to this in just a moment. So let me delete this temporarily
and just say the following. The getJSON function
that comes with jQuery takes at least two
arguments in this case. One is the URL, to get JSON from. And two is what, would you infer? AUDIENCE: An anonymous function. DAVID J. MALAN: A what? AUDIENCE: An anonymous function. DAVID J. MALAN: An anonymous function. That anonymous function, though,
unlike the ones we've seen before, actually takes input this time. So it doesn't have a name. And that's no big deal. But it does take one argument-- data. And this is an example of
using an anonymous function as what's properly called a callback. Because the internet can be slow. And if I am trying to get
a stock quote from /quote, maybe it comes back super fast. But maybe the server is overloaded. Maybe my internet connection is slow. Maybe I'm on my phone. And so it might take a second or
two seconds to get that response. And imagine if things waited in the
world of the web for data to come back, your experience, your user experience,
your UX could be pretty bad, right? The whole browser might hang or wait or
you get the stupid spinning beach ball while you wait for something to happen. Imagine that in Facebook,
like every time your friend is typing you see the dot, dot, dot. But maybe you can't do anything with
the website until he or she hits enter and you finally get the message. That would be blocking you
from doing real useful-- well, "real useful things" from
using Facebook in other ways. So how can you instead
tell the browser, go get me something more, more
tiles of the map, more messages from my friend, more stock
quotes from a server, but call me back when you have the data
so that I can actually keep doing work? Just like, I might be at my desk here. And actually, Brian, if you
wouldn't mind coming up. And Brian may be here is
in his little home office. And I am really curious as to
what Netflix's stock price is. So let me go ahead and
pull up Brian, here. BRIAN: Hello. DAVID J. MALAN: Hi, Brian? BRIAN: Hi. DAVID J. MALAN: Hi, this is David BRIAN: Hi, how are you doing? DAVID J. MALAN: Hi, I'm
really good, thank you. I need the current stock
price of Netflix, please. BRIAN: The current stock price
of Netflix, I'll work on that. But I'll have to call you back. It'll me a little while. DAVID J. MALAN: OK, thank you. BRIAN: No problem. finance.cs50.net. DAVID J. MALAN: Oh, hello? BRIAN: Hello? Hi. The current share of Netflix cost $198 DAVID J. MALAN: Wait a minute,
I'm getting a call from Colton. BRIAN: OK, and $0.35. DAVID J. MALAN: Hold on I got to
call you back Colton, once sec. Wait, hello? BRIAN: Hi. DAVID J. MALAN: Oh, hi Brian. BRIAN: A share of Netflix costs $198.35 DAVID J. MALAN: OK, thank
you very much, Brian. BRIAN: No problem. DAVID J. MALAN: Goodbye. OK, I just hung up on
Colton on the internet. So thank you. OK, so what was the point of that
unexpected surprise and how weird that he called me right at that moment? So the point is that
callbacks are something we're already familiar with, right,
in the real world where you actually want to get some information
back from someone. And maybe it's not as contrived as
hey, I need a stock quote quickly, get back to me. But you do wait for them to get
back to you with some information. How do you implement this in code? This is the exact same idea. So we have this special
function called getJSON. It's baked into this library called
jQuery, whose nickname is dollar sign. I then say, go get me some data
from /quote or, equivalently, Brian in the real world. And then, I tell getJSON, when you
are ready with this information, call me back, so to speak. How do you call me back? Well, you know what, I'm going to
write in advance some code that I want you to call, literally, but in a
computer sense, when the data is ready. So just as Brian verbally gave me
that stock quote, passing it verbally back over the phone, so
can this anonymous function receive as an argument a
data parameter or argument that I, then, can have access to. So I can use dot notation,
like in C, structures, and get at the name or the price
or the symbol, which were the three values that we saw in that JSON object. But meanwhile, this line
of code executes instantly. And it registers, if you will, a
callback function with getJSON. So it just knows whom to call back. And what this means in real terms
is that if my web page were far more interesting than this and is
Facebook or G-mail with lots and lots of other
features, I can get back to working on and using those features
and then get interrupted if and when the phone actually rings or the
message comes in from my friend or I get a new email or I get,
in this case, a stock quote back. So all that happens super quickly on
a fast internet connection, but not necessarily the case on a slower one. As we started seeing with Google Maps,
trying to get more and more titles. But how can I clean this up? So that was version 0. Let me go ahead and
open up version 1 here. And notice that this time, I'm doing
things a little bit differently. Oh, and actually, let me reveal one
last thing by way of this example here. So what are we actually
doing differently here? So in this case, I'm now attaching-- let
me open up the other one so we can go there and back-- in this first version, recall,
I did the sloppy kind of thing where I commingled my
HTML and my JavaScript. And that's bad design. Don't do that, even though that's
where we started the story. So how can I do this,
programmatically, in code? Well, if this is my form now, and
notice there's no mention of onsubmit. There's no mention of that attribute. I'm doing this entirely in code. How can I do that? Well, I can say, when
the document is ready, go ahead and register this
submit handler, if you will. Event handler would be the generic
term for all of these kinds of things. When that form is submitted,
call getJSON of /quote. Then call this number back, so
to speak, when the data is ready. And I deleted this,
temporarily, earlier. But let's tease apart what this is. It's a little cryptic looking. So let me clean that up as follows. Let me go ahead and say the
following, let my HTTP parameters be this JavaScript object
that has a symbol and whose value is this thing here. And this is a little cryptic, too. But we'll tease this
apart in just a second. So let me now replace
this with HTTP parameters. So what's going on here? I'm just being more verbose,
but it's no more correct. Here is a variable
called HTTP parameters. What type of variable is it? It's an object in JavaScript,
note the nomenclature, because of the curly braces. That's the clue. An object, recall, has keys
and values separated by colons. So here's a key symbol. And here is a value. This is a very funky way of writing it. But this is jQuery's
way of saying this-- document.getElementById("symbol").value. So again, the value, no pun intended,
of using jQuery in contexts like this is just fewer keystrokes. It's more cryptic. You kind of have to remember
the syntax over time. But it's fewer things to type. And that's all it's doing. It's getting the symbol's value
from whatever the user typed in, like an NFLX for Netflix, and then it's
storing it as the value of this key. And then to getJSON, It's
passing in those HTTP parameters to create the URL I expected. And what was the URL I expected,
expected in the sense of me being the programmer? Well, if I hover over
the URL in Chrome's log, I visited /quote question
mark, symbol equals NFLX. So it seems that what getJSON is
doing for me is actually constructing, dynamically, a GET request. Just baking into the URL the
parameters that I want to pass in. And so that example does,
fundamentally, just that in the end. So any questions, then, on AJAX or
any of the syntax with which we're doing this? Yeah? AUDIENCE: Why is the keyword
symbol not between quotes? DAVID J. MALAN: Good question. Why is the word symbol
not between quotes? It could be. This would be perfectly correct, too. It's not strictly necessary when you're
providing it as input, shall we say, in this context. It is necessary in the output. So for stupid reasons,
the JSON format that is meant to come back as the
response, everything must be quoted. But when you're actually writing
JavaScript code with objects and keys and values, you don't
strictly need to quote things. Just bad design in the language. Other questions? All right, so if then,
the take-aways thus far are JavaScript has functions
and anonymous functions, which is kind of interesting, loops
and conditions and variables and more, even though we've not really
used some of those features, like loops and conditions. Because we've kind of beaten
them to death with Python and C. They are in there. But more importantly,
there is this notion of callbacks, the ability
to call a line of code and then say when you're
ready with your return value, call me back by calling this function. This is an example of what's called
asynchronous code in contrast with synchronous. Up until now, almost everything we've
written and everything we wrote in C was synchronous, which means
if you run a line of code and that function takes
awhile to run, your code is going to hang there
for some amount of time. And God forbid you've
got an infinite loop, it's going to hang there
forever and block everything. We started to see
asynchronous code in Python, even though we didn't call it
this, just a week or two ago when we started using Flask. Because Flask is asynchronous in the
sense that you write your program, it registers all of those routes, and
then it just kind of waits for things to happen asynchronously, sort
of out of order, in any order. But now in JavaScript,
we really feel the power of asynchronous in the following way. The reason that I was able to sort of-- actually, I didn't really do
anything useful with my time. I just kind of twiddled my fingers here. But theoretically, I could
have made another call. I could have checked my email. I could have gotten a snack while
I wait for Brian to get back to me. I could have gotten real work done. Because if you allow
for asynchronicity, you can do stuff in between the starting
and the finishing of some goal. And that was just like
when Brian called me back, I could have used that time usefully,
just like my program or my website could do other things
while I wait for this data. So the value, then, of
asynchronicity is that we can be ready to do more things at once. And what are some of the
things we might want to do? Well, let me open up some remaining
examples, here, as follows. Let me go ahead, here,
and open up this one. So this is built-in functionality
that's actually kind of cool, even though it's a little verbose. If you've ever noticed,
web pages these days and certainly mobile applications
can know where you are. Frankly, Google knew where
I was when I pulled up Google Maps, even though I was not
logged in, which is a little creepy. But they had enough
information about me. How could you be as creepy
in your own web sites and figure out where the user is? Maybe, I shouldn't have
teed it up like that. Well, this is a mouthful. But the ideas are exactly the same. Here, it turns out, there
is another global variable that comes with browsers these days. It's not just document. There's also navigator. And navigator is like this
special global variable that's got geographic related
functionality built into it. One of those pieces of functionality
literally is navigator.geolocation. So this is like a feature inside
of this global navigator object. It comes with a
function, otherwise known as a method called current position. Which, literally, if you
read the documentation, is supposed to get the
user or technically the browser's current position in
the world, latitude, longitude, using GPS coordinates or the like. But that can take awhile to
figure out where the user is. If we were talking in a CSI sense,
it's got to triangulate the user and figure out where they
are and do all of this, sometimes talking to the server. Somehow their position is determined. And it could take a second, a
minute maybe, some amount of time. So that's a good opportunity for
an asynchronous implementation, to use a callback like
we did with Brian. So that when the browser
does figure out my location, let me know so that I don't see
some annoying beach ball spinning until that answer comes in. So how do I do this? I call getCurrentPosition. I pass in an anonymous function,
though it could have a name. But it doesn't need it. An anonymous function that
takes, per the documentation, one argument called position, which is
going to be a special object containing coordinates. When that function is called some
seconds or milliseconds later, this one line of code here is
going to execute, document.write, which we haven't seen. But this is just a way of writing
additional words to the document, like the web page, the body. position.coords for
coordinates, .latitude. And then concatenate a comma
just to keep it pretty. And then concatenate
position.coords longitude. So this is a huge mouthful
for saying, do the following. Let me go into the web page
called geolocation.html. And nothing seems to happen yet. But if I-- Why did nothing happen? Oh, no. OK. There we go. So it wasn't working because I
wasn't accessing today's demos by HTTPS, which isn't a big deal. Because they're just
public demos anyway. But the browser didn't like it. Because it wants the communication
of my GPS coordinates to be secure. So as soon as I change
to HTTPS, it says, hey, this domain name, my own on the
IDE, wants to know your location. Now, some of us might be in the
habit of just clicking block. Some of us might instead be in
the habit of just clicking allow. Some of us might be in the
habit of clicking enter and who knows what just happened. But if I do click allow and
wait, because it's asynchronous, Brian could be taking awhile
to figure out where I am. There are my incredibly precise,
using floating point values, location in the world, at
least with high probability. Now, I can check for this, I believe. This just happens to be
Cambridge, Massachusetts. If I go to Google Maps and
search for those GPS coordinates, indeed that is pretty darn scary. So that's pretty good. That is, in fact, where we are. So the takeaway is, how can we do this? Well, we can do this by
understanding what a callback is and what asynchronous code is. But again, the paradigm is changing. I'm not just calling
getCurrentPosition and then getting back a return value like we have
been getting for weeks in C and Python. Now, there is nothing
on the left hand side. I'm not waiting for a
return value, per se. I'm certainly not storing a return
value on the left hand side, as we've been doing for
ages with Python and C. Instead, I'm passing in a
function, functionality, like my telephone saying, call
me back when you have the answer. And that's the paradigm now that's
really starting to change for us. And there's a couple of other things
we can do along these lines, too. Let me open up one, which
is just a little silly. But it kind of brings me
back to my days of HTML. Back in the day, in HTML like 1.0,
there was this amazing tag called blink. Whereby, if you did open
bracket blink close bracket and then wrote some words
and then close the tag, it would just do this on the web page. And I'm pretty confident
this is how you were greeted when you visited my like freshman year
website or sophomore year website like, hello, welcome to my website. This is stupid. And eventually, the one good thing the
standards bodies did over the years was remove blink
functionality all together. There was also, as an aside, a marquee
tag, where, just like a stock ticker or like a Broadway show
marquee, it would just scroll text across your screen like
this, which is also pretty stupid. But we can bring back at least
the blink tag as follows. So here is a pretty simple web page
with just a single div and an ID of greeting, just so I have some
way of uniquely identifying it. And suppose I want to
make this text blink. Well, if you consider, now
that you have the ability to execute code on the
user's computer, we should be able to achieve this by like
turning CSS on and turning CSS off, on and off. And you might not have done this before. Because we've probably just used CSS
for like centering text or making it bold or a color or a
different size or the like. But you can also make it display or
not display, visible or invisible, too. So if we look at my script code,
here, for better or for worse, let me consider how I might do this. I'm going to go ahead and
define a function called blink that simply gets that div by its ID. We've seen that before. And then I just do this. If the div's style
property, and you would only know that this exists by seeing
it in class or reading in a manual or seeing it online, if this
div, which came from this line, has a style of visibility equal to
hidden, then use this line of code to change the visibility for that style
of that div to quote unquote "visible." Else, logically, if that div style is
visible change it to hidden instead. To this day, I do not know why the
opposite of visible is not invisible. It is hidden. But that is also a design
decision we're stuck with. So how does this work? This is just one function
that just changes the state. But something's not going
to blink unless you change and then change and then
change and then change. Well, another beautiful
feature of JavaScript that we're kind of using for evil
here is to do something repeatedly but asynchronously. I could easily make
something blink and blink and blink by just
making an infinite loop. But if I had an infinite
while loop or for loop, I would, by definition,
never get out of it. And therefore, the page
would blink forever, but the page would not do anything else. But with asynchronous code like this, I
can register a function with a browser and say browser, go ahead and call
this function every 500 milliseconds. And notice, this is one line of code. So when the browser executes
this code, it executes one line. And it just keeps going. But it remembers, every 500 milliseconds
remember to stop whatever it's doing, blink, then keep going,
then blink, then keep going. So in this way, can you have multiple
things happening on your web page. Because the way JavaScript
works is it itself, the language, built into
the browser, essentially, just itself has this infinite loop. And it's constantly listening
for users to click on things. It's constantly listening
for the mouse to move. It's constantly listening
for a timer to go off. And every time one of
these events happens, it dispatches the handler,
the function, that it was told to call in response to those events. So the end result here
with blink is this. If I go back to my directory index,
here, and open up blink.html, you see it doing exactly that. And I can tweak this
a little differently. If I want to do it every tenth
of a second, we can do this. And if we do this too fast
it's probably not healthy. So we'll just leave it at 50. So you know, this is how I learned
how to make the web years ago. So what more can we do
in a more compelling way? Let's look at one final example
that I fixed during the break, which is this here map. This is where the world starts to
get really, really interesting. Because there are so many
third party APIs out there, application programming interfaces. Like nice people and nice companies
who are trying to sell you services, they have features, code that they've
written that they make available on the internet for us to use
either by grabbing data from them, as in the case of CS50 Finance
pulling in stock quotes. Or in the case of Google Maps, actually
baking in additional functionality to your application, so you don't
have to implement it yourself. If anyone's ever used Lyft
or Uber on your phone, Lyft and Uber did not start
out by being map companies, sending cars all around the
world mapping the whole world. That would be insane for a
startup to try to do that. They wanted to build
a car sharing service on top of another feature that's
just kind of a necessary ingredient. So they used Google
or some other company, paid them some amount to build their
maps into their own application. And then they contribute to their
own intellectual property and ideas. So how can we do this? Well, it turns out if I have a
web page that's pretty simple, and let me go ahead and just
quickly delete this real fast, so that it just looks as follows. Here is a very simple web page
that's got a body and then a div inside of it whose ID is map. And then at the very
bottom of the file notice that there's this JavaScript
code that points specifically to Google API, application programming
interface, slash map slash something. And what I did during the break
was I downloaded a new API key, which allows me, David Malan,
to use their API so that all these requests are associated with me. Previously, I had an old key. So it just wasn't working. And that's why we got the error message. So I signed up now for a free API key. But how do I actually do
something with this map? Well, we can do a few
different things simply by following along with the
documentation online in the right way. Let me go ahead and open
up the following here. If I go ahead and load this page right
now, that I've deleted that code, and open up map.html,
there's nothing there. It's just a big white page. And that's because I haven't
added any of my own code. But if I go into the script tag here,
let me go ahead and do the following. Let me define a function called
initMap that takes no arguments. And then inside of this function,
let me go ahead and do this. Let me declare a variable called
map that takes on the value of a new google.maps.map of
document.getElementById("map") And then pass into that a special object. So we'll see what this
means in a moment. The syntax here is a little funky. But this line of code
I only knew by reading the documentation for Google Maps. Google Maps told me if you
want a new map, type this. And if you want to remember that map in
a return value or in a variable, sorry, I should have said let,
store it in map on the left. So the weird thing
here is the following. The two arguments are these. This is a line of code that we have
seen before that says, hey browser, go get me the HTML element from
the dom whose unique ID is map. What is that element? It's just this div. And it's empty. There's no map there now, obviously. There's nothing between that
close brace and open brace. So that's why there's no map. But this line of code
is what we're going to use to inform Google
where to put its map for me. It takes another argument
here, as per the curly brace and the close curly brace,
which is just an argument, which is to say the documentation told me
I have to pass in multiple key value pairs. I have to configure the map. So let me do that in just a moment. Let me go ahead, now, and reload the map
by going up to the browser and reload. And interesting, it's
not doing anything yet. But we did get progress, right? It's gray. But that suggests I just
haven't configured the map. So let me do that. And I would know this only
from the documentation that I need to provide a key of center. And that center needs a
latitude and longitude. And I can choose just to
be neutral here, 39.833 and a longitude of negative
98.583 close curly brace. And then a zoom key of 4. These mean nothing out
of the context of Google. I know this only from
reading the documentation. And Google's documentation told me
make sure you use a key called center. Have its argument after the colon
be another JavaScript object with two keys, lat and
long, each of which is exactly that, a float that
represents a latitude and a longitude. And then also tell me, the Google
API, what zoom level do you want. Do you want to see the
bird's eye view way up here? Or do you want to really
zoom down on the terrain? And 4 is roughly, it's at a
certain level that's useful. But we can tinker with that as well. Let me save that. Go back over here and reload
the page now and voila. I'm centered over what's roughly
the center of the United States at a certain zoom level. If I want to change one of
those values just to see, let's make this maybe 8, save. Reload. Now I'm really zoomed in on what
appears to be Kansas or Nebraska. So that's a different zoom level. I can really kind of poke
around the world, so to speak. So let's see, if I go to like 139,
let's see where that takes me. Reload. That might not be
geographically possible. Let's do 42, how about. Change that to 42, reload. Now we're over, OK, Sioux City there. Let's maybe go to 44. Anyhow, we're moving the map to
places that I don't know in advance. Now we're in South Dakota. In any case, all we have
done now is just configure the map to be in different places. But there's other
functionality in Google Maps. Let me revert this and let me go ahead
and declare a couple of other things. I can actually declare
a marker, as follows. Let me get myself a new Google
Maps marker, open paren and then close paren. And then notice I have a
curly brace in there, too. Because marker is another
feature of the Google Maps API that lets me specify on what
map I want to put the marker. So there's a key called map. And then coincidentally, there
is a variable called map, which I defined up here. And then it takes one other thing,
the position of this marker. Well, I'm going to put this
marker at latitude 42.3762 and a longitude of negative 71.1158. And then just for good measure,
let's do one more of these. And actually, I don't strictly
need the variable here. So I'm just going to get rid of that. And I'm going to do a
new Google Maps marker. Same syntax as before. The map is going to be the same. But the position of this marker is
going to be a latitude of 41.3104 and a longitude of negative
72.9289 close curly brace, save. And if I didn't screw up, which I did. And it's yelling at me. Unexpected token param--
oh, OK, forgot this. Save. Go away. Go away. Reload. Let's go and zoom out. And look at that. We have markers over what is
hopefully Harvard and Yale. And so where did all this come from? Well, literally Google Maps. And that's what I Googled
during the break, API key. Google Maps API. And if I go to this URL,
as you soon will too, you'll see under its
documentation that they have many different APIs, some of
which are for phones, some of which are for web pages such as
this, the JavaScript API. And you'll see that there's a very
rich interface for actually creating these kinds of maps. And the documentation, frankly, can be
a little overwhelming at first glance. But here they give you examples of
how to put a marker, for instance, over Australia. This is how I inferred how to put one
over Cambridge, Massachusetts and New Haven. There's other functionality, too. Like these things called info Windows. So with info Windows, if I
scroll down to this example here, you'll be able to add clickability. So if I register an event handler
that's not on submit but on click, I can do things like
this, just as Google has, whereby on clicking a marker, we
trigger something else to happen, in this case, an info window to
open, and thereby get functionality. And so to bring all of this together,
which you will do, ultimately, for CS50's mash-up problems
set, your very last, is to implement a user interface
using some of these building blocks. Here we are centered over
Stanford, California. And notice that the map is full screen. But you can zoom in and out down there. Notice that there's a text box,
which is a very simple HTML form at the very top. And notice, just as I did before, we
have configured the staff solution, as yours will soon do too, to
listen for clicks and on clicks, call a function that makes
an AJAX request to a server, get back some news articles, create
an unordered list out of them, and display them in one
of these info windows. And so if we actually look at
what's going on underneath the hood, let me go to my developer
menu, under developer tools. And as you should be in the habit,
again, watching your network tab, let me go ahead and do exactly this. Let me clear that, click
Palo Alto's news, California. And notice a few things just happened. One, my browser made a
request to an articles route, passing in the geography
of this zip code here. Notice that I got back some gifs here. And in fact, the internet here is so
fast, we didn't see the progress bar. But we would have seen a little spinning
indicator if the internet were slow. And that's how I then
got those news results. And if I click on the articles here,
notice what I'm getting back is-- OK, hello. Always check the day's
news before class. So what I see here is a big JSON object. And it's all in one line. So it's a little hard to see. But I'm sure you can
scroll through the news later and see actually what the
articles and the URLs thereof are. But there's one more
piece of functionality. All of us have seen auto-complete
work in our browsers, because it remembers usually
what you've previously typed. But it's more powerful
to autocomplete based not on just what the users typed in the
past, but what you think in the future they might be typing. So if I actually want
to search for 02138, notice I can narrow down the list of
all the cities in the US so that I can click on that autocomplete. And now we have a localized
map to the Cambridge area where I can get the
local news from our area. Or I don't have to
search just by zip code, I can type in New Haven, Connecticut
and get any of New Haven's zip codes and similarly teleport over there. So among the challenges ahead is to
download a pretty big file, a text file, called us.text, in which are
bunches of cities names and states and zip codes, import those
into your own SQL-like database, implement a few routes so that
you can ask your database what are the few cities within view and
what is the current news in this area, and then using JavaScript and today's
ideas, stitch all of this functionality together to mash up all of these
different ideas into an end result, your last. And that's it for today. I'll stick around for
questions one on one. Otherwise, we'll see you next time.
