Chapter 19

Implement the Design

Summary

To take visual design and turn it into a fully-functional (and responsive) web design is a mix of programming, math, and human interaction.

Does this Apply?

This will affect you. Every website comes down HTML being loaded into a browser and interacting with other resources like CSS and JavaScript. You might not write this code yourself, but there are dozens of factors that a developer is going to juggle to make this work, and you should understand what these pressures and influences are, along with the basic tools of the trade.

Narrative

This entire book has been an exercise in moving from theory to reality. This story started with you just thinking about your goals and dreams. From there, you slowly refined the idea, resolving questions and issues, getting a little more concrete with each round of changes and considerations.

And you’ve finally arrived here, where someone is actually going to build something.

Some time ago, you got a design from someone. This isn’t a web page – it was probably a file from a design application like Adobe Photoshop or Sketch . This is a representation of what a web page should look like. It’s really just a theory. Now, you need to implement that design, which means turning it into a functional web page that can load into a browser and perform in all the ways we expect from a web page.

Clearly, we’re not going to teach you how to code. But we are going to introduce you to some coding concepts so you’ll have an understanding of what goes into it and what to look for when you get to this point in the project.


Front Ends and Back Ends

In the early days of the web, there was only one kind of developer: a web developer. They did it all. They were responsible for configuring the content management system, writing the code that ran on the server, and writing all the HTML and CSS (explained below) that displayed the results. They worked with the full stack of technologies.

Over the years, this “Swiss Army Knife Developer” has bifurcated. As the Internet grew and matured, the possible combinations of technologies available to build a website has simply grown to an unmanageable level. There are vastly more languages, technologies, and frameworks, and more seem to pop up every day.

These technologies exist on a spectrum with two ends: glass and sand.

  • The glass is the monitor screen our users stare into. A technology that’s “close to the glass” is something the user directly perceives or interacts with.

  • The sand is the silicon in computer processors. A technology that’s “close to the sand” is a programming function, primarily concerned with execution by the server’s processor.

Different technologies line up in different virtual distances from where the user interacts with them. The HTML loaded into their browser is the most immediate, direct technology that affects what they perceive, while the operating system on the server thousands of miles away is the most distant and indirect.

If we stack up our technologies from glass to sand, it looks something like this:

  • HTML

  • CSS Framework

  • (Raw) CSS

  • JavaScript Framework

  • (Raw) JavaScript

  • Network Infrastructure

  • Content Management System (CMS)

  • Programming Language

  • Database

  • Server Operating System

This corresponds to what we call front-end and back-end. Technologies considered to be on the front-end are those that are close to the glass. Back-end technologies are close to the sand.

Finally, to complicate this a bit further, front-end and back-end are also sometimes known as client-side and server-side. The browser is considered a client of the server. So working on the client-side means all the technologies that happen in the browser – HTML, CSS, and JavaScript. Working on the server-side means all the technologies that happen on the server.

The dividing line is the point when the response leaves the web server. When the server has read or created an HTML document and shipped it out the door to the browser, the responsibilities of the back-end developer are done. When the document arrives in the browser, the front-end developer’s job takes over, and continues until the document is unloaded from the browser (usually by being replaced by another document).

Because both sides of the dichotomy have become more complex, developers have come to identify and specialize with one of the other. Somewhere in the last 10 years, most web developers made a career choice as to whether they wanted to work on the front-end or the back-end. New developers make this same choice: do they want to work with front-end, presentation-level code, or back-end, processing level code?

Most professional services firms of any significant size will have both roles. A team will have back-end developers well-versed in the CMS and the associated programming language. Their job is to manage the processing of data on the server and provide this data in the correct format for the front-end developers to morph it into the visual representation required for the project.

And what happened to the “full stack developer”? There are developers who are still claiming mastery of the full stack, but it usually comes with caveats. They usually know a specific JavaScript and CSS framework, a specific CMS, a specific server-side programming language, etc. They know a full stack, but that stack is comprised out of a specific combination of things – call it their full stack.

Finally, there’s something to note about our stack list above: we get less specific from front to back. On the front-end, we have three specific, named technologies: HTML, CSS, and JavaScript. Moving backwards from there, we can only deal in generalities: a CMS, a programming language, etc.

This is because the technologies that are close to the glass have a common execution environment: the web browser. The developer doesn’t control the browser – their code is merely visiting while their web page is loaded. A developer’s relationship with a browser is temporary. This being the case, the governing authority of the web had to settle on a common standard of technologies for browsers to support. Thus, we can name those explicitly and expect that anyone working on the front-end will know HTML, CSS, and JavaScript.

But there is not governing authority for what happens behind the scenes. A web page can be created and served from any kind of CMS running any kind of database and any language. The server environment is controlled and known – we own this, remember – so it can execute any combination of technologies. We could invent our own programming language and use it to generate web pages, if we wanted, and no one would know the difference. Thus, back-end technologies exist on a much wider range than those on the front end.


The Toolbox: HTML, CSS, JavaScript, and Frameworks

The tools of the front-end developer are the top five from our list above: HTML, a CSS framework, CSS itself, a JavaScript framework, and JavaScript itself. Every front-end developer will know HTML, CSS, and JavaScript, and they likely have a preferred CSS and JavaScript framework that use commonly use.

This section is also where we show you some code. Don’t panic. It’s merely illustrative of concepts, and you don’t have to understand it completely to get the main idea.

Hypertext Markup Language (HTML)

“Hypertext” is a term coined in 1965 by scientist Ted Nelson when he was a professor at Vassar. Nelson conceived it as text which could reference other text, and which you could activate to reveal other documents.

HTML is a text format that embeds formatting and other presentation information inside text. HTML is the basic format of every web page.

An HTML document consists of text interspersed with “tags,” which are delimited by opening and closing brackets. Tags perform different functions. Tags surround text, and impose different functional and visual characteristics to that text. An opening and closing tag with its contents is known as an element.


This is some text. <strong>This text will be bold.</strong>

In the example above, the strong tag is opened and closed, and contains a sentence. That sentence is given special formatting or functionality based on the surrounding tags – it would be rendered in boldface, in this example.

The opening tag might have constructs called attributes which supply additional information.


<h1 class="title">This is the title</h1>

In that example, the h1 tag denotes a “Heading, Level 1.” This imparts some default formatting (large, bold), and the class attribute gives it a referable name so that we can find it again later with CSS and JavaScript.

Tags can nest inside each other – so an entire element can be contained within another element. In fact, all the HTML should be contained inside a “master tag” of HTML that opens at the beginning of the text and closes at the end.

This entire string of text is known as a document. This is what your browser loads and interprets.

HTML is the most basic technology of the web. It forms the backbone of every browser-based experience.

Cascading Stylesheets (CSS)

HTML tags can impart style information to text (like the bold example above). However, it’s considered bad form to embed too much styling into HTML because it can be difficult to sort through it, and a lot of it ends up being duplicated from document to document. By separating the style information from the HTML, you can manage the visual appearance of your documents much more efficiently.

CSS is a language that “selects” tags and applies styles to them. CSS is not part of the HTML, which makes it easier to manage.

Referring to our HTML example above, let’s say that we wanted to color all bolded text red, for whatever reason.


strong {

color: red;

}

That example will color red any text inside a strong tag element.

The specification of an element and the associated style information is called a rule. We can put that CSS in a separate file – called a stylesheet – and link it to our HTML. In fact, we can link the same stylesheet to multiple HTML files – 100,000 HTML files could be affected by the same CSS.

Later, if we decide we want all our bolded text to be blue, we can change the code in our single stylesheet and the appearance of all HTML linked to it will change.

We can use the HTML attributes to make our selectors more specific.


h1.title {

text-decoration: underline;

}

That CSS will affect only h1 tags that have a class attribute (this is what the dot means) with a value of title – like our HTML example above.

Finally, the “cascading” part means that we can cascade our selectors down into nested tags:


main strong {

color: red;

}

That selector would only affect strong elements that are contained inside of a main element.

Many different CSS selectors are available enabling you to apply styles to very specific elements – child elements, descendent elements, adjacent elements, and elements with specific attribute values.

CSS is technically optional – every browser has a set of default styles that get applied to different elements – but has become the fundamental method of styling a web page. Almost every single HTML document will be linked to an associated stylesheet that provides visual formatting, and many websites will have a single stylesheet to which every document is linked.

JavaScript

So far, HTML and CSS have simply allowed for the creation and visual styling of our documents. They are technically not programming languages. They allow for many quasi-programming concepts, but they don’t have full support for complete logical programming – things like variables, looping, and conditional statements. That’s where JavaScript comes in.

JavaScript is the programming language that executes in the browser, in the context of an HTML document.

Using JavaScript, we can manipulate our HTML document in real-time, while the user is looking at it.

For example:


var node = document.getElementById("title");

node.parentNode.removeChild(node);

When that code executes, it will find an HTML element identified by the name “title,” and delete it. It would disappear from the visual display of the document, in real-time. This code might execute in response to someone pushing a button, for example.

JavaScript operates on what’s called the Document Object Model (DOM). The DOM is the digital representation of a web page – all the elements, ordered and nested as they appeared in the HTML from which the document was loaded. To “manipulate the DOM” is to do things like in our example – add, delete, change, or otherwise fiddle around with elements of the DOM.

JavaScript began as a lightweight programming language meant for simple document actions. However, in the two decades since it was invented, it has become an enormously popular language, and has advanced to the point where an HTML document might simply be a shell designed to load and execute a complicated JavaScript program.

Multiple HTML documents can be linked to the same CSS and JavaScript which increase manageability

CSS and JavaScript Frameworks

CSS and JavaScript have become so indispensable that frameworks of pre-written code have developed around them to accomplish common tasks. Some frameworks are simple and designed merely to assist, while other frameworks are large libraries of code with associated philosophies and methodologies around their use.

The largest frameworks are so widely known that many front-end developers use them as a default for every new project. In fact, some developers might struggle to write code without them.

Some examples:

  • Bootstrap is a CSS framework designed by Twitter. It provides CSS that automatically attaches itself to HTML elements with specific attributes and handles such rote tasks and rendering them as columns which adapt to different screen sizes.

  • React is a JavaScript framework designed by Facebook. It allows a front-end developer to create complicated HTML structures in JavaScript code and makes them easier to manipulate when building complex applications.

  • JQuery is a JavaScript framework with associated CSS that eases many visual tasks like making elements appear, disappear, and animate.

Some frameworks are so widely-used that they spawn sub-frameworks or plugins. A front-end developer might use React and a dozen React extensions to change how it functions.


Templating and Design Components

HTML documents don’t normally exist as actual files anywhere. They’re usually assembled from fragments of HTML. You can envision it as a library of separate pieces that are mixed and matched to form a document.

Every website repeats a lot of stuff, visually. The only website that would have an entirely new and different layout on every page would almost have to be an art project of some kind. If you compare one page on a website to another, they might only differ by a heading, some images, and a few paragraphs of text.

Even when the actual content differs, the structure is the same. Consider a image carousel or rotater on the home page. Every frame or slide of that has the same basic structure – image, headline, maybe a few sentences of supporting text, and a link somewhere. The slide itself is a common structure, just with different content injected into it.

A web page divided up until different components which might be reused on multiple pages.

Therefore, one task of a front-end developer is to determine what the repeatable elements of the design are. The developer will view the entire design, note what elements repeat, and figure out how to draw those out into re-usable libraries of code, called design components

A design component is a combination of HTML elements that perform a visual purpose. These components can be duplicated and reused, rather than being recreated in every place they’re required.

An example might be this HTML construct:


<h1 class="header">

<img src="logo.jpg"/>

BigCo

<span class="tagline">Big and proud of it</span>

</h1>

That set of elements in that particular order might form the header for every page on your site. It would render the logo, the name of your company, and your tagline.

A goal of components is consistency and efficiency. You want this to look the same on every page, and you don’t want to re-code it every time. By identifying things like this as repeatable components, the front-end developer can employ techniques to “lift them out” of specific documents, maintain them separately, then "inject" them into documents that need them.

This assembling of documents from HTML fragments is a function of templating. Here are a few different ways this happens:

  • Server-Side Includes. Some tags or tag-like structures can be detected by the server when it’s reading the file to send the response. The server can replace those tags with the contents of other files. Thus, your header component could exist in its own file, and be injected into every document at the instant it’s being returned from the server. If it needs to change, it can be changed in a single file.

  • Server-Side Rendering Languages. Some full programming and templating languages exist that allow logical, procedural computer code to be interspersed with HTML. When the document is requested, this code is executed. It generates or hides HTML constructs in the document, meaning the document “writes itself” at the moment of response.

  • Client-side Templating. Using JavaScript frameworks like React, design components can be created in the browser, and they can populate the content around themselves by making special requests to the server.

Clearly, some of these are server-side technologies, which would imply a back-end developer. This is where the line gets a little blurry, because a front-end developer might work on server-side to generate the HTML that powers the front-end.

In all the cases above, the HTML document that finally displays in the browser doesn’t actually exist as a single file somewhere. It’s assembled from a series of design components, either on the server or in the browser. This rendering does two things:

  1. Generates HTML tags and elements

  2. Injects dynamic content into that HTML, often from a CMS

If this is done on the server, a full HTML document is delivered to the browser, and all the theatrics that happened on the server are hidden.

If it happens in the browser, the document is essentially a small computer program written in JavaScript that executes in the browser to create a new version of itself by manipulating the DOM.


Roles and DevOps

We’d like to say that we can totally encapsulate the front-end development to a single role, but in reality, your project will likely start proceeding along several tracks in parallel here.

Additionally, the role that actually does the front-end development is not a simple answer. Roles and lines will start to get blurry.

Here are a few common scenarios:

  • A front-end developer will code all the HTML, CSS, and JavaScript as a set of HTML documents, then hand them off to a back-end developer who converts them into templates in the CMS. This can be inefficient because the back-end developer has to translate what the front-end developer has done. And if a change is needed, the front-end developer has to change their files, and this has to be translated again.

  • A back-end developer will do the templating in the CMS to generate basic, generic HTML. The front-end developer will write CSS (“apply styles”) and JavaScript against this HTML, asking for changes to the HTML when needed. In this case, some of the front-end development (the HTML) is handled by the back-end developer, but this can work since the HTML is often non-debatable, and a development team might have conventions to ensure the front-end developer gets HTML they expect.

  • A front-end developer might be able to template in the CMS directly so they can generate their own HTML. This is very efficient, but some CMSs make it difficult because the templating can’t be separated from the rest of the code.

  • A front-end developer might do client-side templating in a JavaScript framework like React or Vue. In this case, they don’t need any server-side HTML. Rather, they make requests to special URLs on the server that provide content as pure data which they render to the screen using JavaScript to manipulate the DOM. In this scenario, the back-end developer just needs to make sure the server is returning the correct data.

  • A full-stack developer might do everything. This could be both efficient and inefficient – efficient because there’s no communication or dependencies required, but inefficient because one person can only do one thing at a time, so your project would have to proceed serially instead of in parallel. Once a project gets of a certain size, it can be tough to expect a single person to do everything.

Like we said, roles get a little blurry.

The examples above provide a helpful segue into the world of DevOps, which is short for “development operations.” This is the seemingly mundane but absolutely critical aspect of a project where you figure out how people are going to collaborate on the same code and software without getting in each other’s way.

When a project is big enough that it requires more than one person to write code, you run into coordination issues because the output of all those people has to be combined to form a single, cohesive project that gets deployed. If a front-end developer is writing CSS and JavaScript, their code needs to be combined with all the back-end code to be deployed to the production environment.

Additionally, some developers might require the output of other developers to do their jobs. If I’m a back-end developer working on some aspect of integration, I might need some of the templating code from a front-end developer. And some other people on the team might need my code to test or develop their stuff.

This combining of multiple code sources into a single thing is known as building. The result of a particular combination is called a build.

Code generally works its way through multiple environments before it finally gets deployed to the live, public environment.

  1. Developers will write code on their local workstation. This means they usually have an entire copy of the website running on their own computer. Often this requires them to install the complete technology stack – database, programing framework, CMS, etc.

  2. When their code seems to be running okay, they will submit it to a source code management (SCM) system, like Git or Subversion. These are systems that keep source code safe, and track all the different versions of it. Using an SCM, you can see exactly what changed in code and who changed it, which is helpful when trying to debug something. Additionally, the SCM becomes the central clearinghouse for code, from which developers will download each other’s code to update their environments.

  3. When code is submitted to an SCM, it will often trigger a script with automatically builds and deploys it to an integration environment. Just by submitting new code, an entire build of the website is deleted and rebuilt with the latest submitted code from everyone on the team. This is a concept known as continuous integration (CI) or continuous deployment (CD). If you have lots of developers writing and submitting code, your integration environment might get destroyed and rebuilt dozens of times a day. Developers can submit code, wait a minute for the build, then go check to make sure all their stuff worked with everyone else’s stuff. There also might be some automatic tests that run after building to check for problems.

  4. Every once in a while, the integration environment is be copied to a test environment. This is where the QA team will test all the features to make sure they work and often where the client will review the work product. The test environment is more stable than the integration environment, because it’s changed much less often. You might update the test environment from integration once a week, so it stays relatively stable.

  5. From test, code might be deployed to a staging or pre-production environment for final testing. Some organizations might have a battery of automatic tests that run in this environment, just to make sure no problems slipped through.

  6. From staging, code is deployed to the production environment, where it finally sees the light of day.

An example of a full deployment pipeline starting with multiple developers working on code locally and ending with deployment to production

Yes, code takes a long, winding road from the keyboard of a developer to a place where customers actually interact with it. This is often called a deployment pipeline, or CI/CD pipeline.

What we’ve described above is appropriate for a larger project with a larger team. A smaller project might be done by a single developer, in which case they might only have two steps: they write and test code on their local machine, and they deploy it to production.

They are two ends of the spectrum, and your project lies somewhere between them.


Other Concerns

In addition to evaluating the design for components and actually writing the code necessary to bring them to life, your front-end developer is juggling other concerns and responsibilities.

Browser Compatibility

There are lots of different browsers – Chrome, Firefox, Edge, Internet Explorer, Opera, Brave, etc. – and they’re not all equal. Occasionally, they do things a little bit differently – they might render an element in an odd way, or not support some new-fangled features of HTML or CSS.

This used to be very painful for developers, and there were notorious browsers that front-end developers had to make concessions for, sometimes to the point of coding entirely separate stylesheets just for them (we’re looking right at you, Internet Explorer 6.0). Today’s browsers, thankfully, support a more common set of features and capabilities.

When front-end developers test their code, they have to test in a variety of browser platforms, including many different versions of those platforms. Services even exist that will retrieve your web pages in different browsers and versions and then show a grid of images representing the result.

Remember from our discussion above that there’s one server, but an infinite number of browsers, each with their own quirks? A front-end developer has to find a happy medium that works for all of them.

Responsive Web Design

Responsive web design refers to techniques that enable a web page to change itself in response to the browser environment in which it’s loaded, primarily in relation to the size of the viewable area. A “full” browser experience on a desktop is very different than the tiny browser on a phone, and a web page can be developed to adapt to these differences.

This is accomplished mainly using a CSS tool called a media query. Media queries allow a separate set of CSS rules to apply only when the browser environment meets certain requirements, such as the size of the viewable area.

In this example, all images will appear on the right side of the screen, with text flowing around them. However, when the screen size falls below 500-pixels, three new CSS rules come into effect which will cause images to center themselves in the middle of the screen, with no text wrapping around them.


img {

float: right;

}

@media screen and (max-device-width: 500px) {

img {

float: none;

display: block;

margin: auto;

}

}

The 500-pixels in this example is known as a breakpoint, meaning it’s a threshold where new rules apply – a “breaking point” for the design to change. At what widths your front-end developer sets the breakpoints is up for debate, as is the number of breakpoints they respond to. You can define as many breakpoints as you like.

Here are some examples of screen size and variability – when the width of the browser rendering area falls below the pixel width listed, the design might change for that particular environment:

  • 320px: Phone in Portrait Mode

  • 480px: Phone in Landscape Mode

  • 640px: Tablet in Portrait Mode

  • 960px: Tablet in Landscape Mode

  • 1280px: Standard Full Browser

  • > 1280px: Wide Screen

For many developers, that’s too many. It’s quite common just to support three – phones, tablets, and full browsers. But your situation depends on your visitors and the complexity of your design.

Browser width is the most common usage consideration for responsive design, but media queries can act on any number of variables:

  • Resolution of the device (when Apple’s hi-res “retina” displays were new, some sites provided sharper images for browsers on those devices)

  • Aspect ratio of the device (the ratio of height to width)

  • Available color palette

  • Whether JavaScript is available

  • User preferences, such as if they have a setting to reduce motion (common for some users with vision or seizure disorders) or whether they want a high-contrast color scheme

  • If the web page is being printed or read aloud by a speech processor

Media queries have enabled web design to keep up with the relentless pace of new devices, brought about mainly by the revolution in mobile computing. When everyone viewed web pages on a full computer monitor, it was relatively easy for designers and developers to control that experience. Today, they can’t control anything, they can only respond and adapt to whatever environment they have.

Accessibility and General Usability

Accessibility is a set of practices and coding conventions that seek to provide equal access to the information in a web page, regardless of physical or cognitive abilities. Since most people are generally able-bodied, we tend to look at web pages through that perspective, and we don’t consider that other people might struggle to interact with them.

  • Some users have visibility issues, all the way up to total blindness. These users might need higher contrast, avoidance of certain color schemes, the ability to enlarge text size, or well-structured HTML that makes sense when it’s read aloud.

  • Some users cannot use a mouse, and have to navigate a web page by keyboard. The HTML needs to allow intelligent tabbing from one element to another and the option to skip over non-essential elements.

  • Some users have seizure disorders that might be triggered by certain movement or color changes.

Accessibility overlays a bit onto responsive design in that browsers are now providing settings to allow users to specify when they have accessibility needs, and CSS and JavaScript can request this information and use it to modify the layout and functioning of the page.

And, fittingly, accessibility overlays quite closely with general usability. A web page that’s difficult for someone with disabilities runs a very good chance of being difficult for lots of other people too. Conversely, an accessible page is likely also a very usable page overall.

Simply put: there is no one universal user. Every user exists on a spectrum of physical and cognitive abilities, and we can’t design pages solely for the most capable end of that spectrum.

Thankfully, accessibility is getting more and more attention lately as a wave of lawsuits are being served against egregiously offending websites. Entire consulting practices and services exist now to assist in identifying accessibility problems and providing solutions.

Performance

A lot of CSS and JavaScript will exist in separate files, and these files will need to be linked to the HTML document being rendered. In addition, all the images in a website likely exist in separate files. In some cases, dozens or even hundreds of supporting files might need to be downloaded just to display a single page of content.

This requires multiple connections and download time. These days, a web page is basically a computer program that has to be downloaded and executed by every user. Additionally, our HTML document might not be fully functional right away. The document might display itself, then, as different resources load, react to the information those resources provide or the functionality they dictate.

To avoid dragging down performance, there are a number of things a front-end developer might do:

  • Combine separate CSS or JavaScript files into a single file

  • Minify CSS or JavaScript, which means running an automated process to cut down the number of characters required to perform the needed work, reducing file size

  • Combine multiple smaller images into a single image palette, then use CSS to reveal different parts of that palette in different locations; images used in this way are known as sprites

  • Convert some images to inline formats like Scalable Vector Graphics (SVG) or Base64 data so they can embed directly in the HTML rather than being separate files

  • Code HTML, CSS, and JavaScript in a way to minimize screen re-painting as other resources load, to avoid the annoying “screen jump”

  • Optimize background or structural graphics to reduce file size

The goal is to provide the desired experience with as few file requests as possible, using the least number of bytes possible, and causing the least amount of disruption as resources are progressively loaded by the web page.


The role and responsibilities of front-end web developers have changed enormously over the last decade. Front-end code has transitioned from simple presentation into a full execution and development environment. Some of the most complicated code in your project might be in the combination of HTML, CSS, and JavaScript that executes in the user’s web browser.

Front-end developers have the additional challenge of coping with a variable environment of different browser brands and version, screen sizes, capabilities, connection speeds, and user abilities. Stability and predictability goes out the window. Their code has to be flexible and responsive, adapting to the environment.

It’s like trying to perform a ballet on the deck of a ship in a hurricane while balancing a house of cards on your nose. Consequently, front-end developers have moved from being basically non-existent as a distinct role to being hugely in-demand rock stars in the development world.

Front-end development is about concessions and striking a balance between hundreds of different factors. Be flexible, and understand that making things amazing for a small percentage of users is less valuable than making something beneficial for the overwhelming majority.

Inputs and Outputs

Before you can implement a design, you need one. The output of this process should be a set of files that represent the design in HTML, CSS, and JavaScript. Those files might be standalone, awaiting conversion to back-end code by another team (different development models were detailed in this chapter). In other cases, the files have templating code in them, or constitute an entire client-side application.

Either way, the output is code.

The Big Picture

By the time this happens, development is in full-swing. This is one of the two big categories of development, the other being the back-end, server-side development. Both of these tasks can usually proceed together, in parallel, and they often have to, as they inform and provide information to one another.

Staffing

This job has to be done by a developer. In some cases, this will be a dedicated front-end developer. Other times, a “full stack” developer might be working on the entire project, or a primarily back-end developer will do double-duty. Either way, the person who does this needs to know the basic tools: HTML, CSS, and JavaScript.

Resources

Articles

Books