Client-side tooling overview - Learn web development

Client-side tooling overview
============================

* Overview: Understanding client-side tools
* Next

In this article, we provide an overview of modern web tooling, what kinds of tools are available and where you'll meet them in the lifecycle of web app development, and how to find help with individual tools.

|  |  |
| --- | --- |
| Prerequisites: |
 Familiarity with the core HTML,
 CSS, and
 JavaScript languages.
  |
| Objective: |
 To understand what types of client-side tooling there are, and how to
 find tools and get help with them.
  |

Overview of modern tooling
--------------------------

Writing software for the web has become more sophisticated through the ages. Although it is still entirely reasonable to write HTML, CSS, and JavaScript "by hand" there is now a wealth of tools that developers can use to speed up the process of building a website, or app.

There are some extremely well-established tools that have become common "household names" amongst the development community, and new tools are being written and released every day to solve specific problems. You might even find yourself writing a piece of software to aid your own development process, to solve a specific problem that existing tools don't already seem to handle.

It is easy to become overwhelmed by the sheer number of tools that can be included in a single project. Equally, a single configuration file for a tool like Webpack can be hundreds of lines long, most of which are magical incantations that seem to do the job but which only a master engineer will fully understand!

From time to time, even the most experienced of web developers get stuck on a tooling problem; it is possible to waste hours attempting to get a tooling pipeline working before even touching a single line of application code. If you have found yourself struggling in the past, then don't worry — you are not alone.

In these articles, we won't answer every question about web tooling, but we will provide you with a useful starting point of understanding the fundamentals, which you can then build from. As with any complex topic, it is good to start small, and gradually work your way up to more advanced uses.

The modern tooling ecosystem
----------------------------

Today's modern developer tooling ecosystem is huge, so it's useful to have a broad idea of what main problems the tools are solving. If you jump on your favorite search engine and look for "front-end developer tools" you're going to hit a huge spectrum of results ranging from text editors, to browsers, to the type of pens you can use to take notes.

Though your choice of code editor is certainly a tooling choice, this series of articles will go beyond that, focusing on developer tools that help you produce web code more efficiently.

From a high-level perspective, you can put client-side tools into the following three broad categories of problems to solve:

* **Safety net** — Tools that are useful during your code development.
* **Transformation** — Tools that transform code in some way, e.g. turning an intermediate language into JavaScript that a browser can understand.
* **Post-development** — Tools that are useful after you have written your code, such as testing and deployment tools.

Let's look at each one of these in more detail.

### Safety net

These are tools that make the code you write a little better.

This part of the tooling should be specific to your own development environment, though it's not uncommon for companies to have some kind of policy or pre-baked configuration available to install so that all their developers are using the same processes.

This includes anything that makes your development process easier for generating stable and reliable code. Safety net tooling should also help you either prevent mistakes or correct mistakes automatically without having to build your code from scratch each time.

A few very common safety net tool types you will find being used by developers are as follows.

#### Linters

**Linters** are tools that check through your code and tell you about any errors that are present, what error types they are, and what code lines they are present on. Often linters can be configured to not only report errors, but also report any violations of a specified style guide that your team might be using (for example code that is using the wrong number of spaces for indentation, or using template literals rather than regular string literals).

ESLint is the industry standard JavaScript linter — a highly configurable tool for catching potential syntax errors and encouraging "best practices" throughout your code. Some companies and projects have also shared their ESLint configs.

You can also find linting tools for other languages, such as csslint.

Also well-worth looking at is webhint, a configurable, open-source linter for the web that surfaces best practices including approaches to accessibility, performance, cross-browser compatibility via MDN's browser compatibility data, security, testing for PWAs, and more. It is available as a Node.js command-line tool and a VS Code extension.

#### Source code control

Also known as **version control systems** (VCS), **source code control** is essential for backing work up and working in teams. A typical VCS involves having a local version of the code that you make changes to. You then "push" changes to a "master" version of the code inside a remote repository stored on a server somewhere. There is usually a way of controlling and coordinating what changes are made to the "master" copy of the code, and when, so a team of developers doesn't end up overwriting each other's work all the time.

Git is the source code control system that most people use these days. It is primarily accessed via the command line but can be accessed via friendly user interfaces. With your code in a git repository, you can push it to your own server instance, or use a hosted source control website such as GitHub, GitLab, or BitBucket.

We'll be using GitHub in this module. You can find more information about it at Git and GitHub.

#### Code formatters

Code formatters are somewhat related to linters, except that rather than point out errors in your code, they usually tend to make sure your code is formatted correctly, according to your style rules, ideally automatically fixing errors that they find.

Prettier is a very popular example of a code formatter, which we'll make use of later on in the module.

#### Bundlers/packagers

These are tools that get your code ready for production, for example by "tree-shaking" to make sure only the parts of your code libraries that you are actually using are put into your final production code, or "minifying" to remove all the whitespace in your production code, making it as small as possible before it is uploaded to a server.

Parcel is a particularly clever tool that fits into this category — it can do the above tasks, but also helps to package assets like HTML, CSS, and image files into convenient bundles that you can then go on to deploy, and also adds dependencies for you automatically whenever you try to use them. It can even handle some code transformation duties for you.

Webpack is another very popular packaging tool that does similar things.

### Transformation

This stage of your web app lifecycle typically allows you to code in either "future code" (such as the latest CSS or JavaScript features that might not have native support in browsers yet) or code using another language entirely, such as TypeScript. Transformation tools will then generate browser-compatible code for you, to be used in production.

Generally, web development is thought of as three languages: HTML, CSS, and JavaScript, and there are transformation tools for all of these languages. Transformation offers two main benefits (amongst others):

1. The ability to write code using the latest language features and have that transformed into code that works on everyday devices. For example, you might want to write JavaScript using cutting-edge new language features, but still have your final production code work on older browsers that don't support those features. Good examples here include:
    * Babel: A JavaScript compiler that allows developers to write their code using cutting-edge JavaScript, which Babel then takes and converts into old-fashioned JavaScript that more browsers can understand. Developers can also write and publish plugins for Babel.
    * PostCSS: Does the same kind of thing as Babel, but for cutting-edge CSS features. If there isn't an equivalent way to do something using older CSS features, PostCSS will install a JavaScript polyfill to emulate the CSS effect you want.
2. The option to write your code in an entirely different language and have it transformed into a web-compatible language. For example:
    * Sass/SCSS: This CSS extension allows you to use variables, nested rules, mixins, functions, and many other features, some of which are available in native CSS (such as variables), and some of which aren't.
    * TypeScript: TypeScript is a superset of JavaScript that offers a bunch of additional features. The TypeScript compiler converts TypeScript code to JavaScript when building for production.
    * Frameworks such as React, Ember, and Vue: Frameworks provide a lot of functionality for free and allow you to use it via custom syntax built on top of vanilla JavaScript. In the background, the framework's JavaScript code works hard to interpret this custom syntax and render it as a final web app.
### Post development

Post-development tooling ensures that your software makes it to the web and continues to run. This includes the deployment processes, testing frameworks, auditing tools, and more.

This stage of the development process is one that you want the least amount of active interaction with so that once it is configured, it runs mostly automatically, only popping up to say hello if something has gone wrong.

#### Testing tools

These generally take the form of a tool that will automatically run tests against your code to make sure it is correct before you go any further (for example, when you attempt to push changes to a GitHub repo). This can include linting, but also more sophisticated procedures like unit tests, where you run part of your code, making sure they behave as they should.

* Frameworks for writing tests include Jest, Mocha, and Jasmine.
* Automated test running and notification systems include Travis CI, Jenkins, Circle CI, and others.

#### Deployment tools

Deployment systems allow you to get your website published, are available for both static and dynamic sites, and commonly tend to work alongside testing systems. For example, a typical toolchain will wait for you to push changes to a remote repo, run some tests to see if the changes are OK, and then if the tests pass, automatically deploy your app to a production site.

Netlify is one of the most popular deployment tools right now, but others include Vercel and GitHub Pages.

#### Others

There are several other tool types available to use in the post-development stage, including Code Climate for gathering code quality metrics, the webhint browser extension for performing runtime analysis of cross-browser compatibility and other checks, GitHub bots for providing more powerful GitHub functionality, Updown for providing app uptime monitoring, and so many more!

### Some thoughts about tooling types

There's certainly an order in which the different tooling types apply in the development lifecycle, but rest assured that you don't *have* to have all of these in place to release a website. In fact, you don't need any of these. However, including some of these tools in your process will improve your own development experience and likely improve the overall quality of your code.

It often takes some time for new developer tools to settle down in their complexity. One of the best-known tools, Webpack, has a reputation for being overly complicated to work with, but in the latest major release, there was a huge push to simplify common usage so the configuration required is reduced down to an absolute minimum.

There's definitely no silver bullet that will guarantee success with tools, but as your experience increases you'll find workflows that work *for you* or for your team and their projects. Once all the kinks in the process are flattened out, your toolchain should be something you can forget about and it *should* just work.

How to choose and get help with a particular tool
-------------------------------------------------

Most tools tend to get written and released in isolation, so although there's almost certainly help available it's never in the same place or format. It can therefore be hard to find help with using a tool, or even to choose what tool to use. The knowledge about which are the best tools to use is a bit tribal, meaning that if you aren't already in the web community, it is hard to find out exactly which ones to go for! This is one reason we wrote this series of articles, to hopefully provide that first step that is hard to find otherwise.

You'll probably need a combination of the following things:

* Experienced teachers, mentors, fellow students, or colleagues that have some experience, have solved such problems before, and can give advice.
* A useful specific place to search. General web searches for front-end developer tools are generally useless unless you already know the name of the tool you are searching for.
    + If you are using the npm package manager to manage your dependencies for example, it is a good idea to go to the npm homepage and search for the type of tool you are looking for, for example try searching for "date" if you want a date formatting utility, or "formatter" if you are searching for a general code formatter. Pay attention to the popularity, quality, and maintenance scores, and how recently the package was last updated. Also click through to the tool pages to find out how many monthly downloads a package has, and whether it has good documentation that you can use to figure out whether it does what you need it to do. Based on these criteria, the date-fns library looks like a good date formatting tool to use. You'll see this tool in action and learn more about package managers in general in Chapter 3 of this module.
    + If you are looking for a plugin to integrate tool functionality into your code editor, look at the code editor's plugins/extensions page — see VSCode extensions, for example. Have a look at the featured extensions on the front page, and again, try searching for the kind of extension you want (or the tool name, for example search for "ESLint" on the VSCode extensions page). When you get results, have a look at information such as how many stars or downloads the extension has, as an indicator of its quality.
* Development-related forums to ask questions on about what tools to use, for example MDN Learn Discourse, or Stack Overflow.

When you've chosen a tool to use, the first port of call should be the tool project homepage. This could be a full-blown website or it might be a single readme document in a code repository. The date-fns docs for example are pretty good, complete, and easy to follow. Some documentation however can be rather technical and academic and not a good fit for your learning needs.

Instead, you might want to find some dedicated tutorials on getting started with particular types of tools. A great starting place is to search websites like CSS Tricks, Dev, freeCodeCamp, and Smashing Magazine, as they're tailored to the web development industry.

Again, you'll probably go through several different tools as you search for the right ones for you, trying them out to see if they make sense, are well-supported, and do what you want them to do. This is fine — it is all good for learning, and the road will get smoother as you get more experience.

Summary
-------

That rounds off our gentle introduction to the topic of client-side web tooling, from a high level. Next up we provide you with a crash course on the command line, which is where a lot of tooling is invoked from. We'll take a look at what the command line can do and then try installing and using our first tool.

* Overview: Understanding client-side tools
* Next


Deploying our app - Learn web development

Deploying our app
=================

* Previous
* Overview: Understanding client-side tools

In the final article in our series, we take the example toolchain we built up in the previous article and add to it so that we can deploy our sample app. We push the code to GitHub, deploy it using Netlify, and even show you how to add a simple test into the process.

|  |  |
| --- | --- |
| Prerequisites: |
 Familiarity with the core HTML,
 CSS, and
 JavaScript languages.
  |
| Objective: |
 To finish working through our complete toolchain case study, focusing on
 deploying the app.
  |

Post development
----------------

There's potentially a large range of problems to be solved in this section of the project's lifecycle. As such, it's important to create a toolchain that handles these problems in a way that requires as little manual intervention as possible.

Here's just a few things to consider for this particular project:

* Generating a production build: Ensuring files are minimized, chunked, have tree-shaking applied, and that versions are "cache busted".
* Running tests: These can range from "is this code formatted properly?" to "does this thing do what I expect?", and ensuring failing tests prevent deployment.
* Actually deploying the updated code to a live URL: Or potentially a staging URL so it can be reviewed first.

**Note:** Cache busting is a new term that we haven't met before in the module. This is the strategy of breaking a browser's own caching mechanism, which forces the browser to download a new copy of your code. Parcel (and indeed many other tools) will generate filenames that are unique to each new build. This unique filename "busts" your browser's cache, thereby making sure the browser downloads the fresh code each time an update is made to the deployed code.

The above tasks also break down into further tasks; note that most web development teams will have their own terms and processes for at least some part of the post-development phase.

For this project, we're going to use Netlify's wonderful static hosting offering to host our project. Netlify gives us hosting or more specifically, a URL to view your project online and to share it with your friends, family, and colleagues.

Deploying to hosting tends to be at the tail-end of the project life cycle, but with services such as Netlify bringing down the cost of deployments (both in financial terms and also the time required to actually deploy) it's possible to deploy during development to either share work in progress or to have a pre-release for some other purpose.

Netlify, amongst other things, also allows you to run pre-deployment tasks, which in our case means that all the production code build processes can be performed inside of Netlify and if the build is successful, the website changes will be deployed.

Although Netlify offers a drag and drop deployment service, we are intending to trigger a new deployment to Netlify each time we push to a GitHub repo.

It's exactly these kinds of connected services that we would encourage you to look for when deciding on your own build toolchain. We can commit our code and push to GitHub and the updated code will automatically trigger the entire build routine. If all is well, we get a live change deployed automatically. The *only* action we need to perform is that initial "push".

However, we do have to set these steps up, and we'll look at that now.

The build process
-----------------

Again, because we're using Parcel for development, the build option is extremely simple to add. Instead of running the server with `npx parcel src/index.html`, we can run it with `npx parcel build src/index.html` and Parcel will build everything ready for production instead of just running it for development and testing purposes. This includes doing minification and tree-shaking of code, and cache-busting on filenames.

The newly-created production code is placed in a new directory called `dist`, which contains *all* the files required to run the website, ready for you to upload to a server.

However, doing this step manually isn't our final aim — what we want is for the build to happen automatically and the result of the `dist` directory to be deployed live on our website.

This is where our code, GitHub, and Netlify need to be set up to talk to one another, so that each time we update our GitHub code repository, Netlify will automatically pick up the changes, run the build tasks, and finally release a new update.

We're going to add the build command to our `package.json` file as an npm script, so that the command `npm run build` will trigger the build process. This step isn't necessary, but it is a good best practice to get into the habit of setting up — across all our projects, we can then rely on `npm run build` to always do the complete build step, without needing to remember the specific build command arguments for each project.

1. Open the `package.json` file in your project's root directory, and find the `scripts` property.
2. We'll add a `build` command that we can run to build our code. Add the following line to your project now:

```json
"scripts": {
  // …
  "build": "parcel build src/index.html"
}
```

**Note:** If the `scripts` property already has a command inside it, put a comma at the end of it. Keep the JSON valid.
3. You should now be able to run the following command in the root of your project directory to run the production build step (first quit the running process with `Ctrl` + `C` if you need to):

```bash
npm run build
```

This should give you an output like the following, showing you the production files that were created, how big they are, and how long they took to build:

```bash
dist/src.99d8a31a.js.map       446.15 KB     63ms
dist/src.99d8a31a.js           172.51 KB    5.55s
dist/stars.7f1dd035.svg          6.31 KB    145ms
dist/asteroid2.3ead4904.svg      3.51 KB    155ms
dist/asteroid1.698d75e9.svg       2.9 KB    153ms
dist/src.84f2edd1.css.map        2.57 KB      3ms
dist/src.84f2edd1.css            1.25 KB    1.53s
dist/bg.084d3fd3.svg               795 B    147ms
dist/index.html                    354 B    944ms
```

Try it now!

For you to create your own instance of this project you will need to host this project's code in your own git repository. Our next step is to push the project to GitHub.

Committing changes to GitHub
----------------------------

This section will get you over the line to storing your code in a git repository, but it is a far cry from a git tutorial. There are many great tutorials and books available, and our Git and GitHub page is a good place to start.

We initialized our working directory as a git working directory earlier on. A quick way to verify this is to run the following command:

```bash
git status
```

You should get a status report of what files are being tracked, what files are staged, and so on — all terms that are part of the git grammar. If you get the error `fatal: not a git repository` returned, then the working directory is not a git working directory and you'll need to initialise git using `git init`.

Now we have three tasks ahead of us:

* Add any changes we've made to the stage (a special name for the place that git will commit files from).
* Commit the changes to the repository.
* Push the changes to GitHub.

1. To add changes, run the following command:

```bash
git add .
```

Note the period at the end, it means "everything in this directory". The `git add .` command is a bit of a sledgehammer approach — it will add all local changes you've worked on in one go. If you want finer control over what you add, then use `git add -p` for an interactive process, or add individual files using `git add path/to/file`.
2. Now all the code is staged, we can commit; run the following command:

```bash
git commit -m 'committing initial code'
```

**Note:** Although you're free to write whatever you wish in the commit message, there's some useful tips around the web on good commit messages. Keep them short, concise, and descriptive, so they clearly describe what the change does.
3. Finally, the code needs to be pushed to your GitHub-hosted repository. Let's do that now.
 Over at GitHub, visit https://github.com/new and create your own repository to host this code.
4. Give your repository a short, memorable name, without spaces in it (use hyphens to separate words), and a description, then click *Create repository* at the bottom of the page.
 You should now have a "remote" URL that points to your new GitHub repo.

 ![GitHub screenshot showing remote URLs you can use to deploy code to a GitHub repo](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Deployment/github-quick-setup.png)
5. This remote location needs to be added to our local git repository before we can push it up there, otherwise it won't be able to find it. You'll need to run a command with the following structure (use the provided HTTPS option for now — especially if you are new to GitHub — not the SSH option):

```bash
git remote add github https://github.com/yourname/repo-name.git
```

So if your remote URL was `https://github.com/remy/super-website.git`, as in the screenshot above, your command would be

```bash
git remote add github https://github.com/remy/super-website.git
```

Change the URL to your own repository, and run it now.
6. Now we're ready to push our code to GitHub; run the following command now:

```bash
git push github main
```

At this point, you'll be prompted to enter a username and password before Git will allow the push to be sent. This is because we used the HTTPS option rather than the SSH option, as seen in the screenshot earlier. For this, you need your GitHub username and then — if you do not have two-factor authentication (2FA) turned on — your GitHub password. We would always encourage you to use 2FA if possible, but bear in mind that if you do, you'll also need to use a "personal access token". GitHub help pages has an excellent and simple walkthrough covering how to get one.

**Note:** If you are interested in using the SSH option, thereby avoiding the need to enter your username and password every time you push to GitHub, this tutorial walks you through how.

This final command instructs git to push the code (aka publish) to the "remote" location that we called `github` (that's the repository hosted on github.com — we could have called it anything we like) using the branch `main`. We've not encountered branches at all, but the "main" branch is the default place for our work and it's what git starts on. It's also the default branch that Netlify will look for, which is convenient.

**Note:** Until October 2020 the default branch on GitHub was `master`, which for various social reasons was switched to `main`. You should be aware that this older default branch may appear in various projects you encounter, but we'd suggest using `main` for your own projects.

So with our project committed in git and pushed to our GitHub repository, the next step in the toolchain is to connect GitHub to Netlify so our project can be deployed live on the web!

Using Netlify for deployment
----------------------------

Deploying from GitHub to Netlify is surprisingly simple once you know the steps, particularly with "static websites" such as this project.

**Note:** There are also a lot of guides and tutorials on Netlify to help you improve your development workflow.

Let's get this done:

1. Go to https://app.netlify.com/start.
2. Press the GitHub button underneath the *Continuous Deployment* heading. "Continuous Deployment" means that whenever the code repository changes, Netlify will (try) to deploy the code, thus it being "continuous".

 ![netlify deployment options, as described in the surrounding text](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Deployment/netlify-deploy.png)
3. Depending on whether you authorized Netlify before, you might need to authorize Netlify with GitHub, and choose what account you want to authorize it for (if you have multiple GitHub accounts or orgs). Choose the one you pushed your project to.
4. Netlify will prompt you with a list of the GitHub repositories it can find. Select your project repository and proceed to the next step.
5. Since we've connected Netlify to our GitHub account and given it access to deploy the project repository, Netlify will ask *how* to prepare the project for deployment and *what* to deploy.
 You should enter the command `npm run build` for the *Build command*, and specify the `dist` directory for the *Publish directory* — this contains the code that we want to make public.
6. To finish up, click *Deploy site*.

 ![netlify distribution options, as described in the surrounding text](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Deployment/netlify-dist.png)
7. After a short wait for the deployment to occur, you should get a URL that you can go to, to see your published site — try it out!
8. And even better, whenever we make a change and *push* the change to our remote git repository (on GitHub), this will trigger a notification to Netlify which will then run our specified build task and then deploy the resulting `dist` directory to our published site.
 Try it now — make a small change to your app, and then push it to GitHub using these commands:

```bash
git add .
git commit -m 'simple netlify test'
git push github main
```

You should see your published site update with the change — this might take a few minutes to publish, so have a little patience.

That's it for Netlify. We can optionally change the name of the Netlify project or specify to use our own domain name, which Netlify offers some excellent documentation on.

Now for one final link in our toolchain: a test to ensure our code works.

Testing
-------

Testing itself is a vast subject, even within the realm of front-end development. I'll show you how to add an initial test to your project and how to use the test to prevent or to allow the project deployment to happen.

When approaching tests there are a good deal of ways to approach the problem:

* End-to-end testing, which involves your visitor clicking a thing and some other thing happening.
* Integration testing, which basically says "does one block of code still work when connected to another block?"
* Unit testing, where small and specific bits of functionality are tested to see if they do what they are supposed to do.
* And many more types. Also, see our cross browser testing module for a bunch of useful testing information

Remember also that tests are not limited to JavaScript; tests can be run against the rendered DOM, user interactions, CSS, and even how a page looks.

However, for this project we're going to create a small test that will check the third-party NASA data feed and ensure it's in the correct format. If not, the test will fail and will prevent the project from going live. To do anything else would be beyond the scope of this module — testing is a huge subject that really requires its own separate module. We are hoping that this section will at least make you aware of the need for testing, and will plant the seed that inspires you to go and learn more.

Although the test for this project does not include a test framework, as with all things in the front-end development world, there are a slew of framework options.

The test itself isn't what is important. What is important is how the failure or success is handled. Some deployment platforms will include a specific method for testing as part of their pipeline. Products like GitHub, GitLab, etc., all support running tests against individual commits.

As this project is deploying to Netlify, and Netlify only asks about the build command, we will have to make the tests part of the build. If the test fails, the build fails, and Netlify won't deploy.

Let's get started.

1. Go to your `package.json` file and open it up.
2. Find your `scripts` member, and update it so that it contains the following test and build commands:

```json
"scripts": {
  …
  "test": "node tests/\*.js",
  "build": "npm run test && parcel build src/index.html"
}
```

3. Now of course we need to add the test to our codebase; create a new directory in your root directory called tests:

```bash
mkdir tests
```

4. Inside the new directory, create a test file:

```bash
cd tests
touch nasa-feed.test.js
```

5. Open this file, and add the contents of nasa-feed.test.js to it:
6. This test uses the axios package to fetch the data feed we want to test; to install this dependency, run the following command:

```bash
npm install --save-dev axios
```

We need to manually install axios because Parcel won't help us with this dependency. Our tests are outside of Parcel's view of our system — since Parcel never sees nor runs any of the test code, we're left to install the dependency ourselves.
7. Now to manually run the test, from the command line we can run:

```bash
npm run test
```

The result, if successful, is … nothing. This is considered a success. In general, we only want tests to be noisy if there's something wrong. The test also exited with a special signal that tells the command line that it was successful — an exit signal of 0. If there's a failure the test fails with an exit code of 1 — this is a system-level value that says "something failed".
 The `npm run test` command will use node to run all the files that are in the tests directory that end with `.js`.
 In our build script, `npm run test` is called, then you see the string `&&` — this means "if the thing on the left succeeded (exited with zero), then do this thing on the right". So this translates into: if the tests pass, then build the code.
8. You'll have to upload your new code to GitHub, using similar commands to what you used before:

```bash
git add .
git commit -m 'adding test'
git push github main
```

In some cases you might want to test the result of the built code (since this isn't quite the original code we wrote), so the test might need to be run after the build command. You'll need to consider all these individual aspects whilst you're working on your own projects.

Now, finally, a minute or so after pushing, Netlify will deploy the project update. But only if it passes the test that was introduced.

Summary
-------

That's it for our sample case study, and for the module! We hope you found it useful. While there is a long way to go before you can consider yourself a client-side tooling wizard, we are hoping that this module has given you that first important step towards understanding client-side tooling, and the confidence to learn more and try out new things.

Let's summarize all the parts of the toolchain:

* Code quality and maintenance are performed by ESLint and Prettier. These tools are added as `devDependencies` to the project via `npm install --dev eslint prettier eslint-plugin-react` (the ESLint plugin is needed because this particular project uses React).
* There are two configuration files that the code quality tools read: `.eslintrc` and `.prettierrc`.
* During development, we use Parcel to handle our dependencies. `parcel src/index.html` is running in the background to watch for changes and to automatically build our source.
* Deployment is handled by pushing our changes to GitHub (on the "main" branch), which triggers a build and deployment on Netlify to publish the project. For our instance this URL is near-misses.netlify.com; you will have your own unique URL.
* We also have a simple test that blocks the building and deployment of the site if the NASA API feed isn't giving us the correct data format.

For those of you wanting a challenge, consider whether you can optimize some part of this toolchain. Some questions to ask yourself:

* Can images be compressed during the build step?
* Could React be swapped out for something smaller?
* Could you add more tests to prevent a bad build from deploying, such as performance audits?
* Could you set up a notification to let you know when a new deploy succeeded or failed?
* Previous
* Overview: Understanding client-side tools


Command line crash course - Learn web development

Command line crash course
=========================

* Previous
* Overview: Understanding client-side tools
* Next

In your development process, you'll undoubtedly be required to run some commands in the terminal (or on the "command line" — these are effectively the same thing). This article provides an introduction to the terminal, the essential commands you'll need to enter into it, how to chain commands together, and how to add your own command line interface (CLI) tools.

|  |  |
| --- | --- |
| Prerequisites: |
 Familiarity with the core HTML,
 CSS, and JavaScript languages.
  |
| Objective: | To understand what the terminal/command line is, what basic commands you should learn, and how to install new command line tools. |

Welcome to the terminal
-----------------------

The terminal is a text interface for executing text-based programs. If you're running any tooling for web development there's a near-guaranteed chance that you'll have to pop open the command line and run some commands to use your chosen tools (you'll often see such tools referred to as **CLI tools** — command line interface tools).

 A large number of tools can be used by typing commands into the command line; many come pre-installed on your system, and a huge number of others are installable from package registries.
 Package registries are like app stores, but (mostly) for command line based tools and software.
 We'll see how to install some tools later on in this chapter, and we'll learn more about package registries in the next chapter.

 One of the biggest criticisms of the command line is that it lacks hugely in user experience.
 Viewing the command line for the first time can be a daunting experience: a blank screen and a blinking cursor, with very little obvious help available on what to do.

 On the surface, they're far from welcoming but there's a lot you can do with them, and we promise that, with a bit of guidance and practice, using them will get easier!
 This is why we are providing this chapter — to help you get started in this seemingly unfriendly environment.

### Where did the terminal come from?

The terminal originates from around the 1950s-60s and its original form really doesn't resemble what we use today (for that we should be thankful). You can read a bit of the history on Wikipedia's entry for Computer Terminal.

Since then, the terminal has remained a constant feature of all operating systems — from desktop machines to servers tucked away in the cloud, to microcomputers like the Raspberry PI Zero, and even to mobile phones. It provides direct access to the computer's underlying file system and low-level features, and is therefore incredibly useful for performing complex tasks rapidly, if you know what you are doing.

It is also useful for automation — for example, to write a command to update the titles of hundreds of files instantly, say from "ch01-xxxx.png" to "ch02-xxxx.png". If you updated the file names using your finder or explorer GUI app, it would take you a long time.

Anyway, the terminal is not going away anytime soon.

### What does the terminal look like?

Below you can see some of the different flavors of programs that are available that can get you to a terminal.

The next images show the command prompts available in Windows — there's a good range of options from the "cmd" program to "powershell" — which can be run from the start menu by typing the program name.

![A vanilla windows cmd line window, and a windows powershell window](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/win-terminals.png)

And below, you can see the macOS terminal application.

![A basic vanilla macOS terminal](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/mac-terminal.png)

### How do you access the terminal?

Many developers today are using Unix-based tools (e.g. the terminal, and the tools you can access through it). Many tutorials and tools that exist on the web today support (and sadly assume) Unix-based systems, but not to worry — they are available on most systems. In this section, we'll look at how to get access to the terminal on your chosen system.

#### Linux/Unix

As hinted at above, Linux/Unix systems have a terminal available by default, listed among your Applications.

#### macOS

macOS has a system called Darwin that sits underneath the graphical user interface. Darwin is a Unix-like system, which provides the terminal, and access to the low-level tools. macOS Darwin mostly has parity with Unix, certainly good enough to not cause us any worries as we work through this article.

The terminal is available on macOS at Applications/Utilities/Terminal.

#### Windows

As with some other programming tools, using the terminal (or command line) on Windows has traditionally not been as simple or easy as on other operating systems. But things are getting better.

Windows has traditionally had its own terminal-like program called cmd ("the command prompt") for a long time, but this definitely doesn't have parity with Unix commands, and is equivalent to the old-style Windows DOS prompt.

Better programs exist for providing a terminal experience on Windows, such as Powershell (see here to find installers), and Gitbash (which comes as part of the git for Windows toolset).

However, the best option for Windows in the modern day is the Windows Subsystem for Linux (WSL) — a compatibility layer for running Linux operating systems directly from inside Windows 10, allowing you to run a "true terminal" directly on Windows, without needing a virtual machine.

This can be installed directly from the Windows store for free. You can find all the documentation you need in the Windows Subsystem for Linux Documentation.

![a screenshot of the Windows subsystem for Linux documentation](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/wsl.png)

In terms of what option to choose on Windows, we'd strongly recommend trying to install the WSL. You could stick with the default command prompt (`cmd`), and many tools will work OK, but you'll find everything easier if you have better parity with Unix tools.

#### Side note: what's the difference between a command line and a terminal?

Generally, you'll find these two terms used interchangeably. Technically, a terminal is a software that starts and connects to a shell. A shell is your session and session environment (where things like the prompt and shortcuts might be customized). The command line is the literal line where you enter commands and the cursor blinks.

### Do you have to use the terminal?

Although there's a great wealth of tools available from the command line, if you're using tools like Visual Studio Code there's also a mass of extensions that can be used as a proxy to use terminal commands without needing to use the terminal directly. However, you won't find a code editor extension for everything you want to do — you'll have to get some experience with the terminal eventually.

Basic built-in terminal commands
--------------------------------

Enough talk — let's start looking at some terminal commands! Out of the box, here are just a few of the things the command line can do, along with the names of relevant tools in each case:

* Navigate your computer's file system along with base-level tasks such as create, copy, rename, and delete:
    + Move around your directory structure: `cd`
    + Create directories: `mkdir`
    + Create files (and modify their metadata): `touch`
    + Copy files or directories: `cp`
    + Move files or directories: `mv`
    + Delete files or directories: `rm`
* Download files found at specific URLs: `curl`
* Search for fragments of text inside larger bodies of text: `grep`
* View a file's contents page by page: `less`, `cat`
* Manipulate and transform streams of text (for example changing all the instances of `<div>`s in an HTML file to `<article>`): `awk`, `tr`, `sed`

**Note:** There are a number of good tutorials on the web that go much deeper into the command line — this is only a brief introduction!

Let's move forward and look at using a few of these tools on the command line. Before you go any further, open your terminal program!

### Navigation on the command line

When you visit the command line you will inevitably need to navigate to a particular directory to "do something". All the operating systems (assuming a default setup) will launch their terminal program in your "home" directory, and from there you're likely to want to move to a different place.

The `cd` command lets you Change Directory. Technically, cd isn't a program but a built-in. This means your operating system provides it out of the box, and also that you can't accidentally delete it — thank goodness! You don't need to worry too much about whether a command is built-in or not, but bear in mind that built-ins appear on all unix-based systems.

To change the directory, you type `cd` into your terminal, followed by the directory you want to move to. Assuming the directory is inside your home directory, you can use `cd Desktop` (see the screenshots below).

![results of the cd Desktop command being run in a variety of windows terminals - the terminal location moves into the desktop](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/win-terminals-cd.png)

Try typing this into your system's terminal:

```bash
cd Desktop
```

If you want to move back up to the previous directory, you can use two dots:

```bash
cd ..
```

**Note:** A very useful terminal shortcut is using the `tab` key to autocomplete names that you know are present, rather than having to type out the whole thing. For example, after typing the above two commands, try typing `cd D` and pressing `tab` — it should autocomplete the directory name `Desktop` for you, provided it is present in the current directory. Bear this in mind as you move forward.

If the directory you want to go to is nested deep, you need to know the path to get to it. This usually becomes easier as you get more familiar with the structure of your file system, but if you are not sure of the path you can usually figure it out with a combination of the `ls` command (see below), and by clicking around in your Explorer/Finder window to see where a directory is, relative to where you currently are.

For example, if you wanted to go to a directory called `src`, located inside a directory called `project`, located on the `Desktop`, you could type these three commands to get there from your home folder:

```bash
cd Desktop
cd project
cd src
```

But this a waste of time — instead, you can type one command, with the different items in the path separated by forward slashes, just like you do when specifying paths to images or other assets in CSS, HTML, or JavaScript code:

```bash
cd Desktop/project/src
```

Note that including a leading slash on your path makes the path absolute, for example `/Users/your-user-name/Desktop`. Omitting the leading slash as we've done above makes the path relative to your present working directory. This is exactly the same as you would see with URLs in your web browser. A leading slash means "at the root of the website", whereas omitting the slash means "the URL is relative to my current page".

**Note:** On windows, you use backslashes instead of forward slashes, e.g. `cd Desktop\project\src` — this may seem really odd, but if you are interested in why, watch this YouTube clip featuring an explanation by one of Microsoft's Principal engineers.

### Listing directory contents

Another built-in Unix command is `ls` (short for list), which lists the contents of the directory you're currently in. Note that this won't work if you're using the default Windows command prompt (`cmd`) — the equivalent there is `dir`.

Try running this now in your terminal:

```bash
ls
```

This gives you a list of the files and directories in your present working directory, but the information is really basic — you only get the name of each item present, not whether it is a file or a directory, or anything else. Fortunately, a small change to the command usage can give you a lot more information.

### Introducing command options

Most terminal commands have options — these are modifiers that you add onto the end of a command, which make it behave in a slightly different way. These usually consist of a space after the command name, followed by a dash, followed by one or more letters.

For example, give this a go and see what you get:

```bash
ls -l
```

In the case of `ls`, the `-l` (*dash ell*) option gives you a listing with one file or directory on each line, and a lot more information shown. Directories can be identified by looking for a letter "d" on the very left-hand side of the lines. Those are the ones we can `cd` into.

Below is a screenshot with a "vanilla" macOS terminal at the top, and a customized terminal with some extra icons and colors to keep it looking lively — both showing the results of running `ls -l`:

![A vanilla macOS terminal and a more colorful custom macOS terminal, showing a file listing - the result of running the ls -l command](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/mac-terminals-ls.png)

**Note:** To find out exactly what options each command has available, you can look at its man page. This is done by typing the `man` command, followed by the name of the command you want to look up, for example `man ls`. This will open up the man page in the terminal's default text file viewer (for example, `less` in my terminal), and you should then be able to scroll through the page using the arrow keys, or some similar mechanism. The man page lists all the options in great detail, which may be a bit intimidating to begin with, but at least you know it's there if you need it. Once you are finished looking through the man page, you need to quit out of it using your text viewer's quit command ("q" in `less`; you may have to search on the web to find it if it isn't obvious).

**Note:** To run a command with multiple options at the same time, you can usually put them all in a single string after the dash character, for example `ls -lah`, or `ls -ltrh`. Try looking at the `ls` man page to work out what these extra options do!

Now that we've discussed two fundamental commands, have a little poke around your directory and see if you can navigate from one place to the next.

### Creating, copying, moving, removing

There are a number of other basic utility commands that you'll probably end up using quite a lot as you work with the terminal. They are pretty simple, so we won't explain them all in quite as much detail as the previous couple.

Have a play with them in a test directory you've created somewhere so that you don't accidentally delete anything important, using the example commands below for guidance:

* `mkdir` — this creates a new directory inside the current directory you are in, with the name you provide after the command name. For example, `mkdir my-awesome-website` will make a new directory called `my-awesome-website`.
* `rmdir` — removes the named directory, but only if it's empty. For example, `rmdir my-awesome-website` will remove the directory we created above. If you want to remove a directory that is not empty (and also remove everything it contains), then you can use the `-r` option (recursive), but this is dangerous. Make sure there is nothing you might need inside the directory later on, as it will be gone forever.
* `touch` — creates a new empty file, inside the current directory. For example, `touch mdn-example.md` creates a new empty file called `mdn-example.md`.
* `mv` — moves a file from the first specified file location to the second specified file location, for example `mv mdn-example.md mdn-example.txt` (the locations are written as file paths). This command moves a file called `mdn-example.md` in the current directory to a file called `mdn-example.txt` in the current directory. Technically the file is being moved, but from a practical perspective, this command is actually renaming the file.
* `cp` — similar in usage to `mv`, `cp` creates a copy of the file in the first location specified, in the second location specified. For example, `cp mdn-example.txt mdn-example.txt.bak` creates a copy of `mdn-example.txt` called `mdn-example.txt.bak` (you can of course call it something else if you wish).
* `rm` — removes the specified file. For example, `rm mdn-example.txt` deletes a single file called `mdn-example.txt`. Note that this delete is permanent and can't be undone via the recycle bin that you might have on your desktop user interface.

**Note:** Many terminal commands allow you to use asterisks as "wild card" characters, meaning "any sequence of characters". This allows you to run an operation against a potentially large number of files at once, all of which match the specified pattern. As an example, `rm mdn-*` would delete all files beginning with `mdn-`. `rm mdn-*.bak` would delete all files that start with `mdn-` and end with `.bak`.

Terminal — considered harmful?
------------------------------

We've alluded to this before, but to be clear — you need to be careful with the terminal. Simple commands do not carry too much danger, but as you start putting together more complex commands, you need to think carefully about what the command will do, and try testing them out first before you finally run them in the intended directory.

 Let's say you had 1000 text files in a directory, and you wanted to go through them all and only delete the ones that have a certain substring inside the filename. If you are not careful, then you might end up deleting something important, losing you a load of your work in the process.
 One good habit to get into is to write your terminal command out inside a text editor, figure out how you think it should look, and then make a backup copy of your directory and try running the command on that first, to test it.

Another good tip — if you're not comfortable trying terminal commands out on your own machine, a nice safe place to try them is over at Glitch.com. Along with being a great place to try out web development code, the projects also give you access to a terminal, so you can run all these commands directly in that terminal, safe in the knowledge that you won't break your own machine.

![a double screenshot showing the glitch.com home page, and the glitch terminal emulator](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/glitch.png)

A great resource for getting a quick overview of specific terminal commands is tldr.sh. This is a community-driven documentation service, similar to MDN, but specific to terminal commands.

In the next section let's step it up a notch (or several notches in fact) and see how we can connect tools together on the command line to really see how the terminal can be advantageous over the regular desktop user interface.

Connecting commands together with pipes
---------------------------------------

The terminal really comes into its own when you start to chain commands together using the `|` (pipe) symbol. Let's look at a very quick example of what this means.

We've already looked at `ls`, which outputs the contents of the current directory:

```bash
ls
```

But what if we wanted to quickly count the number of files and directories inside the current directory? `ls` can't do that on its own.

There is another Unix tool available called `wc`. This counts the number of words, lines, characters, or bytes of whatever is inputted into it. This can be a text file — the below example outputs the number of lines in `myfile.txt`:

```bash
wc -l myfile.txt
```

But it can also count the number of lines of whatever output is **piped** into it. For example, the below command counts the number of lines outputted by the `ls` command (what it would normally print to the terminal if run on its own) and outputs that count to the terminal instead:

```bash
ls | wc -l
```

Since `ls` prints each file or directory on its own line, that effectively gives us a directory and file count.

So what is going on here? A general philosophy of (unix) command line tools is that they print text to the terminal (also referred to "printing to standard output" or `STDOUT`). A good deal of commands can also read content from streamed input (known as "standard input" or `STDIN`).

The pipe operator can *connect* these inputs and outputs together, allowing us to build up increasingly more complex operations to suit our needs — the output from one command can become the input to the next command. In this case, `ls` would normally print its output to `STDOUT`, but instead `ls`'s output is being piped into `wc`, which takes that output as an input, counting the number of lines it contains, and prints that count to `STDOUT` instead.

A slightly more complex example
-------------------------------

Let's go through something a bit more complicated.

 We will first try to fetch the contents of MDN's "fetch" page using the `curl` command (which can be used to request content from URLs), from `https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch`.
 Try it now:

```bash
curl https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
```

 You won't get an output because the page has been redirected (to /Web/API/fetch).
 We need to explicitly tell `curl` to follow redirects using the `-L` flag.

Let's also look at the headers that `developer.mozilla.org` returns using `curl`'s `-I` flag, and print all the location redirects it sends to the terminal, by piping the output of `curl` into `grep` (we will ask `grep` to return all the lines that contain the word "location").

Try running the following (you'll see that there is just one redirect before we reach the final page):

```bash
curl https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch -L -I | grep location
```

Your output should look something like this (`curl` will first output some download counters and suchlike):

```bash
location: /en-US/docs/Web/API/fetch
```

 Although contrived, we could take this result a little further and transform the `location:` line contents, adding the base origin to the start of each one so that we get complete URLs printed out.
 For that, we'll add `awk` to the mix (which is a programming language akin to JavaScript or Ruby or Python, just a lot older!).

Try running this:

```bash
curl https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch -L -I | grep location | awk '{ print "https://developer.mozilla.org" $2 }'
```

Your final output should look something like this:

```bash
https://developer.mozilla.org/en-US/docs/Web/API/fetch
```

 By combining these commands we've customized the output to show the full URLs that the Mozilla server is redirecting through when we request the `/docs/Web/API/WindowOrWorkerGlobalScope/fetch` URL.
 Getting to know your system will prove useful in years to come — learn how these single serving tools work and how they can become part of your toolkit to solve niche problems.

Adding powerups
---------------

Now we've had a look at some of the built-in commands your system comes equipped with, let's look at how we can install a third-party CLI tool and make use of it.

 The vast ecosystem of installable tools for front-end web development currently exists mostly inside npm, a privately owned, package hosting service that works closely together with Node.js.
 This is slowly expanding — you can expect to see more package providers as time goes on.

Installing Node.js also installs the npm command line tool (and a supplementary npm-centric tool called npx), which offers a gateway to installing additional command line tools. Node.js and npm work the same across all systems: macOS, Windows, and Linux.

Install npm on your system now, by going to the URL above and downloading and running a Node.js installer appropriate to your operating system. If prompted, make sure to include npm as part of the installation.

![the Node.js installer on windows, showing the option to include npm](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/npm-install-option.png)

 Although we'll look at a number of different tools in the next article onwards, we'll cut our teeth on Prettier.
 Prettier is an opinionated code formatter that only has a "few options".
 Fewer options tends to mean simpler.
 Given how tooling can sometimes get out of hand in terms of complexity, "few options" can be very appealing.

### Where to install our CLI tools?

Before we dive into installing Prettier, there's a question to answer — "where should we install it?"

With `npm` we have the choice of installing tools globally — so we can access them anywhere — or locally to the current project directory.

There are pros and cons each way — and the following lists of pros and cons for installing globally are far from exhaustive.

**Pros of installing globally:**

* Accessible anywhere in your terminal
* Only install once
* Uses less disk space
* Always the same version
* Feels like any other unix command

**Cons of installing globally:**

* May not be compatible with your project's codebase
* Other developers in your team won't have access to these tools, for example if you are sharing the codebase over a tool like git.
* Related to the previous point, it makes project code harder to replicate (if you install your tools locally, they can be set up as dependencies and installed with `npm install`).

 Although the *cons* list is shorter, the negative impact of global installing is potentially much larger than the benefits.
 Here we'll install locally, but feel free to install globally once you understand the relative risks.

### Installing Prettier

Prettier is an opinionated code formatting tool for front-end developers, focusing on JavaScript-based languages and adding support for HTML, CSS, SCSS, JSON, and more.

Prettier can:

* Save the cognitive overhead of getting the style consistent manually across all your code files; Prettier can do this for you automatically.
* Help newcomers to web development format their code in best-practice fashion.
* Be installed on any operating system and even as a direct part of project tooling, ensuring that colleagues and friends who work on your code use the code style you're using.
* Be configured to run upon save, as you type, or even before publishing your code (with additional tooling that we'll see later on in the module).

For this article, we will install Prettier locally, as suggested in the Prettier installation guide

Once you've installed node, open up the terminal and run the following command to install Prettier:

```bash
npm install prettier
```

 You can now run the file locally using the npx tool.
 Running the command without any arguments, as with many other commands, will offer up usage and help information.
 Try this now:

```bash
npx prettier
```

Your output should look something like this:

```bash
Usage: prettier [options] [file/glob ...]

By default, output is written to stdout.
Stdin is read if it is piped to Prettier and no files are given.

…
```

 It's always worth at the very least skimming over the usage information, even if it is long.
 It'll help you to understand better how the tool is intended to be used.

**Note:** If you have not first installed Prettier locally, then running `npx prettier` will download and run the latest version of Prettier all in one go *just for that command*.
 While that might sound great, new versions of Prettier may slightly modify the output.
 You want to install it locally so that you are fixing the version of Prettier that you are using for formatting until you are ready to change it.

### Playing with Prettier

Let's have a quick play with Prettier, so you can see how it works.

First of all, create a new directory somewhere on your file system that is easy to find. Maybe a directory called `prettier-test` on your `Desktop`.

Now save the following code in a new file called `index.js`, inside your test directory:

```js
const myObj = {
a:1,b:{c:2}}
function printMe(obj){console.log(obj.b.c)}
printMe(myObj)
```

We can run Prettier against a codebase to just check if our code wants adjusting. `cd` into your directory, and try running this command:

```bash
npx prettier --check index.js
```

You should get an output along the lines of:

```bash
Checking formatting...
index.js
Code style issues found in the above file(s). Forgot to run Prettier?
```

So, there's some code styles that can be fixed. No problem. Adding the `--write` option to the `prettier` command will fix those up, leaving us to focus on actually writing useful code.

Now try running this version of the command:

```bash
npx prettier --write index.js
```

You'll get an output like this

```bash
Checking formatting...
index.js
Code style issues fixed in the above file(s).
```

But more importantly, if you look back at your JavaScript file you'll find it has been reformatted to something like this:

```js
const myObj = {
  a: 1,
  b: { c: 2 },
};
function printMe(obj) {
  console.log(obj.b.c);
}
printMe(myObj);
```

Depending on your workflow (or the workflow that you pick) you can make this an automated part of your process. Automation is really where tools excel; our personal preference is the kind of automation that "just happens" without having to configure anything.

With Prettier there's a number of ways automation can be achieved and though they're beyond the scope of this article, there's some excellent resources online to help (some of which have been linked to). You can invoke Prettier:

* Before you commit your code into a git repository using Husky.
* Whenever you hit "save" in your code editor, be it VS Code, or Sublime Text.
* As part of continuous integration checks using tools like GitHub Actions.

Our personal preference is the second one — while using say VS Code, Prettier kicks in and cleans up any formatting it needs to do every time we hit save. You can find a lot more information about using Prettier in different ways in the Prettier docs.

Other tools to play with
------------------------

If you want to play with a few more tools, here's a brief list that are fun to try out:

* `bat` — A "nicer" `cat` (`cat` is used to print the contents of files).
* `prettyping` — `ping` on the command line, but visualized (`ping` is a useful tool to check if a server is responding).
* `htop` — A process viewer, useful for when something is making your CPU fan behave like a jet engine and you want to identify the offending program.
* `tldr` — mentioned earlier in this chapter, but available as a command line tool.

Note that some of the above suggestions may need installing using npm, like we did with Prettier.

Summary
-------

That brings us to the end of our brief tour of the terminal/command line. Next up we'll be looking in more detail at package managers, and what we can do with them.

* Previous
* Overview: Understanding client-side tools
* Next


Introduction to HTML - Learn web development

Introduction to HTML
====================

At its heart, HTML is a language made up of elements, which can be applied to pieces of text to give them different meaning in a document (Is it a paragraph? Is it a bulleted list? Is it part of a table?), structure a document into logical sections (Does it have a header? Three columns of content? A navigation menu?), and embed content such as images and videos into a page. This module will introduce the first two of these and introduce fundamental concepts and syntax you need to know to understand HTML.

#### Looking to become a front-end web developer?

 We have put together a course that includes all the essential information you need to
 work towards your goal.

**Get started**

Prerequisites
-------------

Before starting this module, you don't need any previous HTML knowledge, but you should have at least basic familiarity with using computers and using the web passively (i.e., just looking at it and consuming content). You should have a basic work environment set up (as detailed in Installing basic software), and understand how to create and manage files (as detailed in Dealing with files). Both are parts of our Getting started with the web complete beginner's module.

**Note:** If you are working on a computer/tablet/other device where you don't have the ability to create your own files, you could try out (most of) the code examples in an online coding program such as JSBin or Glitch.

Guides
------

This module contains the following articles, which will take you through all the basic theory of HTML and provide ample opportunity for you to test out some skills.

Getting started with HTML

Covers the absolute basics of HTML, to get you started — we define elements, attributes, and other important terms, and show where they fit in the language. We also show how a typical HTML page is structured and how an HTML element is structured, and explain other important basic language features. Along the way, we'll play with some HTML to get you interested!

What's in the head? Metadata in HTML

The head of an HTML document is the part that **is not** displayed in the web browser when the page is loaded. It contains information such as the page `<title>`, links to CSS (if you want to style your HTML content with CSS), links to custom favicons, and metadata (data about the HTML, such as who wrote it, and important keywords that describe the document).

HTML text fundamentals

One of HTML's main jobs is to give text meaning (also known as semantics), so that the browser knows how to display it correctly. This article looks at how to use HTML to break up a block of text into a structure of headings and paragraphs, add emphasis/importance to words, create lists, and more.

Creating hyperlinks

Hyperlinks are really important — they are what makes the web a web. This article shows the syntax required to make a link and discusses best practices for links.

Advanced text formatting

There are many other elements in HTML for formatting text that we didn't get to in the HTML text fundamentals article. The elements here are less well-known, but still useful to know about. In this article, you'll learn about marking up quotations, description lists, computer code and other related text, subscript and superscript, contact information, and more.

Document and website structure

As well as defining individual parts of your page (such as "a paragraph" or "an image"), HTML is also used to define areas of your website (such as "the header", "the navigation menu", or "the main content column"). This article looks into how to plan a basic website structure and how to write the HTML to represent this structure.

Debugging HTML

Writing HTML is fine, but what if something goes wrong, and you can't work out where the error in the code is? This article will introduce you to some tools that can help.

Assessments
-----------

The following assessments will test your understanding of the HTML basics covered in the guides above.

Marking up a letter

We all learn to write a letter sooner or later; it is also a useful example to test out text formatting skills. In this assessment, you'll be given a letter to mark up.

Structuring a page of content

This assessment tests your ability to use HTML to structure a simple page of content, containing a header, a footer, a navigation menu, main content, and a sidebar.


HTML Cheat Sheet - Learn web development

HTML Cheat Sheet
================

While using HTML it can be very handy to have an easy way to remember how to use HTML tags properly and how to apply them. MDN provides you with an extended HTML documentation as well as a deep instructional HTML how-to. However, in many cases we just need some quick hints as we go. That's the whole purpose of the cheat sheet, to give you some quick accurate ready to use code snippets for common usages.

**Note:** HTML tags must be used for their semantic, not their appearance. It's always possible to totally change the look and feel of a given tag using CSS so, when using HTML, take the time to focus on the meaning rather than the appearance.

Inline elements
---------------

An "element" is a single part of a webpage. Some elements are large and hold smaller elements like containers. Some elements are small and are "nested" inside larger ones. By default, "inline elements" appear next to one another in a webpage. They take up only as much width as they need in a page and fit together horizontally like words in a sentence or books shelved side-by-side in a row. All inline elements can be placed within the `<body>` element.

Inline elements: usage and examples| Usage | Element | Example |
| --- | --- | --- |
| A link | `<a>` |
```html
<a href="https://example.org">
A link to example.org</a>.
```
 |
| An image | `<img>` |
```html
<img src="beast.png" width="50" />
```
 |
| An inline container | `<span>` |
```html
Used to group elements: for example,
to <span style="color:blue">style
them</span>.
```
 |
| Emphasize text | `<em>` |
```html
<em>I'm posh</em>.
```
 |
| Italic text | `<i>` |
```html
Mark a phrase in <i>italics</i>.
```
 |
| Bold text | `<b>` |
```html
Bold <b>a word or phrase</b>.
```
 |
| Important text | `<strong>` |
```html
<strong>I'm important!</strong>
```
 |
| Highlight text | `<mark>` |
```html
<mark>Notice me!</mark>
```
 |
| Strikethrough text | `<s>` |
```html
<s>I'm irrelevant.</s>
```
 |
| Subscript | `<sub>` |
```html
H<sub>2</sub>O
```
 |
| Small text | `<small>` |
```html
Used to represent the <small>small
print </small>of a document.
```
 |
| Address | `<address>` |
```html
<address>Main street 67</address>
```
 |
| Textual citation | `<cite>` |
```html
For more monsters,
see <cite>The Monster Book of Monsters</cite>.
```
 |
| Superscript | `<sup>` |
```html
x<sup>2</sup>
```
 |
| Inline quotation | `<q>` |
```html
<q>Me?</q>, she said.
```
 |
| A line break | `<br>` |
```html
Line 1<br>Line 2
```
 |
| A possible line break | `<wbr>` |
```html
<div style="width: 200px">
  Llanfair<wbr>pwllgwyngyllgogerychwyrngogogoch.
</div>
```
 |
| Date | `<time>` |
```html
Used to format the date. For example:
<time datetime="2020-05-24" pubdate>
published on 23-05-2020</time>.
```
 |
| Code format | `<code>` |
```html
This text is in normal format,
but <code>this text is in code
format</code>.
```
 |
| Audio | `<audio>` |
```html
<audio controls>
  <source src="https://interactive-examples.mdn.mozilla.net/media/cc0-audio/t-rex-roar.mp3" type="audio/mpeg">
</audio>

```
 |
| Video | `<video>` |
```html
<video controls width="250"
 src="https://archive.org/download/ElephantsDream/ed\_hd.ogv" >
  <a href="https://archive.org/download/ElephantsDream/ed\_hd.ogv">Download OGV video</a>
</video>
```
 |

Block elements
--------------

"Block elements," on the other hand, take up the entire width of a webpage. They also take up a full line of a webpage; they do not fit together side-by-side. Instead, they stack like paragraphs in an essay or toy blocks in a tower.

**Note:** Because this cheat sheet is limited to a few elements representing specific structures or having special semantics, the `div` element is intentionally not included — because the `div` element doesn't represent anything and doesn't have any special semantics.

| Usage | Element | Example |
| --- | --- | --- |
| A simple paragraph | `<p>` |
```html
<p>I'm a paragraph</p>
<p>I'm another paragraph</p>
```
 |
| An extended quotation | `<blockquote>` |
```html
They said:
<blockquote>The blockquote element indicates
an extended quotation.</blockquote>
```
 |
| Additional information | `<details>` |
```html
<details>
  <summary>Html Cheat Sheet</summary>
  <p>Inline elements</p>
  <p>Block elements</p>
</details>
```
 |
| An unordered list | `<ul>` |
```html
<ul>
  <li>I'm an item</li>
  <li>I'm another item</li>
</ul>
```
 |
| An ordered list | `<ol>` |
```html
<ol>
  <li>I'm the first item</li>
  <li>I'm the second item</li>
</ol>
```
 |
| A definition list | `<dl>` |
```html
<dl>
  <dt>A Term</dt>
  <dd>Definition of a term</dd>
  <dt>Another Term</dt>
  <dd>Definition of another term</dd>
</dl>
```
 |
| A horizontal rule | `<hr>` |
```html
before<hr>after
```
 |
| Text Heading | <h1>-<h6> |
```html
<h1> This is Heading 1 </h1>
<h2> This is Heading 2 </h2>
<h3> This is Heading 3 </h3>
<h4> This is Heading 4 </h4>
<h5> This is Heading 5 </h5>
<h6> This is Heading 6 </h6>
```
 |


Use HTML to solve common problems - Learn web development

Use HTML to solve common problems
=================================

The following links point to solutions to common everyday problems you'll need to solve with HTML.

### Basic structure

The most basic application of HTML is document structure. If you're new to HTML you should start with this.

* How to create a basic HTML document
* How to divide a webpage into logical sections
* How to set up a proper structure of headings and paragraphs
### Basic text-level semantics

HTML specializes in providing semantic information for a document, so HTML answers many questions you might have about how to get your message across best in your document.

* How to create a list of items with HTML
* How to stress or emphasize content
* How to indicate that text is important
* How to display computer code with HTML
* How to annotate images and graphics
* How to mark abbreviations and make them understandable
* How to add quotations and citations to web pages
* How to define terms with HTML
### Hyperlinks

One of the main reasons for HTML is making navigation easy with hyperlinks, which can be used in many different ways:

* How to create a hyperlink
* How to create a table of contents with HTML
### Images & multimedia

* How to add images to a webpage
* How to add video content to a webpage
### Scripting & styling

HTML only sets up document structure. To solve presentation issues, use CSS, or use scripting to make your page interactive.

* How to use CSS within a webpage
* How to use JavaScript within a webpage
### Embedded content

* How to embed a webpage within another webpage
Uncommon or advanced problems
-----------------------------

Beyond the basics, HTML is very rich and offers advanced features for solving complex problems. These articles help you tackle the less common use cases you may face:

### Forms

Forms are a complex HTML structure made to send data from a webpage to a web server. We encourage you to go over our full dedicated guide. Here is where you should start:

* How to create a simple Web form
* How to structure a Web form
### Tabular information

Some information, called tabular data, needs to be organized into tables with columns and rows. It's one of the most complex HTML structures, and mastering it is not easy:

* How to create a data table
* How to make HTML tables accessible
### Data representation

* How to represent numeric and code values with HTML — see Superscript and Subscript, and Representing computer code.
* How to use data attributes
### Advanced text semantics

* How to take control of HTML line breaking
* How to mark changes (added and removed text) — see the `<ins>` and `<del>` elements.
### Advanced images & multimedia

* How to add a responsive image to a webpage
* How to add vector image to a webpage
* How to add a hit map on top of an image
### Internationalization

HTML is not monolingual. It provides tools to handle common internationalization issues.

* How to add multiple languages into a single webpage
* How to display time and date with HTML
### Performance

* How to author fast-loading HTML pages


Multimedia and embedding - Learn web development

Multimedia and embedding
========================

We've looked at a lot of text so far in this course, but the web would be really boring only using text. Let's start looking at how to make the web come alive with more interesting content! This module explores how to use HTML to include multimedia in your web pages, including the different ways that images can be included, and how to embed video, audio, and even entire webpages.

#### Looking to become a front-end web developer?

 We have put together a course that includes all the essential information you need to
 work towards your goal.

**Get started**

Prerequisites
-------------

Before starting this module, you should have a reasonable understanding of the basics of HTML, as previously covered in Introduction to HTML. If you have not worked through this module (or something similar), work through it first, then come back!

**Note:** If you are working on a computer/tablet/other device where you don't have the ability to create your own files, you could try out (most of) the code examples in an online coding program such as JSBin or Glitch.

Guides
------

This module contains the following articles, which will take you through all the fundamentals of embedding multimedia on webpages.

Images in HTML

There are other types of multimedia to consider, but it is logical to start with the humble `<img>` element used to embed a simple image in a webpage. In this article we'll look at how to use it in more depth, including basics, annotating it with captions using `<figure>`, and how it relates to CSS background images.

Video and audio content

Next, we'll look at how to use the HTML `<video>` and `<audio>` elements to embed video and audio on our pages, including basics, providing access to different file formats to different browsers, adding captions and subtitles, and how to add fallbacks for older browsers.

From <object> to <iframe> — other embedding technologies

At this point we'd like to take somewhat of a sideways step, looking at a couple of elements that allow you to embed a wide variety of content types into your webpages: the `<iframe>`, `<embed>` and `<object>` elements. `<iframe>`s are for embedding other web pages, and the other two allow you to embed external resources such as PDF files.

Adding vector graphics to the Web

Vector graphics can be very useful in certain situations. Unlike regular formats like PNG/JPG, they don't distort/pixelate when zoomed in — they can remain smooth when scaled. This article introduces you to what vector graphics are and how to include the popular SVG format in web pages.

Responsive images

In this article, we'll learn about the concept of responsive images — images that work well on devices with widely differing screen sizes, resolutions, and other such features — and look at what tools HTML provides to help implement them. This helps to improve performance across different devices. Responsive images are just one part of responsive design, a future CSS topic for you to learn.

Assessments
-----------

The following assessment will test your understanding of the material covered in the guides above.

Mozilla splash page

In this assessment, we'll test your knowledge of some of the techniques discussed in this module's articles, getting you to add some images and video to a funky splash page all about Mozilla!

See also
--------

Add a hitmap on top of an image

Image maps provide a mechanism to make different parts of an image link to different places. (Think of a map linking through to further information about each different country you click on.) This technique can sometimes be useful.

Web literacy basics II

An excellent Mozilla foundation course that explores and tests some of the skills talked about in this *Multimedia and embedding* module. Dive deeper into the basics of composing webpages, designing for accessibility, sharing resources, using online media, and working open (meaning that your content is freely available and shareable by others).


HTML tables - Learn web development

HTML tables
===========

A very common task in HTML is structuring tabular data, and it has a number of elements and attributes for just this purpose. Coupled with a little CSS for styling, HTML makes it easy to display tables of information on the web such as your school lesson plan, the timetable at your local swimming pool, or statistics about your favorite dinosaurs or football team. This module takes you through all you need to know about structuring tabular data using HTML.

#### Looking to become a front-end web developer?

 We have put together a course that includes all the essential information you need to
 work towards your goal.

**Get started**

Prerequisites
-------------

Before starting this module, you should already have covered the basics of HTML — see Introduction to HTML.

**Note:** If you are working on a computer/tablet/other device where you don't have the ability to create your own files, you could try out (most of) the code examples in an online coding program such as JSBin or Glitch.

Guides
------

This module contains the following articles, which will take you through all the fundamentals of creating tables in HTML.

HTML table basics

This article gets you started with HTML tables, covering the very basics such as rows and cells, headings, making cells span multiple columns and rows, and how to group together all the cells in a column for styling purposes.

HTML table advanced features and accessibility

This article looks at some more advanced features of HTML tables — such as captions/summaries and grouping your rows into table head, body and footer sections — as well as looking at the accessibility of tables for visually impaired users.

Assessments
-----------

The following assessment will test your understanding of the HTML table techniques covered in the guides above.

Structuring planet data

In our table assessment, we provide you with some data on the planets in our solar system, and get you to structure it into an HTML table.