Web Fundamentals

1. Introduction to the Web

Understanding how the web works

As a web designer, it's important to understand how the web works and the processes involved in hosting, serving, and rendering websites. By understanding the terminology and underlying technology, you'll create more efficient sites and have a concrete understanding of why you do the things that you do. Before we move on to specific topics, let's take a moment to examine how the web works as an overall process. If you could compare learning web design to building a house, consider this the foundation. One of the first things I want to clear up is the confusion between the terms the Internet and the web. Most people assume they're the same thing, but they're not.

The Internet is a term that's used to refer to a massive network of millions of computers all over the world that are used to share and transmit information. This is done through various protocols and languages and includes things like email, SMS messaging, application data, as well as the web itself. The World Wide Web, which is usually shortened to just the web, is way of transmitting data over the Internet using the HTTP protocol and HTML. We'll talk more about protocols and languages later. For now, let's just focus how data is shared over the web. The web can be summarised as a series of interactions between two types of systems, clients and servers.

Clients are the devices that request and render web content. Popular clients include browsers, mobile applications, screen readers, and the various content aggregators. We live in an increasingly connected world, and the number of clients that can access web content is growing rapidly. In fact, trying to keep up with all the new clients and how they access and render your content is one of the most challenging aspects of web design. Servers are applications that deliver web content or services to clients. There is a wide range of web servers and types that specialise in specific types of data or specific processing capabilities.

They're all involved in some way in delivering the content that you request or the services that you need performed. If you're interested in the programming aspect of web design or in hosting your own site, you're gonna need to become familiar with the different types of servers and how they work. If that's sounds like a little bit of an over simplification of how the web works, well, it kind of is. So in our next movie, we are gonna dig a little deeper into the interactions between clients and servers.

Working with clients and servers

Now that we understand the client server model that the web is based on, let's take a closer look at the process of requesting and receiving web content. Every time you click a link, or type a URL into your browser, a request for that content is made to a server. As with most processes, there's a little bit more going on behind the scenes. When your browser makes a request, it uses a URL or uniform resource locator to locate the requested content. This request is usually passed on to a domain name server or DNS. The DNS then translates the URL into an IP address. The browser then uses this IP address to locate the host's server and send a request for the content. Based on the type of files requested, several things take place next. If the request is a simple HTML page, the HTML text is sent to the browser where it's rendered and presented to the user. If the page contains additional requests, such as CSS or images, those requests are presented to the server, the resources are downloaded, and the resulting content is rendered as well. Any client side scripts such as JavaScript, triggered by the document loading, are also executed at this point. That's how the process works for what we call static sites. Static sites require no additional processing, just the content requested by the client. For dynamic sites, which are sites that require further processing or business logic to execute before they can present content, there's one more step. Dynamic site pages must first be processed by a web application, such as PHP, .NET, or Ruby before that content is server to a browser. For example, if you are registering for a site, calculating a mortgage payment, or requesting to see which open dates a hotel has, a server is going to need to process those requests first.

structure of an URL

In those cases, the web server processes the page and then the appropriate data is returned to the browser to be rendered. As before, request such as style sheets, images, and client side scripts are then executed. This is a broad, fairly big picture view of how the client server model works. What amazes me is that all of those steps happen so quickly when a request is made. That's why it's so important for designers and developers to understand each stage of how content is served on the web. If a stage isn't carefully executed your site could either function slower than it should, or not at all.

The DNS and why it matters

DNS is one of the most important processes on the web and it's also one of the most overlooked. Domain name servers, or DNS, address one of the fundamental differences between humans and computers. When a web server hosts a website the site is assigned a unique IP address that's used to identify its location. The IP address for lynda.com for example is 69.20.127.243. While computers find working with these long strings of numbers very, very simple, humans struggle to remember them. Imagine trying to remember The IP addresses of every single website you frequent. So, in order to make the web a little bit more usable for us humans, every website is also assigned a unique domain name that's been associated with the site's IP, and that is where the DNS comes in. Others have described it as the phone book of the Internet and I really can't think of a better example than that. When you type www.lynda.com into your browser, the domain name is sent to a name server which looks up the address and then returns the proper IP to your browser which is then used to find the website.

DNS

All of this happens amazingly quickly. To understand this process a little bit better, let's take a look at the flow of the DNS process in more detail. The DNS system is an incredibly complex and fluid database that's distributed across servers all over the world. When you register a newly hosted website it's assigned an IP address and then registered with the DNS. Your hosting company usually handles this step, associating the domain name with the IP behind the scenes. Your website is now registered and ready to accept requests. What happens when a request is made. Let's say you type www.lynda.com into your browser.

Well first, the browser checks with your local ISP's, or ISP's, default DNS to see if the name server has ever heard of that site. If so, you'll receive the IP, and just keep going. But remember, the DNS system is a huge database spread all over the world. So, what happens if you make a request that your local DNS doesn't recognise? This is where it gets a little bit more complicated. There are a group of servers called root name servers. These name servers in turn, know all the name servers for what we call top level domains. So, in the case of lynda.com, the route name servers would give the location of the .com name server. The browser will then query the .com DNS and receive the proper IP address. Now if the address is still not found, in this case, you'd get the dreaded DNS error message telling you that your site can't be found at that location and you'll need to try again. DNS caching helps to speed up the retrieval process even further. If you visited the site within about 24 hours, your default DNS will cache the name for you, and that makes the retrieval really fast. Now, that we know a little bit more about DNS, why does it matter to us designers? Doesn't all this stuff happen behind the scenes? Well actually it matters greatly. If the DNS is not assigned properly when you register your site, no one is gonna be able to find you. So it's really important to monitor this process when registering multiple domain names for one site.

For example, www.lyndatraining.com also takes you to lynda.com. You need to make sure that the domain names are registered to the correct IP. Most importantly, you need to make sure that ownership of the site is properly registered. Most clients are going to want you to handle the registering the site and getting the host set up. If you register in your name, you own that site. Getting the site transferred from one hosting company to another and thereby changing the DNS listing would be impossible without your assistance. Hosting companies will not make changes without the owner's consent. If you're registering a site for a client, make sure that relationship is clearly understood and the proper owner listed for the site.

One more thing, most name servers don't refresh their cache for about 24 hours. That means that if you migrate your site from one host to another, any servers that cached your old location won't point to the new site for about a day or so. That's why migrating sites over the weekend makes the most sense. You'll have fewer visitors wondering where everything went.

Internet Protocols

The internet relies on millions of computers all over the world communicating with each other. These computers might run different hardware, different operating systems, and different software. But, it's critical that they're all able to communicate with each other. If not, the internet wouldn't work. This should give you some idea as to how important internet protocols are. Protocols are simple languages that let one computer share data with another, regardless of software or operating system. The internet uses a loose framework of protocols often referred to as the Internet Protocol Suite. This suite contains multiple types of protocols. That are designed for specific tasks such as networking rules and data transfer. You've also probably heard this protocol suite referred to as TCP/IP, which is short for transmission control protocol and the internet protocol. First formalised in 1973, this series of protocols have evolved to become the backbone of the Internet, and is the main way that data is sent and received. Unless you plan on doing some heavy duty network programming, you won't need to know much about the protocols that make up this suite. It is helpful to know that instead of one generic protocol, the Internet uses multiple layers of protocols that handle different tasks. There's the Application layer which handles the creation and sharing of data over the web. This layer is probably the most interesting one to designers since it has protocols like HTTP, FTP, and SMTP that you'll be interacting with on a regular basis.

There's also the Link layer that defines how routers connect with each other over a network. The Transport layer, which controls how ports are assigned, and communicate with each other. And the Internet layer, which defines the addressing and routing structure for data across the network. Now the important thing to take away from this, is that the internet wouldn't work at all without these protocols. They allow any computer in the world to network with other computers. No matter the distance or the type of computer being used. For most protocols you won't need to know specifics unless you're writing an application that streams video or building a chat client from scratch. It does help however to have a basic understanding of the protocols that send and receive your web content. So, we're gonna take a look at HTTP and other widely used web protocols next.

Exploring HTTP

Have you ever wondered what the HTTP portion of your URL is referring to? HTTP stands for hypertext transfer protocol. And it's the standard protocol for transferring resources on the web. Now, remember a protocol is simply a standardised format for transmitting data between two devices. In this case, your browser is an HTTP client while the web server that hosts the requested site is an HTTP server. Now the browser sends an HTTP request explaining which resources that it requires.

And that in turn, prompts the server to send an HTTP response which, in most cases, includes the resources that were requested. There are other web protocols commonly used to transfer data and most differ based on the type of data requested, which data compression to use, if any, and how the client and server communicate to each other that information has been requested and received. Other common protocols that you may encounter include FTP, SMTP, and RTP. FTP stands for File Transfer Protocol and is the most widely used protocol for sending and receiving files over the web. HTTP is what we call a one-way stateless protocol, and I'll tell you a little bit more about the stateless nature of HTTP in just a moment. But this one way nature make sending and receiving large files over HTTP very difficult. By comparison, FTP connects to a file server instead of a web server. And it's ideal for transmitting larger files. Because of this, designers regularly use FTP connections when uploading and downloading files from their site. SMTP stands for Simple Mail Transfer Protocol. It is the Internet standard protocol for email transactions across the Web. In most email clients, SMTP is used to send email while POP, or Post Office Protocol, is used for receiving mail. RTP, or Real-Time Transfer Protocol, is a standard protocol for delivering audio or video over the Internet. It's most commonly used in voice over IP and chat applications. That's just a few of the protocols that you may encounter while creating and administrating your sites, and should give you an idea of how protocols work and why so many different protocols are needed. Before you move on, I wanna turn your attention back to HTTP for just a moment. As I mentioned before, HTTP is what we call a stateless protocol. That means that once a request has been sent and received it's discarded and forgotten by both the browser and the web server. This makes HTTP a simple and efficient protocol, and it's the reason it's so successful for the web.

Imagine if Web servers had to remember the billions of requests sent and received, every single day. The web would grind to a halt very, very quickly. However, this stateless nature is not without it's downside. Nothing about the request is remembered. So tasks such as storing persistent data like logins and browsing sessions or a passing product information through a shopping cart must be performed by means other than the request itself. This is usually done through several different methods, such as using cookies, which are small text files that the page writes on the client machine. Scripting languages, such as JavaScript. Variables which are stored on the server, or server based session management.

If you're interested in having data persist throughout a user's browsing session, you'll need to have to account for HTTP's lack of memory. You might also see HTTPS which is a variation of HTTP. This stands for Hypertext Transfer Protocol Secure and it is simply a layering of a security protocol along with HTTP. This allows you to send secure requests from client to server and is widely used any time security is needed, such as an e-commerce site.

As a designer, it is important to understand when you need to use HTTPS over HTTP.

Anatomy of a URL

Web design is filled with elements that just seem to fade into the background. We use them over and over to build sites, but never really give them a whole lot of thought. URLs certainly fit into that category and if there's any one part of web design that is sadly overlooked, it's learning exactly what a URL is. URL is short for Uniform Resource Locator. Although we tend to think of them as a single entity that's used for links or web addresses, they're actually made up of several parts. And the syntax used within them helps servers determine what type of file you're looking for, where to find that file, and can also pass along several optional parameters to the server. Let's start by examining a common URL and identifying the different parts of it. So, here I am into my browser and if I type in http://www.lynda.com into my browser, it navigates me to the home page of lynda.com.

Just as you'd expect. But let's take a closer look at this. The first part of the link, the HTTP: is known as the protocol. In this case it tells the browser to use HTTP as its protocol. There are many different protocols and you'll need to make sure that your URLs are using the right protocol based on the file type you're requesting. The second part of the link. The //www.lynda.com is know as the resource name and it also is made up of several parts. Now the two forward slashes are for correct syntax only. The resource name is identified by a series of domains separated by periods between them. Now, in this example, the www is the subdomain, lynda is the domain name. This is the name that the browser uses to check with the web server to see if the site exists or not. Now, it's here that the domain name servers that we talked about earlier come into play. And com, is the top level domain.

This is the name server that your browser will use to resolve the location of the site that you're requesting. Common top level domains are com, org, and edu although, that is, by no means all of them. And in many cases, the subdomain is no longer required. Which is why you could also type in just lynda.com without the www and still arrive at the same page. Most Web servers are now instructed to redirect to the default subdomain if none is provided, giving us the freedom of not really having to type out the entire www syntax. However, this is not always a given, so when creating your URLs, you should know whether this is allowed or not. So, what is a subdomain anyway? Well, in the simplest sense, it's just a folder that your web content is located in on your web server. Most web servers serve multiple types of content and subdomains allow servers to identify unique sites or unique areas of content. Www has evolved as the default subdomain for most web content. When you upload your site to your server, as you publish it, chances are you're looking for the www directory. There are many subdomains besides www, such as FTP or video. In fact, the server administrator can create as many subdomains as they wish. This could in theory be almost anything. Let's turn our attention back to our link. Now it seems like we've examined every part of our example, URL. But in fact there are a couple of parts that we've left off. A URL should also specify the path on the server to the requested file and which port on the server you should connect to. Now in this case, both of those requests are left off, which means that both will get the default values for that server. It's rare to see a port definition within the URL and most servers default to 80. So, unless you're instructed otherwise, it's almost always safe to leave the port number off. The port is appended to the end of the top level domain, and proceeded by a colon. So, for example, we could come up to our URL, and to the lynda.com we could add a :80, hit Return and yep, it navigates us to exactly the same page. Now every site has a default page, often referred to as the home page of the site. And here we're looking at lynda.com's home page. Now this is typically a page named either index.htm or default.htm, but in reality the server can set any page it wishes to as the default page. Of course, if we need to, we can tell the browser exactly which page to browse to. Now let's say that we wanted to read the frequently asked questions for the lynda.com site. If I change my URL, so I'm just gonna go right up here to my location bar. If I type in a forward slash, and then I add support/faq.aspx. ASPX is a type of page the same way HTML pages are a type of page. So if I hit Return, it takes me right to the Frequently asked questions. So, if we break apart what I've added to the URL. The forward slash support tells the server to find the support directory. And then locate inside of that a file named faq.aspx. We can also use the URL to pass parameters to the server, which refine the information that's then retrieved by that server. Let's say we perform a search on lynda.com. So I'll come right over here to the search field and let's just say I type in web design and do a search.

So we get our results for web design but what I really want to draw your attention to is up here in the URL. Note that a few extra items have been added to our URL. So we have the question mark that comes after the path, so it just forward slash search is going into the search directory. So that question mark is a separator between the URL itself and then the parameters that are being passed into this. The parameters are what we call name, value, pairs. In this case of the search, the q represents the query being made and then the web+design indicates the actual value or the query itself. So, for example, if I changed web design up here in the URL to web development and hit Return, you can see that the search results update without me actually having to do a brand new search.

Now, of course, making the user type in this type of URL or even expecting them to know which parameters they're going to use, or they need to use, is not really a great idea. That's why in most cases, additional parameters are passed on due to things like form submittal, the user clicking a specific link or some other automated mean. So the humble URL isn't something that we pay a lot of attention to, but without it the web just wouldn't function at all. As a web designer, make sure that you understand, how URLs work. And, how to properly format them, so that your site works as expected.

How browsers work

Most people use web browsers like they use their cars. They have little to no idea what's going on under the hood. They just turn the key and drive it. To the casual web user, there's really nothing wrong with that. For web designers and developers, however, knowing what's going on inside the browser is very important. Key in fact to making sure that your websites look and perform the way that you design them to. It doesn't help that there are so many browsers. And that each of them perform tasks a little bit differently from the rest. We're gonna start by taking a look at the basics of how browsers work, examining their various components, and then discussing why differences exist between them. The basics of how a browser work are pretty much the same regardless of the browser itself. Browsers use HTTP or hypertext transfer protocol to communicate with web servers and request pages and content.

When a user clicks a link or types in a web address, the browser sends a request document to the server. The server in turn then sends the requested page and assets back to the browser. Once the requested page, usually an HTML document, is fed to the browser, the browser then uses its internal rendering engine to translate the page and then render it on the screen. Any additional content, such as images or video is requested and rendered based on whether the browser supports the file type or whether the plugins necessary to view the content are installed. Any client side scripting, typically JavaScript, is then executed in the browser when it's triggered. Although each is different, browsers are usually made up of the same basic components.

There's the browser UI which contains the visual chrome, the address bar and all those other interface components. A browser's internal engine handles communications, cross components and helps manage the entire process. A rendering engine is used to parse HTML and CSS, and it controls the visual rendering of pages. Browsers also have built in networking components that are used to communicate through HTTP and other common protocols. The data storage component is used for session management and storing data. Now usually this involves writing cookies to client machines but the advent of HTML5 gives browsers multiple methods for storing data on the client. The JavaScript interpreter is another engine and it's responsible for executing any JavaScript code. Understanding that each browser has its own unique set of components, like the Rendering Engine and JavaScript Interpreter, really help explain why different browsers behave so differently. As a designer, it's really important to understand these differences. And what you need to do to ensure that your site behaves acceptably in each browser.

By far, the greatest noticeable difference between browsers is driven by how their rendering engines work. These differences often result in pages that either look subtly different from one browser to the next to layouts that look nothing like each other. Depending upon the browser that's being used. Now the five most common rendering engines are Trident, Gecko, Presto, WebKit and a new one, Blink. Microsoft developed the Trident engine and it's used in a multitude of browsers and web clients. Internet Explorer, Windows Mobile, and most AOL browsers. And yes, there are still AOL browsers.

Most of those guys use Trident. Gecko is an open source rendering engine, originally developed way back in the day by Netscape. But it was released to the open source Mozilla project, which has continued its development. Presto is another proprietary engine, developed by Opera software for their browsers and licensed to other devices. Opera has since shelved Presto and moved on to Blink, which we'll talk about in just a moment. But Presto is still currently very widely used. WebKit is another open source rendering engine, and it was developed by Apple, Google, Nokia and a lot of other folks. It powers browsers such as Apple's Safari browser and a lot of mobile browsers. Now, Blink is a rendering engine that's based on WebKit, but it's being developed separately by Google.

And it's used in the Chrome browser as well as Opera now. It's worth noting that these rendering engines are still being developed. And older versions of the browsers will have older versions of those rendering engines. This is why web designers should test their pages. Not just in multiple browser, but muliple versions of the same browsers as well.

28 years of web browser market disruption

Web Standards and the W3C

One of the most important developments in the evolution of the Web is the development of web standards. To understand why web standards are so important, we first need to consider browsers again for just a moment. Although many differences still exist between how browsers handle events, and render page elements, and layout, and things like that, there really aren't as many differences now, as there have been in the past. So let's go back to the mid to late 90s. There we have two browsers. Netscape and Internet Explorer, both of them were battling each other for market dominance. Now, some refer to this period as the browser wars. In order to build better browsers with cooler capabilities, each one would release proprietary features that were not supported by any other browser.

This meant that with every single new release, web designers would have to learn new ways of developing websites to take advantage of those features. This would often lead to designers needing to develop multiple versions of pages for different browsers. So it was inevitable that as the browser market became more crowded, designers and developers would really just face an impossible task when trying to create pages that looked good everywhere. So it was this environment that led to the creation of the Web Standards Project in 1998 by a group of designers and developers frustrated with the current state of browser development. They began supporting, in an organised way, the adoption of the World Wide Web Consortium recommendations. The World Wide Web Consortium, or it's a little easier to say, the W3C. Began in 1994, an attempted to standardise web protocols in technologies, by issuing a series of recommendations for everyone to follow. Now obviously at this point, no one was listening. So the Web Standards Project started referring to the recommendations as standards in an attempt to convince browser manufacturers to follow them. They began an education initiative to make sure that designers and developers were aware of these standards and would push for them. They also educated the general public by encouraging the use of browsers that supported these standards. In the end, the outcry from the design and development community, along with the rise of open source browsers such as Firefox, helped other manufacturers realise the advantages of supporting web standards. In fact, they did such a good job that in 2013, they announced that their work is now done. I'm not quite sure I agree with that, but I encourage you to learn more about the Web Standards Project by visiting www.webstandards.org. So, what makes understanding web standards so important to designers? Well, if most modern browsers support web standards, and to a degree they all do, that means that by learning those standards and then staying current with their development, you'll ensure that your sites will have a consistent design and user experience across multiple browsers and devices. You can simply design with those standards in mind and make minor tweaks when needed based on browser deficiencies. It's important to note that web standards are a moving target. New recommendations are being published often, in an effort to drive the web forward. The adoption of new standards can be slow, and in most browsers, it's a gradual process. So, it's important to track which standards are supported, which are partially supported, and which lack support based on specific browser versions.

To do that, you'll need to become more familiar with the W3C. On their site, which you can find at w3.org, you can find various specifications for languages like HTML and CSS, that you can use to make sure your code is written to currently accepted web standards.

Web Server basics

Websites are hosted on web servers. And while most designers know this, they don't tend to spend a lot of time learning the ins and outs of how they work. That's okay. But there are some basic server concepts that you need to understand in order to serve your pages correctly. A web server is nothing really more than a computer with a specialised set of software and components. The computer that you're watching this video on could be a web server if you installed a few pieces of software or enabled certain components. All web servers are assigned an IP address, and the sites that they host are registered through a domain name server so that requests for its pages can be found. Many web servers use virtual hosting which allows them to serve multiple web sites under a single IP address. When you sign up for a hosting service, many will advertise plans that will give you the option of shared hosting versus dedicated hosting.

In a shared hosting environment, your site is hosted on a web server with multiple sites, while on a dedicated plan, your site has its own server or servers. Dedicated plans usually cost a little more. Sites are stored on web servers as a series of files and folders. Which are then retrieved based on the HTTP request that it receives. Of course it can get a little bit more complicated than that. For dynamic sites the web server will have to process data from databases and execute any server side scripts that are contained on the site. Because of this, it's also important to understand the web stack that your server might contain. A web stack is just that. It's a stack of software that all works together to serve and process web pages. Each server has its own distinct stack, and it's important to find a hosting company that uses the stack that you need.

A common web stack will contain an operating system, a web server, a database server, and a programming language. Take the popular LAMP stack. LAMP stands for Linux, Apache, MySQL, and PHP, although to some people it stands for Perl or Python. Now for servers that use LAMP, Linux is the operating system, Apache is the web server, MySQL is the database server and PHP is the programming language. LAMP is by far the most commonly used web stack on web servers. It's popularity is largely due to the fact that each of its components are open source. Which made them easy to build and cheap to run. Other common stacks are WAMP, which stands for Windows, Apache, mySQL, and PHP.

WISA which is Windows, IIS, MY SQL Server and .NET and MARS which stands for mySQL, Apache, Ruby and Solaris. Although this by no means a complete list. So why does it matter what's stack a web server uses? Well, you need to host your site on a web server that can process your pages. If you create a dynamic site using Cold Fusion, hosting that site on a web server that doesn't have a Cold Fusion server as part of its stack, won't work. You need to make sure that whatever hosting service you choose has a stack that works with the scripting and database choices you've made for your site.

2. Front-End Technology

Front-end design

Many web designers refer to themselves as front end designers. If you've ever heard that term, you've probably also heard the expression back end, client side, or server side within the same discussion. In this chapter, we're gonna be exploring front end technology. So it would probably help for us to define what front end refers to, and what front end design is in general. Well, in the simplest terms, front end could refer to the UI layer of websites, you know, the things that people see and interact with. Back end usually describes the processes that happen on the server that help make things work. Client side and server side generally refer to the same things and are often used interchangeably with front and back end.

Front-End Development

The most common languages for creating front end content are HTML, CSS, and JavaScript. Most of the designers that call themselves front end designers, are proficient in some mixture of these languages, if not all of them. In the past, front end design, has referred to the design of any content that doesn't rely on server side processing. Recently however, a lot more development is being done within the browser itself. Many of the tasks that in the past would have required a server are now being done within the browser, by using powerful JavaScript libraries. This has led some to use the term front end developer to denote developers that prefer to process information within the browser. You know, in many cases, these terms tend to overlap, so don't be surprised to see somebody refer to themselves as a front end designer or a front end developer and really mean exactly the same thing.

As a general rule, front end designers are more visual designers than they are programmers. While languages like HTML and CSS are required to create their designs, most don't really consider themselves developers in the purest sense of the word. Here's a general list of some elements of web design that front end designers are responsible for. Creating mockups and establishing visual standards. Structuring content semantically. Ensuring the site's accessibility. Controlling typography, page layout, form design, interactivity, animation, and creating images and icon assets. Now, obviously, that is not a complete list, and some designers will specialise in specific areas of front end design, while others might have a blended skill set that allows them to work on broader tasks. The truth is, there's no one thing that accurately describes all front end designers, but most will work across multiple disciplines and tackle several areas of design. However, while it's not unheard of to have people that do both front end and back end development, most front end designers aren't full-fledged developers as well. In the end, if you're a front end designer, you'll probably focus on the areas of front end design that appeals to you the most. Just be sure to explore all of the various areas of front end design so that you have a broader understanding of how all the various technologies fit together.

Data Storytelling

HTML, the language of the web

HTML stands for a Hypertext Markup Language, and it's the standard markup language for web pages. I've also found it to be the number one source of apprehension for new web designers, specifically designers who have backgrounds in visual design or are used to working with print. I can't tell you how many of my students have asked me if there's a way to design web pages without having to learn HTML. I mean, I can sympathize. Looking at HTML code like this page for the first time can seem kind of daunting to any new designer. However, I would like to stress that HTML itself is actually very simple. It's also what I consider an essential skill for any and all web designers. If you take every other technology away, you're left with HTML. It's the foundation of the web and the language that every web page is coded in, so yeah. It's pretty important.

Before we talk about the basic structure of HTML documents, let's first take a look at a little bit of history. The HTML 2.0 specification was released in 1995, an it marked the first release of the language as a quote, unquote, standard. Now the first releases of HTML were fairly basic, and lacked many of the structural elements that we have today. During the 3.0 release, browsers begin to implement their own proprietary tags that were not part of the official HTML specifications. This created a lot of problem for web designers and developers in trying to create consistent sites. And it really threatened the stability of HTML standards. Now, thankfully the HTML 4.0 release stabilised the language and was released in an environment that was increasingly more supportive of web standards.

Modern browsers were quick to adopt HTML 4.0 and it really became the recognised standard for years. In many ways it kinda still is, to be honest with you. Now in 2000 the W3C released what's known as the XHTML 1.0 specification. Now they were hoping that it would replace the HTML 4.0 spec as the standard. XHTML was really meant to move the language to a more structured XML based approach, although a lot of designers embraced this for its stricter rules and its move towards more of a purer structural mark up. It really wasn't a dramatic departure from HTML 4.0, to be honest. Now to keep up with the changing nature of the web, the work on XHTML 2.0 began with a focus on really become a semantic, and if you wanna think of that a different way, think really structural language only, so just structure. Now because XHTML 2.0 broke with the previous practice of being backwards compatible, implementers, really just largely ignored it. And, after years of work the W3C finally ended the working groups charter in 2009. Effectively, eliminating XHTML 2.0 before any browser really supported it. During this time, a group of developers and designers, who were unhappy with the direction that XHTML 2.0 was going, they all got together and they formed a very awkwardly named group called the Web Hypertext Application Technology Working Group, or WHATWG is what some people call it for short. To continue the development of HTML, their efforts were eventually recognised by the W3C, which adopted the work under the name HTML5. HTML5 retains the backwards compatibility of previous versions of HTML, while adding new structural tags and support for APIs, that allow elements to be edited, dragged and dropped, and facilitate communication from within the HTML document without needing outside scripting. Adoption of HTML5 has been very fast, and it's safe now to consider that as the new standard for HTML.

Structuring HTML

One of the reasons that HTML is so popular is that it's so incredibly easy to learn. Let's say we have this sentence that you see here, welcome to Roux Academy. Now if we just typed this in a text file an saved it as an HTML document, which I have done here, if I go over to a browser and try to display that, it renders it just fine. However, the sentence itself, actually right now, has no meaning. HTML is a markup language, which means that it uses tags to structure documents and to give elements meaning.

So if I change this, let's say I go back in here and I grab that. And let's say I wrap this in an H1 tag. So if I save that, go back to the browser, and refresh that you can see, that it changes the way that it renders it. Well that's because the H1 element tells the browser that this is a level 1 heading. HTML has a lot of tags. And they're used to identify the elements of a document and help provide structure. Learning HTML is basically learning the syntax of the language, which elements are supported, and the basic structure of HTML documents. All of this is incredibly easy to learn, and the tag set is small enough to learn within about a day or two. To show you what I mean, let's take a quick look at the structure of a basic HTML page. Now at the very, very top of it you are going to find what's known as a document type declaration, or DTD, and in this case, it just says doc type HTML, which stands for HTML five. The doc tag declaration occurs before anything else in the HTML document.

And essentially it just tells the browser, or whatever client is going to be rendering this page, which version of HTML that it's using. And that way it knows which syntax rules to use when parsing the document. Now let's get back into the actual structure of the HTML document itself. And I'm gonna use an analogy here that I've heard used before to describe the structure of an HTML document, and that is to compare it to a sandwich. To have a sandwich you need to have two slices of bread; without those you don't have a sandwich, you have a salad. So, to have an HTML document, you need to have an opening and a closing HTML tags and you can see those tags here. Now, those tags - like the bread of a sandwich - surround everything else. Now immediately after the opening HTML tag, you're gonna find the head of the document, which you can see here. Now this is identified by an opening and closing head tag.

The head of an HTML file is a lot like the condiments, the lettuce, or tomato, things like that that you might put on a sandwich towards the top of it. They help make the sandwich better but they really aren't all necessary. Well, the head of an HTML file contains all of the non visual elements that help make the page work. Here you'll find elements such at meta tags that might contain keywords or page descriptions to help identify the document's content, links to external resources like the link to the CSS file that you see here. External script libraries that can control the page's presentation, layout, and functionality, and it could also include internal CSS or script content if the designer wishes to embed those elements within the page. Things inside the head tag are not necessarily visual or structural elements, they just help make the page look and function the way you want it to. After the head tag you're gonna find the body tag. Now the body tag is like the meat of the sandwich. Here's the ham, the roast beef, the cheese, whatever else you like in your sandwich there. Now all the visual structural elements are contained within the body tag. Headings, paragraphs, lists, quotes, images, links, those are just a few of the visual elements that can be contained within the body tag. Simply put, if it's a visual element, it needs to appear in the body tag in the order that you want them to appear.

Yes, there are other syntactical rules that you must learn. You may have noticed for example that if one tag is opened inside of another tag, that tag must close before its parent tag can close. Other rules govern things such as which tags can be contained inside of other tags, or which attributes are allowed to modify or extend the meaning of certain tags, things like that. Overall however, the structure that I've presented here, is exactly the same in every HTML document. So if you learn the basic structure, you're well on your way to writing clean, valid HTML.

Controlling presentation through

CSS, or Cascading Style Sheets, is a style sheet language developed to control the presentation of HTML documents. Over the years HTML has evolved into a semantic language. Meaning that the language focuses on identifying elements and defining document structure, not on how those elements should be presented or formatted. For that we have CSS. As the name implies, cascading style sheets are a collection of formatting rules usually contained in an external file. They can control a range of pages from a single page to entire web sites. The term cascade refers to how the styles are applied to pages. Styles may be contained in external files. Embedded within the head of HTML documents or applied as an inline attribute of page elements. Based on where the styles are found, the styles are allowed to overwrite one another when conflicts arise. This creates a cascading order to your styles that allows you to control entire sites through a single CSS file. And exercise a granular level of control, by applying a smaller set of styles within individual documents. Before we go more into the specifics of CSS syntax, I want to show you an example of how it works. So here I have an HTML page open, and if I scroll through the page, it's just HTML, so this is just document structure. Now, if I were to open this unstyled document up inside of a browser, this is what it would look like. So, you can see all the information is there, but it's not really that attractive. But still, it's doing what HTML is supposed to do. It's structuring the document and identifying elements and establishing a order for all of the information in the file. So, it's doing its job. Now, if I go back into our code, you can see right here there's a line that links out to a CSS file. So one of the ways that you can deploy CSS is to link to an external CSS file, that file will then be used to render this page. One of the benefits of this is that you can use one file for your whole site, so it's a much more efficient way of writing your styles. Now if I go into that CSS file, you can see that the code looks a little different from HTML. Really what we've got here is just a collection of different types of rules, and all of those rules identify the element on a page that they wanna style. And then pass along some properties and values for those styles. Now we'll get more into that syntax in just moment, but if I flip back over to the browser, and refresh this page with the CSS turned on, there we go. That looks better. So as you can see, CSS allows you to have an incredible amount of control over documents presentation. Learning CSS is actually fairly simple. Take this simple rule for example. CSS styles are made up of two parts, the selector and the declaration. The selector, which is here p for paragraph, tells the browser which element or elements to style. Based on this selector, the style would change the formatting for all paragraphs, site-wide. The declaration, enclosed in these curly braces, gives the formatting instructions. Now here, there are three rules. One telling the browser which font to use, what size to render the font, and what colour to make all of the paragraph text. All of the rules are made up of two parts, the property and the value. Now, these are separated by colons and use the semicolon to tell the browser to move on to the next rule. While the syntax is simple, you will need to learn how to write more specific selectors to exercise a greater amount over your page elements and you'll need to learn the various properties and values that you set for each element. One of the major benefits that CSS brings to web design is to enable highly modular design. By controlling the structure of the document through HTML and the presentation through CSS, you can change one independently of another. You also speed development and site maintenance by controlling the formatting for an entire site through a small number of CSS files. For example, if we go back to our Roux Academy page, it really doesn't look like they're any styles going on here at all. But, of course, if we look in the head of the document, we can see again this link to the external style sheet.

Now, as the browser parses this page, a request is sent out to the server for the stylesheet, and then the browser is gonna use those styles for page layout and the site's visual design. Another benefit of this separation of style and structure is the added portability it brings to your content. You can change stylesheets, write CSS that changes the layout and styles based on things like screen width and orientation, and write separate styles for how the content looks when printed. Much like HTML, I consider CSS an essential skill for any web designer.

Client-side scripting with Javascript

When students asked me, what are the most important technologies for web designers to focus on learning. I always reply with HTML, CSS and JavaScript. Of those three, JavaScript is almost always the one they learn last. Many new designers are hesitant to learn any type of scripting, but modern web design depends on it so much that not learning it, at least at a basic level, will severely limit your ability to build functional sites. JavaScript is a scripting language used in web design to add interactivity and application functionality to sites. It was created in 1995 by Netscape to increase the capabilities of its popular browser. Contrary to popular belief, JavaScript has absolutely nothing to do with the programming language Java. Netscape actually licensed the term Java from Sun to speed up the acceptance of their new scripting language. Based on the ubiquity of JavaScript on the web, I'd say it worked. JavaScript can perform a number of tasks for your sites, including allowing you to create interactive elements, dynamic menus, open new browser windows, and update data directly in the browser. HTML is static, so making your content respond to user interaction, animate, or change based on other factors is usually the task of JavaScript or some type of server side scripting. JavaScript has the advantage of being performed in the browser, or the client side, if you will, meaning that page content does not have to be refreshed in order for the changes to occur. Let's take a quick look at JavaScript in action. Here I have a very simple page opened up, and this is perhaps the most simple of all scripting examples out there, hello world. Everybody does it so I went in and did one as well. So essentially all we have here is a really basic HTML page with an h1 element and a paragraph. And then right below the paragraph, right before the closing body tag, you can see that we have a script tag. Now this script tag is not JavaScript. This is HTML. And this tells the browser that, hey, inside these script tags, there is a script that needs to be run.

Now we could further identify it as being a JavaScript script but we don't really need to do that any more. And then, we have the alert window, which is just a basic JavaScript command saying, hey I want the alert window to come up. And this is what I want it to say. Hello world. Now if I view that in a browser, you'll see that as soon as the script runs, it goes ahead and displays the JavaScript alert window, and it says, hello world. Clicking OK will dismiss it, but that's JavaScript in action. Now, that was really, really simple. Let's take a look at a more complex example. Now, even though this example is a little bit more complex, the concept is still the same. If I scroll down into my HTML, you can see right before the closing body tag, I have a script tag. And in this case, inside the script tag there's a lot of JavaScript going on.

Now, I'm not gonna go over every line of JavaScript and tell you what's happening here, and actually this is responsible for multiple types of functionality on this page. But essentially the one I wanna really point your attention to is right here, where we're creating a photo gallery. So if I preview this page in the browser and kinda scroll down a little bit, we have a photo gallery down here that, when I click on that, opens up a modal window, and has my photos in it. And all the navigation and all of the behaviour of launching this in a separate window and then closing the window, all of that is being controlled by this JavaScript. Now, one of the more helpful developments in adding scripting functionality to sites has been the development of multiple JavaScript frameworks. Now these frameworks are JavaScript libraries that have prewritten functions and objects already built into them. For example, here you can see that I'm loading up several of these libraries. I'm loading up JQuery, I'm loading up one called class, and I'm loading up another one called photoswipe. Desolve.js isn't a library, it's just external scripts that I'm calling on for this particular file. Now these types of frameworks make creating interactive applications, widgets, and implementing advanced Javascript functionality a lot easier for designers. We're gonna take a closer look at Javascript libraries a little later on in this course. My suggestion is to learn the basics of Javascript. Experiment with what it can do for your site and then look into using Frameworks to deliver a more robust experience. While JavaScript is widely supported among browsers, it is important to note that each browser has its own JavaScript interpreter and that certain user agents may not have JavaScript enabled. As such, it's important to have a strategy for either providing alternative content or giving access to content when Javascript support is either absent or disabled.

Common image types

The web will never be lacking for acronyms, and sometimes it's really difficult to keep track of all of them and what they refer to. That is certainly true when we talk about image formats. As you learn webdesign, you are gonna encounter terms like JPEG, GIF, PNG and SVG. Often without really any reference to what they are, or what they stand for. Well those four acronyms refer to the four most commonly used web graphic formats. An in this movie, I'm gonna be exploring those formats in a little bit more detail. Understanding how those formats work, will make deciding when to use one type of graphic over another, much easier. Now, before we dive into discussing the individual formats, I want to take just a moment to discuss web graphics in general. Designing images for the web requires you to understand how images work within browsers and the unique considerations required for web graphics. You're gonna find yourself always trying to strike a balance between file size and image quality. Bandwidth considerations are a serious concern for websites, so keeping images as small as possible while maintaining quality is an important skill to have. And it's even more important in today's multi-device world where we have low bandwidth connections combined with, high resolution displays.

Now, for a browser to display your image, the image must be in a format that the browser supports. Now almost all browsers support JPEGs, GIFs, PNGs, and SVGs, so, they've have become accepted standards for online graphics. As we move into discussing the individual formats, I want to start with JPEG. JPEG stands for Joint Photographic Experts Group. This standard was established around 1992 and has become widely used in many areas including the web, and digital photography. The JPEG format supports millions of colours, making it ideal for photographs or images with subtle colour transitions. However, to keep file size down, JPEGs are compressed with what we call lossy compression. Now this means the image data is thrown away, as they're saved. Depending upon the level of compression that you choose, JPEG chooses areas of colour that are similar. One area is tagged and the remaining areas are discarded. As the JPEG image is decompressed by the browser, the tagged area is plugged in to those discarded areas. At a high level of compression, this matching becomes less exact, resulting in what we call artifacting and lower image quality. One thing to remember about JPEGs is that they're compressed each time they're saved. Therefore working with a JPEG image as a source image is discouraged.

You should save the original graphic in another format and simply overwrite the JPEG as it's either updated or changed. GIF is short for Graphics Interchange Format, and was introduced in 1987 by CompuServe. In short order it became the most common image type used on the web. Now GIFs are 8-bit graphics, meaning that they're limited to a maximum of 256 colours. Although they use a lossless compression format, this colour limit prevents them from displaying subtle tones and colour shifts. As a result, GIFs are typically used to display solid colours or flat artwork like logos, or icons. GIFs also support transparency and limited animation, which are not supported by the JPEG format. And this makes GIF the favourite format for web icons and smaller animations.

A more recent addition to the world of web graphics is PNG or Portable Network Graphics. PNGs have several advantages over GIFs and JPEGs, and were developed around 1995 as a response to copyright disputes over the GIF format. PNGs, like GIFs, support transparency, and use a lossless compression format. Unlike GIFs, they support millions of colours, making them ideal for displaying photos and subtle colour tones. Despite those strengths, PNGs suffer from one major disadvantage. PNGs typically have a larger file size than JPGs and GIFs. And of course PNG transparency is not supported in older browsers, although we're really talking like Internet Explorer six here. So it's not as big of a deal as it was before.

Currently PNG usage is right on par, if not a little above, both JPGs and GIFs in terms of how often they're used on the web. Although it's not as widely used, SVG, or Scalable Vector Graphic files, are beginning to be used more frequently as web graphics. The interesting thing about SVG is that they're a vector format which allows them to scale to any size without any loss of image quality. SVG Files are actually written using SVG markup, which makes them look very much like an XML or HTML file. Now this makes them unique in terms of web graphics, as designers can modify them just by editing a few lines of code. SVGs also can be further styled through specific CSS properties, so the same graphic can be made to look slightly different throughout your site. SVG support hasn't been great historically, but almost all modern browsers now offer full support.

SVG files are typically a little larger than their compressed counterparts, which is worth keeping in mind when you're considering using them. When deciding which format to use take into consideration colour requirements, image dimensions, and the weight of all of your page content. Knowing how the file types compress graphics, handle colour, and support additional capabilities, such as transparency, will help you make an informed decision when choosing which graphic formate to use for your site.

What is an API?

As the web has matured the amount of information and services shared by sites and applications has grown. Rather than building complex databases and services from scratch, you can often use existing sources of data or services that a site has made available to other users. That's where APIs come in. APIs, or Application Programming Interfaces, are written to provide a set of instructions and standards for using a specific service. They're usually written to make it easier for developers to use an application or to make services publicly available to anyone who wants to use them. Now what does that really mean, and more importantly, what does it mean to web designers? Well, the best way to explain it is through using it in an example. Let's say that you're building a site for a client that focuses on rare books. Now, wouldn't it be great if you could leverage the power of huge sites, like Amazon and eBay.

To find rare first editions and offer those for sale on your site. Well, using Amazon and eBay's APIs, you can. Now the concept of open APIs, and those are APIs that are exposed for other people to use, has dramatically changed the way that the web works. Websites can now leverage the power of larger online applications to offer services and functionality that would be far beyond their normal capabilities. Developers can also combine services from multiple APIs that create what we call mash ups.

Now these leverage the power of multiple sites into a single application. This allows the web to grow in multiple and organic ways. Larger sites like Amazon and Google are happy to let others use their services since it expands their brand and audience. Smaller sites like taking advantage of APIs to create a more powerful service and user experience for their audience. If you're a designer, chances are you won't be doing much with APIs yourself. Each API is slightly different and usually an experienced developer is required to integrate their services into your site. However, by understanding the power of these application interfaces and then thinking creatively about how you can use them, you can design sites that offer compelling content and really powerful features. There are a few things to consider when planning on using other sites' services on your own site.

Many APIs limit the type of data they expose or the services that they allow. Knowing that you can tie into Facebook via their API is one thing. But don't assume that you'll have access to all of Facebook's features and information. Take time to research exactly what a site's API will allow you to integrate into your own site. Now also keep in mind, APIs change over time. Engaging a developer to build an API-sourced application on your site can be an expensive undertaking. If the API change, your code can no longer work leading to disabled services and another round of coding. One final thing. Although site like Amazon, eBay are extremely reliable, sites do go down occasionally or even shut down altogether. Before using an API from a smaller of lesser known site, make sure they're stable and they have a good track record for up time. You don't wanna create a compelling app that never works. So why are we talking about APIs in the chapter on front-end technologies? Because the adoption of HTML5 has introduced several high-level APIs that aren't company specific the way Google Maps or Amazon web services are. They allow you to do things like geolocation and drag and drop, directly within the browser.

This has allowed many of the tasks usually performed by developers. To actually be written by front end designers. Now, we're gonna take a closer look at those HTML5 APIs next.

API first

HTML5 APIs

The development of HTML5 has been one of the greatest and the most confusing moments in the history of the web. In the past, HTML simply provided the mark up language necessary to structure content on the web. Now, as the web evolved, content began to go beyond what a simple markup language could structure. The desire to add elements such as video, interactive widgets, animations and other rich content to sites, led vendors to create plugins, like Adobe's Flash, to get around HTML's limitations. This environment led to the development of HTML5. The idea behind it was to integrate many of the capabilities that web applications needed, directly into HTML itself. These capabilities would allow designers to create richer experiences and apps without having to use plugins or browser extensions.

By standardising them, it would also make adding richer content easier for everyone. And it reflected the reality of web sites, evolving from simple static sites, to the complicated applications that we see in the modern web. So a group called the WHATWG, which stands for Web Hypertext Application Technology Working Group, first developed HTML5. After its initial success, the W3C Standards Body issued a charter for an HTML5 group, and a working draft of the specification was adopted.

Now, one really big difference between the WHATWG specification and the W3C was the way that the W3C took a few of the associated APIs and moved them into their own specifications. Now, this served to keep HTML from becoming too bulky, while separating the development of associated APIs to extend their functionality. So let's take a look at some of the APIs that are often associated with HTML5. The Media API includes the video and audio elements and methods for controlling the loading and playback of media. It's related to the Text Track API that's also used to control subtitles and captions of related media. Another integrated API is the drag and drop API. Now this API allows you to make elements drag-able within the browser and even contains methods for handling how content from outside the browser interacts with a page when dragged and released. This is extremely helpful for building simple interactions, games or even applications that allow users to upload files by simply dragging and dropping them onto the web browser. The App Cache API is designed to make it simpler to create persistent web applications that work even if the site is currently offline. This would allow users, for example, to fill out a form or complete a task in your application while offline, and then complete the task or sync up data later when the connection is restored. Geolocation is often associated with HTML5, but it exists in its own specification. The Geolocation API allows developers to access the current location of users, and then react to it. Now this is especially helpful for mobile devices.

Canvas is another API that's found in a separate specification but is often mentioned with HTML5. The Canvas API allows developers to draw directly in the browser. And this allows you to create complex animations, games, and other visual effects without the use of plugins like Flash. Of course, these are not all of the APIs associated with HTML5. I hope, however, that it's enough of them to convey to you the importance of understanding how HTML5 and its associated APIs are changing front end design. By giving a standardised set of APIs, designers can now build complex interfaces that function more like an application than a website.

Learning web design doesn't mean that you need to master each of these APIs and how to develop with them. Rather, it means that you should be aware of the technology, what it can do for you, and when it's appropriate to use.

Web fonts

For years, the only way to display fonts on your site, was to use the fonts installed on the client machine. That meant that you really couldn't use just any font that you want, you had to rely on system fonts that were widely distributed with popular operating systems. This is why we've become so familiar with reading websites in Arial, Verdana, or Georgia. And recently, that has all changed, with the evolution and support of web fonts. So how do web fonts differ from how we've traditionally used fonts? Technically, the term web fonts refers to any technology that allows the automatic downloading and temporary installation of fonts on the client. Since that's mainly accomplished using the CSS @font-face rule, the term web fonts has begun to simply refer to the @font-face technique. But it is important to note that the SVG font face element allows this functionality as well. Let's take a look at how web fonts work. The @font-face rule allows us to request a font from the web server. The font is downloaded and temporarily installed within the web browser. You can then reference the font family within your site's CSS and have the font display. This sounds like a fairly easy process, but the implementation and support of web fonts took a very long time. One of the biggest issues with the adoption of web fonts dealt with the end user license agreements from most font vendors. The majority of these agreements contain a clause that prevents users from distributing the fonts without prior approval. Actually, the simple mechanics of that font face would have put most designers in violation of those agreements. For the most part, font foundries weren't absolutely crazy about the idea of having browsers and even possibly end users downloading their fonts without their permission either. And I can't really blame them. When you combine those concerns with the increased overhead of downloading large fonts. And the specific needs of on-screen font rendering. You can kinda, see why web fonts require their own specific approach to font design. This led to the development of new font formats that are specific for the Web and they're designed to reduce file size and make the fonts themselves more secure. Font formats such as EOT, which is the early format developed by Microsoft, and the WOFF format was designed to compress fonts and optimise them for on screen usage. While foundries and type designers weren't always crazy about the idea, it's important to note that they have been instrumental in the adoption of web fonts.

In addition to working with the W3C and browser manufacturers in developing new formats, they have begun to design or modify existing fonts, specifically for use on the web. Reduced glyph sets, auto hinting fonts to assist with screen rendering, and new licenses designed to allow usage with @font-face, are just a few of the ways fonts are being redesigned for the web. Support for web fonts have led to multiple services that offer web fonts for sale, or download, as well as hosted solutions that serve the fonts for you. By using a hosted service like Typekit, you can avoid having to worry about cross browser implementations or the legal issues surrounding font usage, and just use the fonts you want from their huge library. If you want, you can always host the fonts yourself. Because of the advent of web fonts, front end designers now have options for the typefaces they use on their sites and applications. In turn, this is allowing designers to create a more visually sophisticated web.

3. Back-end Technology

Server-side scripting

In our last chapter, we discussed front-end technology. In this one, we're gonna change our focus to exploring what happens on the server, and the types of technologies that are used to create dynamic websites. Any scripting or programming that runs on a web server is referred to as server-side scripting. This could be anything from processing a form, managing an online purchase, registering a new user, or even something like booking a hotel room. As web sites have matured, technologies that surround server-side scripting have matured as well. In the early days of the web, most server side scripting was done with what we call CGI Scripts. CGI stands for Common Gateway Interface, and it was created as a way to run scripts from programming languages like C+ or Perl on websites. Since then, a multitude of programming languages and frameworks, like PHP, Java, .NET, Cold Fusion and others have given developers a wider array of tools to choose from when they're creating dynamic sites. Although each language is slightly different, the process for utilising server side scripting on a web page is pretty consistent. If a web page containing server side scripting is requested from a server, the web server first processes the script before the page is served to the browser. Processing the script could involve pulling information from a database, making simple calculations, or choosing which pieces of content to display on the page. Once the script has been processed, the resulting content is then returned to the browser, an then it's rendered. This process can occur from either a simple page request, through something like a user, filling out a form, or from interacting with a specific widget. Since the scripts run on the web server prior to serving the content, the scripts themselves are hidden from the end user. Now this adds a layer of security for both the data and the source code itself. There are, of course, some downsides to using server side scripting. Since the processing must be done on the server, it places the burden of running the application on the web server itself rather than the client machine. For larger applications, or sites with a lot of page requests, this can slow down the site, or force the site to upgrade to larger or even multiple servers to handle the load. The flow of dynamic pages can be frustrating for end users as well. Because the server must process the scripts, there's usually a page refresh required to display new content. This is largely the reason that client-side scripting has gained in popularity as well as the development of techniques that run server-side scripts without requiring page refreshes. To be honest, the terms client-side scripting and server-side scripting are becoming rather nebulous. Developers have become very adept at using Java Script to blend the two methods together into a seamless user experience.

If web development interests you, be sure you focus on not just the server-side software that we're going to be exploring in this chapter, but also how JavaScript is being increasingly used for more powerful client-side scripting, and as a method of controlling scripting on the server as well.

The importance of PHP

The first server-side language we'll examine is arguably the one that has had the greatest impact on web design, and that would be PHP. In 1994, and forgive me cuz I'm just gonna butcher some people's names in this movie, but Rasmus Lerdorf wrote a set of CGI scripts in the language C for tracking visits for his online resume. And that is really how it started. He was just tracking how many people were visiting his resume. He named these scripts Personal Home Page. And spent the next few years refining them and then opening the source to the public. Well, in 1997, developers Andi Gutmans and Zeev Suraski, in collaboration with Lerdorf, rewrote the existing parser and released PHP 3.0. Now, they changed the name of it a little bit too.

PHP now stood for Hypertext Preprocessor. But that basically completed its evolution into a really powerful server side processing language. Because PHP was free and it was open source, it attracted a wide user base that continued to contribute to its development, so you had people from all over the world working on it. What makes PHP so important to the development of the web was its pairing with Apache servers and mySQL databases. By using open source software, now anyone could create a powerful web server that could build and host robust dynamic sites. And since PHP is relatively easy to learn and it's so widely hosted, it really has become the most widely used language for building dynamic sites. In fact, many complex web applications, like WordPress, are built in PHP. Like most server side languages, the PHP code is embedded within a page's HTML. The code is then processed on the server and then replaced by HTML or some other content. To the end user the PHP code itself is invisible. I want to take a quick look at PHP in action. Since most server side languages work in a similar fashion, this will give you a good idea of the basics of how all server side languages work.

Here I have a file called time.php. Now note that it has .php extension, not HTML. If you look at it, it's an HTML document. But by having a php extension, this tells the web server that you need to process me first. So any time you see something like asp, or aspx, or cfm, or php, that's essentially just telling the web server, hey I need some processing done before I'm actually rendered within the browser. They're still HTML, they just need processing done and that identifies the language that's being used. So if we look at the page itself, it's a very simple example. There's not a lot going on, it's mainly HTML, except for this section I should say right there. Here are PHP language.

Now, each language is slightly different, but essentially it has some type of an identifier to let the server know where the processing code is and where the HTML is. And basically for PHP, it's this right here, the question mark PHP. A lot of people will shorten that to just a question mark, but I kept it I kept the long hand so you can kinda see what's going on there. Essentially we're doing something very simple here, we're doing the echo command, which tells the server to write whatever the result of this on the actual page. And then we're running the date function, and I've just got some formatting here that's gonna return the current date and time. So it's really just sort of learning the syntax, just like any language that you're gonna be working with. Now if I save this, and I preview this in a browser, you can see right here it says the current time is Saturday, November 9th, 2013. Although the time on my computer is obviously wrong, because that's not what time it is, but hey, you get the idea. What it is doing is it's processing this code in the back end. And in fact, if I looked at this, let's say I inspect the element. You can see that it just returned normal text. The PHP code is gone. That's because the PHP code was processed on the server. The resulting information was then written to the page using the echo function. So, to the end user, this PHP is totally invisible. One more thing I want to point out to you before we just go back to talking about PHP for a moment, and that's where this is located. Now because I'm previewing this locally, I need a web server running on my own computer. Since I have a Mac, and since I want to use the Apache, MySQL, PHP stack, I'm using what we call MAMP. MAMP is a free open source server, you can download this, you can run this locally on your machine, and you can test all of the dynamic sites locally that you're building. Now in order for me to do this, however, I have to literally host this the same way that you would host a website. And the way for me do this is to go into the map server, find the htdocs folder, which is essentially taking the place of the www subdomain and place the time.php file there. So I'm actually previewing from within the local server and that's how the server is able to process that.

If I just open the time.php file in a regular browser without a web server available to me, it would return an error. Since PHP is open sourced and free, it's available on almost any hosting plan. By using PHP it's really easy to find a plan that can fit almost any budget, and there's a large pool of talented PHP developers that can assist you with your projects if you don't feel like learning it yourself. If you are interested in eventually scripting the dynamic portions of your site, PHP is a really good choice. PHP syntax is fairly easy to learn, and extensive programming language is not required to begin adding dynamic content to your sites.

Other popular server languages

In addition to PHP there are a multitude of popular server side languages that are used to build dynamic sites and applications. Let's take a moment to examine a few of the more popular options. JSP stands for Java Server Pages and is a powerful server side application tool that's been developed by Sun. As part of the larger Java Framework, JSP can be an amazingly powerful development tool. And as you would imagine, it's a favourite of traditional Java programmers. JSP is very similar to server site applications in that the JSP code is embedded directly into the HTML, and then processed on the server.

Scripts are a combination of XML and what they call Java scriptlets. So, JSP might have a little bit of a steeper learning curve to those that are new to programming. Now, JSP has a reputation of only being used for large scale enterprise sites. But while it's certainly powerful enough to handle sites of any scale. I want to point out that JSP can be used for any sites. Even little small ones, with modest server side needs. It doesn't really matter. JSP can be ported to almost server environment so finding a hosting company is relatively simple.

However; there are a lot of different Java platforms out there and the cost of hosting might vary greatly by which platform you're using, so it's important to understand. Which platform that your site requires for hosting, and that's especially true if you're working with a Java developer in developing your site for you. .NET itself is not a server side application. .NET is the name used by Microsoft to identify its entire application framework. Now, if you're working with the developer to develop web based applications.

Make sure you discuss the pros and cons of which language you're going to be using within the .NET framework. Much like Java, .NET allows developers to build large scale applications for both the web and for the desktop. As such. .NET is typically more complicated than, say, PHP or ColdFusion. And it's unlikely to be the choice of web developers that focus only on developing dynamic websites. Sites built using the .NET framework must be hosted on a Windows server. So, hosting companies can be a little bit more limited, and the pricing structure is typically a little higher for those sites.

ColdFusion was originally developed by a layer and has since been acquired in turn by both Macromedia and Adobe. And both of those have just continued to develop the language. ColdFusion differs from other server-side applications in that it's added to HTML by using it's own markup language, CFML. Many web designers find that the similarities between writing CFML and HTML. Makes learning cold fusion relatively easy. Especially for simple web applications. I know I found it a little bit easier to pickup than PHP when I was first starting to learn it.

The cold fusion administrator also handles a lot of common tasks. So just connecting to databases, and setting up mail objects. They usually require additional programming and other server side applications. This and the simplicity of tag base approach means that cold fusion applications typically require less code than other approaches. Cold fusion integration with other Adobe products. Allows ColdFusion developers to easily generate PDF files, dynamically integrate with Flash and Flex based applications, although that's not as big of a deal as it used to be.

But the ColdFusion server is not free, so ColdFusion host accounts are typically a little bit more expensive than PHP. However the pricing structure for ColdFusion sites has dropped dramatically over the years as the number of hosting services offering it has increased. Python is a very powerful open sourced programming language, that was developed as a multipurpose development tool. While not solely focused on the web, Python includes a variety of web related libraries that make it very simple to build powerful websites and applications with it.

Although Python's syntax is fairly simple and relatively easy to learn. It's really not generally used to create small dynamic sites, rather it's commonly used to create larger dynamic sites and web based applications.You can learn more about Python at docs.python.org. Ruby is another powerful programming language often used in web development. Although some see it as a relatively new addition to web development, the Ruby language has actually been around over twenty years. Much like Perl, or C, Ruby is a general purpose programming language and can be used for a variety of development tasks.

Tasks, not just the web. Now Ruby's popularity on the web exploded due to the Ruby on Rails framework. Ruby on Rails which is sometimes referred to just as Rails is actually an extension of Ruby that's designed specifically to build websites. Because of its simple syntax and powerful integrated web capabilities, Rails has become a very popular tool in creating dynamic sites and applications. Now obviously this is a very general overview of server-side languages. For most web designers, choosing an application platform comes down to three main factors.

Cost and hosting availability, partnering with a qualified developer, and ease of use. My advice for any new web designer without a programming background would be to take it slowly. Find a talented web developer or firm that you can build a relationship with and have them help you make the decisions regarding server technology that's right for your client and their budget, and the project itself. Most of all, learn as much as you can about the various platforms so that when the time comes to make a choice, you're making an informed one.

Dealing with data

Many websites require the storage and retrieval of data. A popular message board would need to store things like user names and passwords. Blogs would need to store blog posts and comments, and something like a travel site would need to store information about specific tours, some of the other things that they'd be working with. Well online data can be handled in a number of different ways. Typically, data can be stored locally on the client. Stored in simply structured text files or stored within a database. Several factors drive which method of data storage is ultimately used, such as the type of data that needs to be saved and the needs of the site regarding data, retrieval and usage. In the past, designers have been very limited in the terms of the type of data they could store within the client. Due to security concerns, browsers have been limited to writing small text files called cookies, on client machines. These text files could store small items like user preferences or session IDs that could enhance the user experience, but Really did very little in terms of storing actual data. Well recently, with the advent of HTML5, that has changed. HTML5 introduced the web storage API. And that allows web sites to store simple, what we call, key value pairs within the browser. A keep value pair is a set of values like, name equals James. This makes it really easy for browsers to save user preferences on sites.

Or have the site pick right up from when the user last visited. Now for larger sets of data. Sites could also use XML files, or what we call adjacent objects. XML is a markup language a lot like HTML, but it's extensible and it's name, for example, stands for extensible markup language, and it can contain any data that you wanna store in it. For example a tours XML file, could store tour names, prices, dates and descriptions. JSON, stands for JavaScript Object Notation and it allows you to store simple values in a text file, both methods allow you to use JavaScript to write and retrieve data from the appropriate file and they're relatively easy to use. None of the previous methods that I just mentioned are really ideal for more robust data needs. However, the most efficient way to store complex data or large data sets is by using a database, databases can make life a lot easier for both the web designer and the client.

Let's say that you're designing a site for a bakery that specialises in selling cupcakes. Well, with a static site, you'd have to enter each cupcake, image, description and price by hand. As the inventory changes You'd have to update each one manually and add and delete items as necessary. That's very time consuming and frankly, I don't think anybody out there wants to do that. By using a database, you can simply add all of the cupcakes and their info into the database. Use server-sized scripting or client-sized scripting to display it on the page, and then just update the database as needed. A scripting will ensure that the most current information in the database is being displayed on the site. The easiest way to visualise a database is just think about a table of information. It's a lot like a spreadsheet, honestly. Because databases can contain a lot of different tables, and because those tables can relate to each other, you can create complex interactions between data and making sorting and searching your data a lot more efficient.

Many databases allow you to store more than just text, which allows the storage of images, video, and other types of content. Although most databases will sit on the server, there are currently two competing data storage methods that allow you to store databases within the browser, Indexed Databases, and Web SQL databases. Currently, Indexed DB seems to hold the most promise. But at this point, it's really too early to tell which method, if either of them, are really gonna achieve full adoption. In terms of online databases, there are two main types.

There's relational databases and non-relational databases. Relational databases store data in tables that relate to each other based on key columns of information. For example, a tours database might have a table for tour regions and another table for individual tours. That then uses the tour region key, in it's table. This allows you to perform complex data sorting and filtering, based on the relationship between those tables. Popular relational databases include Oracle, mySQL, Sybase, and a number of SQL based versions. SQL databases are, so important to web development that I'm gonna discuss them separately in just a moment. Non-relational databases which are also often referred to as NoSQL databases, so if you see that, that's what they're talking about Well, they offer an alternative to traditional relational databases, and they're actually growing in popularity as websites get bigger and have to serve larger loads. There are several different methods for creating a non-relational database, but most center around the idea of creating flat object driven datasets that are faster to index than relational databases, and easier to scale and modify. Relational databases are driven by what is known as a schema, which can be very difficult to modify once it's been created. Non-relational databases don't have schema's, and thus are a little easier to modify once they're put in place.

Popular no SQL databases include MongoDB CouchDB, Amazon's SimpleDB, HBase, CouchBase and Cassandra, although that is certainly not a complete list. I know that's a lot of information to digest and truthfully, I've really barely scratched the surface of managing data for websites. Obviously, this is a subject that you should devote a fair amount of time and effort to study, to ensure that you're making the best choice for any potential project.

Using SQL databases

Before we move on from talking about data, I want to talk in a little bit more detail about SQL databases. SQL, or structured query language, often referred to as SQL as well, is the standard language for managing and retrieving information from databases. By taking a deeper look at it, you're gonna get a better overall feel for how data management works. Web applications typically use SQL or some form of it to update, create, delete or retrieve information from a relational database. Relational databases are the most common form of data storages by web applications. They store related data in one or more tables. If you've never dealt with a database before, just picture a spreadsheet. Data is stored in rows and columns with the columns describing the data and the rows storing the data itself. Using simple SQL queries or SQL queries, if you will, web applications can parse and use this data within the application. SQL uses simple logical syntax that's very easy for most people to learn. Common statements like select, insert, update, and delete make it really easy to retrieve or manipulate data, and SQL queries can be refined to filter data sets even further or even join related tables together to create a larger data set. So check out this sample SQL query. Even without me explaining it to you, you can probably get a good idea as to what this is doing. So, if I take a look at the syntax in a little bit more detail, the star means select everything.

From tours means from the tours table. Where the price is less than 200. So, less than $200.00. And then, take the results and order them by tour name in descending order. So put them in alphabetical order. Now, the data returned from our tourist table here, is often referred to as a data set. And could be used by a web application to populate a table on a web page, display data based on user searches or really any number of data related tasks within a site. While SQL is relatively easy to learn, it should be noted that there are several different versions of SQL, and most feature proprietary extensions to the language that are unique for each version. SQL queries are typically found as a string inside web application syntax and passed into the database as the page is being processed on the server. There are many dedicated programs that use SQL to manage databases. And most of the web server applications use database management tools like mySQL to control data within the application itself. Now for most of you, that might be more information about SQL than you ever wanted to learn. Well this of course poses the question: do web designers have to learn SQL? Well, the short answer is no. Web developers or programmers will write the code that will perform most data manipulation within your sites. However, on smaller sites or sites where you need to perform simple web application scripting, a basic knowledge of SQL is a really good thing. Learning the basics of SQL is simple, so it's a good idea for any new web designer to spend some time working with SQL queries and becoming comfortable with its syntax. This will make life a lot easier for you if you ever need to manipulate a query within your application, or tackle some basic data management yourself.

Content Management systems

A content management system, or CMS, is an application that helps control the creation, publishing and archiving of your site's content. A good CMS can speed up the creation of sites, make updating and creating new content easier and less technical, create groups of users that have varying degrees of control over your site's content and easily allow added site functionality by installing pre-built modules or extensions. Let's take a quick look at the typical workflow involved when working with a CMS. As a designer, you can create a template, or a series of templates, that control the layout and the design of the site. Many CMSs separate page regions as well, and that allows you to design things like multiple headers, footers or content regions that can then be assembled into custom pages later. The content for the site is then ingested into the CMS and then stored in a database. This can be anything from text, images, or even multimedia. Usually you can either add the content as pages are being created, or you can upload the content separately. Now to create a page, you first choose a template, assemble the elements you want onto the page, or add content through the use of the CMS's page editor, which is typically what they call a WYSIWYG, or a what you see is what you get, editor that closely resembles using a word processor. As you create pages, you can also use the CMS to structure the site and build navigation. As a designer, this can make creating and deploying sites incredibly fast. For most web designers, the real benefits of a CMS are what they allow you to do after the site is published.

Updating page content is usually done through the WYSIWYG editor, which allows non-web designers and non-technical people to update and maintain the site's content. In fact, most CMSs allow you to create user groups and set permissions based on those groups. That means that you can allow clients to edit as much or as little of the site's content as you'd like after you're finished with the project. Within an organisation, you can have individuals within one department edit specific pages, while another department is responsible for, say, another section of the site.

Depending upon how you organise the site, clients could even create new pages or sections themselves, which would allow you to turn site management over to the client entirely. CMSs also allow you to extend the functionality of your site in really powerful ways. Often just installing modules or plugins will allow you to add things like logging capabilities, e-commerce, calendars, or a million other features to your sites. This ability often allows you to scale a site's functionality without having to engage a development team or even add additional skills on your own. They're just plug and play for the most part. CMSs come in a variety of sizes and capabilities. Most are hosted online, and they require little more than just setting up an account before you begin creating your sites with them. Others are gonna have installers that hosting companies can use to generate a custom install on your own hosted account. While still other require you to manually set up the CMS. Features between them differ as well.

Some drastically limit the amount of customisation you can do to page design, or the number of page layouts available, while others give you total control over your site's structure. If you wanna learn more about CMSs, I suggest going straight to the source. Some of the more popular CMSs are Joomla, Drupal, Movable Type, ModX, Radiant, WordPress, and Expression Engine. With a little research, you should have a good idea as to which CMS is right for you.

Content delivery networks

Content Delivery Networks, often referred to as CDNs, are a way of delivering content online over a distributed network of servers. This is usually geographically diverse in order to provide local access to users all over the world. Unlike traditional web hosting where content is hosted on a single server, CDNs take content and distribute over a huge network. Often this will be thousands of servers located all over the world. This means as requests are made for the content, the network can share the load and serve content based on the closest location. This means that the delivery of the content and makes it easier for sites to manage heavy traffic or spikes in requests. CDNs are used largely to serve static resources like CSS and JavaScript libraries, as well as media files like images and video. Entire websites can be served through them, but it's more common to find site all floating specific types of content through CDNs. For example, if your site uses the popular jQuery JavaScript library, you could certainly host it yourself, but that would mean that every visitor to your site will have to request and download it from your server. However, if you used the following line of code, you can actually offload this request to Google's Content Delivery Network of hosted JavaScript libraries. This has the benefit of reducing the load from your server, speeding up the delivery of jQuery through Google's CDN, and it also increases the likelihood that the resource will already be cached in case one of your visitors had visited another site which uses Google to serve jQuery. There are several types of CDNs that are available to you. Some, like Google's hosted libraries, or the bootstrap CDN, exist to serve specific resources for sites.

internet traffic

Some CDNs like YouTube offer resource hosting as both a service and as a content aggregator. There are also many free or commercial CDNs that can be configured to assist with serving your entire site or specific content types. A few popular ones are Akamai, CloudFlare, Amazon's CloudFront, EdgeCast, and Windows Azure service. CDNs aren't right for every site, however. Using one adds an additional layer of complexity to your site that small site or sites with low traffic might not need. Often, instead of using an entire framework or a library, it's better to use a minified version with only the parts that you need. Such customisation is usually not available through CDNs that host those libraries. It's especially important to consider a site's security needs before using a CDN.

Cloud

For sites where you need complete ownership and control over the site's content, a CDN probably isn't the best choice. CDNs are an important option to consider when deciding how content from your site should be served. In many cases, it makes sense to take advantage of the performance gains they offer as well as the reduced bandwidth to your own host.

Cloud services

Earlier in the course I discussed the difference between the web and the internet. If you remember we talked about the web referring to content being transmitted over the internet, usually structured in HTML, and then transferred using web protocols like HTTP. Honestly though, that's just a really overly technical way to say, websites. So the web, consists of websites. Now the internet however is something much bigger. Over the past 20 years, a vast network of millions of computers have evolved to comprise an amazingly powerful development platform. That platform is beginning to mature with the growth of what we call Cloud services. By now, I'm sure you're familiar with the term the Cloud. In many ways, the Cloud is just another buzzword, but what it represents is significant shift in how we use and develop the Internet. By using the global scale of the always-connected, always-on internet, developers are creating applications and services that fundamentally change the way people interact with the internet. Take the service DropBox. DropBox isn't a website at all. In fact, if you visit dropbox.com, and you can see it here, you'll find an amazingly simple website. It barely tells you anything about the service at all. It just offers you a way to create an account or sign in, and the ability to download their app. What Dropdox does however, is allow everyone that has an internet connection the ability to store and share files whenever they're connected. By using Dropbox I can access the same file I was working on at home over 2,000 miles away using somebody else's computer or even my phone. I can also share a project with team members in various locations without ever sending email attachments or making them download a zip file. We can all update project files and then they'll sync automatically, making sure that all files are the same no matter where they're accessed. Well, Dropbox is just one of hundreds of cloud-based services that are changing the way we access content and services over the internet.

These services usually are accessed through apps that can be installed on desktops, mobile devices and even non-traditional clients like cars and watches. It's web development in a way that looks at the web as merely one component of its architecture. The technologies used to develop these services are roughly the same as the ones used to develop websites and web apps. You'll find Java, Ruby, .NET, and even JavaScript driving the majority of these apps. What is different, is how they're architected and served. The majority of these services require extremely robust hosting through multiple servers that can handle high traffic rates and large amounts of storage. They also need to be scalable, so that as the services audience grows, their capabilities can grow as well. Since the development hosting requirements of cloud services are far beyond most hosting companies or individuals, cloud platforms have arisen to make developing and hosting these apps easier. Companies like Google, Amazon and Microsoft all have powerful cloud-based app services in addition to specialised companies like Rackspace and Heroku. In fact, a quick search will reveal dozens of powerful cloud development platforms. It's important to understand that these types of cloud-based services and applications are fundamentally changing the way the internet distributes its content.

It means that we should view the internet not as simply a network that allows us to deliver the web, but rather as a robust and mature application platform.

Cloud Comparison Cheat Sheet

What is GitHub?

Although I've tried to keep this chapter focused on a high level overview of back end technology, there are some applications that warrant a closer inspection. GitHub is one of those. And it's significantly changing how people develop, publish, and distribute content and applications online. GitHub is an online distribution service, offering users a way to store, publish, and version control their content. That's not exactly a new idea, as version control software such as CVS and Subversion have been doing that for years. In fact, GitHub is built around Git, which is an open source version control system created by Linus Torvalds, the creator of Linux. Like most version control systems, it allows you to manage projects and store revisions of them as they're developed. That makes it easier for developers to revisit older versions of a project, correct errors or branch a project off into a new direction. So if these capabilities are nothing new, what makes GitHub so special? For one, GitHub is an online service, that offers both free and private commercial plans. The only barrier to using it is just creating an account.

Git is also a command line tool. Which makes it difficult for those not comfortable using command lines to use. GitHub by comparison has a web interface that makes it a lot easier to use. Where GitHub really excels however, is in the public nature of its service. And the social aspect of sharing and collaborating on projects. Here are the basics of how it works. When you create a new project in GitHub, you upload the latest version of your project files. This could be an app you have in development, a website, or even a video editing project that you're working on. The type of files really doesn't matter. GitHub then syncs the project files to your local copy. When you make a change to your local files, you check in the changes and only the changes are uploaded to the repository. At each stage, a version of the previous files is saved.

Allowing you to roll back to an earlier stage if necessary. For the most part, that's exactly how other version control system works. But, here's how GitHub is different. Unless you have a paid private directory, anyone can access your files and fork them. That is, create a copy of the files in their own GitHub repository. From there, they can change or update the files. And then either keep developing their version separately, or they can issue a poll request. Which is their polite way of asking you, if you would like to accept the changes that they've made. If you say yes, their changes are then merged into your repository. What's more is that GitHub allows you to create a Wiki style homepage for your projects. Which encourages exploration, can provide documentation, and facilitate project planning. That may sound slightly insane, but it's actually incredible boon to open source projects. The open source collaborative nature of GitHub has led to an explosion of new open source software in web libraries. That are driven by the crowd source development process of forking and then merging projects together. Ideas can be tested out faster, teams can collaborate not only with themselves, but anyone that's interested in their project. As you can imagine, many other web based collaborative tools have emerged since GitHub. But GitHub's sizable online community, streamlined tool set and widespread integration with other services.

Makes it an increasingly important part of the web development process.

GIT commands

GIT merge vs GIT rebase

GIT workflow

4. Assembly Technologies

Javascript libraries

HTML, CSS, and JavaScript are the three core technologies for creating content on the web. Almost anything you want to build online can be built by learning just those three languages. As the web has matured, however, sites have become increasingly more diverse and complex. And building those types of sites can require a lot more effort. To make life easier for web developers, various assembly technologies have been created that reduce a lot of the time and effort required when writing complex sites and applications. In this chapter we're gonna focus on a couple of those assembly technologies starting with JavaScript Libraries.

A JavaScript library is a collection of pre written JavaScript code, that makes it easier to perform certain tasks using JavaScript. Let's say for example, that you want to fade a tool tip in once somebody has clicked on a frequently asked questions link. To write that myself, I'd have to write multiple JavaScript functions that are unique to my site and that it account for any differences between browser JavaScript engines. Or, I can just take advantage of the popular jQuery library and use the built in method, fade in. In many ways, JavaScript libraries extend the JavaScript language by adding methods and values for commonly performed tasks. Some libraries are extremely focused.

Such as Date.js, a small JavaScript library, whose only task is to make formatting multiple date types easier. Others like jQuery have a much broader focus and seek to make the entire JavaScript authoring process a little easier. To use a JavaScript library, you simply need to include a link to it in your page, so that the browser downloads the library and makes it available for use. Once that's done, any scripts that use methods or objects from the library will execute properly. In many cases, popular JavaScript libraries are served by CDNs, although you can certainly host them yourself. Like any technique, using a JavaScript library has its pros and cons. Using one will usually make the scripting process much more efficient.

But would normally take hundreds if not thousands of lines of JavaScript can often be done in just a few minutes with a few lines of code. A JavaScript library can also often extend your coding capabilities. For example, there is no way I could author half of the functionality of most of the libraries out there. By using them, I extend what I can do with JavaScript. You're also using code that's been tested by hundreds of other users. Most libraries are open source and free which means that they also have communities of contributors constantly testing the code and making it better however and JavaScript library isn't always the right choice. Since you have to include the library as a site resource it increases the size of your site and the amount of code that you're using. For simple functionality, you'd lower your overhead by just writing the scripts yourself. There's also the danger of learning the framework and not the underlying language. There's a great number of developers out there that can write efficient jQuery code but don't really know how to write the same thing efficiently in native JavaScript. Limiting yourself like that means that you don't understand when a library is the best choice and when it's not. Ultimately, if you do almost any type of web authoring, you're gonna find yourself turning to JavaScript libraries to make the process easier and extend your site's functionality. Just make sure that you investigate your options to make sure you're creating the most efficient code possible.

Frameworks and boilerplates

Much like JavaScript libraries, there are also pre-built collections that package HTML, CSS and JavaScript files designed to make the process of authoring sites easier. These are often referred to as frameworks or boiler plates. A broader definition of these would be that they contain CSS files that have predefined rules for layout, typography, and browser resets, HTML files that contain a default starting semantic structure for sites, and JavaScript files that offer enhanced functionality like modal windows and tool tips. Now in many cases, the term framework and boiler plate are used interchangeably, although there are some subtle differences between most of them. A boiler plate usually refers to a set of templates that are focused around a very specific standard or goal.

A starting point, if you will. The HTML5 boiler plate, for example, focuses on providing starter pages in assets for building HTML5 sites and apps. Frameworks, on the other hand, are usually more of a collection of assets that provide a system for building sites. Frameworks usually have a specific focus such as building responsive sites, crafting user interfaces or a specific design aesthetic. There's an incredible amount of diversity among frameworks and boiler plates. They range from CSS-only layouts or browser resets to complex systems for building and deploying sites.

Now, this is largely due to the circumstances that led to their creation in the first place. Most frameworks are the result of a studio or an individual creating a starting point and systems that allow them to build their sites a little bit more efficiently. After creating these assets internally, they'll release them to the community as open source tools. Some frameworks are built around specific user interface goals and offer a wide range of tools to help you build sites. Bootstrap, for example, comes with a collection of CSS, Javascript files, images, icons, and even optional HTML templates and demo files. UI frameworks are typically fully functional development tools for building complete user interfaces and sites.

Frameworks like Bootstrap typically add the most overhead to sites, but they also give authors the most complete set of tools to build the entire front end of projects. Other frameworks and boiler plates, take a little bit more of a minimal approach. Rather than trying to encompass every aspect of site design, they focus on establishing a stable base for projects to start from and then leave the bulk of the styling up to the designer. While they might include basic styling for site typography and layout, they're more concerned with creating consistency with the smallest footprint possible. Obviously, this is a very different strategy from comprehensive frameworks. And you'll probably find yourself drawn to one over the other based on your own personal style and philosophy. In many cases, frameworks and boiler plates are used to help with rapid prototyping. By using the framework as a starting point, developers can have working HTML prototypes in hours rather than days. This helps integrate changes faster and speeds up the development process. However, many firms don't like to use frameworks for production code. Using a framework ties you down to its code structure and methods, and it can add considerable overhead to sites. That means that while frameworks and boiler plates can often be very helpful when building sites, they're not gonna be right for every project.

CSS preprocessors

Although CSS is a powerful presentational language, it's not always easy to write for larger sites, and it lacks many of the features that authors have requested over the years. Because the process of updating specifications and then waiting on implementations within browsers is so long, CSS pre-processors were created to kinda fill the gap and make writing CSS more efficient. A CSS pre-processor is a scripting language that allows you to extend CSS with new syntax and then compiles the script into regular CSS once run through the processor. This essentially means that using a pre-processor is a two-step process.

First, you author your styles using the pre-processor syntax. Then, you compile your file at Runtime to generate the actual CSS, which is then used by the site. There are multiple ways to compile your pre-processor files, and most are driven by the pre-processor that you choose and which workflow fits your preferences the best. There are many benefits to using a pre-processor. They can add additional functionality that's not built into CSS, like variables and conditional logic. They also make code more efficient to write by allowing you to nest selectors and write reusable blocks of code.

And they help deal with browser inconsistencies by generating CSS that's formatted to work across browsers. Although there are many pre-processors available, there are three that have emerged as the most popular. Sass is written in Ruby, and has two versions of syntax to choose from. Less is written in JavaScript, and it has syntax that more closely resembles regular CSS, so it's fairly easy for designers that are familiar with CSS to make the transition to Less. There's also Stylus. Now, this is written in JavaScript as well, and it has most of the features contained in Sass and Less, but with a more stripped-down syntax. Each of these pre-processors has a community of developers that have created extensions, modules, and workflow tools around each of the versions.

Now that you've heard the reason why might want to use a pre-processor, what are some of the reasons that you might not. Well first, everybody on your team that will work on your CSS will need to use the same pre-processor. For development environments where you might handoff files to other team members or agencies, this could be a problem if they're not familiar with it. Also, the more minimal code that you write on the front end doesn't always translate to the finished project. Often, the compiled CSS is much larger than you would have written manually, which can cause unnecessary code bloating. You're also adding an additional layer of complexity to your workflow. You'll have to write the preprocessor syntax, compile it, and then deploy the resulting CSS. This can largely be automated, but it does make the process more complex and often a little slower. The good news is that many of the features added by pre-processors are slowly making their way into native CSS, so in the near future, we might not need to use them at all.