The PWA Resource list

Recently I started getting asked more and more about the development of Progressive Web Apps. After the basic explanation about what they are I usually point to various places on the web. So, I decided to create this list of resources to have them available for everyone.





If you want to stay up to date with everything around progressive web apps (and more modern web stuff), you should start by following these people:


More examples




I’ll keep this page up to date as new, or better, resources come around. If you know something that is absolutely missing from the list, please let me know in the comments, or through twitter (@sorskoot).

Live-LiveCoding: node.js @ SDN event

Hello CodersHere’s the recording of my LiveCoding session at the SDN Event. In this session I’ve build a very basic website using node.js and express.js. I talk about Pug for templating and Sass for my css. I also explain some great features in Visual Studio Code.

I also streamed the session to my channel. Be sure to check that to find out when I’ll be streaming again.

You can find the code build in the session at my GitHub.

I want to thank SDN for organizing the event. Be sure to check their channel as well (it’s in Dutch).

The Express.js Route to Success | express.js router

You probably want your node.js server to respond to requests that are coming in, specially when you are building a website in this site This can be complex and quite tedious to implement in vanilla node.js. Luckily express.js has done this for you.

Basic Routing

Your node.js server needs to respond to event the most basic HTTP requests. If it doesn’t your website would be very boring. Express.js has functions for the 23( I thought there were like 8… :P ) most common HTTP methods. They all work in the same way. For example, to respond to an HTTP GET method on the root url you can do this:

Let’s dissect this piece. The app object is defined earlier and holds the current instance of  the Express app. This object is instantiated at the beginning of your app.js file if you followed the description in my previous tutorial

On the app object the get function is called. The first parameter of this function hold the URL on which the GET method should be handled. The second parameter is a function that is called when a request to the URL from the first parameter is coming in. This function has to have 2 parameters itself, an object containing all information of the request and an object you can use to create a response. In this case its send function is called with a string. This string will be send back to the client.

In a real-world application you probably end up with a lot of routes and handlers. You don’t want all of these handled inside you app.js. Express.js has you covered. This should be already inside the default app.js:

and if we look at that file at ./routes/index:

In the first part you can see that the _index _file is loaded with require. A few lines below that it is used. Instead of the _get _function the use function is used this time. Again, its first parameter is the route to cover, the second a Router object from Express.js. And that is it as far as the app.js goes. You’ll probably end up with a whole list of these use functions. The use function can be used for a lot more than only routing. If you want to use logging or authentication, this function can be used to specify middleware for that as well. Often the path parameter is omitted than.

The second part is located inside the ./routes folder by default. In this case I’m showing the default index.js file that’s in there. Right at the start of the file it loads ‘express’ and initialized the router.

After that the get function is called, again with a path. That path however starts at the location that is used in the app.js file. So for example when you do something like “app.use(‘/users/‘,users);” in your app.js file, the path you use in the users.js file may look like “router.put(‘/description’, someFunction)”. In that case the URL for which the HTTP PUT verb handles “”.  

Handling query parameters

With handling calls to certain URLs, you also want to be able to handle query parameters or the message body send to that URL. Both are handled differently, so first let’s look at the query parameters.

Take the following URL: “”. In the handling of the HTTP GET, you want to get access to the name parameter.

To get access to the query parameters you can use the params object that is available though the _req _argument in the handling of the request. Since JavaScript isn’t strongly typed, you can just access the parameter.

It’s nice to be able to use ‘ ? ‘ and stuff in the URL, but I personally would rather have the URL written like: “”. In situations like that, express.js provides us with the solution. You can add a ‘ : ‘ to the path argument followed by the name of the parameter and the rest is handled automatically. The code would look like this in that case:

Now what if we want to use an HTTP POST? We don’t have a query string to pick parameters from. In that case we don’t use the params property, but the body property of the req argument. In the case below I want to POST something to “”. Inside my users.js file I can handle this like:

More advanced routing

Sometimes you need to do more than one thing on a certain request or URL. Express.js provides a mechanism to have the routing being continuously checked. By calling the next() function that is passed to the route handler you do exactly that. You can have multiple callback handlers on the exact same route.

There are two more functions on the route that can be very useful when chaining handlers, ‘router.all()’ and ‘router.param()‘. The ‘router.all()’  is similar to the ‘router.use()’ function, except that it handles all HTTP verbs. The ‘router.param()’ function adds a callback that triggers on the parameters. This function takes the name of the url parameter as an argument and is called when a url is routed that contains that parameter.

This means that you can have a routers that handle every path,  that handle the parameters and that handle the HTTP verbs:

Keep in mind that the order of registering the handlers is significant. The param function is always called before the use of that parameter. But placing the all function after the get function, this having the wildcard path ‘ * ‘  later than the much tighter ‘/p/:name’ will cause the _all _function not being called.

Working with the response

When you are done handling the route you’ll probably want to send some response back to the client. There are a lot of specialized function you can use. I’m going to give you some information on the most common.

‘res.send()’ sends a response back to the client. This can be pretty much everything, a string, a JSON object or a Buffer. The content-length header is set automatically.

_‘res.json()‘ _can be used to send a piece of JSON back to the client. Even though you can send JSON back using the send function, the json function provide a little bit more customization on the data. For example, you can specify the number of spaces used or specify a replacer function to further customize the parsing.

The last one I like to mention is ‘res.render()‘. This function uses to specified view engine to render a template to HTML.

Here are a few examples:

How to build node.js apps effortlessly with express.js

Node.js is a pretty powerful and versatile framework to build sites and tools. But using the defaults to handle HTTP requests and such can be a pain. Express.js can make your life a lot easier.

In the previous tutorial I showed you how to get started with node.js, this time I’m going to expand on that. We’re going to scaffold a new Express.js app.  Express.js is a web framework that makes it very easy to handle calls to the node.js server. It helps you with routing, error handling and it works very well other frameworks.

Installing the express generator

The easiest way to get going with any Express.js-based node.js app is by using the express-generator. I’ve you are planning to use it multiple times (and trust me, you will), run the following command and install the express-generator globally.

This might take a moment, but if it’s done installing you should be able to run the ‘express’ command with the ‘-h’ flag to display the help.

Options are limited, but that’s fine. You can select a one of a few common view engines and stylesheet engines. Personally I prefer pug and sass. I plan on doing an entire tutorial on pug soon.

Run the following command to bootstrap the new app.

Next, to install the necessary dependencies, run ‘npm install’.

…and wait…

When it’s eventually done, run ‘npm start’ to start your new application and go to the browser at http://localhost:3000 to view your node.js app running.

This was the easy part… now lets go into a bit more detail on what this has generated.

The App

Left you can see a partial screenshot of the app opened in Visual Studio Code. Let’s go over the folders and let me briefly explain what these contain. In a later tutorial we’ll dive deeper in much of the concepts.

At the top you find a ./bin folder. In there is a _‘www’. _This file actually contains the JavaScript needed too start your server. It handles the port at which the server is running. And it literally creates a server for your app.

Which brings to the next important file. Near the bottom of the list you can find ‘app.js‘. In here the express.js app is instantiated and the root level routing is configured. This means that there is some the app is told at what url specific could should be called to handle the requests. It also configures the apps view engine (pug) and the css engine (sass).

Inside the ./views folder there are 3 .pug files. These files are used by the _pug_ view engine and contain the markup of the app.

Then there are the 2 .js files in the ./routes folders. These two handle the requests on the root level routing configured in app.js. What happens is that a request comes at the server, say an HTTP GET request at url http://localhost:3000/users. The url /users is configured in app.js and points to the users.js file in ./routes. Inside users.js the request is taken from there, so the HTTP GET is handled from ‘/’ and a string is placed in the response.

Last, there’s the public folder. This folders is configured in app.js as the location from which static files are served. In fact, this folder is mapped to the root url. So http://localhost:3000/stylesheets/style.css returns the css file, note that there’s no ‘public’ part in that url.

When using Gulp or Grunt to compile your JavaScript and Sass, the resulting files are placed in the public folder.