Ch3

Lesson1: 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 overthe 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 summarized 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 specialize 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 programing 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 isserver 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.

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 ofhow
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 aunique IP address that's used to identify its location. The IP address for lynda.com for
exampleis 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 ushumans, 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
bookof the Internet and I really can't think of a better example than that. When you typewww.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.

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 internet service provider's, or ISP's, default DNSto 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 recognize? This
is where it gets alittle 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. Thebrowser 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 defaultDNS will cache the name for you, and
that makes the retrieval really fast. Now, that we know alittle 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
ofsoftware or operating system. The internet uses a loose framework of protocols often referredto as the Internet
Protocol Suite. This suite contains multiple types of protocols. That aredesigned for specific tasks such as
networking rules and data transfer. You've also probablyheard this protocol suite referred to as TCP/IP, which is short
for transmission control protocol and the internet protocol. First formalized 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 protocolsyou 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 standardized
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, includesthe 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 recieved. 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 oneway 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 downloadingfiles 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 thatyou 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 yuour 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'rerequesting. 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
andsubdomains allow servers to identify unique sites or unique areas of content. Www hasevolved 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 theFrequently 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 seperator 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 tothe 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
thebrowser 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, crosscomponents 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 thisinvolves 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 wseb clients. Internet Explorer, Windows Mobile, and most AOLbrowsers. 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 asApple'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 mulitiple versions of the same browsers as well.

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 browsershandle 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 battlingeach 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 featuresthat 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 in1998 by a group of designers and
developers frustrated with the current state of browser development. They began supporting, in an organized 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 standardize web protocols in technologies, byissuing 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 asstandards 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 encouragingthe 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 realize 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
specialized set of software andcomponents. 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 fora 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 areWAMP, 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.

Lesson2: 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.

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 JavaScriptlibraries. 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 specialize 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
allfront 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.
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 anessential 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
HTMLspecifications. 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 stabilized 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 recognized 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 justlargely
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 XHTML2.0 was going, they all got together and they formed a very awkwardly named
group called theWeb 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 recognized 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 wehave 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 browserand 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 mightcontain 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 thatcan 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. Thingsinside 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 syntactual 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

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 usuallycontained 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 intothe 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 identifyingelements 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 thatthey 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 instructons. Now here, there are three rules. One telling the browser which font to use, what size to render
the font, and what color 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
speeddevelopment 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 desinger.
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. Netscapeactually licensed the term Java from Sun to speed up the acceptance of their new
scriptinglanguage. 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. JavaScripthas 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 Iwent 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 behavior 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
loteasier 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. Assuch,
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 JPG, 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. Bandwidthconsiderations 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 browsersupports. 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 individualformats, 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 colors, making it ideal for photographs or images with subtle color
transitions. However, to keep file size down, JPEGs are compressed with what we call lossy compression. Now this
means the image datais thrown away, as they're saved. Depending upon the level of compression that you choose, JPEG
chooses areas of color 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. And no, it doesn't matter if you say GIF or GIF, it just doesn't matter. Now
GIFs are 8-bit graphics, meaning that they're limited to a maximum of 256 colors. Although they use a
lossless compression format, this color limit prevents them from displaying subtle tones and color shifts. As a result, GIFs
are typically used to display solid colors 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 favorite 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 colors,
makingthem ideal for displaying photos and subtle color 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 anyloss 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 differentthroughout 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 color requirements, image
dimensions, and the weight of all of your page content. Knowing how the file types compress graphics, handle color, and
support additionalcapabilities, 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 anexample. 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 nowleverage 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 isslightly 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 thenthinking 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 APs 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 orAmazon 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.

HTML5 APIs

The development of HTML5 has been one of the greatest and the most confusing moments inthe history of the web. In
the past, HTML simply provided the mark up language necessary tostructure 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 standardizing 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 ofassociated 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 andmethods for
controlling the loading and playback of media. It's related to the Text Track APIthat'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 createpersistent 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
thencomplete 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 standardized 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 onsystem 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 hasall changed, with the evolution and support of web fonts. So how do web fonts differ
from howwe'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 temporarilyinstalled
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 theirpermission 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
fontrendering. 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 new
WOFF or WOFF format Were designed to compress fonts and optimize them for on screen usage. While foundries and
type designers weren't always crazy about the idea, it's important to note thatthey 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.

Lesson3: 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 utilizing 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. Nowthis 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, itreally 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 isinvisible. I want to take a quick look at PHP in action. Since
most server side languages work ina 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 questionmark, 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 becausethe 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 locallythat 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 mapserver, 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 favorite 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 programminglanguage 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 datastorage 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 storetour 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 specializes 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 asnecessary. 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, andthen 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
visualize 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, soimportant 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 mostcenter 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 ofinformation 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 passedinto the database as the page is being processed on the server. There are many
dedicatedprograms 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 datamanipulation 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 willl 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 typicalworkflow
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 beingcreated, 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. Thatmeans 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 organization, you can have individuals withinone
department edit specific pages, while another department is responsible for, say, another section of the site.

Depending upon how you organize 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 customization 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. Thismeans that the delivery of
the content and makes it easier for sites to manage heavy traffic orspikes 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 ityourself, but that would mean
that every visitor to your site will have to request and download itfrom 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 incase 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.

Some CDNs like YouTube offer resource hosting as both a service and as a contentaggregator. There are also many free
or commercial CDNs that can be configured to assistwith 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 customization 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.

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
anddevelop 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 todevelop 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 specialized companies likeRackspace 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.

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, thecreator 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 thesecapabilities 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 youcreate 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 neccessary. 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 drivenby 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 toolshave 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.

Lesson4: 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 performcertain tasks using
JavaScript. Let's say for example, that you want to fade a tool tip in oncesomebody 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 codebut 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 andJavaScript 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 theycontain 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 subtledifferences 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 starterpages 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 andboiler 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. Mostframeworks 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 functionaldevelopment 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 atRuntime 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 chooseand 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
resemblesregular 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 processmore 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.