DEV Community: Brian Emilius

The ExpressJS Router

Brian Emilius — Wed, 18 Mar 2020 10:33:23 +0000

This article was originally published on www.brianemilius.com/the-express-router.
Visit www.brianemilius.com for more content.

ExpressJS is probably the most popular framework for creating server-side web applications in Node.js.
In this blog series I want to show you how to get started and how to do it The Right Way™.

Articles in this series so far

Upcomming articles:

ExpressJS Template Engines
ExpressJS Middleware
How To Parse Content From Forms With ExpressJS

Prerequisites

Basic knowledge of Node.js and npm
Some intermediate JavaScript knowledge
Basic HTML and CSS
It's a good idea to have read the previous posts in this series.

Intro

I've written about the very basics of ExpressJS and how to build a solid project structure that scales. In this article we'll take a look at the Router and what we can do with it.

What Even Is Routing?

The basic idea of routing in web applications is to make sure a request is directed to the correct resource and the correct functionality.

Any request to a web application is made with the HTTP-protocol.

When a server receives a HTTP request from a client it looks at the path, the query, and the fragment part of the request, as well as the HTTP method with which the request was made.

The server then decides what to do with this request - how to treat it. This is what the router does.

Once the router has delegated the request to the proper resource, the server sends a response back to the client.

The Express Router

This brings us to the router functionality in Express. A very basic router function could look something like this:

router.get("/profile", function(request, response) {
    // ... treat the request
    response.send("Welcome to your profile"); // send a response
});

Let's break this down.

router.get determines which HTTP method the router should capture. HTTP methods are a part of the HTTP specification and are meant to convey what a request wishes to do:

GET is for retrieving a resource. Every time you enter a URL in your browser and hit enter you effectively create a GET request. This is the most common method.
POST is for creating a resource.
DELETE is for deleting a resource.
PUT and PATCH are for updating resources, but they do it differently from each other; PUT replaces the resource to be updated entirely, while PATCH updates only parts of the resource to be updated.

You know two of these methods from HTML-forms.

Next is "/profile". This is the HTTP request path, query, and fragment part. Here we tell the router which "resource" on the server the router should work for. There are several things we can do with this, which I will get into later in this article. The path basically means that we can type in http://mydomain.com/profile in the browser, and this will trigger the above router function.

Lastly, the callback function:

function(request, response) {
    // ... code
}

This is what is called a middleware function in the Express framework. It takes as a minimum 2 arguments; Request, and Response.

Requests and responses always contain a header and a body. The header deals with meta-information about the request or response, and the body is the actual contents of the request or the response.

The Request object contains all relevant information about the request, and the Response object the same, but for the response.

You can console.log the two to see exactly what they contain.

What We Can do With The Router

The router function is a very flexible tool that lets you capture requests to the server, to server resources, and it can sort through the HTTP request methods used - as I explained above. But we can digest requests even further, looking at pre-defined parameters or query strings.

Parameters

app.get("/product/:id", function(request, response) {
    response.send("You requested a product with the ID: " + request.params.id);
});

A parameter is defined in the route resource string with a colon prefix :id. You can reference it inside your router callback function in the request object.

If there are any parameters defined, the request object will have an object named params.

This means, that if you defined a parameter as :id, you can access it with request.params.id.

Query Strings

Query strings are often used to add modifications to a resource request. A very common use-case is pagination:

app.get("/products?page=2", function(request, response) {
    response.send("You requested to see page: " + request.query.page);
});

As with parameters, query strings are defined in the route resource string as you would a common query string ?page=1. If you need more query string variables you can separate them with a & ?page=1&limit=10.

And, as with parameters, you can access the query string variables in the request object request.query.page and request.query.limit.

What Is The Difference?

Well, I would say parameters are used for making pretty URLs, such as https://mywebsite.com/products/42, and query string variables should be used for search strings, and modifications such as page number, limits, language localization, etc.

RegExp

You can even define your route resource string as a regular expression!

app.get(/a/, function(request, response) {
    // treat the request ...
    response.send("This route captures all resources that has an 'a' in it.");
});

Middleware

Remember how I said that the router callback function is what we call a middleware function in Express?

A middleware function is basically a function that can access the request and response object. But there is one more, which is important to know about: next.

A true Express middleware function has all 3 objects as parameters:

function myMiddlewareFunction(request, response, next) {
    // treat the request ...
    // ...
    // provide either a
    response.send("Hello, World!");
    // or a 
    next();
}

The response.send() method sends headers and a response body to the client. This basically ends the response, and no more headers can be sent after this.

But if we instead use the next() callback function, we send the request on to the next middleware function down the line.

What does this mean? Well, you can, in fact, have as many middleware functions in a route as you wish.

function myFirstMiddleware(request, response, next) {
    if (request.headers.authorization !== "Bearer 123456789") {
        response.status(401);
        response.send("You are not allowed to view this page.");
        return;
    }
    next();
}

function mySecondMiddleware(request, response, next) {
    response.send("Hello, and welcome to the secret page.");
}

app.get("/secret", myFirstMiddleware, mySecondMiddleware);

In the above example, two middleware functions are defined. The first one makes a check on the request header to see if it includes an authorization header with a correct Bearer token. If it does not, the middleware replies with status code 401 (unauthorized) and a message.

Otherwise, the first middleware sends the request on to the next middleware, which shows a secret page.

You can write your own middleware functions like this - but there is also a vast library of middleware functions on open source platforms such as npm.

Read more about the Express Router on the Express website documentation.

Cover image by www.freepik.com.

ExpressJS Project Structure

Brian Emilius — Wed, 11 Dec 2019 08:33:37 +0000

This article was originally published on www.brianemilius.com/expressjs-structure. Visit www.brianemilius.com/blog for more content.

ExpressJS is probably the most popular framework for creating server-side web applications in Node.js.
In this blog series I want to show you how to get started and how to do it The Right Way™.

Prerequisites

Basic knowledge of Node.js and npm
Some intermediate JavaScript knowledge
Basic HTML and CSS

Intro

In the previous blog post I introduced you to ExpressJS with a very simple example code.

For this post I want to show you how to build a proper project structure for your ExpressJS application, that will scale and is robust.

The keyword for what I want to do here is "fragmentation". We are going to divide the application into a lot of small, modular files.

The reasoning behind this choice is

smaller files are easier to maintain
collaboration runs more smoothly on version control platforms such as GitHub
you can inject or remove functionality without breaking the application in other places

The folder structure

Let's start out by taking a look at the folder structure

my-express-app/
|   app.js
|   package.json
|
└───node_modules/
|   |   ...
|
└───bin/
|   |   www
|
└───config/
|   |   parsing.js
|   |   view-engine.js
|   |   static-files.js
|   |   database.js
|
└───controllers/
|   |   page.controller.js
|
└───models/
|   |   page.model.js
|
└───views/
|   |   page.ejs
|   |
|   └───partials/
|       |   head.ejs
|       |   seo.ejs
|       |   header.ejs
|       |   footer.ejs
|       |   after-footer.ejs
|
└───routes/
|   |   page.route.js
|   |   router.js
|
assets/
    |   ...

Model, View, Controller

The folders models, views, and controllers are at the very core of the application functionality and is meant to use the programming design pattern "MVC".

Configuration

In the folder config we will keep all the little configuration files that express makes use of. Anything from database setup, which parser to use, or what view engine the application should use.

The router

I've taken routing logic completely out of the main application file and placed it by itself. As I mention in the previous blog post, I like to keep application configuration and logic separate from the router engine. Basically, the router engine should be able to function on its own. This is a great pattern for testing purposes, in my opinion.

www and app.js

The app.js file is the main application file. Here we gather all the threads from the configuration and router. This file is also meant to handle application errors and provide a flow for error pages (for example a 404 page) and error reporting (for example logging).

The www file is the application executable. This file starts the server and handles any server-related errors. We can have several different executables for different situations. An example could be one executable file for development and one for the production environment.

Static files

Finally, most websites have a bunch of static files that needs to be served so they can be viewed in the browser. These are files such as stylesheets, front-end related JavaScript, images and other media files. These files are kept in the assets folder.

Tie the fragments together

First, let's create the main application file app.js with the following code:

// app.js

let express = require("express");
let app = express();

// Here, we will require the configuration files

module.exports = app;

That's it, really. For now. We still need to add requirements for some of our configuration files and the router, but all that comes later. This is the very least we need for the application to run.

The next file we want to create is the bin/www executable. There are 3 things we need to do in this file:

require the application
create a server instance and make it listen
handle errors related to the server instance

// bin/www

#!/usr/bin/env node
let app = require("../app");
let http = require("http");

// Define a port for the server to listen on
let port = process.env.PORT || 3000;
app.set("port", port);

// Create a server instance
let server = http.createServer(app);

// Make the server listen on a port
server.listen(port);

// Handle errors and success
server.on("error", onError);
server.on("listening", onListening);

function pipeOrPort(address) {
    return typeof address == "string" ? `pipe ${address}` : `port ${address.port}`;
}

function onError(error) {
    if (error.syscall != "listen") {
        throw error;
    }

    let bind = pipeOrPort(server.address());

    switch (error.code) {
        case "EACCES":
            console.error(`${bind} requires elevated privileges.`);
            process.exit(1);
            break;
        case "EADDRINUSE":
            console.error(`${bind} is already in use.`);
            process.exit(1);
            break;
        default:
            throw error;
    }
}

function onListening() {
    let bind = pipeOrPort(server.address());
    console.log(`Listening on ${bind}`);
}

We start out by requiring the app module from app.js as well as the http package, which is a part of the Node.js general API.

let app = require("../app");
let http = require("http");

Next, we define a port for the server to listen on. In this case, the port is set to whatever is in our environment variable PORT or, if the environment variable doesn't exist; 3000.

let port = process.env.PORT || 3000;
app.set("port", port);

Then we create a server instance and make it listen on the port.

let server = http.createServer(app);
server.listen(port);

The rest of the file is basic event handling. We set up listeners for 2 events: "error" and "listening".

server.on("error", onError);
server.on("listening", onListening);

If the error event is triggered, we call the function onError which handles a few different scenarios, such as

the server cannot run because the port we defined is in use by another program
the server cannot run because the operating system requires certain privileges for a user to run a program

If the listening event is triggered, we log a short message to the console to let us know the server is running.

Configuration injection

Now that we've got the application and server set up and it's basically ready to run, I want to show you how you can tie in configuration modules. We will be making a single configuration module:

config for the location of our static files folder

We need two files.

// config/static-files.js

module.exports = function(express, app) {
    app.use("/assets", express.static("assets"));
};

This configuration is a middleware function. It tells express to use a function, express.static("assets"), on requests to the "http://localhost:3000/assets" address and serve the folder "assets" as static content to the client.

Basically, this means that when a client navigates to "http://localhost:3000/assets" they have access to anything inside the "assets" folder.

I will dive deeper into what middlewares are in a later article.

Finally, inject this module to our app.js file.

// app.js

let express = require("express");
let app = express();

// Here, we will require the configuration files
require("./config/static-files")(express, app);

module.exports = app;

Test all the things!

Now it's time to see if all we did actually work. To test the server, I want to have a HTML file in the assets folder, that prints out a simple message, so I can see that everything runs correctly so far.

<!-- assets/test.html -->

<h1>Hello there!</h1>
<p>If you can see this, the server is running and has been configured correctly.</p>

Now save the file and run the server from your console with the command

node bin/www

You should see the message

Listening on port 3000

Then open your browser and navigate to http://localhost:3000/assets/test.html.

You should see this:

If you have followed along so far, I would really love your input. Are the concepts I demonstrate easy to understand or is there something you wish I explain more clearly?

I have prepared a small repository on GitHub, that you can clone and play around with. It contains everything covered in this post.

The next article will be about the router.

Articles in this series so far

Upcoming articles:

The ExpressJS Router
ExpressJS Template Engines
ExpressJS Middleware
How To Parse Content From Forms With ExpressJS

Construction photo created by jcomp - www.freepik.com

Get Started With ExpressJS

Brian Emilius — Tue, 10 Dec 2019 08:51:32 +0000

This article was first published on www.brianemilius.com/get-started-with-expressjs/. Visit www.brianemilius.com/blog for more content.

ExpressJS is probably the most popular framework for creating server-side web applications in Node.js.
In this blog series I want to show you how to get started and how to do it The Right Way™.

Prerequisites

Basic knowledge of Node.js and npm
Some intermediate JavaScript knowledge
Basic HTML and CSS

Intro

First things first. Before I throw you into a lot of little code snippets and techy-talk, let's have a look at what is a server-side web application.

Basically, we have two kinds of web applications that differ majorly: Server-side and Client-side.

On the client-side, the usual case is, that a browser receives a scaffold HTML page from the server. It then queries the server for data and then renders the data into the HTML scaffold. We call this client-side-rendering (CSR for short).

This use-case is very popular (in 2019) and you see it on a lot of big company websites such as Facebook or Youtube.

Two of the reasons for the popularity of this method are performance and maintenance. Servers perform better, if they have to do less work with every request. This also means that maintaining a server environment is a lot easier (and, importantly, a lot cheaper).

The downside of methods like this is that we put a lot of the work on client devices. This means that phones or laptops drain their battery faster, and data plans gets used up quicker.

On the flip-side is server-side-rendering (SSR for short).

SSR is a method, where the server receives a request for a webpage. It then gathers all the data it needs to put together a HTML-page, renders the page, and then ships it off to the client.

This method leaves almost all the hard work to the server, and not the client device. The downside here is that the server actually has to do some work for every request. The more requests your web-application gets, the harder the server has to work.

Now let's dive in

To begin with we need to initialize an NPM project and install the ExpressJS package. Create a new folder somewhere on your computer. This folder is our root.

mkdir my-express-app
cd my-express-app
npm init -y && npm i express

Let's create an app.js file in the root folder and enter this code.

// app.js

let express = require("express");
let app = express();
let Router = express.Router();

Router.get("/", function routerCallback(request, response) {
    response.send("Hello, World!");
});

app.use(Router);

app.listen(1337, function server(err) {
    if (err) {
        console.log(error);
        process.exit(1);
    }
    console.log("Server is listening on port 1337");
});

Standard configuration

First, we require the express library. This is needed for the entire application to function at all.

Then we invoke the express library and put it in a variable named app.

We also need to invoke the Router function from express.

These 3 items are the core of the application. We could choose not to use the Router function, but in this example I am using it because I like to separate application configuration and logic from the router engine.

Routing

The next thing in the application is the route. We create a listener for the endpoint "/", which is the root of our homepage (the "frontpage").

Router.get("/", function routerCallback(request, response) {
    response.send("Hello, World!");
});

The listener listens for any requests to the endpoint with the HTTP method GET. If a client makes a GET request to the endpoint address, the callback function is triggered. I've put a very short example of how to make something appear on your website. This one renders ye olde "Hello, World!" message.

Once we've written all our route functions (yes, we can have as many as we want), we need to tell the application to use the Router.

app.use(Router);

Starting the server

Lastly we start the server by telling our app to listen on a port. In this example I use port 1337 but in reality you could use any non-reserved port. A common port to use with express applications is 3000.

app.listen(1337, function server(err) {
    if (err) {
        console.log(error);
        process.exit(1);
    }
    console.log("Server is listening on port 1337");
});

Start the application and test it

Once we've saved the app.js file we can run the application and test it. To run it, type this in your console.

node app

It should give you the message

Server is listening on port 1337

Now you can open the website in a browser by navigating to this address: http://localhost:1337/.

This is what you should see:

To stop the application, click CTRL+C in your console.

This is the very basics of getting started with ExpressJS. In the next blog-post I will write a bit about the structure of an express application.

Let me know in the comments if you followed along and how it worked out for you.

Technology vector image created by slidesgo - www.freepik.com

Get Unstuck!

Brian Emilius — Mon, 02 Sep 2019 11:03:14 +0000

This article was originally published on www.brianemilius.com/get-unstuck. Visit www.brianemilius.com/blog for more content.

Some code in my application is being naughty and won't do as I tell it. And I just cannot fathom what could possibly be wrong! I've had this issue for days now. No matter how I look at it, I just can't see a way out. I'm a stubborn fellow, so I dig in deep and keep gnawing at this problem until I alone emerge victoriously.

We've all tried this. We've all had an issue that we struggled to solve. We all probably both hate and love these situations - I know I do! Problem-solving is at the very core of what it means to be a software developer.

So how do we do it? How do we time and again emerge triumphantly? I don't know how you do it, but I know what I do. This article is about that.

Cannot read property 'xyz' of undefined

First of all, I've put in some time learning the different kinds of error types my language has. For example, it pays off for me to know the difference between "cannot read x of undefined" and "unhandled exception".

I've taught myself to analyse the error messages I get in the console, search through my code where the error message suggests and look for something related to the error type.

An example!

async function getUserByUsername(req, res, next) {
  try {
    const [result] = await conn.query("SELECT id, name FROM users WHERE username = :username", {
      username: req.fields.username
    });
    res.json(JSON.parse(result));
    return;
  }
  catch (error) {
    next(error);
  }
}

The above code snippet is a middleware for something like Express or Restify. If I got the error

Cannot read 'username' of undefined on /path/to/file:4:28

I know what file to look in and what line to look at. But I also know that 'username' cannot be read because of the thingy 'username' is stuck on (fields) is undefined. Now I can begin to detective my way out of the problem - by asking: "Why is 'fields' undefined? What did I forget to do?"

Learning what the different kinds of error types mean has probably been the most important thing for me when it comes to debugging my code.

Console.log(all the things)

I've got a bunch of nested conditionals in my code and I am not getting the response I expected.

console.log("here") to the rescue!

I use this little debugging trick so much you might say it's my go-to solution. Move the console.log() around in your code. Notice where it pops up and where it doesn't.

It might seem dumb, but you'd be surprised how often this simple little trick helps (how's that for a click-batey title?).

"But doesn't the IDE debugger already give you this functionality?" you might ask.

Well, yes. It does. Often, spinning up the debugger just to know where my logic fails in a JavaScript is a bit much, though.

That being said:

Befriend Your Debugging Tool

All the big IDEs and VS Code have debugging tools. How you use them differs a bit from IDE to IDE. But get to know yours. Learn about break-points, the call stack, jump in and jump over, and so on.

I often run an application in debugging mode when I develop. This lets me add break-points on the fly.

Take A Break!

For real! Do something else. Go for a walk, clear your mind. Work on a different problem in a different language. Help someone else with their coding problem. Whatever you do, do something that will distract you and take your mind off of your problem.

Some of you might think this is some hippie new-age advice. But it helps. I promise! There's even science to back this claim.

Quack!

Rubber duck debugging is something I practice almost religiously. It's a method where you verbalise your issue. Preferably you do this to a rubber duck. The theory behind this practice is that when you have to describe a problem, the solution often presents itself within the description. I do this a lot with my students. So much, in fact, that some of my students refer to it as "being rubber ducked by Brian".

Learn To Search

Let's be honest. Googling the solution to a problem is something we all do. Or maybe we DuckDuckGo it. Maybe we only search on specific platforms such as StackOverflow. Whatever the case is for you, learn to formulate the core of your problem. Use keywords. Computers understand unhinged sentences such as "undefined error req.fields express" (bonus: This very search phrase on DuckDuckGo has a body-parser issue listed as the number 1 result, which, incidentally, is what is wrong in my example).

Learn To Formulate The Problem

Asking a question on StackOverflow or similar communities can be a really great exercise. Why?

You train yourself in being clear
You might help others with similar problems along the way
You might realise the solution as you describe your issue (rubber duck debugging gone digital).

Ask

Seriously. There's no shame in asking for help. Know what you know. But more importantly; know when there is something you don't know. Use it as an opportunity to learn something new. Ask your friend, teacher, co-worker, the Almighty Google Overlord.

Practice pair-programming. My experience is that programming in pairs gives cause for great discussions about the 'why' in your code.

Don't Worry

Programming is hard. Programming is frustrating. Discipline your mind to understand that failure is a chance to learn. We don't learn anything from being good at the same thing over and over again. Dare to "move fast and break things" - just, like, not in a "let's create an app that has the potential to overthrow governments"-way.

We all struggle. Daily even. It's okay, don't worry about it. It won't get any easier, but it will get a lot more fun as you learn and become a better developer.

Now it's time for you to share your little tips and tricks for getting unstuck on a programming problem. Do you do any of the things I do?

Cover image created by asier_relampagoestudio - www.freepik.com

What In Tarnation Are JavaScript Prototypes?

Brian Emilius — Wed, 14 Aug 2019 16:12:27 +0000

This article was originally posted on www.brianemilius.com/javascript-prototypes. Visit www.brianemilius.com/blog for more content.

A friend of mine asked me the other day about the MDN JavaScript manual.

He noticed something odd when he looked up a function. For example, the title on the page for "forEach" was not "forEach". It was "Array.prototype.forEach".

My friend wanted to know what that prototype thing was all about. This article is about that.

Primitives

So in JavaScript, we have something called "primitives". According to MDN, a primitive is

data that is not an object and has no methods. There are 7 primitive data types: string, number, bigint, boolean, null, undefined, and symbol.

But each primitive, except for null and undefined, has something we call a "primitive wrapper object". These are the ones we want to look at.

String is the wrapper object for the primitive string,
Number for the number primitive,
BigInt for the bigint primitive,
Boolean for the boolean primitive,
and finally, Symbol for the symbol primitive.

Notice that the wrapper objects start with a capital letter (this is important).

Objects

All objects in JavaScript have a prototype. This includes objects that are not primitive wrappers, such as "Function", "Array", and "Object".

The prototype of an object is just what you think it is; A prototype for the object.

Prototypes

Let us take a step back and clear up what a prototype is.

Imagine we have a primitive in JavaScript called "human". The wrapper object would be named "Human".

The prototype of a Human is filled with properties and methods. For example, a few of the properties of a Human could be

Eyes: 2
Ears: 2
Noses: 1
Mouths: 1

These are properties that tell us what the Human has - what it is created with and looks like.

The Human prototype also includes methods. These tell us what the Human can do:

Eat
Sleep
Rave

Now imagine this piece of code in JavaScript that won't actually work in real life:

var Bob = new Human;

Here, we create a variable, Bob, which is built upon the Human prototype.

We can now call any of the properties that Human has on Bob:

Bob.Eyes // output: 2
Bob.Mouths // output: 1

We can also run any method the Human prototype has on Bob:

Bob.Eat() // output: Bob probably eats something
Bob.Sleep() // output: Bob sleeps

Back To Actual JavaScript

As with Bob the Human, so it is with primitive wrapper objects in JavaScript.

Let us use Number as an example.

The wrapper object Number prototype has a bunch of methods we can run on any actual number primitive. One I use often is "Number.prototype.toString".

This method converts the number primitive into a string primitive.

var myNumber = 42;
console.log(myNumber); // output: 42 <-- a number

var myString = 42.toString();
console.log(myString); // output: "42" <-- a string

Got It! What Now?

There are loads of useful methods you can run on objects. The MDN manual has them all listed and there are WAY too many to name them here, so go explore!

If you use console.log() on a primitive wrapper object you can see the entire list of prototype properties and methods in your browser or console. That's a fun place to start.

Cover photo created by kjpargeter - www.freepik.com

Bob photo created by freepik - www.freepik.com

What to put in your portfolio as a beginner web dev

Brian Emilius — Tue, 06 Aug 2019 13:35:10 +0000

This article was originally published on www.brianemilius.com/portfolio-ideas. Visit www.brianemilius.com/blog/ for more content.

Last week I wrote up a list of advice for beginner web developers. One of the bullets on the list was to build a portfolio.

My Advice to Beginner Devs

Brian Emilius ・ Aug 3 '19 ・ 3 min read

#beginners #career

But the challenge with this is that beginners have nothing to show.

Or do they? Here is a list of ideas for beginner portfolios. Please share yours too at the bottom.

The code to your portfolio itself. Put it up on GitHub and share the link.
Finish a pet project and display it.
Design a contact form complete with validation, error messages, and confirmation message.
How about the same as above, but for a login/signup form?
Or a newsletter signup/cancellation flow?
A small site that gathers news from RSS feeds and displays them.
Photo gallery
Are you a member of a sports club or do you play in a band? Make a website for that - even if your club doesn't need one.
Call up non-profits in your area and ask if they would like to make use of your skills (this is also a great exercise in making cold-calls).
Make a few [insert your preferred CMS] templates.
A case study of that time you helped your aunt make a genealogy site.
Or a case study of that other time you helped Non-Profit X tune their SEO and accessibility issues.
A responsive website navigation (that doesn't default to a hamburger menu) (Why? Because this requires some outside-the-box thinking).
Contribute to an open-source project. Yes, this is a daunting task for pretty much all beginners, but a great place to start in the open-source community is documentation and translation (fix those comma errors).
A Tic-Tac-Toe game app, but with your personal twist.
A To-do app you can speak to.
An analogue clock.
A small chat interface, maybe for something like webshop live support.
Set up a landing page for Relay For Life, even though they never asked you to (seriously, help spread the brand!).
Share unfinished projects. This can say a lot about your thought process and has real value.

That's 20 ideas for your beginner portfolio. A good one has 6 to 10 examples that show off your skills. Remember; Show me, don't tell me. Use visual examples. Show me what you can do rather than talk about it.

What ideas do you have? Or maybe you want to show off your portfolio so others can be inspired. Share in the comments.

My Advice to Beginner Devs

Brian Emilius — Sat, 03 Aug 2019 10:02:24 +0000

This article was originally posted on www.brianemilius.com/advice-to-beginner-devs. Visit www.brianemilius.com/blog for more content.

I have been messing around on the World Wide Web since it was a thing. Today I teach Web Developer classes at college. Here is my advice for beginning web developers.

Doesn't matter how you did it

Don't spend too much time fussing over your solution to a problem. If it works, you did it right.

It doesn't really matter how you made your solution work. What matters is that it does work. In time you will learn to identify smarter or faster solutions. Or how to follow best-practice for your language or framework.

But for now, make it work.

Have a pet project

When you learn new things it can be a tremendous benefit to test your knowledge on a project that you care about.

The Internet is full of Hello, World! and To-do app examples. These are all great and will teach you the basics of what you can do with a language or tool.

You have to apply your knowledge to something you are passionate about. This will help you internalise new learning. And it's a way to move past tutorials. Pet projects are perfect for this.

Build a portfolio

Yesterday is a great time to get started building your portfolio. A good portfolio should show your skills.
Don't have any real-life cases to display? Don't worry; make some up:

Finish that pet project of yours and put it in the portfolio.
Display a few of your tutorial apps (but not too many).
Call up a local sports club and ask if they need some free web-work done.
Offer free SEO or accessibility audits to some local non-profit organisations.

Now, I know it's a bit of a slippery slope to offer your work for free. I am not suggesting you should "trade hours for exposure". But these few free jobs can get your portfolio up and running. You will earn some real-world experience which can give you real leads.

Even senior devs struggle

Part of being a developer, any kind of program development, is problem-solving. You might say we make a living off finding solutions to problems.

Problems can be... well, problematic. I've been doing this for 25 years. Sometimes I think web developers are a masochistic breed.

I can get so frustrated over a problem that I am ready to quit. But over the years I have learned several problem-solving tricks.

Break your problem into smaller parts.
Learn to use debugging tools.
Ask for help (for real!).
Use pseudo-code.
Use flow-charts.
Go for a walk to clear your head.
Work on something else for a while.

Keep up-to-date

Web development is an industry that works both super fast and super slow. So slow it sometimes seems like you are watching paint dry.

What do I mean by this? The World Wide Web has existed for over 30 years now. A lot has happened, but then again, we still use HTML, CSS, and JavaScript for a lot of it. This is the slow-evolving core (and this is a good thing!).

Then there are server-side languages, frameworks, libraries, design systems and so on. These evolve at a break-neck pace. New things emerge almost every day. Some of these things grow to be common-place tools, others die.

But keep up with the industry.

Listen to podcasts.
Subscribe to a few mailing lists and newsletters.
Follow industry leaders and first-movers on social media.
Be curious.

Know your motivation

It doesn't matter why you are a web developer. It pays your rent or it is your life's passion to make awesome web apps, build and be creative. Whatever your motivation is, don't lose sight of it.

What helps you in your journey as a web developer? Do you have any advice to pass on to the next generation? Leave your comments below. You never know, your advice might help someone.

Cover photo created by rawpixel.com - www.freepik.com

How To Get a Comment Section On Your Static Site

Brian Emilius — Tue, 23 Jul 2019 10:41:21 +0000

This article was originally posted on www.brianemilius.com/static-site-comments/, 2019-07-23. Visit www.brianemilius.com/blog for more content.

In this article, I will show you how to implement a comment section on a static website with no backend. But first, let me explain what a static site is, and what a backend is.

Static Site

A static site is a website that has no dynamic content. Usually, they are written entirely with HTML, CSS, and JavaScript. Sites like these do not fetch content from an external source. Each page is unique and will work isolated from the other pages on the website.

Advantages of static sites include

ease of development
easy to host
works fast on slow connections

Disadvantages might be

low scalability
hard to implement design changes

A recent trend in web development has been to use something called Static Site Generators.

Static Site Generators lets the developer work with templates and web components that in the end are generated into static HTML pages.

Some of the popular Static Site Generators are

Backend

A backend in web development is for generating data and receiving and storing data. This includes data manipulation.

An example of this is a website that presents weather forecasts.

The backend receives a lot of data from weather satellites, weather balloons, weather stations, etc. This data needs to be translated, interpreted and stored in a database.

When a visitor requests a forecast through the website, the backend will select the appropriate data, format it so it can be presented, and sends it to the visitor.

Advantages of having a backend could be

dynamic content creation results in more visits
support for interaction between users
separation of content and design

Some disadvantages of having a backend might include

depending on the scope of a project, hosting can become quite expensive
backends are at a high risk of malicious attacks from hackers, so you need to know about server security

Comments With No Backend

Now that we know the terminology, let us have a look at one solution to the following problem:

I want to have a comment section on my static website, but I have no backend, so I don't know where to store the comments.

There are many ways to solve this problem. Most of them use social media platforms as the engine under the hood. Privacy is a constant concern of mine, so I want to solve my problem without using technology that tracks my users.

To the rescue comes GitHub and Gitalk.

GitHub is the go-to platform for collaboration with code. Every project on GitHub exists in something called a repository. Repositories can have connected issues, and you can comment on issues. This is the technology we are going to leverage.

To do this, we are going to use a nice little open-source package called Gitalk.

Gitalk will let you add a fully functional comment section to any static page, as long as you have a GitHub account. This does, however, limit the use of your website comment section to people who are interested in programming and already have a GitHub account. This is why I suggest you use this method if your website topic is about programming, web development or similar.

Step 1

First, you need to go to GitHub and create an OAuth App.

Go to your GitHub settings page and click "Developer Settings in the left-hand menu, then click "OAuth Apps" also in the menu.
Click the little "New OAuth App" button at the top.
Fill out the form with your application name, the URL of your website, and an authorization callback URL. The callback URL, in this case, is the same as your website URL.
Once you have registered your OAuth App, you will receive a Client ID, and a Client Secret. Save these.

Step 2

Create a public repository. This is where your comments will be saved.

On GitHub, click the plus-sign the top-right corner and select "New repository"
Fill in the form. Make sure to select public, not private. The only thing you need to fill in is the repository name. It could be something like "my-website-comments".
Click the green "Create repository" button.

This is all the setup you need to do on GitHub.

Step 3

Now you need to copy and paste some code into your website pages.

On the pages where you want a comment section, place this in your head section.

<link rel="stylesheet" href="https://unpkg.com/gitalk/dist/gitalk.css">
<script src="https://unpkg.com/gitalk/dist/gitalk.min.js"></script>

This will load the stylesheet and the Gitalk script into your page.

Next, you need to decide where on your page you want the comments. Place this code where you need it.

<div id="gitalk-container"></div>

And finally, insert this script at the bottom of your page, just before the </body> tag.

<script>
const gitalk = new Gitalk({
  clientID: 'GitHub Application Client ID',
  clientSecret: 'GitHub Application Client Secret',
  repo: 'GitHub repo',
  owner: 'GitHub repo owner',
  admin: ['GitHub repo owner and collaborators, only these people can initialize github issues'],
  id: location.pathname,
  distractionFreeMode: false  // Facebook-like distraction free mode
})

gitalk.render('gitalk-container')
</script>

Insert your Client ID and Client Secret from step 1 into the script, change owner, and admin to your GitHub username, and repo to the name of your repository that you selected in step 2.

Step 4

Open each page with a comment section in your browser and click the Init button. This will create an issue for the comment section on GitHub and let your visitors use the new functionality.

I use this method on my website, however, I created my website with Gatsby. This means I had to use a slightly different approach. If you are interested, you can take a look at my website repository on GitHub to see how I did it.

Let me know your thoughts on this method in the comments below!

Cover photo created by rawpixel.com - www.freepik.com

Optimize Your Website

Brian Emilius — Sun, 21 Jul 2019 13:49:22 +0000

This article was originally posted on https://www.brianemilius.com/optimize-your-website/, 2018-04-17. Visit https://www.brianemilius.com/blog for more content.

If you have ever used Google Chrome's Audit tool you've probably noticed that almost no matter what you do Audit will tell you that your CSS is blocking the rendering of your site.

If you take a look at the report details Google recommends loading critical parts of your styling directly in the head section and deferring non-critical styling.

So what is critical styling? What does render-blocking even mean?

When you load a website page with your browser you put it to work. From the server, your browser receives a bunch of HTML, CSS, and in most cases JavaScript. The browser needs to interpret all this code and translate it into something that looks good and is understandable to any regular page-visitor. In other words text, shapes, colours, and animations. This is what we call rendering.

All stylesheets and scripts that you place in the head section must first be downloaded and then treated by the browser before the browser can start interpreting what to do and show. This means that any external script or stylesheet is blocking the browser from doing its job quickly - especially on devices with a slow connection.

<html>
        <head>
                <title>Slow Website</title>

                <link rel="stylesheet" href="/css/mainstyling.css">
                <link rel="stylesheet" href="/css/fonts.css">
                <link rel="stylesheet" href="/css/fancybox.css">

                <script src="/js/jquery.min.js"></script>
                <script src="/js/app.js"></script>
                <script src="/js/fancybox.js"></script>
                <script src="/js/googleadwords.min.js"></script>
        </head>
        <body>
        <!-- contents that needs to render -->
        </body>
</html>

In the above example, 7 external files need to download before the browser can even begin to start rendering. This is what we call render-blocking.

Critical styling has to do with how we want our website to look. It has to do with the layout of your site, the most important colours, font faces and font sizes.

A Solution

I suggest a two-part solution:

We need to identify what our critical styling is, and
defer downloading our stylesheets and scripts till after the DOM is loaded.

Critical Styling

What critical styling is on your website depends entirely on the individual site. You will have to determine how much or how little styling you need for the first rendering. Ask yourself this question: "How little does it take for my site to approximate the look I want?" Then choose the CSS required for this and place it in a <style> tag in the head section.

<html>
    <head>
        <title>A Slightly Faster Website</title>
        <style>
        :root {
            --colorPrimaryForeground: hsl(0, 0%, 7%);
            --colorPrimaryBackground: hsl(0, 0%, 98%);
            --fontStack: Arial, Verdana, sans-serif;
            --fontSize: 1em;
        }
        html, body {
            margin: 0;
            padding: 0;
        }
        body {
            background-color: var(--colorPrimaryBackground);
            color: var(--colorPrimaryForeground);
            font: normal 400 var(--fontSize)/100% var(--fontStack);
        }
        .container {
            display: grid;
            grid-template-columns: repeat(12, minmax(50px, 1fr));
            grid-template-rows: 100px auto 50px;
        }
        </style>
    </head>
    <body>
    <!-- contents that needs to render -->
    </body>
</html>

Defer Downloading Of Non-Critical Styling And Scripts

When the page has rendered and the DOM is loaded we can download the rest of our stylesheets and scripts. JavaScripts are real easy to load in this manner. All you need to do is add the attribute defer to the script tag:

<script src="/js/jquery.min.js" defer></script>
<script src="/js/app.js" defer></script>
<script src="/js/fancybox.js" defer></script>
<script src="/js/googleadwords.min.js" defer></script>

Furthermore, I consider it good praxis to place script tags at the very end of your HTML document right before the </body> tag.

Stylesheets are a bit more complicated to handle. We need to write a short JavaScript function that will inject <link> tags after the DOM has loaded.

const cssLoader = function (src) {
    const stylesheet = document.createElement('link');
    stylesheet.href = src;
    stylesheet.rel = 'stylesheet';
    stylesheet.type = 'text/css';
    document.getElementsByTagName('head')[0].appendChild(stylesheet);
};

This function can be used inside an event listener:

document.addEventListener('DOMContentLoaded', () => {
    cssLoader('/css/mainstyling.css');
    cssLoader('/css/fonts.css');
    cssLoader('/css/fancybox.css');
});

This makes the entire HTML document look as such:

<html>
    <head>
        <title>Much Faster Website</title>
        <style>
        :root {
            --colorPrimaryForeground: hsl(0, 0%, 7%);
            --colorPrimaryBackground: hsl(0, 0%, 98%);
            --fontStack: Arial, Verdana, sans-serif;
            --fontSize: 1em;
        }
        html, body {
            margin: 0;
            padding: 0;
        }
        body {
            background-color: var(--colorPrimaryBackground);
            color: var(--colorPrimaryForeground);
            font: normal 400 var(--fontSize)/100% var(--fontStack);
        }
        .container {
            display: grid;
            grid-template-columns: repeat(12, minmax(50px, 1fr));
            grid-template-rows: 100px auto 50px;
        }
        </style>
    </head>
    <body>

    <!-- contents that needs to render -->

    <script src="/js/jquery.min.js" defer></script>
    <script src="/js/app.js" defer></script>
    <script src="/js/fancybox.js" defer></script>
    <script src="/js/googleadwords.min.js" defer></script>
    <script>
    const cssLoader = function (src) {
        const stylesheet = document.createElement('link');
        stylesheet.href = src;
        stylesheet.rel = 'stylesheet';
        stylesheet.type = 'text/css';
        document.getElementsByTagName('head')[0].appendChild(stylesheet);
    };
    document.addEventListener('DOMContentLoaded', () => {
        cssLoader('/css/mainstyling.css');
        cssLoader('/css/fonts.css');
        cssLoader('/css/fancybox.css');
    });
    </script>
    </body>
</html>

The only thing we now need to do to perfect this is to make sure the stylesheets are loaded even if the browser has JavaScript switched off.

<noscript>
<link rel="stylesheet" href="/css/mainstyling.css">
<link rel="stylesheet" href="/css/fonts.css">
<link rel="stylesheet" href="/css/fancybox.css">
</noscript>

Try this method on your next project and see if you can notice whether it makes a difference in your Audit performance report.

I would love to hear from you about your experiences with this method in the commentaries below.

Cover photo by luis_molinero - www.freepik.com