All of the HTML web have created has been created in a text editor and saved in a .html file, or maybe added to the page after it gets to the browser with JavaScript.
The .html files were placed on the server, and sent out when the corresponding URL is requested. The server's job is simple: find and send the file.
That's not enough for many web sites, where the pages you see on many sites must be created for you, when they are requested.
e.g. Facebook must go to its database to find your friends' recent activity to generate HTML for your feed; Google must find pages with your search terms in their index, and build HTML with the results.
In these cases, the HTML must be generated when the page is requested: dynamic web pages.
Pages that come from .html files: static web pages.
The browser has no idea where the HTML comes from: it just gets HTML from the server and static and dynamic pages look the same from the outside.
Dynamic web pages require a program on the server that can build the HTML.
… and for the web server to be configured to run a program to generate content for some URLs, but serve static content for others (stylesheets, images, etc).
Also, somebody has to write the program that runs on the server and generates the HTML. These are server-side programs.
… because they run on the web server. We have been using JavaScript to write client-side programs which run in the web browser (client).
With dynamic pages (and the server side programs that generate them), code can do anything any other program can do. Most notably, access a database to read information (like your account, sales, friends, etc) or update it.
When writing client-side programs, we can only use JavaScript as a programming language because that's the only language web browsers know [almost].
For server-side programs, we can choose any language (as long as we can make it run on the server and generate HTML).
Common choices for server-side programming language: Ruby, Python, PHP, C#, Java, JavaScript.
JavaScript is common on the server because web programmers already know it.
All of the basic programming ideas we have (variables, functions, conditionals, loops, etc) still apply to server-side programming. We need to add some way to generate pieces of output where we can build HTML.
The details of server-side JavaScript aren't important, but we can look at a sample program for some hints about what happens in server-side code.
Throughout the course, we have been talking about information travelling over the Internet. This happens using various protocols, usually HTTP for us.
But all information transmitted must be sent as a sequence 0s and 1s. The same is true for info stored on disk, in the computer's memory, etc.
Each 0 and 1 is a bit, usually abbreviated b
.
A sequence of eight bits is a byte, usually B
.
There are 28 = 256 possible bytes. e.g. 00101011
is a byte.
When talking about bits and bytes, the metric prefixes are usually used slightly differently.
A kilobyte (kB) is 1024 bytes. (1024 = 210; usually kilo is 1000)
A megabyte (MB) is 1024 kilobytes. A gigabyte (GB) is 1024 megabytes. A terabyte (TB) is 1024 gigabytes.
In general, n bits can store 2n distinct values. That's why 24-bit colour has 224 possible colours for each pixel.
How information is converted to bits depends on the kind of information.
e.g. for bitmap images, store the R, G, B values for each pixel, then do some compression on the to keep file size down. That why the things we saw about file size for bitmaps worked out like they did:
Most of the files we have worked with have been text files: HTML, CSS, JavaScript. These contain only characters: how are those encoded into bits?
It turns out this is important: if the author and browser disagree on the characters ↔ bits translation, they won't appear properly.
If we want to encode characters as bits…
Step 1: decide what characters exist and number them. e.g. A
is character 65, and €
is 8364.
This is done by Unicode, the character set generally used on the web (which we have talked about before). There are several older single-language character sets.
Step 2: turn the character numbers into bits/bytes.
There are a few ways to do this for Unicode: character encodings. Details aside, UTF-8 is the one to choose for the web.
You may have to choose UTF-8
somewhere in your text editor when saving files to make sure characters are encoded as expected.
The <meta charset="UTF-8" /> has been there on every page so we're explicit about our character encodings, thus increasing the chance everything works.
You may have seen pages where a characters like é
appeared as é
, it happens like this:.
é.
1100001110101001.
é.
It's generally worth it to try your pages (when encountering a new server/editor/tool) to make sure non-English text appears properly. If not, you may have character encoding problems.
Overall, this course focussed on front-end web development: creating web pages, and interacting with the user and browser.
This necessarily involves the web standards model: HTML, CSS, and JavaScript.
The first of the three building blocks we saw: HTML.
HTML was used to describe content of pages. On our side, we try to choose markup that describes meaning (semantic markup).
The browser interprets the markup for display on-screen. It can also be changed from JavaScript code.
When read by a search engine, the markup is used to help decipher the meaning of the page (or more directly, what search terms the page will be relevant for). Some other automated tool might come along and try to extract meaning from the page as well.
If we do it right, our markup should be good for all of these situations.
The second component, CSS, is used to describe the appearance of the content (which we specified with HTML).
If the HTML describes the content in a specific-enough way, we should be able to grab the appropriate parts in CSS and make them look as we like.
Many CSS changes are fairly simple: colours, fonts, margins, borders, etc.
Positioning is more complex: it can be tricky to specify a layout for the page that (1) is compatible with all browsers, and (2) looks good on a variety of screen sizes.
In general, browser compatibility is more of an issue with CSS (than HTML or JavaScript as we have seen it).
Since the first introduction, we have also seen that CSS can be changed with JavaScript using the jQuery .css() function.
We haven't talked much about the graphic design aspect inherent in CSS: that's another department's strengh.
Finally, we saw JavaScript as the last of the web standards components, and used it to describe behaviour of the page.
With JavaScript, we are able to modify the HTML page, and respond to user events (clicking, changing form contents, etc).
Most of the hard
part of JavaScript is figuring out the programming basics: functions, variables, for, if, etc.
We have done a fairly small amount of programming, hopefully enough that you start to see the possibilities, but probably not enough to make you a programmer
.
As ways to use JavaScript more effectively, we saw two libraries to help: jQuery and Raphaël.
jQuery gave us a way to find and modify parts of the page (more easily than can be done in plain JavaScript). The jQuery() (or equivalently, $()) function gives back a jQuery object that contains several useful functions: .click(), .append(), .css(), etc.
Raphaël gives us similar functionality for SVG images.
We can create SVG images (Raphaël paper objects), and populate them with shapes, and modify those shapes as we like. Raphaël shape objects contain similar (but not identical) functions: .attr(), .click(), .transform().
Using jQuery and Raphaël did two things in the course: (1) let us get more done than we could have without the libraries, and (2) gave us an excuse to exercise more programming concepts (loops, ifs, etc).
The other topic that we spent some time on was graphics.
Graphics are probably going to be part of any web site you make.
Graphics are the only thing we have seen where file size becomes large enough that we need to worry about download times. (But it's also true for video, audio, large JavaScript libraries, ….)
As a result, you need to think a little about how to get images reasonably small, while keeping reasonable quality. We get to select image format, (and depending on format…) number of pixels, colour depth, compression type, and compression quality
As we turned to Raphaël, vector graphics became something we could manipulate with code.
Hopefully this course has given you enough of an introduction to demystify some of the technology in your life.
I feel like I should have a conclusion here, but I don't.