Good afternoon, everyone. Sorry for the late restart time. I had a
a physical this morning and so
And those were hard to schedule, so I had to kind of take it when it was.
So today, so administrative thing, source any
If you have questions, go ahead and put them in the chat.
I'll go ahead and start here so um
I think I have all the midterm marks, so I should be able to put those out today.
Yeah, I'll say.
books should
Also, we'll be out by next class.
Boy, you know.
And then…
So we'll get that going.
for assignment
So question, folks, would you all like a bit more time for the assignment? I'm just kind of curious.
Anyone here?
I was thinking of extending it to
So I'll keep the official due date the same.
Yeah, so…
Yeah, so I'll extend it to Saturday night and
give you all a um
The official due date will remain the same, but it will be accepted till Saturday.
If you submitted already, you'll be able to resubmit.
it only keeps the most recent version.
So feel free to
I only download it after, you know, after submissions closed.
please make sure the assignment three passes the validator. If you
If it doesn't pass the validator at this point, I'm just going like, are you looking at the code? It's going to make me very sad.
There.
Oh, someone wants to visit.
If you want to come in
Oh, yeah, you're here. I'm going to pick you up.
Okay, come here. Come here. Come here.
Oh.
This is Mr. Tab.
Hello. Say hello to everyone.
He brought his toy in. He wants me to throw it for him.
So I won't throw it for him but then
Here you go.
Yeah. Yes, exactly. Ironic that a submission that doesn't pass a value or submit it, it's like.
Yeah, that's, I don't understand that.
Okay, he's now…
I don't want to give him a second here. Hopefully he'll calm down. Let's all kick him out.
Trying to think anything else any other administrative things?
So…
So we're right now on the 19th.
So just…
Last day of class is December 5th.
So you'll have…
I mean, you'll have at least 10 days to work on it, but it'll be based on the
you know, just the code that you all have seen.
So what I wanted to talk about today
is um
So the last tutorial
I cover, I don't think I had finished it
by the time, let me walk through that a little bit.
And then I want to
talk about
I'll just bring up the code here.
Come up. Come up.
Come on.
Okay, you're done.
you go.
So he's wanting to play.
So let's bring up the code for the tutorials here.
So in terms of the code.
what i um
trying to remember things here so
So there's the getting the cookie if we want to get the auth user, get cookies from the
include AI code, and this is all the same
uh…
redirect, that was something I added in
So the idea is that once you
When you do a login and what it does is, so if council student
we redirect to student index.html.
And that's what this does.
And it just sets the status see other status.
see other is a status
303.
And that's a basically load a different page. And so the browser will, when it gets that, it says, oh, which page should I load?
And so the redirect
Does this, the contents are ignored
But the location is what's used.
For the redirect.
And then we'll try response. And then we have
So it does these redirections. Otherwise here if
If we get something that the user's unauthorized and we're here trying to log in and stuff.
we can just say
you know.
Yeah, this is because if the account's there and the account equals the password
this is all fine and then we're just checking whether they're student or admin access.
And it's some other kind of access. We don't know what it is, so we signal internal server error.
Otherwise, we say it's unauthorized and we redirect to login fail.
Create account.
Just loads the form, puts it all in there, puts it
you know the response, nothing exciting there
outposts, nothing exciting there
All right.
Oh, they have nothing there. Handler got changed a little bit
with adding in
So we have the RAuth user if that's defined, we do a set cookie
And if location is set.
as in a redirect, we add the location header and do this.
So that, and then um
In terms of AuthDB, this is all, I think, the same as I had set before.
Well, I think there might have been a mistake.
Somewhere in there. But basically this code is as you'd expect it. There's nothing particularly excited. Although one thing I will say is
I had trouble debugging ad account.
When I was doing ad account, I had this all set up and I was like, why is it not working? It's not adding to my database.
I left out the…
the square brackets. So it means I was actually giving it five arguments rather than one argument
that was an array, which is what db query wanted.
This is where the lack of type checking can
cause problems.
And then…
get account. Yeah, that's all there.
templates the same static
I put this log and fail. It's just a simple dot.
So otherwise, I think the code is pretty much as I showed it to you.
on…
On Thursday.
I'm happy to answer for the questions about tutorial 8 code.
But more what I want to do today is I want to talk about
going forward.
the cat's unhappy that I've left him out.
He's kind of still scratching at the door, but
He will deal.
So unless there's any other questions, I want to start talking about new material. And really here, I want to lay the groundwork
for stuff that this class
Is it covering in depth?
But you have the basis for understanding
At this point.
one um
So let's say in terms of advanced things, one is sessions
which I'm hoping to incorporate properly into the next
And into tutorial nine.
And so the idea of sessions
I'll say sessions.
So if you want to store more data.
You have a client.
And you want to store something about the current user session, like when did they last log in?
What are their preferences? What are the things like you have two basic approaches. Either you shove it all into the cookie
or the cookie is a reference
to a database record on the server.
The advantage of putting on the database record is that
all that's on the client side is just a reference to it.
even if it gets deleted, no state has been lost.
you still always have that information on the server.
But if you maintain it in the cookie.
then don't.
the server doesn't have to store it. Then you don't have to maintain that state. It can just do everything based on the cookie that's brought to their butt.
brought to the server as part of each request.
But if you really want to maintain the same amount of stake per user.
the cookie could get quite large and stuff so
you typically um
It all depends on exactly the nature of the web application, how much state you want to store.
So there's this notion of HTTV global storage.
Hi. Yes.
Assignment 3 will be due Saturday night.
So at least it can be submitted by Saturday night.
But so HV local storage.
This is…
So this HTTP local storage, it's basically like cookies except
It allows you to store a lot more in the client.
So it's a newer standard. Cookies are older.
I mean, cookies are like 4k
HV local stores that you put in north. But conceptually otherwise it's
basically the same stuff.
So we've got all the tech you need for sessions
local storage is just another API, but it's
basically like cookies.
Except that, of course.
It's also serving a different role. It's basically serving as data can be there
on the client say like
This is the sort of thing that's used for Google Docs.
If you want to use Google Docs, you know.
Awesome.
So if you want to use something offline, HP Local Storage lets you keep things there.
And then, so just in terms of topics we're not going to really talk about too much.
Another thing that we're not really going to talk about, but I want to at least mention
is um
Has anyone heard about virtual doms
Okay.
I'll just keep.
We got to use virtual dome. Yep.
So, well, so the virtual DOM is not
one thing.
So the base you know
So the DOM is just the document object model.
It's the JavaScript accessible representation
of the HTML page.
It's generated for every HTML document
that a browser loads.
And that has JavaScript, because if you don't have JavaScript, why does it need to build the DOM? Because no one's ever going to access it.
browsers might build it internally but
conceptually, it doesn't really exist unless JavaScript can access it.
So this is what the data structure
that JavaScript on the client
will access in order to change what the page looks like.
So the idea of a
So a virtual dom is just
a DOM-like data structure.
It's not necessarily exactly the same.
Because that's implementation dependent.
But but it's
basically like the dominant
data structure that's in the browser
But it's in the server.
So, uh.
Why? Why maintain, you know, this is strictly duplicative functionality
the DOM is on the server. The server served the HTML there
why do you have
have this.
make the page they want.
So why does the virtual DOM update a DOM element faster than the DOM?
That's not strictly true.
If you know exactly what you want to change.
client side, you can always just
have JavaScript in the client
just change it.
Now…
That's not what it is. It's not really about
speed per se. It's more about managing compliance.
Because if you think about it, you have a complex user interface.
And you're server side and you're going like, well, I need to change
something in that page.
Now, you don't have
In a classic JavaScript.
you know a classic web application, you don't have
the data structure
that is being manipulated, visible to you
on the server.
The DOM is purely client side. So the server has to guess what updates need to be made to the DOM
without having a copy of it.
All a virtual DOM is is a copy of that data structure on the server side so it can say, oh, I'm changing this, this, and refer to that data structure, make the changes it wants, and it says, oh, now these changes do the same thing on the client.
So it just minimizes the complexity
of state updates, given the fact that the server can't directly introspect.
So…
I don't remember the exact term.
What was it?
It's an isometric?
pages, I'm not quite sure of the term
But a modern trend is now to have
you know to um what's it called?
not saturate.
So this is really kind of the modern way of doing things is you have a virtual DOM,
on the server. And of course, there's the DOM on the client.
But what you actually ship. So rather than shipping
a template
to the client and the template then gets filled in by client side JavaScript.
you have the template on the server. It fills in the initial version of the template. So you basically have a static page with some JavaScript embedded
for future updates.
And then that gets shipped to the client. The initial version is fully usable without any JavaScript
And then to do updates, client-side JavaScript runs, and then you get the nice smooth user interface.
Oh.
All I'm saying with all of this
is all of this is all of this
This is the thing I want to point out is that
This doesn't really use anything conceptually new. I mean, there's some little fancier things here and there for
You know, helping with the software. I haven't really talked about um
how JavaScript objects work, I want to do that um
probably later even though it's
you only need if you're, well, you might need it at some point.
But it's all stuff built on top of this
foundation that you already know.
It's just different ways of using it.
in a way that makes life easier for a developer. And in particular, you don't need to use it.
It's just that that's the trend. I mean, there's a real trend to have a lot of JavaScript running in the client.
And a lot of jobs are running the server. But then there's the alternate trend where
you make client-side pages have almost no JavaScript.
And everything gets um
generated as HTML documents on the server. I mean.
There's so many ways to slice things. Modern clients are so powerful. The servers, they're so many powerful
Framework said there's all this technology that allows you to share code between the
the client and server so you can decide where you want it to run. Do you need your JavaScript to run on the server or on the client?
If you have validation code, it could run on the client and or on the server. So you get the user UI benefits on the client and get the
data integrity benefits on the server
it's all just playing around with the toys that you've
seen already.
And it's amazing how complicated it gets.
given how
straightforward, like the tech seems so simple it's just basic mechanism but they're very
powerful mechanisms.
And that's what allows the modern ecosystem
to be.
I am…
I'd already mentioned WebAssembly.
that's a you know just um
you know something about it.
You still need some JavaScript to access. So WebAssembly allows you to compile.
It's like an assembly for the web. It's its own bytecode language. It's formally verified. It's a really cool set of tech. I'm doing some research on it.
But it's a target.
for compilation. So you can run
Um…
Have you all learned about garbage collection?
Is that something that's come up in your past classes?
Somewhat? Okay.
Okay, so…
Good job.
Python.
So this is just a cool thing that WebAssembly is really this cool tech
that lets you take an arbitrary
program for the arbitrary language, compile it to WebAssembly, and then run it in the browser.
current standards for WebAssembly
don't really have full…
you can't do that for access to the DOM. You have to go through a JavaScript shim. There's proposals for changing that. That isn't standardized.
But a newer standard that does seem to be standardized is garbage collection for WebAssembly, because traditionally WebAssembly is like a
like x86 code or something you can't
If you want garbage collection, you'd have to implement a garbage collector.
But so if you wanted to have code like
Python running in the browser.
you'd have to include the entire Python runtime, the big chunk of which is the garbage collector. But if you rely on
JavaScript's awesome collector. JavaScript's awesome collector you were
They're good to go, makes it possible to use
dynamic language as opposed to just stackly compiled languages.
in the browser.
So there's still there's still
WebAssembly plus JavaScript is so good.
They may be the main execution
thing going forward.
they have lots of good features. They have built-in security. They're efficient.
Standard, portable
This is, I think, potentially going to get rid of native code for
many, if not most applications, mobile apps currently are hold out. Those are still compiled natively to a large extent, and embedded apps.
you know things on
you know just any sort of embedded application
Embedded stuff I think
it might actually still make inroads there.
With mobile apps.
I think most of the reason
We don't have more use of web standards in mobile apps is as much.
market power issues as opposed to technical issues.
And given the current litigation landscape, I would be surprised if that changes.
Okay, so it's entold in the context of Java only.
JavaScript, I will say that Java garbage collectors
used to be the, I mean, any language
where you aren't doing manual memory allocation.
Yes, sir.
say something.
So most languages
If you don't do manual memory management, you're going to have a garbage collector. All that means is
Let's say we had some code, silly code like this here.
What native code, I'll
I'll talk about that in a second. So if you're doing this.
So just in terms of, so for review what I put here
So if you run this code here.
you've got a is equal to one, two, three, four, five.
And we say B equals a.
So that's now so now we have two references to this
data structure, but then we say a equals six, seven, eight, and we say B equals A.
Now, A and B are the same. They're both referring to the array six, seven, eight. What happened to the first array, 1, 2, 3, 4, 5,
it still exists.
it has been deallocated. If you did this in um
in c
this would be a memory leak.
Garbage collected languages don't have memory leaks.
Unless you really, really try and confuse the garbage collector.
But, you know, that's what
talking about here. Now, one funny bit of
of information here. Python's garbage collector is
not the best. Python is not fast.
Python slow. Garbage collector's not great. Language runtime's not great. It's just due to engineering.
But Java and JavaScript
So there's lots of engineering that's gone into
Java and JavaScript.
Really because of the web.
And then enterprise apps for Java.
Because it was competing with C. But JavaScript has gotten a lot because of client-side JavaScript.
So there's a question here, what do we mean by, when I talk about native code here.
Well, the three common ones you'll see nowadays.
You lose the arm as in mobile devices. You'll see x8664 that's on PCs.
And you're starting to see RISC-V that's a
was at risk five. So I'm not sure it was risk B or risk five.
This is a…
have an open source
architecture.
So if you compile it for CC++ or Rust, you've got to make sure you
choose the target, you know, what it's going to run on
I'm just going to say this is not strictly true because you don't have to
Turns out when you run
you think running native code is always faster
As opposed to having to dynamically
But, you know.
There's this notion of just-in-time compilation
I could talk about that if we have time, you know, end of class but um
it can actually make things
I'll just put it.
the link in there.
If you're curious about, this is a bit of old work, which is still really fun.
It's wild what they did here with this just-in-time compilation.
something for you to look at but that's
I'm just now kind of talking generally. This is stuff that I'm not covering directly um
you know in here, but this is more contextual stuff
for you to understand what's going on.
But the main thing, the reason why I wanted to talk about this is because in a sense, at this point in the class.
I've covered
the fundamentals for the most part. I mean, the things I haven't
I don't really cover language features that much. I haven't talked about closures
properly.
and prototype-based inheritance and JavaScript enclosures.
probably other JavaScript language features we haven't really covered.
JavaScript is actually a relatively
straightforward language. I mean there's
There's various niceties now.
But…
It's a pretty straightforward language. We haven't covered
TypeScript.
So TypeScript is saying supports it natively. Brows do not.
So I'm mentioning TypeScript. Deno supports it natively. It's a big thing now in web development. A lot of people like
using it.
I've specifically avoided
using it here.
Because TypeScript doesn't add any new semantics.
All it does is it adds types
to JavaScript and they are optional. You don't have to put it on all the code.
But you put these types onto
onto variables and then
the compiler knows what they are. And so when you load that code, rather than running and then running along going, oh, wow, this is data we aren't expecting.
it will um
detect those kind of errors at compile time, much like you do with
Rust code or you do with them
or C and C++, like all those things, you know, this is what we have strongly typed languages, but languages like Python and JavaScript don't do this.
Data types have types.
But references to them do not have types. So a reference can refer to anything or refer to an integer. It could refer to
a string, you can refer to an object and refer to a function when you just have
a variable, you don't know what it is.
that's not the case now.
There's a philosophical argument about which is better to do.
you've already had enough
exposure to adding types. So if you add types to JavaScript to do TypeScript.
you know it's
It's pretty simple. For me.
I find it irritating.
I think because I
Because of how I learned how to do programming.
But if you prefer to do it, there's no reason you can't do TypeScript. The only thing is if you have TypeScript code.
on the server.
And then you want to use that same code in the client
you'll have to convert the TypeScript
to JavaScript and then send it to the client.
Which is not, I mean, that's not hard at all to do but
one of the things I really like about
doing things with JavaScript, you have the same language in the browser.
has on the server.
But yeah, in terms of low level technology things
you have what you need to understand stuff.
Oh.
So having said this is what's
you know, in terms of
that's out there this is really…
the foundations of stuff that you haven't seen.
There's cryptography, but we already talked about cryptography and stuff but
So there's a bit more to HTML. If you look at the HTML spec, there are
other little things you can do with html but
HTML itself isn't actually that complicated.
there's a lot of complexity to CSS.
CSS has gotten very fancy.
parts of CSS
isn't supported by all browsers. Some parts of CSS
work slightly differently between browsers. There's a lot of complexity around CSS.
to the point that a lot of people try to abstract CSS.
I'll talk about how you deal with complexity later.
there's a lot to CSS.
For JavaScript, there's a
Well, we need to look at closures some more, look at the object system but otherwise
then you basically know JavaScript.
there's now some language facilities like iterators and things
Nothing too fancy, nothing that you don't see in other languages.
That's what mostly the additions to JavaScript are is to add in programming
conveniences that are present in
other languages.
But what you have instead is
there's just a lot of JavaScript code that just does a lot of stuff.
And…
Yeah.
So…
there's a lot of service client-side JavaScript. I'll talk a little about React.
In a second here.
But there's also a lot of server-side technologies. There's java
There's C sharp, there's Ruby, there's Node.
You know, this is node is
like deno
but not and there's many, many frameworks and libraries built on top of this.
So…
When people talk about how complex the web is.
If you're going to be a web developer.
there's a lot of complexity.
But much of what that complexity is
is first of all is
is all the stuff people have built on top of it.
I mean, there's all this
you know, there's a lot of stuff built on top of CSS. There's so much JavaScript code that meant for the client side.
There's so many server-side things entire
frameworks and libraries and all these elaborate things that have been built on the server
And then to integrate with clients in order to build complex web apps.
There's so many of them and so many of them are very
very fancy technologies.
If you're going to be really getting to web dev, you're going to be learning those.
And there's a lot to learn.
But they're all built on the basic technologies that we've covered in this class.
And if you look at those core technologies, the core is actually relatively small.
I mean, SQL, basic SQL is not that complicated basic
Even basic HTML, basic CSS and stuff. These are all not very fancy, but there's lots of little corner cases and it gets large in but
Some of this stuff is obsolete. For example.
you know you have XML HTTP request and fetch
Fetch is the modern way to
have JavaScript get content from
from the server, it's a nice, clean, promises based api
It just stopped.
It's so nice to use.
XML HTTP request.
It's an older API.
It's kind of messy.
Almost nobody uses that directly. They might use it inside of a
a library function which would provide fetch-like functionality
now it's all standardized on
Fetch is now supported in the browser, so you might as well use that. Now, you might say, well, that old tech
why doesn't that go away?
So web servers
Web servers, web apps, they can choose to use like certain tech, newer
But browsers have to support everything.
Remember the look of a page?
when you don't specify CSS,
the look of that page without any CSS
is essentially the way the web looked.
in the late 1990s.
That is the web.
And if you declare the top of your web page
certain things that correspond to older web standards like the
HTML 4.01 and so like there's all these older ways of having the
of having the document type at the top
the browser will detect this and go like, oh, you want to do rendering like it's 2001.
Sure, go ahead and the browser deals with it.
But if you want to use more modern stuff, then you tell it and the browser does the modern stuff.
as an application developer, you mostly don't have to worry about that old stuff.
So there's been a lot of work on web standards
Over the last decade.
And that's
it isn't…
let me show you. So if you look on MDM,
So in the older days of the web, there were changing of technologies. Some browsers wouldn't change as fast, and so a lot of effort had to be put into making
And making sure
web apps work the same on
all browsers.
now most of the things can basically be run and it's like.
it's compatible with a widely available in terms of features.
Bye.
you do have to worry about this complexity
when you're running a web app to some degree, because you have to test things on multiple platforms.
If you write code, you write your web app, and you run it in Firefox.
It'll probably work finding Chrome.
If you write stuff in Chrome and then run on Firefox.
it's a little less likely because Firefox is very good at following the standards.
Chrome has some deviations and
Because everyone uses the same
same few engines.
Firefox is not very well
commonly used outside of Firefox but
Crohn's is, like Edge uses the same rendering engine as Chrome.
Safari's WebKit is a
relative of blink.
So there's a lot of
overlap here is it's written very consolidated because these engines are very
how do you say it? Complex.
Have any of you heard…
I think everyone uses blank.
If that's wrong, please correct me.
Is Blink used no browsers that use Chromium? Yes. Blink is part of, if they're using Chromium, they're using more than Blink. They're using the whole thing.
Chromium is basically the open source version of Chrome.
I think you've heard of Lady Bird?
This is Lee Burton.
labor browser, the Serenity operating system
I was wondering if that's something that you guys had heard of.
If you haven't.
I think I personally am very hopeful
that's
the ladybird browser is going to get good enough
that people can start using it because
I think we need other things that can view the web and
good for someone to do a clean slate approach and try to do things but
We'll see. We'll see.
I have about 15 minutes left.
Now.
What I think I want to do now is
I think it's worth talking about some of the
I'm going to talk a little bit about React.
This reactive.
So if you talk about web development.
people will talk about React.
React is super popular.
And it's termed as a library for web and native user interfaces. It was developed by
Facebook Meta.
And…
So if you know anything about Swift UI,
SwiftUI is an Apple specific technology for creating declarative interfaces.
React, I would say, I don't think they
by any means, but they really pioneered
doing this for the web.
So when you're developing user interfaces
one of the hardest things to manage
is state.
Which means that what is the current state of the application? You want the state of the user interface
to reflect the internal state
of the data in the application.
what you often have to do
is, you know, without something like a decorative interface
you have to specify code
that when the internal state of the app changes.
the interface changes.
And because you're doing this manually by synchronizing these two, it's very easy to have errors crop up
where the user interface will say one thing, the backend state will be another, and the user will get confused because it thinks the world is this way, but
it's actually something else completely different.
Or maybe sometimes it might be slightly deviated, sometimes you get very large deviations.
huge source of bugs in user interfaces
Things like React.
make most of these errors go away
because you don't
manually synchronize the state.
It's kind of like the virtual DOM thing.
That's why it uses a virtual DOM is because it's managing state for you.
This case, the state of the user interface versus the state of the web app.
by having
declarative approach to interfaces and maintaining a virtual DOM mirror of the client
you just manipulate the state
in your code.
this is the real win of things like React.
you just change
the internal data structures of them like.
Is this related to MVC? So
Yeah, if you're talking about an MVC model, model view controller.
you as a developer maintain the model.
that's your job.
you declare the views.
You say, this is what I want, what data I want to be shown to the user and how it's going to be related to each other.
And then the controllers for how you connect all these together and it's like
you don't even have to specify that. The controllers basically become automatic because in the views
you would specify like how it relates the internal state. And then if you give the user a knob here, it will automatically change the internal state. You don't actually need a controller at all.
So it's really, MVC is a very old way of thinking of interfaces
that's not really how
things are done today.
Because if you use these declarative interfaces.
up.
So when we're talking about React Native, what we're really talking about
React Native really was developed by Facebook because they wanted to be able to have a single code base
for writing their web app.
for their iOS app and for their Android app.
They couldn't have them completely unified, but they wanted to
share functionality and they didn't want to make just iOS and Android apps be web apps because they knew that they would not give as nice of an interface.
it would be a smooth and everything as responsive as they did it as a native app.
they wanted to use native widgets
the native controls rather than just web controls.
So that was the idea behind React really becoming popular, especially in the mobile space.
is because you write a web app and write mobile apps and share most of your code base between all of them.
Honestly, um.
The odd thing is in practice, I've said so many things of people
try and do things with React Native and maintain multiple versions of an app.
And then going like, this is so hard. And they just give up and then just write separate
apps for each of those i mean it's
Yeah, it gets messy.
I mean, that's really what you're talking about when you talk about like SvelteKit or Preact or React or other things.
It's all about how do you specify the user interface?
How do you synchronize that user interface with state that is on the server side? Because you have the server side.
I'll end with this.
So that's what
where we get into all this stuff here?
is how do I deal with my UI being separate from
the core logic of my application. These are in different things
you want to have this highlighted
this fact that you're splitting them apart from each other just makes a lot of things hard.
we're going to explore these issues more in the remaining classes.
But I will just end saying
I'm going to introduce some new code.
And here's some code in tutorial 9.
But…
most of that is, I don't think I'm going to have most of that on the final exam.
Most of that stuff's going to be more fun stuff
I'd like you to expose you to look at, but it's not really the core stuff I want you to learn.
Because…
Again, there's so much variation there when you get to this, I'm literally picking out a couple examples
to show you what they're like.
And you'll see that
you could have implemented themselves but these things
provide some simplicity and stuff, provide some functionality, but they write a lot of code.
To do that, is it worth having the extra code for it? It really depends on
you and your application but i just
just remember the underlying web tech is there and you don't have to actually play with all these
these extra things in order to produce good web apps.
And we're out of time.
Thank you all for coming. Thank you for coming for later time. My apologies for that.
And I will see you all on Thursday.