[Intro to HTML, CSS, JS](https://docs.google.com/file/d/1tEnwxdIzMJeTEtjuNhiBWflaXVfngg7bnIGU2UUz-ZUz18lsTGc7sfd_zofW/edit?usp=sharing)
====================
From HTTP Request to Rendered Page
----------------------------------
1. You begin by typing a URL into address bar in your preferred browser or clicking a link.
2. The browser parses the URL to find the protocol, host, port, and path.
3. If HTTP was specified, it forms a HTTP request.
4. To reach the host, it first needs to translate the human readable host into an IP address,
and it does this by doing a DNS lookup on the host.
5. Then a socket needs to be opened from the user’s computer to that IP address,
on the port specified (usually port 80 for HTTP).
6. When a network connection is open, the HTTP request is sent to the host.
The details of this connection are specified in the 7-layer OSI model.
7. The host forwards the request to the server software (most often Apache) configured to listen on the specified port.
8. The server inspects the request (most often only the path), and the subsequent behaviour depends on the type of site.
• For static content:
– The HTTP response does not change as a function of the user, time of day, geographic location, or other parameters (such as HTTP Request headers).
– In this case a fast static web server like nginx can rapidly serve up the same HTML/CSS/JS and binary files (jpg, mp4, etc.) to each visitor.
– Academic webpages like http://startup.stanford.edu are good examples of static content: the experience is the same for each user and there is no login.
• For dynamic content:
– The HTTP response does change as a function of the user, time of day, geographical location, or the like.
– In this case you will usually forward dynamic requests from a web-server like nginx (or Apache) to a constantly running server-side daemon (like mod_wsgi hosting Django or node.js behind nginx), with the static requests intercepted and returned by nginx (or even before via caching layers).
– The server-side web framework you use (such as Python / Django, Ruby / Rails, or node.js / Express) gets access to the full request, and starts to prepare a HTTP response. **A web framework is a collection of related libraries for working with HTTP responses and requests** (and other things).
– To construct the HTTP response a relational database is often accessed.
– While sometimes raw SQL is used to access the database, modern web frameworks allow engineers to access data via so-called Object-Relational Mappers (ORMs), such as sequelize.js (for node.js) or the Django ORM (for Python). The ORM provides a high-level way of manipulating data within your language after defining some models.
– The specific data for the current HTTP request is often obtained via a database search using the ORM, based on parameters in the path (or data) of the request.
– The objects created via the ORM are then used to template an HTML page (server-side templating), to directly return JSON (for usage in APIs or client-side templating), or to otherwise populate the body of the HTTP Response. This body is then conceptually put in an envelope with HTTP Response headers as metadata labeling that envelope.
– The web framework then returns the HTTP response back to the browser.
9. The browser receives the response. Assuming for now that the web framework used server-side templating and returned HTML, this HTML is parsed. Importantly, the browser must be robust to handle broken or misformatted HTML.
10. A Document Object Model (DOM) tree is built out of the HTML. The DOM is a tree structure representation of a webpage. Think of a webpage as composed of chapter headings, subsections, and subsubsections.
11. All browsers provide a standard programmatic Javascript API for interacting with the DOM, though today most engineers manipulate the DOM through the cross-browser JQuery library or higher-level frameworks like Backbone.
12. New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files). Go back to step 3 and repeat for each resource.
13. CSS is parsed, and used to annotate each node in the DOM tree with style information on how it should render.
14. Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly. That is, Javascript controls behavior, and the Javascript executed on page load can be used to move nodes around or change appearance (by updating or
setting CSS styles).
15. The browser renders the page on the screen according to the DOM tree and the final style information for each node.
16. You see the webpage and can interact with it by clicking on buttons or submitting forms. Every link you click or form you submit sends another HTTP request to a server, and the process repeats!
Separation of concerns
-----------------------
Any web app will include HTML, CSS, and JS files in addition to server-side code.
One of the advantages of node.js is that the server-side code is also in JS.
You should separate your HTML, CSS, and JS, such that you can change any of the three (or more) files that specify a webpage without worrying about the other two. In practice, you will need to develop all files (.html, .css. and .js) at the
same time as significant changes to the structure of a page will often remove id attributes or CSS styles that your JS code depends upon.
When in doubt, err on the side of separation of concerns: use HTML for structure, CSS for appearance, and JS for behaviour.
Tools
-----
The single most important thing to learn are the Chrome Developer Tools. With these tools, you can do the following:
1. Edit the styles and DOM nodes live on a page.
2. Click an element on a page to find it in the markup, or vice versa.
3. Watch network connections and inspect HTTP requests and responses.
4. Execute Javascript to alter the page.
5. Mimic mobile browsers with the [User Agent Switcher](https://chrome.google.com/webstore/detail/user-agent-switcher-for-c/djflhoibgkdhkhhcedjiklpkjnoahfmg?hl=en-US).
Also familiarize yourself with [jsfiddle](http://jsfiddle.net/) (very useful for sharing examples) and reloading tools like [Live Reload](http://livereload.com/) ([alternatives](http://feedback.livereload.com/knowledgebase/articles/86189-i-don-t-like-livereload-can-you-recommend-somethi)) or [Codekit](http://incident57.com/codekit/).