Front-end skills to become a pro
In the previous section, I briefly introduced the most essential concepts and tools any web developer needs to be familiar with.
In this section, I’ll introduce the tools professional front-end developers use in their daily development workflow.
Photo by cottonbro (remixed) from Pexels
Using these tools will save you plenty of time and increase your chance of finding a spot in a development team.
Are you ready to become a pro?
Let’s go!
CSS preprocessors
One of the tools front-end developers use daily is a CSS preprocessor.
A CSS preprocessor, also known as a CSS interpreter, helps you write CSS more easily with the help of features that do not exist in standard CSS.
These features do not change how CSS works but only simplify writing CSS.
As a front-end developer, you usually use a preprocessor to write CSS styles instead of writing your styles with standard CSS.
The main benefit of a CSS preprocessor is code reusability.
But what does it mean?
It’s easier to explain it with an example.
First, I write a couple of CSS rules with standard CSS, then I’ll rewrite it with a Sass, which is a popular CSS preprocessor:
.button { background: #882bff; color: #fff;}
.button–outlined { border: #882bff; color: #882bff;}
In the above snippet, #882bff is a hexadecimal code, which has been repeated three times.
This means if you decide to change the color, you’ll have to update every single instance across all your styles.
Now, let’s rewrite it with a Sass:
$buttonColor: #882bff;
.button {
background: $buttonColor;
color: #fff;
}
.button–outlined {
border: $buttonColor;
color: $buttonColor;
}
As you can see, in the Sass approach, we used a variable named $buttonColor.
By storing the color code in a variable, we’d just have to update this variable if we ever decide to change the color.
CSS preprocessors help us not end up with giant CSS files.
The most popular CSS preprocessors are Sass, LESS, and Stylus.
CSS styles written by the preprocessor are slightly different from the standard CSS.
That being said, to use your styles, you need to compile them to CSS first.
Compiling is the process of converting a computer code written in one programming language to another language. For example, C++ code to an executable format, or a Sass to standard CSS.
BEM and ABEM
Choosing names for CSS selectors might become a hassle over time, as you’ll have plenty of rule sets to name and remember.
The CSS community has adapted some naming conventions to tackle this problem.
BEM (Block Element Modifier) or its enhanced version ABEM (Atomic BEM) are the two popular naming conventions adopted by the CSS community.
So if you ever feel naming your selectors is becoming a problem, you know what to look for.
JavaScript frameworks
Frontend developers usually use a framework to make complex websites or web applications.
Just like JavaScript libraries, JavaScript frameworks are pre-made JavaScript codes for easier app development.
JavaScript frameworks are different from JavaScript libraries, though.
JavaScript libraries are in the form of reusable units of code that you use alongside your code.
However, a JavaScript framework defines the entire application architecture.
A framework is the skeleton of your JavaScript application and your code extends its functionality – shaping it to your application.
When you start using a JavaScript framework, you’ll have to play by its architectural rules.
In return, it’ll help you concentrate more on your product’s value than its implementation.
- Data interpolation (inserting dynamic data in your HTML page)
- Event management (like when users click on a button or submit a form)
- State management (keep track of every piece of data your application uses during runtime)
- Routing (showing different pages per URL)
- Custom HTML elements
- And more.
The most popular frameworks in the JavaScript ecosystem are React.js, Vue.js, and Angular.
Even though React doesn’t claim to be a framework, many front-end developers use it to make various web applications and websites.
Vue.js is the youngest of all and has been gaining popularity among many front-end and back-end developers.
If you’re wondering which framework to choose, I suggest you give Vue.js a ride.
How about vanilla JavaScript people talk about
Vanilla JavaScript means pure JavaScript code without any libraries or frameworks.
Photo by Pixabay (remixed) from Pexels
Sometimes loading a 100kb library on your page – just to call a couple of its functions – isn’t necessary.
In many cases, you can achieve the same results with minimal effort in standard JavaScript.
Why is learning vanilla JavaScript essential?
If you get too dependent on a framework (or library) and forget about the language itself, a “major” update of your favorite framework (or library) might pour your “knowledge” down the drain.
- Pick up new JavaScript libraries and frameworks more quickly
- Debug defected software more quickly – especially when you use a sophisticated framework
- Know when to use a framework or library and when not to
- Be more creative and come up with efficient alternatives, rather than just using pre-made code.
What is Node.js?
Node.js is a JavaScript run-time environment equipped with a V8 JavaScript engine.
What’s a run-time environment? You may ask.
A run-time environment is a program that executes other programs.
A web browser is a run-time environment, so is Node.js.
And needless to say, both have a JavaScript engine.
Node.js enables web developers to use JavaScript for back-end development too.
Using the same language for back-end and front-end development makes your life much easier (especially if you’re doing both yourself).
What Is asynchronous I/O
There are times you might hear people say Node.js has an event-driven architecture with asynchronous I/O.
But what does it mean?
Let’s decode it.
As I mentioned earlier, I/O (Input/Output) is the data exchange between a computer and the outside world.
This data exchange could be between you and your web browser.
There’s a problem with I/O operations, though.
They are very slow compared to the CPU!
CPUs use electric current to operate, while I/O devices might involve mechanical movements, such as a hard disk drive’s head.
Also, there are times when the I/O has to be made over the network to communicate with another system. This type of I/O is called network I/O.
Network I/O is the type of I/O we use a lot in JavaScript-based web apps.
But why should we care?
During I/O, the faster end (the CPU) always has to wait for the slower end (the I/O device).
And that wastes a lot of CPU time.
There are solutions to this problem.
Computer programs perform I/O in two ways: Synchronous I/O and Asynchronous I/O.
In Synchronous I/O, the program stops running while I/O is in progress. For instance, it has to wait until it receives a response from an API.
On the other hand, the program remains paused until it can confirm the I/O was successful.
After that, it’ll resume the execution.
That might make users crazy!
In Asynchronous I/O, however, the I/O operation is started, but the program execution is continued (while I/O is still in progress).
But how do we know if the I/O was successful so that we can take the necessary action? Like displaying the content or notifying the user that the operation was successful.
Here’s how it works:
In Asynchronous I/O, the programmer associates a piece of code to each I/O operation.
This piece of code is called a callback.
Here’s an example of a network I/O (fetching something from an API) and a callback:
// Fetching the list of movies from an API (network I/O)
fetch(‘http://example.com/movies.json’)
.then(
// this is the callback executed when
//the API returns a response:
response => response.json()
)
Once a particular I/O operation is completed, the program executes its associated callback.
This approach is significantly helpful when a program depends on many I/O operations, as it lets the program continue running while I/O is in progress.
JavaScript programs usually contain many I/O operations (especially network I/O) and, of course, many callbacks.
NPM (Node Package Manager)
NPM is a package manager for JavaScript, and it’s the default package manager for Node.js too.
A package manager is a program used to install JavaScript libraries. It’s like the App Store and Google Play Store.
JavaScript libraries are also called JavaScript packages.
Before getting onto the JavaScript packages, let’s define what a module is in programming.
In simple terms, a module is a reusable piece of code stored in a file.
You usually import and use modules in your code.
A JavaScript package is a directory of modules accompanied by a manifest file, called package.json.
JavaScript developers publish their open-source libraries as packages on a registry such as NPM.
A package.json file is a plain-text file that contains information about the package, such as the author, dependencies (if it depends on other modules), etc.
NPM automates the installation of JavaScript packages via its command-line program: npm.
When you install Node.js on your computer, the node.js installer installs NPM too.
Without a package manager, you’d have to download and unzip a file and all its dependencies yourself.
NPM’s online database, known as the npm registry, hosts thousands of useful JavaScript packages.
npm CLI tool uses package.json to download and install a JavaScript package from the registry.
That said, all packages on the npm registry should have a package.json file.
When you want to use a library, you install it via npm:
npm install package-name@version
Here’s an example:
npm install vue@next
The above npm command downloads the package and every package it depends on.
npm stores installed packages in a directory called node_modules under your project’s directory.
In the above example, we installed the latest version of Vue.js in our project’s node_modules directory.
Anytime, you need to use that module in your code, you simply import it from the node_modules directory.
I know you might be asking, ok, how should I do the import anyway?
Worry not.
Every package you want to use in the future has clear-cut instructions on how to install and import its modules.
And after a while, it becomes a normal routine.
For now, just knowing about package managers is enough.
Remember: No vetting process takes place when a package is published to the npm registry. This means packages on npm can be low in quality, unreliable, or even malicious.
However, like any other open-source code, you can judge its credibility based on several factors, such as the number of installs, the recent update time, and the number of packages depending on it.
NPM isn’t the only package manager for JavaScript apps, though.
Yarn is also a popular package manager, which does the same thing as npm.
TypeScript
TypeScript is a programming language developed by Microsoft. It is the syntactical superset of JavaScript.
It means JavaScript code is valid TypeScript code, but TypeScript has static typing too.
On the other hand, TypeScript is JavaScript with superpowers.
Static typing is a programming feature used to ensure the programmer doesn’t make data-related mistakes while programming.
For instance, when she unintentionally assigns a numeric value to a variable, which stores a string.
Even though these mistakes are unintentional, they make the program deliver unexpected results when it’s live.
Being a loosely-typed language, JavaScript doesn’t check for these mistakes and obviously won’t complain about them.
TypeScript, however, is more strict and guarantees that these sorts of mistakes never happen.
For instance, this is what happens if you make a data-related mistake in TypeScript:
TypeScript to JavaScript is like what Sass is to CSS; It doesn’t change how JavaScript works, but it helps the programmer write reliable JavaScript code.
Many teams use TypeScript to write their JavaScript apps.
TypeScript has to be compiled to standard JavaScript eventually because browsers can only run JavaScript code.
The compilation process is done during build time with the help of the module bundler program. We’ll get to it shortly.
Depending on your team’s preferred technology stack, you might have to learn and use TypeScript in your projects.
Build automation tools
Before the popularity of modern front-end technologies, most front-end developers used core web technologies to build their websites and web apps.
CSS and JavaScript files were saved as plain-text files, loaded into an HTML page, and that was it.
No preprocessor, no modules, no compilation were required at the time.
But things are different now.
In modern development workflows, there are always extra steps to take before you have a working web page.
For example, if you use TypeScript, you’ll have to convert it to standard JavaScript first.
Or if your JavaScript code is written based on the ES6 specification, you’ll have to make sure older browsers can run your code.
Another thing is if you’re using multiple JavaScript packages in your node_modules directory, you’ll have to combine them into a bundle (single file) so you won’t have to include fifty files on your web page in the correct order!
This preparation process is called software build or the building process.
The building process isn’t limited to bundling or transpiling, though.
- Running tests
- Linting
- Minification
- Tree shaking
- Environment setup
- Generating config files
And everything else required to run your software
The burden associated with these operations inspired the creation of build automation tools, such as task runners and module bundlers.
Imagine you run the following command in the command line:
$ npm run build
And a queue of complicated and tedious tasks is taken care of in a few seconds.
How cool is that?
Module bundlers
In simple terms, a bundle is a single file made by combining multiple files.
A module bundler (a.k.a package bundler) is a tool that collects multiple JavaScript files, modules, libraries, runs them through certain transformations (that you define), and combines them into a single file – called a bundle.
Why would you need a bundler?
Your code usually depends on multiple third-party modules (installed with npm or yarn).
And to make your code work, you need to load all of them on your page in the correct order!
Loading a dozen JavaScript files on a page is an error-prone and tedious job.
When you have a JavaScript bundle, you only have to deal with only one file.
An additional bonus is that your browser will have to make just one request to fetch your JavaScript file – less load on the server.
The most popular module bundlers in the market are Webpack, Parcel, Rollup, and Browserfiy.
Using a module bundler is a must in today’s web development workflows.
Installing and configuring a module bundler is one of the first things you do when starting a project.
All module bundlers have a configuration file where you define all the bundling configurations you need.
For example, this is a simple Webpack configuration file, which bundles /src/index.js with all its dependencies into a single file named bundle.js and stores it in a directory named dist.
path = require(‘path’)
module.exports = {
entry: ‘./src/index.js’,
output: {
path: path.resolve(__dirname, ‘dist’),
filename: ‘bundle.js’,
}
}
Task runners
Task runners are automation tools that do your tasks automatically, so you won’t have to.
These tasks can be anything you would have to do manually while making software, such as running tests, generating config files, linting scripts, etc.
The most prominent task runners in the market are Grunt and Gulp.
Even though you can use a module bundler with your task runner, you usually end up using a module bundler in most cases.
A module bundler with custom npm scripts can give you the best of both worlds.
What is Babel?
Babel is an open-source JavaScript transcompiler used to convert modern JavaScript code to a backward-compatible equivalent.
What’s a transcompiler anyway? You may ask.
A transcompiler, also known as transpiler or source-to-source translator, is a computer program that translates your code into an equivalent code – in the same or a different programming language.
One use case is to transpile a modern syntax into an older syntax to support all environments – especially for JavaScript code.
Why do we do this?
We usually use JavaScript transpilers to make the code backward-compatible so older browsers can run it too.
For example, if you write a JavaScript program based on ES7 specifications (ECMAScript 2017), older versions of web browsers might not be able to run your code correctly.
With babel, you can fix that.
Babel automatically makes your code backward-compatible, so you won’t have to do it yourself.
Babel uses polyfills to do its job.
A polyfill is a piece of code that makes up for a missing feature in a web browser.
Babel, add necessary polyfills to your code to ensure it will work even if the target browser lacks modern features.
You can configure Babel to use certain polyfills based on the modern browser features your code needs.
Or you can use a preset, which contains the most common polyfills for a particular use case.
The following code is from Babel’s documentation, showing how it transpiles ES6 code into the older ES5:
// Babel Input: ES2015 arrow function
[1, 2, 3].map((n) => n + 1);
// Babel Output: ES5 equivalent
[1, 2, 3].map(function(n) { return n + 1;});
You usually use Babel via your module bundler program.
For instance, if you use Webpack as your module bundler, you add babel configuration in your Webpack’s config file.
Never miss a guide like this!
Disclaimer: This post may contain affiliate links. I might receive a commission if a purchase is made. However, it doesn’t change the cost you’ll pay.