DEV Community: Pegah Safaie

Keep An Eye On These Build Tools For Your Web Apps

Pegah Safaie — Sun, 23 May 2021 07:10:59 +0000

Introduction

You might remember the battle in which webpack won over module loaders and task runners such as requireJS and gulp.
For a while, most of the webapps were built and bundled with webpack. Libraries on the other hand mostly preferred rollup as bundler.
But things are changing. There is a new generation of fast build tools that has a pretty good chance to keep up or even overtake Webpack. They might not be yet mature enough for production, but they are on the right path, so they are worth monitoring.

What are these fast build tools?

Vite, Snowpack and esbuild.

What makes them alternative for webpack?

They are fast
In what?
Build time
How?
The bundling is excluded from the build process of "Vite" and "Snowpack" and "esbuild" is being written in Go instead of javascript!
now I know the names. Why should I read on?
Because I want you to deeply understand how and why we need bundling and how and why we can exclude it from your build process! So stay with me if you are interested.

This would be a history lesson. But why?

When talking about a tool/concept in our ecosystem, it is important to keep in mind that these tools/concepts are created in response to the needs of their times. Therefore, to understand how a tool is built, we need to put it in the context of time and understand what problem it was supposed to solve at the time. By using this approach, you won't continue to believe in something just because your fathers did ;)
Here is the history of evolving JS module systems and their impact on task runners, module loaders, build tools and bundlers.

Problems of a world without having modules

The first javascript project I saw had a huge main.js file referenced by a script tag in index.html. Later some colleagues complained about the mess in this huge file, so we decided to write every single feature in one file and include all of them as script tags in index.html file.

We detected a problem very quickly: We were all working on different files and each had his own variables. In some cases, we could have used the same variable names in separate files.
Why was there a problem?

The variables inside a function in JavaScript are limited to that function, but everything outside of the function is global and accessible even from other scripts referenced in the same HTML page (that changed after introducing ES2015 and defining module and block scope besides function scope). Suppose everyone were to change the variable you depend on, you could easily run into conflict.

IFFE pattern, one step forward

The IIFE pattern was introduced to solve the name collision(encapsulation) problem we saw in the previous section.
By looking at the picture, we see that the authors of external.js and func1.js wrapped their code into an immediately executing function

(()=> {})()

This function returns the functions and variables we want to export.
When our name collisions problem was resolved, we had some free time to start complaining about another issue in the non-module world: dependency management. Let me put it into the context:
-Dependency: An external code your code depends on. For example, func1.js is a dependency of main.js and external.js is a dependency of func1.js
-Management: Refrencing JS libraries (scripts) in an HTML file with a script tag.

Managing dependencies using script tags was a challenging task for three reasons:

The order in which scripts are included matters. The code above does not work if main.js is referenced after func1.js.
If your external library requires other dependencies, you must be aware of and specify all of their dependencies.
For the newer version, you must check the creator's website regularly and replace the old address in the index.html with the new one.

CJS modules, node and NPM. A revolution in dependency management

Nodejs was born in 2009 and revolutionized the modules world. As Nodejs applications don't have any html files in which dependencies can be defined, the Nodejs society has developed its own way of writing modular code, which turned out to be better than the IFFE pattern. The system was called CommonJS module system (CJS).

IFFE and CJS both support encapsulation, but CJS(+npm) has a more efficient way of handling dependencies. As an example, imagine you need to use lodash in one of your modules. Instead of placing <script src='./lib/lodash'></script> inside of index.html which makes it available and global for all your modules, you can place

const lodash = require('./lib/lodash');

inside the js file you want to use lodash.

If you have already used the require syntax to import modules you might get confused by the relative address whitin require. what we write nowadays looks like:

const lodash = require('lodash');

The difference lies in NPM(Node Package Manager) and your package.json file.
You can use the latter code by adding the lodash to your package.json file and then running the npm install command. NPM downloads the latest version of lodash(based on the semver rules you specifies for lodash) and put it in the node_modules folder. By writing require('lodash'), Node finds and reads the content of the "lodash" folder within node_modules.
CJS was(and continues to be) widely accepted in javascript ecosystem and many famous libraries like lodash are written using this system.

Nodejs also led to the emergence of Modejs task runners(2011) like Grunt and Gulp that were used alone or in conjunction with other build tools to manage our development pipelines and accomplish tasks like minifying and concatenation(both helped to reduce the amount of code you deploy and the others have to download). The field of build tools was dominated by them until 2015, when webpack arrived.

The problem with CJS is that it cannot be used in a browser! When you run npm install, NPM will still download lodash and place it under the lodash folder in node_modules. However, unlike node, browser does not know what to do with require('lodash').

AMD modules and module loaders

There were two main reasons why CJS was not suitable for browsers:

In CJS, only one module per file is allowed This increases the network traffic.
Dependencies(modules) can not be loaded asynchronously. require is a sync command. When you have ten require dependencies, they all will be loaded one after the other. Nodejs dos'nt have any issues with that since everything executing on the server and IO actions are executed really quickly. However, the browser will freeze until all 10 are downloaded. By comparison, an async module load sends ten requests at the same time (even when they are dependent on one another) and serves the user even while the dependencies are downloading.

To resolve these two issues, frontend developers devised AMD module which come with RequireJS as its module loader.
But what is a module loader for?

Do you remember how Node supported CJS to manage dependencies?
Well, no browser do it for AMD. That's why AMD needs its own dependency manager which loads as a script in the browser and performs the exact same functions as node did for CJS.
AMD Module loaders manage dependencies for AMD module systems in an async manner! Lets see an example to understand it better.

Main.js depends on two dependencies, A and B. RequireJS loads B and then A asynchronously(at the sametime) but, it does not allow main.js to be executed until both of them are completely loaded.

AMD and Requirejs combination was popular for several years, but did not last because of two reasons:
The syntax of AMD modules was confusing for exporting and importing modules. Further, javascript developers were increasingly using CJS libraries written primarily in Nodejs, such as lodash.

CJS modules, browser and bundlers

To solve CJS's "sync module load" problem for browsers, some smart developers jumped in and created a build tool named Browserify(2011). Browserify crawls the whole webapp at build time to find all requires and replaces them with content from the node-module folder(since it runs in build time). At the end of the build we have one single js file containing all the js files.

Browserify allowed frontend developers to write their entire webapp in CJS module format.

World of incompatible modules

At this point, developers can choose from a variety of modules and write their projects in one of them. The problem arises when one tries to use a module from another system but the formats are incompatible.
In order to resolve this problem, two solutions were proposed:

Some developers preferred to create a standard module system that works with both nodejs(backend) and browsers(frontend). They introduced the ES module system(2016) but it was not supported by neither Nodejs nor browsers until 2019.
Some other developers proposed to create a bundler that accepts all types of modules. You probably know it: webpack. Webpack is a swiss army knife which allows developers to write code in multiple module systems (for example, ES and CJS simultaneously). It also provides additional functionalities like asset management, code splitting, tree shaking, etc.

In this phase, we have modules which can support encapsulation and provide dependency management, and thanks to webpack we can use our favorite libraries without being worry of incompatibilities. Are we at the end of our journey?
The answer is no. JS world prefers to have a native solution for this incompatibility problem. Wouldn't it be better to have one standard module that doesn't need any extra transpilation system to be understood by browsers and nodes? Remember that webpack's nice features came with a price: complexity. Webpack is difficult to configure even after starting with a zero configuration at version 4.

Supporting ES modules and new bundlers

After node v13 and some famouse modern browsers started to support ES modules, more and more developers from both environments started to use ES modules. Even famouse CJS modules like lodash delivered an ES version of their library.
In addition to its standard status, ES is popular for two other reasons:

Its static nature allows for some build-time bundle optimization, such as tree shaking.
The flexibility to define multiple modules in one file (AMD managed to do this, but their implementation had a number of other problems).

It was suggested that since everyone writes their code in ES modules and node and most browsers can resolve es modules, why would we use a complicated bundler like webpack to convert each module type into another? What if we just had a bundler for ES modules?

This led to the creation of Rollup. The philosophy was:
Since ES modules can be deployed both in browsers and in nodes, this should eliminate the need for unnecessary transformations. Using this approach, Rollup could reduce not only the configuration complexity but also the bundle size as well as the build time.

There is an old saying, "Use Rollup for your libraries and Webpack for your web applications". It's a rule of thumb, and many web apps are bundled with Rollup or vice versa, but what makes Webpack the most appealing choice for building webApps?

Asset(css, images, font) management features
Giving developers the flexibility to write their code in the ES modules while importing the CJS libraries like lodash(It is also possible with Rollup but requires plugins).

However, Rollup is popular among libraries since it supports a variety of expose formats, including ES, CJS, AMD, and script tags (whereas webpack does not support ES output).

Supported ES modules and non-bundlers

After modern browsers began supporting ES modules, a discussion began between two groups of developers:

Revolutionary developers: Currently, our development team's productivity is negatively affected by bundling. During build time, we spent too much time finding and resolving dependencies. Why not just transpile other popular module formats(CJS) into ES and let the browser resolve and execute them?

Conservative developers: No bundle?! You will have a network request per file which effects your runtime performance.
And would you be able to guarantee that your clients do not use old browsers like IE11(which does not support ES modules)?

Revolutionary developers: We can't guarantee which browsers our clients use, so we still bundle for our production mode. However, we can ensure that our developers have access to modern browsers so that we can skip bundling in development mode. This is what our proposal looks like:

if (production) {
    // Do bundling
    // Do the rest of building tasks
}
else {
    // Do the rest of building tasks
}

Conservative developers: ok! Let's give it a try. But we will be careful with that because due to the different build approaches what you see and test in development mode could be different from what you have finally in your production.

Vite(pronounced /vit/) and Snowpack were created as a result of this discussion. There are many similarities between them. The big difference is that vite is opinionated. It means you get rid of some configuration but it also reduces your flexibility.

For example Using Vite, your production will use Rollup to bundle, whereas with Snowpack, you can use your choice of bundle (or even leave it unbundled).

Generally, if you're comfortable with tools such as vue-cli or react-create-app, which set up scafffolding projects with zero config, Vite would be a good choice for you.

It seems interesting for me as a Vue developer who does not like to set up a project from scratch with its build tool. But before using Vite for development, you should be aware of some aspects.

Until recently, Vite had no official support for legacy browsers. To put it simply: Vite's created bundles didn't work with IE11. Currently, it is supported by an official plugin named: plugin-legacy.

Another fact to know is that using Vite you can import CJS dependencies in ES modules, but in some cases, it may not work quite as expected.

esbuild

Esbuild is an impressively fast bundler based on Go, which many think will be the most used bundler for big applications in the future. esbuid's problem is its small community team and the fact that it is not production-ready. Some features like dev server is missing but you can use the combination of Snowpack and esbuild.
Furthermore, Vite documentation indicates that esbuild would be preferred over or in addition to Rollup when esbuild became production ready.

History overview

Request

I am so interested to see which module system and build tool you use/have used for your projects. Drop a comment below and let's talk about it.

Resources

Unbundling the JavaScript Module Bundler

Writing Modular JavaScript With AMD, CommonJS & ES Harmony

Java Script Module Systems Showdown

Moving Past RequireJS

Why AMD

Comparing the New Generation of Build Tools

Why I Use Rollup And Not Webpack

Modern JavaScript Explained for Dinosaurs

Real world example of compose function and currying.

Pegah Safaie — Thu, 22 Apr 2021 18:00:09 +0000

Another currying article

Using Javascript, you can decide to write your code based on FP or OOP principles. When you decide on FP there are some concepts you need to understand in order to make the most out of FP principles. These include concepts like currying and compose functions. For me it took a while to understand what the currying is and when and how I should use it in my code. Here, I tried to explain what I found in a simple way, hopping to make the learning process quicker and smoother for you.

When to use compose functions?
How to use compose functions?
How to enhance compose functions using currying?
Homework
Your opinion

When should we use compose functions in our code?

we want to model the following ice cream production line by using javascript functions.

We see a sequence of 3 actions following one another:

Mix the ice cream with sth like 🍓, 🍒 and 🍇.
Decorate the ice cream with sth like 🍫.
Form the ice cream scoopes.

All actions take ice cream as input, modify it with some settings(berries or chocolate) and send the modifed ice cream to the ouput to be used by next function.

Here is the atomic function for each action.

function mix(ice, tastes) {
    return tastes.join(', ') + ice;
}

function decorate(ice, taste) {
    return 'decorated with ' + taste;
}

function form(ice) {
    return 'scooped ' + ice;
}

For a berry ice cream with chocolate topping, you might write:

 decorate(form(mix(ice, 🍓, 🍒, 🍇)), 🍫)
 // output: " scooped 🍓, 🍒, 🍇 ice cream decorated with 🍫"

I'm sure you've seen this pattern in your code:
Modifying a single data (ice cream) by a couple of operations to create the desired outcome (scooped berry ice cream with chocolate).
But this way of writing function sequences is not quite nice. The brackets are too many, and the execution order is from right to left.
To write it better, we can use the Composition Function concept in math:

Having

f: x -> y

g: y -> z

we can create a third function which receives a single input(x) and creates an output(z)

h: x -> z

it looks like

h(x) = g(f(x))

3 steps to write a better function sequence using the composition function in JS

1. Create a new compose function
For me the simplest compose function would be a wrapper function, which receives all required inputs and returns the results of the function sequence execution.

const compose = (ice, tastes, decorateTaste) => 
    form(decorate(mix(ice, tastes), decorateTaste));

// call compose
compose('ice',['🍓', '🍒', '🍇'], '🍫');

// output: " scooped 🍓, 🍒, 🍇 ice cream decorated with 🍫"

2. Reduce the compose function's input parameters
Compose function should take only one single input. This is the data that gets modified throught the function sequence and comes out as output. In our example ice cream is this data.
It matters to keep compose function unary because when calling compose function we only want to focus on the data that is sent to the method and not care about the setting parameters.

As you see in the above picture, Each action(mix, decorate) can be customized by its corresponding setting parameters(berries and chocolate):

// Customized version of mix function using berries
const mixWithBerries = ice => mix('ice', ['🍓', '🍒', '🍇']);

// Customized version of decorate function using chocolate
const decorateWithChoclate = ice => decorate('ice', '🍫');

// Compose function accepts just one single input
const compose = (ice) => form(decorateWithChoclate (mixWithBerries(ice)));

// Call compose. looks nicer!
compose('ice');

3. A more elegant generic way of creating compose functions
In this section we write a compose function generator. Why? Because it is more convenient to use a compose function generator rather than to write a compose function every time if you use compose functions a lot.

You can skip this section if you want to use composeGenerator function available in lodash/fp and ramda libraries.

We also implement our compose function generator in a more elegant fashion than our previous implementation of compose function, where we still have a lot of brackets and the execution order is still from right to left.

Then compose function generator is a function that takes a series of functions(fn1, fn2, ..., fnN) as input parameters and returns a new function(compose). The returned compose function receives data and executes functions(fn1, fn2, ..., fnN) in a given order.

That looks like this:

const composeGenerator = (fn1, fn2, fn3) => data => fn1(fn2(fn3(data)))

// create compose function using composGenerator
const compose = composeGenerator(form, decorate, mix)
compose('ice')

// or
composeGenerator(form, decorate, mix)('ice')

The double arrow in the code above indicates a function composegenerator(fn1, fn2, fn3) which returns another function compose(data).

This implementation of composeGenerator is limited to 3 functions. We need something more generic to compose as many functions as you want:

const composeGenerator = (...fns) => data => 
    fns.reduceRight((y,  fn) => fn(y), data)

const compose = composeGenerator(form, decorateWithBerries , mixWithChoclate )
compose('ice')

// or
composeGenerator(form, decorateWithBerries , mixWithChoclate )('ice')

It's not easy but at least you define it once, and then you don't have to worry about the complexity anymore. Let's break it down into a group of smaller parts to make it easier to understand.

And here is how reduceRigth works when we call composeGenerator with our piepeline functions.

Enhance your compose function with currying

Our solution to remove the setting parameter from our compose function is not good since we will have to write new custom function every time we wish to add a new flavor to our pipeline:

// Change the production line to decorate with 🍓
const decorateWithStrawberry = ice => decorate('ice', ['🍓']);
composeGenerator(form, decorateWithStrawberry , mixWithChoclate )('ice');

// Change the production line to decorate with 🍓 and 🍫
const decorateWithChocAndStrawberry = ice => decorate('ice', ['🍓', '🍫'])
composeGenerator(form, decorateWithChocAndStrawberry , mixWithChoclate )('ice')

Our solution is to implement the curry function, which accepts the tastes and returns the decorate function with one single argument.

// Currying decorate function
const curriedDecorate = (tastes) => (ice) => decorate(ice, tastes);
// Currying mix function
const curriedMix = (taste) => (ice) => decorate(ice, taste);

composeGenerator(
    form, 
    curriedDecorate('🍫') , 
    curriedMix(['🍓', '🍒', '🍇]))('ice')

Like compose functions, we may write our curried functions ourselves or create a generic function that returns a curried version of a function.

You can skip this section if you want to use curry function available in lodash/fp and ramda libraries.

A curry function receives a function fn as input. If the passed arguments(args.length) are at least equal to the function fn's required arguments(fn.length), it will execute function fn, otherwise it will return a partially bind callback.

const curry = fn => ()  ({
        const args = Array.prototype.slice.call(arguments)
        return args.length >= fn.length ? 
            fn.apply(null, args) : 
            currify.bind(null, ...args) 
    })

curry(decorate)(['🍓','🍫']) //output: a function which just needs ice cream as input

When we execute a curryFunction(curriedDecorate) with all the setting parameters(decorateTaste), it returns a new function which only needs one data parameter, and we can use it in our compose function.

A homework for you:

Generally, remember that currying is used to decrease the number of parameters of a function. In our last example, we saw that reducing inputs to a single one can be beneficial when using a compose function but unary functions can be used in more cases where we only require a single argument. For example in arrow functions we can remove the brackets when function just has one parameter:

// 👎
[1,2,3].map(function(digit) {
    return digit * 2
})

// 👍
[1,2,3].map(digit => digit * 2)

As a pratice try to improve this code using currying.

const pow = (base, exponent) => Math.pow(base, exponent)
const digits = [1,2,3];
const exponent = 2;
digits.map(digit, function(digit) {
    return pow(digit, exponent)
})

you can find the solution in this video from Derick Bailey

Your opinion

What is your favorite example of using currying in your code? And generally do you like using it or do you think it makes the code unnecessarily complicated ?

You need types; but not necessarily typescript.

Pegah Safaie — Sun, 21 Mar 2021 21:52:38 +0000

Motivation

There are many good reasons why you might not be a fan of adding typrscript to your project: migration cost, additional transpiling step, or lack of knowledge.
On the other hand we cant overlook the advantages of typing like validation, problem detection at compile time and better debugging experience.
This article shows how the combination of VSCode + ESLint + JSDOC allows you to type your project without using typescript. I created a small JS sample project with a practical readme to play around with this concept.

What I like best about this approach is that you can gradually introduce typing into your project without the need for any extra transpilation step in build or configuration boilerplates in the project.

Requirement

VSCode IDE
ESLint extension installed and enabled.
You must be familiar with JSDoc. Maybe you already used it but did not know its name 😉
A little bit! understanding of typing

Explain the project

What is our goal?

We have a small simple JS project and we want to add typing advantages to that without using typescript. These advantages are:

We want VSCode to show us intelligent code completion, hover info, and signature information.
We want to detect the potential bugs while writing the code, not during runtime.

What is our plan?

Review our JS code to find potential problems caused by lack of typings.
Add JSDoc documentation to our JS files and enable the eslint plugin to see how that changes things.
We will also go over some advanced typing features, such as custom types, imports and unions. Check out the GitHub repository for more examples of inheritance, declaration files and modifiers.
Finally, we will talk about the challenges we might face using this approach.

Start

Our project consists of a number of utils functions(left), and a main file(right) that uses them.

See any problems? Yes! Did eslint or vsCode complain? Not yet!

OK! time to fix them in two steps:

Adding JSDoc to the util methods.
Telling ESLint to be strict with the main.js file!

Still no errors from IDE or ESLint, but autocompleting works now.

Now add // @ts-check to the top of the main.js file and you should see errors appearing. Although isPositive doesn't report any errors, using autocomplete we can see the output which is a string and we can therefore avoid the bug.

Q: Is it possible to define our own custom types? Sure we can, with @typedef annotations of JSDoc. Let's see how.

using @typedef we define a new type named Animal with two properties.
using @type we assign this type to a variable.

Q: Can we use the same type in multiple places? Like we use modules to organize our code? Yes! We can do it by using @import and here's how:

If someone changes the race property to type in the future, our JSDoc annotations help him to see the side effect and fix it!

The Animal type can be defined once at the top of a file and be used many times there afterwards.

The challenges of moving to JSDoc:

Enough talking through the flowers. Things are not always so easy as they are discussed here.
Learning Curve: By complicated typings, you will still need to know about typing concepts and learn JSDoc syntax.

Organizing : Organizing your JSDocs and avoiding duplication. (JSDoc can tie into the modules concept)

Maintenance: Think of JSDoc as some meta data that needs maintenance. If people don't care, and no longer update it as they make changes, there is no benefit to that. Maybe you should include it in your MR process and ask reviewers to double check it.

Useful links:

These decision trees help you to create your first website.

Pegah Safaie — Mon, 08 Mar 2021 11:35:05 +0000

As a frontend developer, people expect me to be good and proficient at building websites. But I am not. I decided to change this, so I started creating my own Portfolio.

Initially I looked for tutorials showing me the general path from a dev point of view but what I found were either too tech specific like 'How to develop website with x and y technologies' or some others articles like 'how to create a website without coding'.

That's how I came up with my own set of decision trees!

First stop: Draw what you want to see at the end

Draw the layout of each page of your website. Think about the user's navigation, positioning and content but ignore details such as styles, colors and fonts.

Don't underestimate this step as it will get you deeper into your project requirements and help you discover issues from the very beginning.

Second stop: Are you a designer?

Templates are the best way to go If you don't need a custom website. They're well-designed and well-organized and save your time. You can even find templates in your favorite CSS frameworks.
Theme Forest prices start from 2$
Free CSS and HTML templates
Jamstack template website Choosing your stack it gives you a starter theme✨.
CSS challenge websites Get the idea and implement your CSS

To find a website designer, it's always best to ask your (social)friends. You can also hire a freelancer through Fiverr or Freelancer. I also search in Figma and Sketch communities to see work samples of designers. If you like their work, you may contact them directly .

To communicate with your designer
1. Prepare first draft of your website skeleton.
2. Inform your designer If you prefer to receive CSS in a specific framework (Tailwind, material, ...).
3. Prepare a list of your favorite websites in your scope.

Third stop: Select your static tech stack

Understanding your content and its updating behavior plays an important role in technologies you choose. If you are the only one updating the website from time to time, put all the content in HTML and ignore the CMS topic, but if you have a non-technical person updating the content, you should choose a CMS for your website.

Traditional CMS vs headleass CMS:
traditional CMS platforms allow non-technical users to create entire website without coding. Selecting template, adding plugins and modifying content all happens in one place. A disadvantage? You are limited to this platform. You can't integrate custom code and functionality to your website.
Using Headless CMS, non technical users still receive a dashboard for easy content creation. However this's it. The rest of site creation is handled by developers calling APIs(REST,GraphQL) to access the content.List of headless CMS for Jamstack sites

Once you've decided on your content, it's time to think about optimization and SEO.

SSG or Static Site Generators:
You decided to fetch your content using APIs. Nice! But it also means your users have to wait for your content to be fetched! Search engines crawlers are even less patient and just ignore your content when they see an asyncronous API call.
Solution? Using SSGs, you can fetch your content in build time and put it in your templates.
Here is a List of SSGs for Jamstack sites. Remember that SSG frameworks can add boilerplate and complexity to your project. If you don't need their features use simpler ones such as 11ty and Jekyll.

Finaly the last part of decision tree belong to our lovely frameworks and libraries.
Do not use frameworks for small simple websites like portfolios. Frameworks add complexity and boilerplate to your website. In many cases a light DOM manipulator like JQuery is all you will need. Although you may not use frameworks, you may still require modules (for example if you would use npm packages). If you use modules in your code, you will also need a module bundler. In most JS frameworks, the bundler is provided and configured by default. But if you don't use a framework, you may need to do it manually. Make sure to not underestimate the amount of time it will take.

Fourth stop: Contact form

The contact form is a must have feature for your Portfolio.

Use EmailJS as a client solution with a generous free tier. If you do not have module bundler in your project, use browser script instead of the npm package.

If you are thinking about implementing your own email service, don't forget about serverless functions as an alternative to building server.

Serverless functions give you all the power of a traditional server app while eliminating the headache of routing, deployment and scaling. Because of this, they're an attractive choice for client developers. The word serverless doesn't mean that there is no server, but that you don't need to think about a permanently up and running server.
This article compares serverless functions with classic server apps.

Final: Hosting

There are many hosts with generous free plans that you can choose from. To avoid confusion, create a matrix for yourself. The vertical axis identifies features you should compare and the horizontal axis names the hosts.
My sample matrix for the free tier looks like this:

	Heroku	Vercel	Firebase
static website	✅	✅	✅
Nodejs	✅	✅
ssl		✅	✅
custom domain		✅	✅
easy deploy	✅	✅

Hosting providers give you a generic domain name like websitename.hostname.---
For a nice looking domain name, buy it separately and add it as a custom domain to your host.

An unexpected sweet conclusion

After finishing this article I just realized that all the decisions we made here led us to the Jamstack approach🍯! to understand Jamstack, I invite you through a discussion I had with myself:

Wise Me: In Jamstack approach, client devs don't write any server code. They call APIs when a dynamic content or server functionality is needed.
Stupid Me: Common! It has been a long time since we have separated client and server projects that communicate through APIs. You just gave it a trendy name.
Wise me: The new trend is not just about separated client and server projects but rather about 3rd party services that offer a wide range of backend functionalities from authentication to API definition. Using them, a client dev can easily develop a web project from scratch without the help of a server dev. For more customized backend functionality, client devs can use serverless functions.
Stupid Me: Got it. You deliver your projects with fewer experts and infrastructures in less time. Are they expensive?
Wise Me: You pay based on your scale. When you have a low traffic website, you don't pay but when your website becomes famous and you get more visitors and customers, you start paying.

PWA for Vue applications: A practical guide

Pegah Safaie — Tue, 23 Feb 2021 14:28:08 +0000

What is PWA?
Fast decoration of your app using PWA Vue CLI plugin
Get deeper on caching
- How does caching affect "reach offline exprience" of my page?
- Customize Vue CLI PWA plugin to support API caching

What is PWA?

Consider the PWA as ice toppings that you can add to your Web App. Each topping is different but by blending them together they turn your Web App into one that tastes exactly like a native app. These flavors have always been available, but Google's chefs put them all together in one tray and called them Progressive Web Apps or PWA!
They even introduced the Lighthouse taster that lets us know how well our web app tastes like a PWA (or better yet, how well it tastes like a native App).
Many apps since then have added these toppings or parts of them to their websites. Some of the most famous ones are Spotify, Housing, and Starbox.

Do you need PWA tray?
In order to reply to this question, you need to know more about the toppings available in the PWA tray along with your customers preferences. If your customers don’t like strawberries in their ice cream, why would you pay for one?

🍓 Reach offline experience: This means your app is available and fast even if the internet connection fails. If your web app is on the intranet, no one will care about this topping. However, people who live in developing countries and users who access your website on their mobile phones may very well value this topping.
🍯 Installable: Installable apps are'nt just accessible via a URL in the browser, but also can be installed on android and ios devices.In this case users will click on an icon to open your app instead of writing the URL in the browser. That's it! You don't have to re-write your app in native or electron.
🍒 Background sync: A Background sync feature lets you defer the actions if the user doesn't have a reliable connection. Imagine that your user fills out a form and presses 'Send'. But there is no connection currently. You don't want his efforts go to waste, so you gather the actions and send it to server as soon as the connection is back.
🍇 push notification: What do you think about mobile app notifications, especially when they're closed? For instance: when you're watching TV and you're receiving a notification from the twitter app, saying: "Hey, somebody gave you a 👍. If you think it's a good idea to notify your users, then the Push notification feature might suit you.

How much time and effort should I spend on this tray?
When using PWA plugins, you can dramatically improve your PWA factor within 30 minutes. After that, it gets exponentially harder to make it better.

Fast decoration of your App using PWA Vue CLI plugin 🍓🍯

I hope you already know about Vue CLI plugins. But don't worry if you don't. They're pretty easy to understand.

Vue CLI is a npm package you install globally on your computer.
It lets you set up Vue projects quickly and without headaches.

Vue CLI Plugins are npm packages you add as dependency to your Vue CLI project,
They add some features and functionalities to your Vue project quickly and without headaches.

Here we use @vue/cli-plugin-pwa to add "🍓Reach offine experience" and "🍯Installable" support to our web app. That’s important to know: you don’t necessarily need a plugin to add PWA support, but using a plugin will make this process faster.

Preparation
I use a simple Vue CLI project for this article. You can find it here but you can use any other Vue CLI project of your choice. If you don't know how to create a Vue CLI project look at this link.

Measure the PWA of your webpage before any changes
Before we make any changes let's see what does Google's taster says about us. I recommend you use Incognito, but Chrome or Firefox works too.
Before running Lighthouse tests on our web app, you have to deploy your app first:

Build your web app in production mode using:
```
 npm run build
```
This command will generate a build directory named (by default) dist.
To run dist folder locally on a HTTP-server, Install the HTTP-server on your machine:
```
 npm install -g serve
```
Now run the server with placing the build directly(dist) on the server:
```
 serve -s dist
```

During development you'll be able to use service worker through localhost, but to deploy it on a site you'll need to have HTTPS setup on your server.

Open the website in your localhost and go to devTools>Lighthouse. Select the "Progressive Web App" category and press 'Generate new report'. That's what you probably see after some minutes.

Apply PWA Plugin
If you are using Git, clean your local changes (commit, stash or discard them). This way you are able to see the changes that were added by the plugin.

To install and invoke PWA Vue CLI plugin execute this command:

 vue add pwa

Measure Again
Build your app again in production mode and deploy it locally. Now we can ask Mr. Taster about the PWA factor.

Congrats! It means that your app works offline and you can register it on "App store" or "Google play store". Take a Look at this article on how to get progressive web app into the google play store.

Get deeper

When I first applied PWA plugin to my app, I didn't have a good feeling about it. Even after receiving a Lighthouse taster award, My app was performing well without me knowing how. I wasn't even asked to config it during the installation process.

That's because the plugin does not aim to confuse you with PWA concepts but instead applies proven best practices that most web applications should follow. It assumes that if you know a lot about PWA configuration, you'll return to do your customizations.

With this section we go one level deeper to see how these best practices can be customized to meet your needs.

How does default caching affect my app?

As said before, "Reach Offline Experience" on a website means that it is fast and accessible even with an unreliable connection.
Service Workers are the heart and soul of this feature. A service worker is a script that runs independently from your webpage and acts as an interconnect between your website and network, implementing caching strategies to reduce traffic between the webpage and server.

This diagram below illustrates you how the service worker caches your essential static resources. The essential static resources are the resources that your webpage requires in order to be initiated. For example html, js, css and image files used in your home page are essential resources for your webpage.

This process is also logged to your console. Don't be confused with the word workbox. It is a webpack plugin used by your serviceworker to complete the precaching process. Let's learn more about it later on.

Looking at the application tab of your browser, you see all the precached resources.

Caching worked fine. But let's see how does caching affect the speed of your webpage?
When we refresh the page here is what happens:

I refreshed both the PWA and non PWA webpages in 3 different network modes. You can see the differences in network tab in the next pictures:

Refreshing without throttleing. The PWA webpage reads from the cache while the non PWA webpage downloads all the resources again. Still you don't see a big time difference in load time as the webpage is small and internet connection is pretty good.
By refreshing with slow 3G the load time difference is 2 times bigger.
Rereshing while offline does not load anything for non PWA webpage. The PW webpage on the other hand is loaded smoothly and fast.

As you can see, with a PWA, there isn’t much difference between the three modes. That indicates this website is quite reliable even when the network is not stable.

Customize Vue CLI PWA plugin to support API caching

It's important to know what the PWA plugin does before we customize our application. Once you activate the plugin, it registers serviceworker.js in your main file. Registering serviceworker from the main file means we want serviceworker to get registered as soon as the page loads. Apart from that, PWA plugin does'nt do much more than organizing! Whenever the project is built, the PWA plugin tells Workbox to generate a serviceworker to cache the static resources. Workbox is the heart of caching strategies. Two modules in Workbox webpack plugins are responsible for implementing caching strategy: 'generateSW' and 'InjectManifest'.
We can use 'generateSW' when we don't have any configuration and we just want to precache essential static resources. Otherwise it's necessary to use InjectManifest. You can find more details on workbox webpack plugin here.

Improve Reach offline exprience of your users

If you prefer to skip the details and go directly to the code, visit my repository here on github.

We have seen how does Vue CLI PWA plugin applies precaching to our webpage. Now Let's improve the project by adding an API request to load some data. It gets an ip address and returns a country name.

How can I cache the response from my API? Can I rely on the default configuration of the PWA Vue CLI plugin?
Unfortunately no! This time we have to add the caching strategy ourselves.
How should we start?
First we need to determine our caching strategy. Google offers a list of caching strategies for a quick start called an offline cookbook.
I also made a simple matrix out of these strategies, so it's easier for me to choose what I want.

Updates Frequency / Fallback Support High Low

True Network First/Stale While Revalidate Cache First

False Network Only Cache Only

Does my API response update often? No! We always get the same country for the same ip.
Does my API need a fallback? Sure. I don't want to enter a risk and not show anything when my cache is empty for the first time.

So i take Cache First strategy which says:

We look in the cache first. If the resource is there we use it. If not, we get it from the network and also update the cache using the response of the network.
I know my strategy. Where should I put it?

Vue CLI PWA plugin configuration is handled via the pwa property of either the vue.config.js file, or the "vue" field in package.json. You can find more details here

In the previous section, we learned that the Workbox webpack plugin includes two caching modules: 'generateSW' and 'InjectManifest'. To customize our caching strategy, we call 'InjectManifest'. The InjectManifest Module requires a js file which contains our extra scripts or logic.

Updates Frequency / Fallback Support	High	Low
True	Network First/Stale While Revalidate	Cache First
False	Network Only	Cache Only

// Inside vue.config.js
module.exports = {
  // ...other vue-cli plugin options...
  pwa: {
    workboxPluginMode: 'InjectManifest',
    workboxOptions: {
      // swSrc is required in InjectManifest mode.
      swSrc: 'src/service-worker.js',
    }
  }
}

Let's put our new strategy in the src/service-worker.js file.

// inside src/service-worker.js 

// define a prefix for your cache names. It is recommended to use your project name
workbox.core.setCacheNameDetails({prefix:  "simple-vue-project"});

// Start of Precaching##########################
// __precacheManifest is the list of resources you want to precache. This list will be generated and imported automatically by workbox during build time
self.__precacheManifest = [].concat(self.__precacheManifest || []);
workbox.precaching.precacheAndRoute(self.__precacheManifest, {});
// End of Precaching############################

// Start of CachFirst Strategy##################
// all the api request which matchs the following pattern will use CacheFirst strategy for caching
workbox.routing.registerRoute(
/https:\/\/get\.geojs\.io\/v1\/ip\/country\.json/,
new  workbox.strategies.CacheFirst()
);
// End of CachFirst Strategy####################

As you might have noticed, once you switch from 'GenerateSW' mode to 'InvokeManifest' mode, there is no default precaching and everything has to be added by hand to the script.

You might be wondering where the workbox came from. There was no import! Workbox injects the whole library from the official CDN during the build process. Not ideal but quick and easy for our tutorial. More information here.

Test our imporvements
Let's check the application and network tabs to make sure our code works. As we mentioned earlier: the app must be built and deployed to your localhost.

Once you make an API call, The response data will be cached and you can see it in your cache list. Now if you switch to offline mode and call the API again, you will receive the response data from the cache.

Congratulations! Your caching strategy has been customized! Please leave me a comment if you have further questions regarding the customization of your caching strategies😊.