Web Development

There are many different roles web development. The Front End is the stuff that you see and interact with: HTML, CSS, and JS. The Back End is everything else.

Using the analogy of a restaurant: The backend is everything that happens in the kitchen and the front end is what is plated and sent to your table. (Steele, The Web Developer Bootcamp, 2017)

This section covers the following topics:

Overview

Front-end developers work with languages and frameworks that render in the browser (or client) like HTML, CSS and JavaScript. Back-end development is where most of the action happens… the work that occurs on the server or behind the scenes and is not seen by the user. A full-stack developer is someone who works with all the different layers of web development. (Villalobos, 2016)

Web Pages are actually made up of several different file types and languages. HTML files are used to create the content for the web pages. CSS files are used to modify colors, font types, font sizes, etc. that change the way the content looks. (Codecademy.com, 2016) JavaScript is the language responsible for managing interaction within a browser (Villalobos, 2016), or rather controlling how the web page behaves (Williamson, 2016).

Web Development

HTML (HyperText markup Language)

  • Defines the structure or skeleton of a webpage
    • "put an image here"
    • "put a form here"
  • The "nouns" of a webpage

CSS (Cascading Style Sheets)

  • Defines the style of the HTML
    • "make all text purple"
    • "give the first image a yellow border"
  • The "adjectives" of a webpage
  • Note: You can have HTML without CSS, but CSS without HTML does nothing.

When doing web development, follow the DRY method (Don’t Repeat Yourself). This will help avoid wasted effort, poor application performance and sometimes unplanned downtime. (Veroneau, 2016)

Web Servers

Web browsers communicate with web servers using the HyperText Transport Protocol (HTTP). When you click a link on a web page, submit a form, or run a search, the browser sends an HTTP Request to the server.

This request includes:

  • A URL identifying the target server and resource (e.g. an HTML file, a specific data point on the server, a tool to run, etc.).

  • A method that defines the required action (for example to get a file, to save or update some data, etc.). The different methods/verbs and their associated actions are listed below:

    • GET: Get a specific resource (e.g. an HTML file containing information about a product, or a list of products).
    • POST: Create a new resource (e.g. add a new article to a wiki, add a new contact to a database).
    • HEAD: Get the metadata information about a specific resource without getting the body like GET would. You might for example use a HEAD request to find out the last time a resource was updated, and then only use the (more "expensive") GET request to download the resource if it has changed.
    • PUT: Update an existing resource (or create a new one if it doesn't exist).
    • DELETE: Delete the specified resource.
    • TRACE, OPTIONS, CONNECT, PATCH: These verbs are for less common/advanced tasks, so we won't cover them here.

  • Additional information can be encoded with the request (for example, HTML form data). Information can be encoded as:

    • URL parameters: GET requests encode data in the URL sent to the server by adding name/value pairs onto the end of it.
      • For example: http://mysite.com?name=Fred&age=11. You always have a question mark (?) separating the rest of the URL from the URL parameters, an equals sign (=) separating each name from its associated value, and an ampersand (&) separating each pair.
      • URL parameters are inherently "insecure" as they can be changed by users and then resubmitted. As a result, URL parameters/GET requests are not used for requests that update data on the server.
    • POST data: POST requests add new resources, the data for which is encoded within the request body.
    • Client-side cookies: Cookies contain session data about the client, including keys that the server can use to determine their logged in status and permissions/accesses to resources.

Web servers wait for client request messages, process them when they arrive, and reply to the web browser with an HTTP Response message. The response contains an HTTP Response status code indicating whether or not the request succeeded (e.g. "200 OK" for success, "404 Not Found" if the resource cannot be found, etc.). The body of a successful response to a GET request would contain the requested resource. (MDN-Servers, 2016)

Web Development

You can find a list of common HTTP Response status codes here.

Static Sites

A static site is one that returns the same hard coded content from the server whenever a particular resource is requested. Static sites are useful when you have a small number of pages and want to send the same content to every user. But they are not efficient when the number of pages becomes larger. (MDN-Servers, 2016)

Dynamic Sites

A dynamic site is one that can generate and return content based on the specific request URL and data (rather than always returning the same hard-coded file for a particular URL). (MDN-Servers, 2016)

Web Browsers

A Web browser is an application used to access the World Wide Web or Internet.

There are several major web browsers used all over the world. Some are tied to and come with a specific Operating System (Microsoft Windows defaults to Internet Explorer or Edge, depending on your Windows version; Apple defaults to Safari). Others are free to download from the Internet. The most common browsers are: Internet Explorer/Edge, Safari, Firefox and Google Chrome.

Important! From a developer point of view, it is important to know that there are differences in how each of these browsers handle layout instructions from a web site. This means that not all of your website users will experience the same look and feel as each other simply because of the browser they may use.

In order to accommodate the various browsers, there are some tricks that you can use to specify how elements will look when rendered by different engines.

One approach is to add a prefix to your CSS property so that the web page is rendered the same regardless of the engine. For example, the box-sizing property might be declared like this:

* { 
  -webkit-box-sizing: border-box;
    -moz-box-sizing: border-box;
      -ms-box-sizing: border-box;
          box-sizing: border-box; 
}

Another trick is to determine the browser type and create a special styling file for that particular browser.

  • For example, Microsoft’s browser, Internet Explorer, is often slow to adapt to new technologies on the Internet.
  • There is actually a free page (NetRenderer) available to view your page as it would appear in Internet Explorer. This gives you insight into what styles may or may not work in that browser.
  • Another useful tool is the website Can I Use?, which shows you which elements are available by browser.

Regardless, it is important to be aware that there are differences and understand that your site may render differently depending on what application is being used to view it.

. .
Back to top Forward to HTML ==>