CS 1100: Web Development: Client-Side Coding

Session 2: An Introduction to the Web and Our Tools

Vignette: My Oldest Pages

While designing this week's material on the history of the internet and web last year, I thought back to my first experience writing web pages. It occurred to me that those were among the first web pages created at UNI. A little file archeology supports two facts included on the About Me page:

I promise not to continue to draw attention to myself, and especially not my age. But history is history, even if ancient. And it's fun for me to know just how long I have been working on the web.

The Architecture of the Web

I won't work through every word of the reading for the week in class, but I do want to hit some highlights and expand on a couple of topics.

The Internet and the Web

Like all of computing, the histories of the internet and the web do not go back all that far in time. (How old are your grandparents?) 2023 was the 50th anniversary of the beginning of TCP/IP, the protocol that governs the internet. It was the 30th anniversary of the first graphical web browser, Mosaic [image].

One of the wonderful features of the web is that the standards are backward compatible: pages from the 1990s still load and run as they did then. We just saw that with my simple pages from the mid-1990s. Here is the first web page ever, which still resides at http://info.cern.ch/hypertext/WWW/TheProject.html. We can see the raw HTML code in our browser, too.

The first web page, like all other pages of that time, is static. It is a text file that lives on the info.cern.ch server in Switzerland and is delivered over the internet to our browser. All processing happens client-side, in the browser.

This is in contrast to the page you see when you log in to Amazon, Netflix, or YouTube. That page is dynamic, assembled on the server based on your account details and history. That page is then delivered over the internet to your browser. The page then talks to the server as you interact with it.

Web Clients

When we speak of "web clients", we are usually referring to a program called a web browser. Today's web browser is a graphical user interface that interprets HTML, presents information to us, and supports input from us.

Earlier, we saw the difference between what a web page is in its raw form and what we see in the browser when we looked at the first-ever web page. Consider the reading notes for this week, which live at http://www.cs.uni.edu/~wallingf/teaching/cs1100/readings/01-arch-of-web.html.

We can, course, open the page source in any text editor, such TextEdit or emacs to see the page source, too.

We can also interact with data on the web more directly over the internet, using a text-based tool. One of the common command-line programs for doing this is curl (client URL). curl retrieves and presents raw data to us.

curl http://www.cs.uni.edu/~wallingf/teaching/cs1100/readings/01-arch-of-web.html delivers the source code for the web page to us as uninterpreted text.

curl --verbose http://www.cs.uni.edu/~wallingf/teaching/cs1100/readings/01-arch-of-web.html delivers the source code, too. But first it shows information about the request sent to the web server: 

* Host www.cs.uni.edu:80 was resolved.
* IPv6: (none)
* IPv4: 134.161.120.93
*   Trying 134.161.120.93:80...
* Connected to www.cs.uni.edu (134.161.120.93) port 80
> GET /~wallingf/teaching/cs1100/readings/01-arch-of-web.html HTTP/1.1
> Host: www.cs.uni.edu
> User-Agent: curl/8.7.1
> Accept: */*
>

And then it shows the HTTP response from the server, as described in the reading: 

* Request completely sent off
< HTTP/1.1 200 OK
< Date: Wed, 28 Aug 2024 20:09:09 GMT
< Server: Apache
< Last-Modified: Tue, 27 Aug 2024 15:04:43 GMT
< Accept-Ranges: bytes
< Content-Length: 25005
< Vary: Accept-Encoding
< Connection: close
< Content-Type: text/html
<

The response is a sequence of name/value pairs that describe the what the server has returned to us, and how.

A web browser and curl look different in both their use and their output. But both use the same protocol for communicating over the internet. Recall that a protocol is set of rules for sending and receiving data.

Our Tools This Semester

Web Browsers

As noted in the reading for today: Web developers can never know for sure which browser their users will have. This means they have to test their pages in different browsers and on different computers in order to make sure the experience is good for as many people as possible. I won't expect you to test your pages on different computers, but we will test them in different browsers.

The first is the default browser for your operating system. On macOS, that is Safari; on Windows, it is Edge.

We will also use two popular cross-platform browsers this semester: Firefox and Chrome. I used Firefox earlier today. Many of you are probably already familiar with Chrome.

We will use all three browsers during the course to view web pages like any other user. But we will also use each browser's developer tools (devtools) to let us look under the hood at the web page and how the browser processes it. These tools will help us understand code better, debug code that is not working as we'd like, and create better pages.

Each browser offers devtools available off their title menu:

All of the browsers offer a short-cut to the inspector: ctrl-click inside the window and choose 'Inspect' (in Safari, it is 'Inspect Element'). The inspector looks much the same in the different browsers, with a few variations among them. We will use the inspectors frequently this semester.

Use the devtools. Examine Elements, Source, Console, and Network. Connect what we see under Network to what we saw using curl. Defer console to later, when we learn JavaScript.

These will be our tools for viewing, examining, and experimenting with web pages.

Text Editor

We don't use word processors like Word or Pages to create and edit files for the web. The purpose of a word processor is to create formatted documents, so they add information to the file that the user doesn't see. Files for the web consist of plain text: bare HTML and CSS.

To work with plain text, we need a plain text editor. There are many, including NotePad on Windows and TextEdit on Safari. Many computer programmers use command-line programs such as emacs and vim. (In my daily life, I am almost exclusively an emacs person.)

To create and edit web pages, stylesheets, and JavaScript code, we will use a text editor created specifically for web developers: VS Code.

Use VS Code to open a file, edit text, autocomplete, follow advice, and read documentation.

Closing

We will use another software tool this semester, Node.js. It will help us learn and work with JavaScript. Let's save learning about it until we get to JavaScript.

Homework 1 is available now and due one week from tomorrow. Its goal is to set us up to use the software tools we need for the rest of the course, including VS Code, the browsers, and the course's submission system (homegrown and written in a mix of HTML and Python). It asks you to explore VS Code on a simple file so that you start to feel comfortable before we begin writing code next week.