Soma: Created page with "==Video== Video from the lecture for October 8, 2024 is now available: * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec09-20241008.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec09-20241008.cc.vtt auto-generated captions] ==Notes==

 Lecture 9 ---------  I'm happy to answer any questions, but otherwise will be moving on to new material.  If you want to work on your code locally..."

2024-10-08T19:48:01Z

Created page with "==Video== Video from the lecture for October 8, 2024 is now available: * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec09-20241008.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec09-20241008.cc.vtt auto-generated captions] ==Notes== <pre> Lecture 9 --------- I'm happy to answer any questions, but otherwise will be moving on to new material. If you want to work on your code locally..."

New page

==Video==

Video from the lecture for October 8, 2024 is now available:
* [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec09-20241008.m4v video]
* [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec09-20241008.cc.vtt auto-generated captions]

==Notes==

<pre>
Lecture 9
---------

I'm happy to answer any questions, but otherwise will be moving on to new material.

If you want to work on your code locally but run it in the class VM, using something like git makes sense, specifically with the master repository being on github.
- you push updates from your local machine and then pull down updates on the VM
- classic way of doing cloud development
- but there's a learning curve, outside the scope of this class

My expectation is that you will understand the code in the assignments on a line-by-line level.
- know why each line is there, consequences of removing or altering any of them

Remember that at some point we'll start doing interviews...

Main topic today: client-side JavaScript
- what we're going to be focusing on in one way or another for the rest of the semester.

let vs var
- both used to declare variables
- var is function scope, let is block scope

For me, let isn't so useful because I like my functions to not be too long, so there aren't too many variables that are declared and used in it.

If you have larger functions, then let can be useful.

Many people don't like var so much because it is "hoisted" up, i.e., declarations late in the function act as if they were declared at the top.
- but this makes sense to me since this is how C works

let has block-level scope so it is "safer" in the sense of smaller scope, but that doesn't seem to matter much in practice

Common use case for let
- declare variables inside the scope of an if/else statement
- here this is good if you don't want variables to be visible outside of the if or else clause

// Demo of scoping rules

function outer(a) {

function inner(b) {
if (b > 7) {
let x = 5;
// var x = 5;
}

return a + b + x;
}

return inner(x);
}

var x = 12;

If you're declaring a variable to have the scope of a block, use let. Otherwise, use var or let.

Question: does JavaScript do shallow or deep copies of arrays and objects?

Answer: shallow only, on assignment

a = [1,2,3];

b = a;

a and b both refer to the same array.
- so changes to b will be reflected in a
- declaring const makes no difference (objects & arrays are always mutable)
- strings are mostly immutable however
- really, a and b are pointers to the array
- and if they were declared const, then they are immutable pointers

How to clone an array:

https://www.geeksforgeeks.org/how-to-clone-an-array-in-javascript/

Interestingly enough, the slice operator creates a copy of the array or string always
- so you can use it as a copy method
- but the copy will just be one level, won't be recursive

Let's talk about client-side JavaScript

The origin of JavaScript was in the web browser, not the web server
- it was a language that was to be embedded inside of a web page
- specifically, you'd have an HTML <script> tags which would enclose JavaScript code.
- or, you could load JavaScript from a separate file, but same syntax

Why run JavaScript (or any language) inside of a web page?
- originally the idea was very modest
- do things like validate form data, implement drop-down menus,
just make the page slightly interactive

And in fact client-side JavaScript had lots of limitations
- would only run when the page was loaded or when specific user actions happened (i.e., when a user pressed a button)
- HEAVILY sandboxed for security
- no local file access, or local access at all
- no persistent storage in browser
- very limited network access (same origin policy)

So, JavaScript code couldn't run for very long and couldn't access much. This kept JavaScript secure.

But then web developers wanted to do more and more
- they wanted to make web apps, not web documents

But one little addition to JavaScript changed the game: XMLHttpRequest
- this allowed for background network queries and for background JavaScript code execution
- originally implemented using an ActiveX control, but then became built-in to all modern web browsers

ActiveX controls were digitally signed bits of Windows code that could be downloaded and executed by Microsoft's Internet Explorer web browser
- yes, it was downloading binaries from the Internet that could do anything
- all that protected you was the fact that they came from "authorized" entities
- there were evil ActiveX controls, and now nobody supports them anymore
because they were a BAD IDEA

Microsoft created XMLHttpRequest for Outlook Web Access
- because the Outlook team knew they couldn't make a good web email
client without background network access and background code execution

But this opened the door for web apps that have taken over from desktop apps

The big ones that showed people what was possible were Gmail & Google Maps

Document Object Model (DOM)
- the key technology bridging the world of JavaScript and HTML
- you COULD have JavaScript manipulate HTML as a big string, but that is not efficient and is very error prone
- instead, the browser converts HTML into a bunch of JavaScript objects
that can be queried and manipulated
- when those objects are changed, what the user sees changes as well

The DOM is the killer app of client-side JavaScript
- no other client-side language has direct access to the DOM, they all
go through JavaScript
(one day WebAssembly may have access but not today)
</pre>

WebFund 2024F Lecture 9 - Revision history