At its core, every business thrives on delivering value to its users. When users are unable to access this value due to poor performance, it ultimately impacts the business's success. Slow load times, among other factors, frustrate users and drive them away before they even get a chance to engage.

Optimizing performance is more than just a technical detail – it’s also a critical part of creating a successful application. Without it, even the best features can go unnoticed if users don’t stick around long enough to see them.

In this article, we’ll explore key approaches to optimize your Next.js application, making it faster and more efficient.

Table of Contents

• Building a Performant Application

• How to Optimize Your Applications

• Key Techniques To Optimize Performance

  • Using The Next.js Image Component

  • Optimizing Third-Party Scripts with the Next.js Script Component

  • Remove Unused Packages/Dependencies

  • Caching and Incremental Static Regeneration (ISR)

  • Caching Frequently Used Content

  • Font Optimization With next/font

  • Lazy Loading And Code Splitting

  • Lazy Loading in Next.js

  • Code Splitting

• Conclusion

Building a Performant Application

Making your apps more performant means striking the right balance between speed, responsiveness, and efficient use of resources. You should strive to create an application that delivers value and keeps users satisfied.

Building a performant app is about making sure the app feels smooth and intuitive so that there are no frustrating lags when a user clicks buttons, scrolls, or navigates around. You’ll also want to make sure that data loads or updates without unnecessary delays.

How to Optimize Your Applications

The first step in optimizing your application is identifying problem areas. A number of tools and packages can help you analyze your application's performance effectively. Here's how you can use them:

Using npm run build

When you run npm run build, Next.js creates a production-ready version of your application and gives a detailed breakdown of your pages. This includes:

• Size: The size of the JavaScript files for each route. Highlighting any routes that are too large and could slow things down. Smaller page sizes generally result in faster load times while large pages might take longer to download, especially for users with slower network connections.

• First Load Js: This column provides information about the total amount of JavaScript the browser needs to download and execute to fully render the page for the first time. Large First Load JS values

  cause Slower Time-to-Interactive (TTI).

Running this command produces an analysis like below:

Using @next/bundle-analyzer

The bundle analyzer is a package provided by Next.js to analyze the size of JavaScript bundles by providing a visual representation of the application’s module and dependencies. Here’s how to use the package:

First, install the package by running this command:

npm install @next/bundle-analyzer

Or you can use yarn:

yarn add @next/bundle-analyzer

Then add the @next/bundle-analyzer configuration to your next.config.js file:

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});

module.exports = withBundleAnalyzer({
  // other Next.js config options here
});

To analyze your application bundles while generating a production build, run the following command:

ANALYZE=true npm run build

For a step-by-step guide on how to use the bundle analyzer effectively, check out this detailed video tutorial

Browser tools

Finally, modern browsers, including Google Chrome, Firefox, and Edge, offer powerful tools to analyze and improve your application's performance. Features like the Performance Tab help you record and visualize how your application runs, pinpointing issues like slow rendering or long tasks.

You can also use tools like Lighthouse (available in Chrome and Edge) to generate automated audits, highlighting problems such as large assets and unoptimized resources.

To access the Lighthouse and Performance tabs:

1. Open your browser's developer tools by right-clicking anywhere on the browser and selecting the Inspect option or pressing Command + Option + I (on Mac) or Ctrl + Shift + I (on Windows).

2. Look at the top menu in the developer tools.

3. If you don’t see the Lighthouse or Performance tabs right away, click the double right arrow (>>) to reveal hidden tabs.

4. Select the desired tab to start analyzing performance or generating a Lighthouse report.

Here is an example of a generated audit in the Performance tab on Chrome

Here’s another image showing the generated audit by lighthouse

Key Techniques to Optimize Performance

1.) Using The Next.js Image Component

Images often account for the largest portion of page weight, directly affecting load times and user experience. Large images slow down rendering and ultimately, increase bandwidth usage.

Next.js has a built-in Image component that automatically optimizes images, making it very useful for web performance. It takes care of resizing, lazy loading, and format optimization, so images are served in the most performant format (like .WebP) when the browser supports it.

import Image from 'next/image';

    <Image
      src="/house.jpg"
      alt="House Image"
      width={700}
      height={500}
      priority={false} // Lazy loads the image by default
    />

In the snippet above,

• src="/house.jpg": This points to the image file's location, which is in the public folder. Images in the /public directory are served statically, so you don’t need extra configuration.

• alt="House Image": The alt text (just like in the native HTML image element) provides a description of the image, which is great for accessibility (like screen readers) and also helps with SEO.

• width & height: By explicitly setting the width and height, Next.js can calculate the space the image will occupy on the page before it loads. This prevents the page layout from shifting as the image loads, which improves user experience and boosts performance metrics like Cumulative Layout Shift (as shown in the image above).

• priority={false}: This ensures the image will only load when it's near the user's viewport conserving the bandwidth and improving page load times for non-critical images. However, for important images that should load immediately (like those visible as soon as the page opens), you can set priority={true} to bypass lazy loading and ensure the image loads as quickly as possible.

One of the key advantages of the Next.js Image component is its built-in lazy loading feature. This means that images won’t be loaded until they are actually needed (when they enter the viewport). By only loading images that are about to be viewed, performance is improved and pages can load faster, even with many high-quality images.

2.) Optimizing Third-Party Scripts with the Next.js Script Component

Third-party scripts, such as analytics tools or advertising networks, can heavily affect your application's performance if not properly managed. Next.js has a Script component that makes it easy to load scripts efficiently, giving you control over how and when they load.

The Script component allows you to define a loading strategy for scripts, determining when and how they are fetched and executed. By prioritizing or deferring scripts based on their importance, you can improve the overall performance and user experience of your application.

• beforeInteractive: Use this strategy for scripts that must load before the page becomes interactive, like essential analytics or monitoring tools.

• afterInteractive: When you use this strategy, the script loads after the page becomes interactive, which is the default behavior. This is ideal for scripts that add functionality but aren’t essential for initial rendering.

• lazyOnload: Defers loading the script until all other page resources have finished loading. This is perfect for non-essential scripts like ads or social media widgets.

<Script src="https://example.com/non-essential.js" strategy="lazyOnload" /> //Pass the strategy as a prop to the component

By leveraging the Next.js Script component, you can prevent scripts from blocking critical rendering, reducing load times and improve Time to Interactive (TTI).

3.) Remove Unused Packages/Dependencies

Over time, as you build and maintain your project, unused dependencies can pile up in your codebase. These unnecessary packages increase the size of your project, slow down installation times, and make the code harder to maintain. Cleaning up these unused dependencies is essential for optimizing your application's performance and keeping your codebase clean.

The depcheck tool is a great way to identify and remove unused dependencies from your project. It analyzes your package.json and the project files to find unused dependencies, unused devDependencies, and missing dependencies.

You can run a depcheck like this:

npx depcheck

After identifying the unused dependencies, you can remove them by running:

npm uninstall <package-name>

or with yarn:

yarn remove <package-name>

Regularly running depcheck is a simple yet effective way to keep your project clean and efficient.

4.) Caching and Incremental Static Regeneration (ISR)

When you find yourself running the same calculations or database queries repeatedly, you should consider caching. It’s a simple yet powerful way to boost your web application's performance, especially for content that doesn’t change often. By storing frequently accessed data in a cache, you can avoid unnecessary processing and speed up load times.

In Next.js, you can take this a step further with Incremental Static Regeneration (ISR), which lets you serve static content instantly while keeping it fresh behind the scenes.

Incremental Static Regeneration (ISR) in Next.js lets you update static pages without rebuilding the whole site. Here's how it works:

1. Build time generation: ISR generates pages when the site is built.

2. Caching: It stores the pages so they load quickly when users visit.

3. Background updates: When content changes, ISR updates the pages behind the scenes without affecting users.

4. Dynamic updates: It combines the fast loading of static pages with the ability to update content regularly.

export async function getStaticProps() {

  const data = await fetchData();

  return {
    props: { data },
    //regenerate the page every 20 seconds.
    revalidate: 20,
  };
}

//pre-render the page as static content
function MyPage({ data }) {
  return (
    <div>
      <h1>My Page</h1>
      <p>{data}</p>
    </div>
  );
}

export default MyPage;

Caching Frequently Used Content

For websites with pages that get a lot of visitors, like product listings or blog posts, it's important to keep the content fast and up-to-date.

Caching helps achieve this by saving a copy of the page so it doesn't need to be created from scratch each time someone visits. The browser or server will store this cached page for a set amount of time, which is controlled by caching headers. Meanwhile, ISR (Incremental Static Regeneration) ensures that the page can be updated in the background when necessary, without needing to rebuild the entire site.

In applications with lots of data, caching can also speed up the process by storing API responses. This way, when users request the same data again, they can get it quickly from the cache instead of waiting for it to be fetched anew. Tools like Vercel and Content Delivery Networks (CDNs) help by storing these cached pages in multiple locations around the world, so visitors can access them faster.

export async function getStaticProps() {
  const data = await fetchData();

  return {
    props: { data },
    // Regenerate page at most once every 30 seconds
    revalidate: 30,
    // Cache for 1 hour at the CDN level
    headers: {
      'Cache-Control': 'public, max-age=3600, must-revalidate',
    },
  };
}

Here, the page regenerates every 30 seconds and is cached at the CDN level for one hour. The Cache-Control header tells the CDN and browser to cache the page for 1 hour and revalidate it afterward.

For a deeper dive into caching and its role in web performance, check out this insightful freeCodeCamp article on Caching vs. Content Delivery Networks.

5.) Font Optimization With next/font

The next/font module in Next.js automatically handles font loading for improved performance, so you don’t need to manually configure or use extra libraries. It loads only the essential parts of the font, which results in faster page load times.

To further reduce the font file size, you can provide the subsets array which ensures fewer bytes are transferred and pages load quickly.

Here’s how it works:

• Automatic font loading: The module optimizes font loading automatically, making sure fonts are served in the most efficient way, improving performance without extra effort.

• Subsetting fonts: You can specify the exact font characters needed for your app.

• Font display strategy: The font-display strategy determines how text is shown to the user while fonts are loading. Next.js typically uses the swap strategy by default, but you can manually configure it if necessary. The most common strategies are swap fallback optional and block.

•   import { Inter } from 'next/font/google'
  
    const inter = Inter({
      subsets: ['latin', 'latin-ext'], // Load only the Latin and extended Latin subsets
      weight: '400', // Choose the specific weight you need
      style: 'normal', // Specify the style if needed
    })
  
    export default function Page() {
      return <div className={inter.className}>Hello World</div>
    }
  

The snippet above uses the Next.js built-in tool for Google Fonts. Instead of adding the font link in your HTML or using a third-party library, you can import it directly like this for ease and efficiency.s

• subsets: Tells the app to load only the characters needed. Skipping other character sets like Cyrillic (used in Russian) or Greek, avoids downloading extra, unnecessary data, which keeps your app lightweight and faster to load.

• weight: Instead of loading all font weights (e.g., Bold, Light), you only bring in Regular (400). This reduces the overall size.

• style: Stick with the standard style (no fancy italics). This also trims down what’s downloaded.

6.) Lazy Loading and Code Splitting

When building web apps, you want to make sure your users don’t wait too long for your pages to load. A big part of this involves reducing how much JavaScript is loaded when the page first opens. Two techniques that help with this are lazy loading and code splitting, both of which Next.js makes easy to use.

Lazy Loading in Next.js

Think of lazy loading like waiting to download a movie only when you decide to watch it. Imagine you have a large component like a chart or a map that users only see after interacting with a page. Instead of loading it upfront, you can tell Next.js to load it only when it’s needed using next/dynamic.

Code Splitting in Next.js

Code splitting breaks your JavaScript into smaller pieces (called bundles), so users only load what’s necessary. For example, if a user visits your homepage, there’s no need to load JavaScript for other pages like "About Us" or "Dashboard". It typically happens during the build process or dynamically at runtime.

import dynamic from 'next/dynamic'

// Load HeavyComponent only when it’s rendered
const HeavyComponent = dynamic(() => import('./HeavyComponent'), { ssr: false })

export default function Home() {
  return (
    <div>
      <h1>Welcome Home!</h1>
      <HeavyComponent /> {/* This loads only when rendered */}
    </div>
  )
}

In the above code, dynamic dynamically imports the component only when needed. ssr: false disables server-side rendering for the component, which can save resources if the component doesn’t need to be pre-rendered.

Next.js automatically splits code by page, meaning each page only loads the necessary JavaScript when accessed, improving load times. For more granular control, next/dynamic allows you to dynamically import specific components, ensuring they are loaded lazily only when needed. While Next.js handles page-level code splitting by default, using next/dynamic gives you the flexibility to apply component-level splitting, optimizing resource loading and enhancing performance.

Conclusion

Creating a high-performance application is a very important aspect of any business. A faster and more efficient application enhances user engagement, lowers bounce rates, and boosts SEO rankings, which all contribute to business growth and customer satisfaction.

By utilizing these techniques we discussed in this guide, you can provide a smooth user experience while maintaining optimal efficiency behind the scenes.

Remember, every second saved in load time translates to happier users and, ultimately, better business outcomes.

Thank you for reading!

Want to connect with me?

• Twitter / X: @timi471

• Linkedin: Ayantunji Timilehin

• Email: ayantunjitimilehin@gmail.com

References

• Next.Js Documentation

• Caching-vs-content-delivery-network

• Using next/bundle-analyzer

• Cumulative layout shift

There are various ways to design web applications, including GraphQL, SOAP, Falcor, gRPC, WebSockets, and Serverless Functions, with REST being the most popular (according to the 2021 State-of-API survey by Postman). And at the heart of all these architectures is HTTP.

What to Learn Along with HTTP

To understand HTTP, it is helpful to have a basic understanding of the following concepts:

1. Networking: Knowledge of how computers communicate with each other over networks is essential for understanding HTTP. This includes concepts such as IP addresses, DNS, and routing.
2. Web architecture: HTTP is a key part of web architecture, so understanding how web applications and websites are built can help you understand HTTP better. This includes concepts such as HTML, CSS, and JavaScript.
3. Server-side programming: HTTP is used to communicate between web browsers and servers, so understanding how servers work and how to build server-side applications can help you understand how HTTP works.
4. Client-side programming: HTTP is also used to communicate between web browsers and client-side applications, so understanding how to build client-side applications using JavaScript can also be helpful.

What to Expect in This Article

• How the HTTP protocol works.
• How to make network requests with Chrome and Postman.
• How to upload data with the HTTP POST method in Postman.

By the end of the article, readers should have a basic understanding of HTTP, as well as the tools and resources available for testing and troubleshooting applications.

Table of Contents

• Introduction to HTTP
• What is the HTTP Request-Response Cycle?
• How to Create HTTP Requests
• What is an HTTP Request URL?
• What Are HTTP Request Methods?
• What Are HTTP Request Headers?
• What is an HTTP Request Body?
• What is an HTTP Response?

Introduction to HTTP

HTTP (Hypertext Transfer Protocol) is a protocol used for exchanging information over the internet. HTTP is like the delivery system for information on the internet. It makes sure information goes from one place to another, like how ships carry goods across the ocean. It's the foundation of the World Wide Web.

HTTP is what makes the internet work. It's a way for web browsers and servers to talk to each other and send things like web pages back and forth. It's important for people who build websites and web applications to know how it works.

Without HTTP, it would be difficult to imagine how the internet would work. There would be no web pages, no URLs, and no hyperlinks. Instead, users would need to know the exact IP address of the server hosting the information they want to access, and they would need to use a low-level protocol like TCP/IP to transfer data.

What is the HTTP Request-Response Cycle?

Communication in HTTP centers around a concept called the Request-Response Cycle.

The request-response cycle is the process by which a client (such as a web browser or a mobile app) communicates with a server to retrieve resources or perform actions. The cycle involves several steps:

1. The client initiates a request to the server by sending an HTTP request message, which contains information such as the requested resource and any additional parameters.
2. The server receives the request message and processes it, using its resources to generate a response message.
3. The server sends the response message back to the client, which typically contains the requested resource (such as a web page) and any additional information or metadata.
4. The client receives the response message and processes it, usually by rendering the content in a web browser or displaying it in an app.
5. The client may initiate additional requests to the server, repeating the cycle as needed.

How to Create HTTP Requests

To create a valid HTTP request, you need the following:

• A URL.
• The HTTP method.
• A list of headers (request headers).
• The request body.

Here's an example of an HTTP request header, with three lines:

GET /watch?v=8PoQpnlBXD0 HTTP/1.1
Host: www.youtube.com
Cookie: GPS=1; VISITOR_INFO1_LIVE=kOe2UTUyPmw; YSC=Jt6s9YVWMd4

1. The first line specifies the HTTP method, path, and protocol version. In this case, it is a GET request for the video located at the path /watch?v=8PoQpnlBXD0 using the HTTP/1.1 protocol.
2. The second line specifies the host of the website, which is www.youtube.com.
3. The third line contains a cookie header, which is used for sending and storing small pieces of data on the client side. In this case, the cookie header contains three values: GPS=1, VISITOR_INFO1_LIVE=kOe2UTUyPmw, and YSC=Jt6s9YVWMd4. These values can be used by YouTube to track and personalize the user's experience.

What is an HTTP Request URL?

When a web browser attempts to access an image on the internet, it sends a request to the server using a URL. This URL is unique and points to a specific resource on the server.

A resource can be anything that has a name and can be accessed with a unique identifier like a user, product, article, document, or image. You can think of resources as nouns.

What Are HTTP Request Methods?

The request method tells the server what kind of action the client wants the server to take. The most common methods are:

What Are HTTP Request Headers?

HTTP request headers are additional pieces of information that are sent by the client as part of an HTTP request. They have a name/value format. That is:

Name: Value

These headers provide context and additional instructions to the server, which can be used to process the request or customize the response.

Here's an example of an HTTP request header:

GET /api/data HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
Accept: application/json
Accept-Language: en-US,en;q=0.5
Authorization: Token abc123
Cache-Control: no-cache
Connection: keep-alive
Referer: https://www.google.com/
Pragma: no-cache

In this example, the GET method is used to send a request to the /api/data endpoint on the example.com server using HTTP/1.1 protocol. The request includes ten headers:

What is an HTTP Request Body?

In HTTP, the request body is the data that is sent from the client to the server as part of an HTTP request. The example below shows how to upload an image to the Cat API Server:

And here's what the request looks like:

POST /v1/images/upload HTTP/1.1
Host: api.thecatapi.com
x-api-key: API_KEY
Content-Length: 232
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="/C:/Users/USER/Downloads/cat1.jpg"
Content-Type: image/jpeg

(data)
------WebKitFormBoundary7MA4YWxkTrZu0gW--

The request includes these headers:

1. Host: This header specifies the hostname of the server that the client is trying to connect to.
2. Content-Type: The request is uploading an image file named cat1.jpg using a type of data called multipart/form-data. The image is in JPEG format and its content is included in the request body.
3. x-api-key: This header provides an API key for authentication purposes.
4. Content-Length: This header specifies the length of the request body in bytes. The value of this field is 232.

When the server receives this request, it will parse the request body and use it to create a new entry in the Cat API database. The server will then return a response that includes information about the new entry, such as the image URL and the database ID.

What is an HTTP Response?

An HTTP response is the message that a server sends back to a client in response to an HTTP request. It usually consists of a status line, headers, and a message body:

HTTP/1.1 200 OK
Date: Sun, 28 Mar 2023 10:15:00 GMT
Content-Type: application/json
Server: Apache/2.4.39 (Unix) OpenSSL/1.1.1c PHP/7.3.6
Content-Length: 1024

{
    "name": "John Doe",
    "email": "johndoe@example.com",
    "age": 30,
    "address": {
        "street": "123 Main St",
        "city": "Anytown",
        "state": "CA",
        "zip": "12345"
    }
}

The status line contains the HTTP version, a status code indicating the outcome of the request, and a corresponding message.

The headers provide additional information about the response, such as the content type of the message body or the date and time that the response was sent.

The message body contains the actual response data, such as HTML, JSON, or XML content.

Some common HTTP status codes include:

Here's an example of a JSON response from the Cat API:

{
    "id": "ErDd1JRRT",
    "url": "https://cdn2.thecatapi.com/images/ErDd1JRRT.jpg",
    "width": 4282,
    "height": 6424,
    "original_filename": "cat1.jpg",
    "pending": 0,
    "approved": 1
}

This is a JSON response from a Cat API request that appears to provide metadata about an image that has been uploaded or retrieved from the API. Here's what each field means:

• id: A unique identifier for the image.
• url: The URL where the image can be accessed.
• width: The width of the image in pixels.
• height: The height of the image in pixels.
• original_filename: The original name of the file that was uploaded.
• pending: A flag indicating whether the image is still being processed by the API.
• approved: A flag indicating whether the image has been approved for public use by the API.

Conclusion

HTTP (Hypertext Transfer Protocol) is a protocol used for exchanging information over the internet. It forms the foundation of the World Wide Web and allows communication between web browsers and servers.

This article is a short introduction to HTTP. If you are interested in learning more, check out these textbook recommendations:

• "HTTP: The Definitive Guide" by David Gourley and Brian Totty - This book is widely regarded as the authoritative guide to HTTP. It covers the protocol in-depth and provides detailed information on its features and implementation.
• "HTTP Pocket Reference" by Clinton Wong - This book provides a concise and portable reference to the HTTP protocol. It covers the essentials of the protocol and is a great resource for developers who need quick access to HTTP information.
• "Web Performance Daybook Volume 2: Techniques and Tips for Optimizing Web Site Performance" edited by Stoyan Stefanov - This book is a collection of essays and articles on web performance, including a section on HTTP optimization. It provides practical advice on how to optimize HTTP for faster and more efficient web performance.

We just published a course on the freeCodeCamp.org YouTube channel that will teach you how to monetize your website using microtransactions and the Interledger Protocol.

By the end of this crash course you will know:

• what web monetization is,
• how to implement it onto your website to get paid for your hard work,
• and how to receive payments.

Ania Kubow developed this course. She is a software developer and course creator on YouTube, as well as your guide to the world of Web Monetization.

While you will learn about many different monetization strategies, this course focusses on one in particular. You will learn how to make money from your website without having to reply on third party advertisers or selling your users data.

The method involves users, who value the service you offer them from your website, paying you a very small payment for visiting your site.

You will learn how to develop a website where users can choose either an ad-supported version or an ad-free premium experience where they pay a small fee.

Watch the full course below or on the freeCodeCamp.org YouTube channel (1-hour watch).

URLs are sometimes called web addresses. Like street addresses, URLs are unique, and lead to specific online resources. These resources could be HTML or CSS files, API endpoints, and much more.

Here is the URL to freeCodeCamp's homepage: https://www.freecodecamp.org/

Tim Berners-Lee created the first specification for the URL in 1994. It built upon the existing domain name structure and added slashes (/) to separate directory and file names like computer file systems.

URLs are made up of several parts, and always include the scheme/protocol, domain name, and path to the file or resource. They may also include the port, parameters, and anchor:

_Source: What is a URL?_

The domain names of a URL can be broken down further into a subdomain, second-level domain, and top-level domain.

For example, the freeCodeCamp forum is located at https://forum.freecodecamp.org/.

In this URL, forum is the subdomain, freecodecamp is the second-level domain, and .org is the top-level domain.

The subdomain is a division of the whole domain, and is a bit like a room in a house. Similar to how a bedroom and bathroom serve totally different purposes, different websites or applications can exist on each subdomain. Common subdomains include www, blog, shop, and m for the mobile version of a site.

The second-level domain is the name of your website or resource, and is how people will find it online. Second-level domains are usually the names of people, companies, or organizations.

The top-level domain, or TLD, can give people some information about your company or organization. For example, .com is a generic TLD that can be used for everything from personal sites to online stores. Meanwhile, .org is meant for nonprofit organizations and communities.

These days there are many different TLDs like .dev, .tech, and .rocks.

Whether you know it or not, cookies are everywhere, and for better or worse, they completely changed the way we use the web.

In this article, we'll go over the history of cookies, how they work, how to use them in JavaScript, and some security concerns to keep in mind.

A brief history of cookies

HTTP, or the Hypertext Transfer Protocol, is a stateless protocol. According to Wikipedia, its a stateless protocol because it "does not require the HTTP server to retain information or status about each user for the duration of multiple requests."

You can still see this today with simple websites – you type in the URL to the browser, the browser makes a request to a server somewhere, and the server returns the files to render the page and the connection is closed.

Now imagine that you need to sign in to a website to see certain content, like with LinkedIn. The process is largely the same as the one above, but you're presented with a form to enter in your email address and password.

You enter that information in and your browser sends it to the server. The server checks your login information, and if everything looks good, it sends the data needed to render the page back to your browser.

But if LinkedIn was truly stateless, once you navigate to a different page, the server would not remember that you just signed in. It would ask you to enter in your email address and password again, check them, then send over the data to render the new page.

That would be super frustrating, wouldn't it? A lot of developers thought so, too, and found different ways to create stateful sessions on the web.

The invention of the HTTP cookie

Lou Montoulli, a developer at Netscape in the early 90s, had a problem – he was developing an online store for another company, MCI, which would store the items in each customer's cart on its servers. This meant that people had to create an account first, it was slow, and it took up a lot of storage.

MCI requested for all of this data to be stored on each customer's own computer instead. Also, they wanted everything to work without customers having to sign in first.

To solve this, Lou turned to an idea that was already pretty well known among programmers: the magic cookie.

A magic cookie, or just cookie, is a bit of data that's passed between two computer programs. They're "magic" because the data in the cookie is often a random key or token, and is really just meant for the software using it.

Lou took the magic cookie concept and applied it to the online store, and later to browsers as a whole.

Now that you know about their history, let's take a quick look at how cookies are used to create stateful sessions on the web.

How cookies work

One way to think of cookies is that they're a bit like the wristbands you get when you visit an amusement park.

For example, when you sign in to a website, it's like the process of entering an amusement park. First you pay for a ticket, then when you enter the park, the staff checks your ticket and gives you a wristband.

This is like how you sign in – the server checks your username and password, creates and stores a session, generates a unique session id, and sends back a cookie with the session id.

(Note that the session id is not your password, but is something completely separate and generated on the fly. Proper password handling and authentication is outside the scope of this article, but you can find some in depth guides here.)

While you're in the amusement park, you can go on any ride by showing your wristband.

Similarly, when you make requests to the website you're signed in to, your browser sends your cookie with your session id back to the server. The server checks for your session using your session id, then returns data for your request.

Finally, once you leave the amusement park, your wristband no longer works – you can't use it to get back into the park or go on more rides.

This is like signing out of a website. Your browser sends your sign out request to the server with your cookie, the server removes your session, and lets your browser know to remove your session id cookie.

If you want to get back into the amusement park, you'd have to buy another ticket and get another wristband. In other words, if you want to continue using the website, you'd have to sign back in.

Source: Session vs Token Authentication in 100 Seconds (YouTube)

This is just a simple example of how cookies can be used to keep you signed in to websites. They can be used to remember your setting for dark mode, to track your behavior on a website, and so much more.

How to use cookies

Now that you know about the history of cookies and why they're used, let's look at some of the limitations of using cookies, then dive into some simple examples.

Cookie limitations

Cookies are quite limited compared to some modern alternatives to storing data in the browser like localStorage or sessionStorage. Here's a rundown of cookies compared to those other technologies:

Based on: cookies vs localStorage vs sessionStorage - Beau teaches JavaScript (YouTube)

Cookies are a much older technology, and have a very limited capacity. Still, there's quite a bit you can do with them. And their small size makes it easy for the browser to send cookies with each request to the server.

It's also worth mentioning that browsers only allow cookies to work from one domain for security reasons.

So if you sign in to your bank at, say, ally.com, then cookies will only work within that domain and its subdomains. For example, your ally.com cookie will work on ally.com, ally.com/about, and the subdomain www.ally.com, but not axos.com.

This means that, even if you have accounts and are signed in at both ally.com and axos.com, those sites won't be able to read each other's cookies.

It's important to remember that your cookies are sent with every request you make in the browser. This is very convenient, but has some serious security implications we'll get into later.

Finally, if there's one thing you take away from this article, just remember that cookies are meant to be openly read and sent, so you should never store sensitive information like passwords in them.

How to set a cookie in JavaScript

Cookies are really just strings with key / value pairs. Though you'll probably work with cookies more on the backend, there may be times you'll want to set a cookie on the client side.

Here's how to set a cookie in vanilla JavaScript:

document.cookie = 'dark_mode=true'

Then when you open the developer console, click "Application" and then on the site under "Cookies", you'll see the cookie you just added:

If you take a closer look at your cookie, you'll see that its expiration date is set to Session. That means the cookie will be destroyed when you close your tab / browser.

That might be the behavior you want, like for an online store with payment information.

But if you want your cookie to last longer, you'll need to set an expiration date.

How to set an expiration date on a cookie in JavaScript

To set an expiration date, just set the value of your cookie, then add an expires attribute with a date set sometime in the future:

document.cookie = 'dark_mode=true; expires=Fri, 26 Feb 2021 00:00:00 GMT' // expires 1 week from now

JavaScript's Date object should make this much easier and more flexible. You can read more about the Date object here.

Or you could use the max-age attribute with the number of seconds you'd like your cookie to last:

document.cookie = 'dark_mode=true; max-age=604800'; // expires 1 week from now

Then when that date rolls around, the browser will automatically remove your cookie.

How to update a cookie in JavaScript

Whether or not your cookie has an expiration date, updating it is easy.

Just change the value for your cookie, and the browser will automatically pick it up:

document.cookie = "dark_mode=false; max-age=604800"; // expires 1 week from now

How to set the path for a cookie in JavaScript

Sometimes you'll only want your cookie to work with certain parts of your website. Depending on how your website is set up, one way to do this is with the path attribute.

Here's how to make it so a cookie only works on the about page at /about:

document.cookie = 'dark_mode=true; path=/about';

Now your cookie will only work on /about and other nested subdirectories like /about/team, but not on /blog.

Then when you visit the about page and check your cookies, you'll see it:

How to delete a cookie in JavaScript

To delete a cookie in JavaScript, just set the expires attribute to a date that's already passed:

document.cookie = 'dark_mode=true; expires=Sun, 14 Feb 2021 00:00:00 GMT'; // 1 week earlier

You could also use max-age and pass it a negative value:

document.cookie = 'dark_mode=true; max-age=-60'; // 1 minute earlier

Then when you check for your cookie, it'll be gone:

And that should be everything you need to know about using cookies in vanilla JS.

Everything we covered will work in a pinch, but if you plan on working with cookies extensively, look into libraries like JavaScript Cookie or Cookie Parser.

Security concerns with cookies

In general, cookies are very secure when implemented correctly. Browsers have a lot of built-in limitations that we covered earlier, partly due to the age of the technology, but also to improve security.

Still, there are a few ways that a bad actor can steal your cookie and use it to wreak havoc.

We'll go over some common ways this can happen, and look at different ways to fix it.

Also, note that any code snippets will be in vanilla JavaScript. If you want to implement these fixes on the server, you'll need to look up the exact syntax for your language or framework.

Man-in-the-middle attacks

A man-in-the-middle (MitM) attack describes a broad category of attacks where an attacker sits between a client and a server and intercepts the data going between the two.

Source: Man-in-the-Middle Attacks and How To Avoid Them

This can be done in a lot of ways: by gaining access to or listening in on an insecure website, mimicking a public WiFi router, DNS spoofing, or through malware / adware like SuperFish.

Here's a high-level overview of MitM attacks, and how websites can protect themselves and their users.

Warning: The beginning of the video talks about Mary, Queen of Scotts, and shows an animated depiction of her beheading. It's not overly gruesome, but if you'd like to avoid it, skip ahead to this timestamp:

As a developer, you can greatly reduce the chance of a MitM attack by ensuring that you enable HTTPS on your server, use an SSL certificate from a trusted certificate authority, and ensure your code uses HTTPS instead of the insecure HTTP.

In terms of cookies, you should add the Secure attribute to your cookies so they can only be sent over a secure HTTPS connection:

document.cookie = 'dark_mode=false; Secure';

Just remember that the Secure attribute doesn't actually encrypt any data in your cookie – it just ensures that the cookie can't be sent over an HTTP connection.

However, a bad actor could still possibly intercept and manipulate the cookie. To prevent this from happening, you can also use the HttpOnly parameter:

document.cookie = 'dark_mode=false; Secure; HttpOnly';

Cookies with HttpOnly can only be accessed by the server, and not by the browser's Document.cookie API. This is perfect for things like a login session, where only the server really needs to know if you're signed into a site, and you don't need that information client side.

XSS attacks

An XSS (cross-site scripting) attack describes a category of attacks when a bad actor injects unintended, potentially dangerous code into a website.

These attacks are very problematic because they could affect every person that visits the site.

Source: Cross-site scripting

For example, if a site has a comments section and someone is able to include malicious code as a comment, it's possible that every person who visits the site and reads that comment will be affected.

In terms of cookies, if a bad actor pulls off a successful XSS attack on a site, they could gain access to session cookies and access the site as another signed in user. From there, they may be able to access the other user's settings, buy things as that user and have it shipped to another address, and so on.

Here's a video that gives a high-level overview of the different types of XSS – Reflected, Stored, DOM-based, and Mutation:

As a developer, you'll want to ensure that your server enforces the Same Origin Policy, and that any input you receive from people is properly sanitized.

And like with preventing MitM attacks, you should set the Secure and HttpOnly parameters with any cookies you use:

document.cookie = 'dark_mode=false; Secure; HttpOnly';

CSRF attacks

A CSRF (cross-site request forgery) attack is when a bad actor tricks a person into carrying out an unintended, potentially malicious action.

For example, if you're signed into a site and click on a link in a comment, if that link is part of a CSRF attack, it may lead to you unintentionally changing your sign in details, or even deleting your account.

Source: Cross-site request forgery

While CSRF attacks are somewhat related to XSS attacks, specifically reflected XSS attacks where someone inserts malicious code into a site, each preys on a different type of trust.

According to Wikipedia, while XSS "exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser."

Here's a video that explains the basics of CSRF, and gives some useful examples:

As for cookies, one way to prevent possible CSRF attacks is with the SameSite flag:

document.cookie = 'dark_mode=false; Secure; HttpOnly; SameSite=Strict';

There are a few values you can set for SameSite:

• Lax: Cookies are not sent for embedded content (images, iframes, etc.) but are sent when you click on a link or send a request to the origin the cookie is set for. For example, if you're on testing.com and you click on a link to go to test.com/about, your browser will send your cookie for test.com with that request
• Strict: Cookies are only sent when you click on a link or send a request from the origin the cookie is set for. For example, your test.com cookie will only be sent while you're in and around test.com, and not coming from other sites like testing.com
• None: Cookies will be sent with every request, regardless of context. If you set SameSite to None, you must also add the Secure attribute. It's better to avoid this value if possible

Major browsers handle SameSite a bit differently. For example, if SameSite isn't set on a cookie, Google Chrome sets it to Lax by default.

Alternatives to cookies

You might be wondering, if there are so many potential security flaws with cookies, why are we still using them? Surely there must be a better alternative.

These days, you can use either sessionStorage or localStorage to store information that originally used cookies. And for stateful sessions, there's token-based authentication with things like JWT (JSON Web Tokens).

While it may seem like you have to choose between cookie-based or token-based authentication, it's possible to use both. For example, you might want use cookie-based authentication when someone signs in through the browser, and token-based authentication when someone signs in through a phone app.

To muddy the waters a bit more, authentication-as-a-service providers like Auth0 allow you to do both types of authentication.

If you'd like to learn more about web tokens and token-based authentication, check out some of our articles here.

When you give a developer a cookie

That's it! That should be just about everything you need to know to get started with using cookies, and what to watch out for along the way.

Did you find this useful? How do you use cookies? Let me know over on Twitter.

If you've been online for any amount of time, no doubt you've seen the somewhat vague 503 Service Unavailable error.

In this article we'll go over HTTP status codes, what the 503 error means, and some possible ways to solve it – both for a site you're trying to visit and for your own site.

An overview of HTTP status codes

Servers that host web pages listen for requests from web browsers or devices, also known as clients. The server then uses a bunch of different status codes to communicate back.

These status codes are organized into different classes, which is indicated by the first number of the status code:

• 1xx: Information – the server is still processing the request
• 2xx: Success – the request succeeded and the server responds with the page or resource
• 3xx: Redirection – the page or resource has moved and server will respond with its new location
• 4xx: Client error – there is an error in the request from the browser or device
• 5xx: Server error – there is an error with the server

The last two digits of each HTTP status code represent a more specific status for each class. For example, 301 means that a page or resource has moved permanently, while 302 means the move is temporary.

Check out this page for a list of common HTTP status codes and their meaning: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Most status codes go by totally unnoticed, which is fine because it means everything is working. It's only when you get to the 4xx-5xx range that you might notice a status code because you'll see a page like this:

A typical 503 error page – Source: Stack Overflow

Now that you have a basic understanding of HTTP status codes, let's dig a bit deeper into the 503 Service Unavailable error.

What does the 503 error code mean?

As mentioned above, 5xx status codes mean there's a problem with the server itself.

A 503 Service Unavailable error means that the page or resource is unavailable. There are many reasons why a server might return a 503 error, but some common reasons are maintenance, a bug in the server's code, or a sudden spike in traffic that causes the server to become overwhelmed.

The message that's sent with the 503 error can vary depending on server it's coming from, but here are some of the common ones you'll see:

• 503 Service Unavailable
• 503 Service Temporarily Unavailable
• HTTP Server Error 503
• HTTP Error 503
• Error 503 Service Unavailable
• The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Source

Whatever the reason for the 503 error, it's usually temporary – the server will restart, traffic will die down, and the issue will resolve itself.

How to solve the 503 Status Unavailable error

When trying to solve a 503 error, there are two general camps.

The first is where you're an end user, and you're trying to visit a site that you don't own. In the second, you own the site, and it's throwing 503 errors to people who are trying to visit.

The method to solve 503 errors is different depending on which group you fall into. Let's take a look at some things you can do as an end user if you see a 503 error.

How to solve a 503 Status Unavailable error as an end user

Since 5xx status codes mean that the error is on the server-side, there isn't a lot you can do directly.

Even though 503 errors are usually temporary, there are some things you can do while you wait.

#1: Refresh the page

Sometimes the error is so temporary that a simple refresh is all it takes. With the page open, just press Ctrl - R on Windows and Linux, or Cmd - R on macOS to refresh the page.

#2: See if the page is down for other people

The next thing you can do is use a service like Is It Down Right Now? or Down For Everyone Or Just Me to see if other people are getting the same error.

Just go to either of those sites and enter in the URL for the page you're trying to visit.

The service will ping the URL you entered to see if it gets a response. Then it'll show you some cool stats and graphs about the page:

Checking freeCodeCamp on Is It Down Right Now?

If you scroll down a bit you'll see some comments from other people. Often people will give their general location and other data, so this can be a good way to determine if the error is just affecting certain regions or specific devices.

#3: Restart your router

Sometimes the issue has to do with a DNS server failure.

DNS stands for Domain Name System, and they basically act as translators between IP addresses and human readable URLs.

For example, you can visit Google by entering its long IP address directly (172.217.25.206), or you can just enter in the URL, www.google.com.

It's a DNS, often hosted on a server, that handles all that behind the scenes.

All of that is to say, many routers cache responses from DNS servers (www.google.com <==> 172.217.25.206). But sometimes this cache can get corrupted and cause errors.

An easy way to reset or "flush" the cache is to restart your router. Just unplug your router for about 5 seconds, then plug it back in again.

It should restart after a minute and all of your devices should reconnect automatically. Once they do, try visiting the site again.

How to solve a 503 Status Unavailable error as the site's owner

If you are the owner/developer of the site that's returning 503 errors, there's a bit more you can do to diagnose and resolve the issue.

Here are some general tips to get you started:

#1: Restart the server

Development is tough – even a simple static page can have so many moving parts that it can be difficult to pin down what's causing the 503 error.

Sometimes the best thing to do is to restart the server and see if that fixes the issue.

Source: imgflip

The exact method of restarting your server can vary, but usually you can access it from your provider's dashboard or by SSH'ing into the server and running a restart command.

The server should restart after a couple of minutes. If you've configured everything to run automatically on boot, you can visit your site and see if it's working.

#2: Check the server logs

The next thing to do is check the logs.

The location of the server logs can vary depending on what service you're running, but they're often found in /var/log/....

Take a look around that directory and see if you can find anything. If not, check the manual for your programs by running man program_name.

#3: Check if there's ongoing automated maintenance

Some service providers offer automated package updates and maintenance. Normally this is a good thing – they usually occur during downtime, and help make sure everything is up-to-date.

Occasionally 503 errors are due to these scheduled maintenance sessions.

For example, some hosting providers that specialize in WordPress hosting automatically update WP whenever there's a new release. WordPress automatically returns a 503 Service Unavailable error whenever it's being updated.

Check with your service providers to see if the 503 error is being caused by scheduled maintenance.

#4: Check your server's firewall settings

Sometimes 503 Service Unavailable errors are cause by a misconfigured firewall where connections can get through, but fail to get back out to the client.

Your firewall might also need special settings for a CDN, where multiple connections from a small handful of IP addresses might be misinterpreted as a DDoS attack.

The exact method of adjusting your firewall's settings depends on a lot of factors. Take a look at your pipeline and your service provider's dashboards to see where you can configure the firewall.

#5: Check the code

Bugs, like errors, happen. Try as you might, it's impossible to catch them all. Occasionally one might slip through and cause a 503 error.

If you've tried everything else and your site is still showing a 503 Service Unavailable error, the cause might be somewhere in the code.

Check any server-side code, and pay special attention to anything having to do with regular expressions – a small regex bug is what caused a huge spike in CPU usage, rolling outages, and about three days of panic for us at freeCodeCamp.

Hopefully you'll be able to track down the culprit, deploy a fix, and everything will be back to normal.

In summary

That should be everything you need to know about 503 Service Unavailable errors. While there's usually not much you can do when you see a 503 error, hopefully some of these steps will help the next time you encounter one.

Stay safe, and happy refreshing-until-it-works :)

Are you planning to get into web development? Take a tool with you, it's scary out there. Let's take a look at some common web development tools that'll help you speed up your workflow and be a better web developer.

Note that your mileage may vary a lot. This article just lists the most popular solutions out there in the wild. You still need to integrate them in your projects and learn more about them.

With that being said, here's a list of most common tools/packages I use in my workflows regularly.

#1 VSCode ?

VSCode needs no introduction. It's a beautiful and powerful code editor that supports extensions, integrated terminal, snippets, themes, shortcuts, remote SSH, and much more - according to your needs.

Running on top of electron, it is cross OS compatible and is constantly improved by Microsoft as an open source project. VSCode comes with a rich set of tools, IntelliSense through Language Server Protocol, and quick fixes/patches all through the year.

Get VSCode now from the official VSCode site.

#2 Webpack ?

Webpack sells itself as a module bundler, but in reality, it is much more extensible than that. You can attach a plethora of plugins and tweak its configuration to make it more robust and fit to your needs.

Webpack 4 comes as a zero config module bundler - that means you can get started with Webpack almost immediately! You just have to download the module using npm i webpack and then run npx webpack in your directory. Here's how to setup zero configuration with webpack:

#3 Cypress ?

Cypress is a great e2e testing tool which can actually spin up a headless or a full chrome window to run actual tests of your code. It can interact with asynchronous code in a very intuitive manner. For example, it waits for resources to load/become available, unlike Selenium, which is quite an old technology made for automated testing of mostly static sites. Let's see how Cypress works through a quick video:

Cypress tests are very simple and human-friendly to write, and it does all the heavy lifting out of the box (like launching a chrome instance, proper keyboard events, trusted event emitters, you name it). Get cypress here.

#4 TypeScript ?

Writing plain JavaScript? It can be really painful to find subtle bugs and errors without proper linting. To make it even more powerful with better type checking and module autocompletion, take TypeScript with you.

TypeScript is a superset of JavaScript which transpiles down to JavaScript before executing. This means that you get JavaScript running just like before, but with the added development benefit of coding JS in a 'stricter' manner.

It wouldn't be wrong to say that TypeScript really enables helpful JavaScript codebase maintenance and makes refactoring a breeze. You can start learning TypeScript through their official docs.

#5 Sentry ?

Sentry is an error reporting service for production. Many a time, especially on the front end, your users might face crashes or unexpected bugs.

I personally use Sentry for codedamn, and I've fixed quite a few nasty bugs and causes of crashes which were rare and had happened to very specific users during very specific actions taken on the platform.

As a bonus, Sentry exists on a lot of platforms, and is not only restricted to JavaScript runtimes. This means Sentry can be used with mostly any popular tech stack.

Sentry sends full stack trace/information about the bug right into your dashboard so that you can fix that nasty bug on the next release cycle. Read about sentry here.

#6 Git ?

Git is the magic wand of any large project. Git is a Version Control System (VCS) allowing you to incrementally build your software, while maintaining a complete diff of the previous builds. This means you don't lose any history and can easily revert back to last working point.

Not only this, you can branch off and work on something completely different, without actually affecting the original project. This concept is called branches in git. There's so much more about git you can learn. I love this series from thenewboston on git. Have a look:

The most popular solution for hosting git repos is GitHub. It offers free public and private repositories. You can learn more about git here.

#7 Babel ?

Babel allows you to write bleeding edge JavaScript features, but then transpile them to browsers in a standard those browsers know and have implemented for ages.

Using babel with webpack is a very powerful combination that allows you to use cutting edge features and then bundle/minify them together. This provides the best experience for developers when developing apps as well as for serving minified builds to users for speed and performance.

For example, you can write ES2020 code in babel and let it transpile it down to the ES2015 version to ship to browsers. It makes writing JavaScript really fun and convenient as it allows you to use JavaScript from the future! Learn about babel here.

#8 Material UI ⭐️

Material UI is a specification from Google on how layouts should be created. On top of Material UI, there are a lot of component libraries available for a number of frameworks like Angular, React, or React Native. Some component libraries include:

1. Material UI - React
2. React Native paper
3. Vuetify
4. Angular Materials

This eases the process of building a lot of components manually for developers. And at the same time, it provides them with fast and well-designed components. Learn about Material UI here.

#9 Joi ?

Data validation is an important part of any application. This is because you can never trust data coming from a user. For large scale applications with multiple endpoints to reach to backend server, it can become very tricky to handle all the edge cases.

Joi is a very handy library that helps you validate all the incoming data through a strict predefined schema. Joi allows you to construct schemas for arrays, objects and even the values they should accept.

Should the input fail, it also allows you to customize the error messages. No more hassles of obj && typeof obj === 'string' in your code anymore! Using Joi's schema is not only safe but also makes your code much more readable for other developers. Learn more about Joi here.

#10 Docker ?

Setting up docker for development comes with its own set of challenges (speaking from experience). But once done, it's worth the investment. Partially because you remove the "it-works-on-my-machine" errors.

But also, running sandboxed code has another benefit. In the unfortunate event that your web application is hacked or brought down, the docker container would make sure that the attack is contained to only that particular container and no other service is affected (unless, of course, your container has substandard security rules).

You can get started with Docker today! Start with this playlist:

Conclusion

The web is vast, and if you're just getting started it can be overwhelming to begin! Get some help from fellow developers who've been in your shoes. You can even reach out to me on twitter / instagram and connect. I'll be happy to help.

Do you wish to learn web development and other programming languages in a completely new way? Head on to a new platform for developers I'm working on to try it out today!

Sir Issac Newton discovered the law of gravity when practicing “social distancing” during the Plague. What will YOU do? One silver lining of quarantine is that all this free time brings out the entrepreneur spirit and creativity in us.

However, especially because of the quarantine, now more than ever, any new idea or project must have a web site. Traditional CMS solutions like Wordpress, Squarespace, or Wix are difficult to use, look dated, are expensive, or all of the above!

We wanted to create a web site that has a sophisticated look and feel, yet is easy to customize. A non-technical person should be able to edit the source files and see the changes appear on the live web site in a few minutes. Ideally, it should also be free (forever free, not just free-for-now), and can scale to handle millions of visitors if it becomes popular.

Is this possible?

In this short article, I will walk you through a solution based on the Hugo framework, GitHub Pages, and GitHub Actions. You can get up and running with your shiny new website by the end of this article.

It is so easy that my 9-year-old son did it. He now manages a web site for his fictional country called Arenztopia. Check out the back story.

TL;DR

If you just want to get started with a working web site as soon as possible, first make sure that you have a free GitHub account.

Go to this GitHub repository, and click on the “Fork” button on the top right, and fork it to your own account.

Go to your forked repository, and click on the Actions tab. You will see a message like the one in the picture below. Click on the “I understand my workflows …” button.

Go to the Settings tab of your repository, and then scroll down to GitHub Pages. Re-select the gh-pages from the dropdown for the web site to build.

Go to the Code tab of the repository, open the config.toml file, and edit it. Change its title attribute to something else, and click on the “Commit changes” button at the bottom. We need this step to trigger the workflow at the new repository.

Wait a few minutes, go to the “published at” web address at GitHub Pages and you will see the template web site.

Next, you can customize the site by editing the config.toml file and the files in the content folder. Go to the “Add your own content” section at the end of this article to see how. You can check out the instructions for the Ananke theme here.

That’s it for the quick start! In the next several sections, I will explain in more detail the concepts and processes.

Hugo basics

Older generation CMS solutions like Wordpress are too difficult to adapt to new web site designs, and commercially hosted solutions like SquareSpace are too expensive and not flexible enough. Static web site generators like Hugo offer a good balance among features, flexibility, and ease of authoring.

• Hugo web sites can be customized and modified through configuration files.

• New pages and content sections can be written in markdown instead of HTML. That makes content authoring much easier.

• There are many modern design themes to choose from.

• The output of Hugo is a static HTML web site that can be deployed on any low-cost hosting provider.

• Together with static web site hosting services like GitHub Pages and Netlify, they can offer a completely free solution.

The Hugo software distribution is available on all major operating systems. You can learn about it here. But, since we will use GitHub Actions to automatically build our Hugo web sites, we do not actually need to install Hugo software here.

Here is how to do it.

Create a template website

First, select a Hugo theme. There are many. Some are geared toward web sites with one or more content web pages, while others are optimized for blog-like sites with timestamped posts.

Hugo themes

Find one you like, download a zip package or clone a GitHub repo, and unpack the theme into a folder. Let’s assume that the theme distribution is unpacked into a folder called my-theme. The following are commands in a Linux terminal. You could use the Terminal app on Mac or PowerShell on Windows.

Next, create your web site project directory on your computer.

$ mkdir -r my-site/themes

Copy the theme folder into your project.

$ cp -r my-theme my-site/themes

Next, copy the theme’s exampleSite to the project’s top-level directory.

$ cd my-site
$ cp -r themes/my-theme/exampleSite/* ./

Edit the config.toml in the project root directory my-site/ to point to the right theme.

baseURL = "/"themesDir = "themes"theme = "my-theme"

Next, create a GitHub repo called my-site, and push the my-site directory onto its master branch. Here are the steps for uploading files from GitHub’s web UI. Now we are ready to publish the theme example site.

For a Hugo-based system to be useable to a non-developer (or a young developer who has yet to master the command line tools), we must automate the process of building and deploying the static web site.

Automate deployment

In the GitHub project, go to Settings and enable GitHub Pages. Select the source to be the gh-pages branch.

Settings, GitHub Pages

Next, we create a GitHub Actions workflow to run the Hugo command on the source files from master branch, and push the generated HTML files to the gh-pages branch for publication. From the project’s Actions tab, click on the “set up a workflow yourself” button.

Set up a workflow yourself

The workflow is stored in the master branch as .github/workflows/main.yml file. The content of the file is as follows.

name: github pages

on:
  push:
    branches:
      - master

jobs:
  deploy:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v1  # v2 does not have submodules option now
        # with:
        #   submodules: true

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: '0.62.2'
          extended: true

      - name: Build
        run: hugo

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public

What happens here is that the web site authors and editors will change content and files on the master branch. Whenever new content is pushed to the master branch, the automated GitHub Actions workflow will set up the Hugo software, run the hugo command, and turn those files into HTML files for a static web site.

The HTML files are pushed to the gh-pages branch of the same repository. They will be published on the specified web address by GitHub Pages as configured.

Notice the cname attribute in the last line. That is the custom domain name we set up with GitHub Pages. If you do not have a custom domain name, just remove this line, and you can access your web site at the domain provided by GitHub Pages.

Now go to the web site, and you should see the theme’s default web page.

The HugoSerif template for one of our web sites.

Add your own content

To change the default theme web site to your own content, you just need to change the files on the master branch. Please refer to the documentation of your selected theme. In general, Hugo templates work like this:

• The web pages are authored in markdown format and the md files are in the content folder.

• Each md file has a header section with properties such as the page’s menu placement, priority, timestamp, excerpt, etc.

• The overall configuration, such as the menu items and properties used by multiple pages, are stored in the data folder.

• Static content such as raw HTML files, JavaScript files, and image files can be placed in the static folder.

In particular, here is how you customize the Ananke theme that comes with our template:

• The config.toml file allows you to configure the website title, social icons on all pages, and the big featured image on the home page.

• All images should be uploaded to the static/images folder.

• The content/_index.md file contains the text for the home page.

• To add pages to the site, you can just create markdown files in the content folder. An example is the contact.md file. Notice that at the top of the file, there are attributes to control whether this page should be on the website menu.

• To add articles to the site, you can create markdown files in the content/post folder. Those are blog-like content articles that have dates and titles at the top. The most recent two articles will show up on the home page.

If you are interested in learning more and see how we did it, you can watch our progress at

• The Country of Arenztopia [GitHub] [Web site]

• Second State blog [GitHub] [Web site]

Good luck and stay healthy!

About the author

Dr. Michael Yuan is the author of 5 books on software engineering. His latest book Building Blockchain Apps was published by Addison-Wesley in Dec 2019. Dr. Yuan is the co-founder of Second State, a VC-funded startup that brings WebAssembly and Rust technologies to cloud, blockchain, and AI applications. It enables developers to deploy fast, safe, portable, and serverless Rust functions on Node.js.

Prior to Second State, Dr. Yuan was a long time open source contributor at Red Hat, JBoss, and Mozilla. Outside of software, Dr. Yuan is a Principal Investigator at the National Institutes of Health, with multiple research awards on cancer and public health research. He holds a PhD in astrophysics from the University of Texas at Austin.

Twaikura, haikus but funnier

As easy as ABC: some stranger on the Internet starts a 120 characters story, some stranger on the Internet finishes it. And that makes a Twaiku (tweet + haiku). Twaikus can be funny, serious, artistic, it’s up to you.

So, as a developer, implementing something like that shouldn't be hard, right? Yes, but no. Here is the story of how it took me multiple years to create Twaikura and how you could do the same in a matter of hours.

Back to TwentyParts and why it never came to existence

TwentyParts was my first “entrepreneurial concept” back in 2015. As you may guess, the idea is to write a story in 20 parts, with each part written by a different author.

I was a CS student at the time and it took me 2 months to release a first draft. The result was disastrous. I didn’t even know about the concept of a “framework”, picture the code. The concept was too complex, the interface unusable.

I did not give up. A few months later, in 2016, I came up with a simplified version of TwentyParts, HiKoo. I limited the length of a story to 3 tweets. And instead of rushing to development, I created mocks using a marvelous tool named MarvelApp.

Now I had a great UI and all, but no working code. One more app that never came to existence.

Looks good, doesn't work

Fast forward to now. I’ve graduated. I’ve built my consulting company, LBKE. I’ve developed complex SaaS platforms for multiple clients. And I've kept this question running in my head:

What prevents me from recreating TwentyParts, now I am fast and skilled and over-confident?

After all, it would only take a full work week nowadays. Yet there’s a problem: I am not a student anymore. With one spare hour here and there, a “full work week“ can span over a few months. Too slow.

How to code fast: don’t.

I’ve explored thoroughly the realms of fast web development. You may have read my previous articles on freeCodeCamp about Vulcan, a framework based on Meteor that makes me very productive.

Those researches all lead me to the same conclusion: the best code is the code you don’t write.

There are a lot of ways NOT to write code, even for a developer. Scaffolding, declarative programming, using snippets, or using an ORM are all methods to circumvent writing code. Using open source is another great example. Some may even think that developers are a bit lazy – but aren't they?

Yet minimal skills in web development are still necessary. That means careful thinking, lots of doc reading, debugging and so on. In the end, the time needed to create a fully functional app can only be reduced this much.

You know what? Using a massive framework to speed up developments feels like cheating sometimes. What if I did not have those skills? What if I was not a developer? I would have no other choice than embracing the “no-code way”. And that’s what I’ve done.

Relax, Code will be on vacation for the remainder of this article

Sparkling innovations for web non-developers

No-code solutions have been pretty bad in the past. Limited, difficult to extend, proprietary, expensive, the list is long. But some recent tools are starting to be worthy enough.

I will focus specifically on Bubble. Its plugin system coupled with its data management features makes it the most complete solution on the market currently. Here are a few key features and how I used them to build Twaikura.

The UI editor

Bubble proposes a WYSIWYG editor (What You See Is What You Get) to create the app user interface. You put your blocks of content wherever you want, and configure their content.

It’s grid-based so you can have pixel perfect alignment. It handles responsiveness. So you should be able to create designs as complex as you wish.

Building Twaikura's interface using the WYSIWYG editor.

But I’ll be honest, I am not the hugest fan. More precisely, I am not very good with it. It’s very different both from writing HTML/CSS and from using web-based design tools like Figma, so there is a learning curve.

I ended up sticking myself to an old school Windows 98-ish style. With a little bit of imagination you could even believe it has some “V a p o r w a v e” aesthetic.

Thinking in workflows

The most impressive feature of Bubble to me is its “Workflows”. It lets you describe complex process in a visual language. It can mix data management (validating and storing a Twaiku, sending an email) and user experience (resetting a form, refreshing the page) transparently. You don’t need to mentally split the workflow between frontend and backend as you would do in a traditional web app.

Twaiku creation workflow

This example workflow is triggered when the user wants to submit the second part of a Twaiku. It will create a "Twaiku End" in the database, link it with a "Twaiku Begin", and reset the form. I could also display a success message, send a mail to a moderator and so on. Visualizing the full workflow in a single timeline is very intuitive.

Complete data management

Bubbles comes with a relational database and complete filtering features. That means you can easily create both forms and list of data. For example, the “Read latest Twaikus” block will load all valid Twaikus.

Plugins can help secure your content. For example, there is a ReCaptcha plugin to add CAPTCHAs to your form in a matter of minutes. This is important as security is usually left behind in the prototyping steps. Malevolent bots and hackers don't care that you are a "lean startup-er", and they won't miss an opportunity to spam or hack your website.

A few hours of work for an app that works

I won’t describe all features of Bubble, because it has a lot more. The conclusion is that it's been powerful enough to write an app like Twaikura. Instead of writing tons of crappy code that will end up in a dumpster, instead of creating a visual prototype as lively as Frankenstein’s Creature, I just created something that works.

Is my website great? Honestly, not yet. Does it do the job? Hell yes. I had fun creating it, it cost me no more than a few hours, and I am able to test the concept in the most direct possible way. The longest part was writing this article.

I especially recommend no-code tools for people who want to learn web development. Taking a lot of time to produce simple features can feel frustrating at first. Using a no-code tool alongside traditional programming is a way to keep having fun. It's instructive too, because, even if you don't write code, you still have to think like a developer: designing conditional workflows, structuring a database, validating forms... That's a win-win.

I won't become a no-code evangelist, but Bubble is a great addition to my tool belt. And it could be great addition to yours too!

Thanks for the read. If you liked this article, come try a Bubble app by creating your first Twaiku on twaikura.com!

Imagine software that you work on. It was written by programmers before you joined the team and the software works properly. There are some bugs that need to be fixed but it does what it’s supposed to do. Nothing else. This is what others see from outside of the code–software that solves customers’ problems and works as expected.

But what about the code? What about the programmers? What do they think about their software?

As one of the programmers that built this software, you see totally different things from inside the code.

First things first, you think the code base is so big. You know certainly that this software could have been written with much less code while still providing the same functionality. The code base seems so complex to you. You know that the code could have been written in a better, simpler, and more well-structured way.

Adding new features or implementing something new is hard and painful because you have to consider the other parts that are connected to each other. The modules are not loosely coupled, so making changes takes too much time. And what about debugging? Finding bugs and fixing them takes too much time as well.

Besides the bad design and ugly code, the software works properly and the customers are happy. Now you are at the crossroads. There are two possible ways for you: one way tells you that you should follow the old engineering adage, “If it works, don’t fix it.” The other one that tells you that you should do some refactoring to make your job easier while working on your code base so that you have more readable and understandable code.

Which way would you prefer? Would you follow the old engineering adage “If it works, don’t fix it?”

Two different programmer mindsets

The answer to that question can be simple. But before explaining the appropriate answer, I want to introduce you to two different programmer’s mindsets when it comes to fixing bad code that works properly.

The first mindset believes in the old engineering adage: “If it works, don’t fix it.” To them, their code style doesn’t matter. They are result-driven programmers. It can be complex, badly structured code, completely opposite of important programming principles, but they don’t care about how well the code is written. They just care about what it does.

So to these programmers, fixing badly written code is a waste of time. It just works. Why should they touch it?! And besides, there is a big risk of introducing new bugs while fixing the bad code. So what will they do? They will not touch the code and continue following the old engineering adage.

On the other hand, the other programmers who see the code as artwork will be uncomfortable with that kind of situation. They will feel disgusted while reading badly written code. They will try to fix each piece of code in the project because they care about code style a lot, and every piece of code in their project should be treated as art.

They are too obsessive about their code style. Even if other programmers write well-structured code, they will try to change that code to make it suitable to their own style. So basically they don’t follow the old “if it works, don’t fix it” adage. They will fix everything according to their own mindset. In the end, it doesn’t matter to them if it works or not.

What would be the best solution that works for you?

Find the parts of code that you work on actively and fix these parts to make them more understandable and readable. Don’t touch other parts if they work as expected and they are bug-free.

Why is this core so important? The core parts of your software are the parts you will work on the most. You will read these parts more often and will make changes in them more often than the rest. If there is a need for adding additional functionalities or implementing new features, they will be connected directly to the core.

Most of the bugs will be introduced from this core, which means you will spend most of your time debugging these parts. Remember the 80/20 rule (Pareto Principle), “20 percent of the code has 80 percent of the errors. Find them, fix them!”

What about the other parts?

Those parts are the ones that you will rarely work on. They are bug-free. They were written maybe even months or years ago and they work as expected. They might be written in an ugly way, even though they could have been written in a simpler, more readable and understandable way. This doesn’t mean that you have to fix them too. God knows when you will have to read them or change them again. So these parts can stay as they are. Forget about them. No need to fix them. You can spend your time working on more important stuff.

Why is fixing core parts so important even if they work as expected?

If you want to serve your customers for many years, you should have a maintainable product. A maintainable product means that making changes is not a struggle. Debugging and fixing bugs shouldn’t take too much time and adding new features should also be easy. So as a result, your programmers are happy and your customers are happy, too.

As Martin Fowler said in his Refactoring book:

“When you think about programmers, most of us will think that they spend most of their time writing code. Actually, this is quite a small fraction. Programmers spend most of their time reading the code and debugging it. Every programmer can tell a story of a bug that took a whole day (or more) to find. Fixing the bug is usually pretty quick, but finding it is a nightmare.”

The more well-written code you have, the easier it is to understand the code. The more understandable your code is, the easier your job is.

That is the reason why not following the old engineering adage (if it works, don’t fix it) for the core parts of your software is an important decision you can make.

The story of requesting twice, allow me to explain how it all began.

While working on a feature, I decided to look at the network tab and observed that the first request was sent with method OPTIONS, and the following request after it was the request with the correct method eg GET, POST etc, which is returning the expected payload. Basically two calls for the same request.

Here take a look at the screen shots below

Request with OPTIONS method

Request with GET method

After digging few docs, I realised it was an expected behaviour. It is related to the concept of HTTP access control (CORS).

To understand it better, let me explain a bit about CORS and requests.

HTTP access control (CORS)

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use.

Cross-Origin Resource Sharing (CORS)

Let us understand the above image above to get a better understanding of CORS.

1. Same Origin Request: We have opened domain-a.com, where we are requesting a blue image hosted in web server domain-a.com. Since we are performing our requests in the same domain, it is called a Same-origin request.

2. Cross Origin Request: We have opened domain-a.com, where we are requesting a red image hosted in web server domain-b.com. Since we are performing our requests in different domains, it is called a Cross-origin Request.

Simple requests

These are requests that doesn't send it’s first request as method OPTIONS. It is fired only once.

Surely it begs the question, why will the first request have method OPTIONS if we are not sending it, please have patience it will be explained below in preflight section ☺

But before that let us understand what are the points that make request simple.

1. The only allowed methods in simple request are:

• GET

• HEAD

• POST

2. Apart from the headers set automatically by the user agent (for example, connection , User-Agent, or any of the other headers with names defined in the Fetch spec as a “forbidden header name”), the only headers which are allowed to be manually set are those which the Fetch spec defines as being a “CORS-safelisted request-header”, which are:

• Accept

• Accept-Language

• Content-Language

• Content-Type

• DPR

• Downlink

• Save-Data

• Viewport-Width

• Width

3. The only allowed values for the Content-Type header are:

• application/x-www-form-urlencoded

• multipart/form-data

• text/plain

4. No event listeners are registered on any XMLHttpRequestUpload object used in the request.

5. No ReadableStream object is used in the request.

Preflighted requests

Preflighted request is a type of request which sends an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data. It is evident from the screenshots above.

For requests like PUT, DELETE, PATCH etc, preflight requests are sent.

Below flowchart summarises really well how it works.

Image Courtesy html5rocks

This flowchart opens up a door to a whole new knowledge. Couldn’t help but appreciate how good it is!

Strangely enough even GET request was observed to have preflights which for my case was due to presence of custom header Authorization, which can be seen from the screenshot below

Is Preflight request bad?

It is a small request without a body, but I always felt it as a bother. It is still a request, and each request is a cost, no matter how small that request is, so I definitely recommend to try and avoid having such cases.

How do we avoid it?

Well the easiest solution is avoid CORS, try to keep our resources and APIs in the same domain. It is really that simple.

Conclusion

It is always good to be armed with knowledge of how requests work. Even if the cost is very low, it still matters. Saving small requests can make our application really fast in the long run. Well I believe in the future, which is fast and furious.

Follow me on twitter to get more updates regarding new articles and to stay updated in latest frontend developments. Also share this article on twitter to help others know about it. Sharing is caring ^_^

Some helpful resources

Below are some of the links that inspired this article

1. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

2. https://stackoverflow.com/questions/24704638/options-request-makes-application-2x-slower

3. https://stackoverflow.com/questions/29954037/why-is-an-options-request-sent-and-can-i-disable-it/29954326

4. https://www.html5rocks.com/en/tutorials/cors/

It was the first years of the modern web. People were getting sick of waiting minutes for their connection to transfer the 8 bits of data telling them “Sorry, your password must contain an & or a %. Please try again.” They wanted more instantaneous feedback. Something that felt more like a desktop application.

Then finally on a rainy night in May of 1995, the great champion was born. His father, Brendan Eich, named him JavaScript after his successful grandfather Java.

(Karl Benz,the founder of Mercedes-Benz patent, is considered the father of the first practical motorcar, and JavaScript is the main engine of all browsers. This is what Brendan would look like if we called him the Benz of the web ?)

Mr. Eich, father of the champion

JavaScript: Rise of an empire

When JavaScript came into the world, no one was thinking it would be very popular like it is today. JavaScript was a true time saver because of its browser-side validations. But what happened that caused JavaScript to grow so fast?

Before I learn JavaScript, I used to write programs in the VB6 language. But VB6 wasn’t independent. It needed its own platform to run. One of the main reasons that JavaScript is so popular is that almost all devices have a browser. In short: JavaScript won’t limit you to a platform or type of device. You can run it on basically everything.

JavaScript’s progress and popularity is not a secret, but below you can see how JavaScript compares favorably with some other languages.

There are more contents on the web for JavaScript:

Search engines show the number of found results below their search; here is the search result for Java and JavaScript.

Google result for searching Java and JavaScript

There are more people who are learning it:

Stack Overflow tags and the number of questions that were asked for any tag, it can show us the number of people who are learning the tag which is a technology; Stack Overflow tags are also a good way to check how a technology is growing and its popularity.

JavaScript is the most popular tag of Stack Overflow

The most popular language on GitHub:

According to GitHub, JavaScript is the most popular language of GitHub followed by Java, Ruby and PHP.

JavaScript is already the most popular but it is still growing fast

Stack Overflow runs a survey every year, and this year’s survey result is very interesting and there are good things to learn from it. The picture below from the survey result shows that JavaScript is growing faster than before.

_Source: [Stack Overflow developer survey 2017](http://stackoverflow.com/insights/survey/2017/?utm_source=so-owned&utm_medium=hero&utm_campaign=dev-survey-2017&utmcontent=hero-questions#technology-languages-over-time" rel="noopener nofollow)

JavaScript is still misunderstood

All programming languages have their own rules, syntaxes and concepts, and each of them were made to be perfect in something, and none of them are completely perfect, we should not expect a programming language to be jack of all trades and master of none. That’s the reason many projects should chose different programming languages to bring better performance for each parts of their software.

It’s fair to say that JavaScript does not have some concepts that other programming languages have but it might come back to language design goals. One of the currently recognized problems with JavaScript is a lack of static typings that might cause problems in larger applications. That is why elegant TypeScript was created.

JavaScript was never really engineered to write large applications, it was in fact invented in about 3 weeks, in the mid 90s as a quick response to Java…, For Brendan Eich build it in 3 weeks and for having only 3 weeks, he actually did a fantasticjob, JavaScript was perhaps intended for a 100 or maybe up to a 1,000 lines of code, and now with regularity people are building 100,000 line apps, if not million lines apps. —Anders Hejlsberg, known for TypeScript, Turbo Pascal, Delphi, and lead architect of C# (source: this video, time: 01:20)

Without a doubt, JavaScript owes its progress to browsers and their support of good things such as responsive web design, WebGL, WebRTC and lots of more cool things that made JavaScript more useful. Nowadays, developers are using JavaScript for game development, data visualization, mobile applications, back-end development and other fun things as well.

Motivated to learn JavaScript or being a better JavaScript developer? Let’s get started.

Let’s say you already know some JavaScript or you’re a beginner. Don’t waste time and jump into your preferred IDE and start writing the codes you want.

The fastest way to learn is learn while doing, but there is a problem with this method. There are some tricks you don’t know or you never heard of them but you’re writing your codes without knowing them and it’s hard to learn those rules or tricks without reading them somewhere. You already know you can define a variable by using the var keyword, but maybe you did not know that if you don’t use the var keyword, the variable will be global regardless of its defined place.

You will eventually learn what you need to know but that is doing it the hard way. Indeed, one of the best places you can learn while doing isfreeCodeCamp, You can work through freeCodeCamp’s self-paced coding challenges, build projects, and earn certificates. it’s like diving into code but still knowing what you’re doing and learning tricks and rules in a fast and effective way.

The problem with learning JavaScript

There are many technologies and libraries for JavaScript that make it feel scary for beginners. There are some famous names that maybe you have never used and you hear about them constantly.

Some people think “What’s this Babel thing everyone is talking about. All the famous open-source projects are using it!” Or, “Wait — should I use Browserify orWebpack? Where did Gulp and Grunt came from? Ahhh, another new library or framework introduced last week! I can’t learn them all ?”

Yes, you can’t and you should not learn them all immediately. Those technologies, frameworks and libraries exist to help you work smarter, faster and easier. When you find something interesting that is worthwhile to use on your project or is an answer to one of your needs, then you should go ahead and learn it with a beautiful smile on your face while remembering the English proverb “necessity is the mother of invention.”

“I’d encourage folks to remember we’re all in the same boat and our tools are here to help us. If they’re not doing that, we should get them out of the way.” — Addy Osmani (Link to his story)

Finally, I would like to thank Grammarly because of their perfect tool, which let me write an article in English, even though I'm not a native English speaker. Try it even if you're a native English speaker

As you may know, browsers are starting to catch up with ES6. However, not everything works as smooth as expected, and this can be a time-consuming and tedious problem to solve. If something goes wrong, trying to identify if the problem lies in the code or the browser is not an easy process.

But don’t worry, I’ll show you how you can quickly install and write ES6 code, and most importantly, make it compatible to all browsers that support ES5.

ES5 to ES6

In order to write ES6 code, we need to install something that can compile it to ES5. We will be using, Rollup. It compiles small pieces of code into something larger and more complex, such as a library or application. This allows you to use OOP (object-oriented-programming) which makes your code look cleaner, structured and modular, along with other useful functionalities. To clarify, JS is object-oriented, but is not a class-based object-oriented language like Java, C++, C#, etc, until the release of ES6.

Otherwise, the closest you can come to OOP in regards to include classes with ES5 is to use IIFE (Immediately Invoked Function Expression), or install external libraries. But why rely on external resources when you have a core-language that supports the OOP paradigm? Many of the most widely used programming languages already support it (like C++, Java, C# and PHP).

Why ES6?

Personally, I use it because it allows me to organize my code into separate files, which makes it easier to scale and maintain the code.

For instance, in my HTML, I have one script that loads main.js, and inside main.js, I load multiple JS files using import and export statements. Instead of having multiple scripts in my HTML file, I only need one (less code).

Prerequisites

• Linux or macOS (Debian based)
• NPM (package manager) installed
• Basic CLI knowledge

Step one: Install Rollup

In order to use Rollup we must install it globally. Remember to use sudo. This allows you to access Rollup commands in whatever project you work with.

Step two: File structure

After you’ve installed Rollup globally, the next step is to setup up the folder structure and create two folders src and dest inside your project. In addition, create index.html.

• src → ES6 files (Where you’ll write the code)
• dest → Generates an ES5 (Compiled versions of ES6)

Project ES6 folder structure

Keep in mind, the bundle.js file is auto-generated when the Rollup command is executed. We will talk about this later.

Step three: Create a configuration file

Create a new file and name it rollup.config.js . Then add this code:

Configuration file for rollup.config.js

Make sure that the input and output source path is correct with your folder structure, and that this file is placed in the main folder.

Step four: Load the script file in HTML

We are almost ready, but first we need to link to the right source file in our HTML template. This will load the ES5 file which is compiled from ES6.

HTML template loads ES6 script

Step five: Setup JS files

In order to verify that the Rollup command works, we need to setup a simple OOP structure. We will create a car.js class, and default export it to main.js.

Keep in mind that this file exports a new instance of the car.js class, and this allows to access the methods directly rather than writing const car = new Car() in the main.js class.

Since I am a lazy software engineer, dealing with a few extra characters of code is time-consuming :)

car.js class

Next, import the car.js class to main.js in order to access the method’s type().

main.js class

Step six: Compile ES6 to ES5

To execute the configuration file we’ve created, run this command $ rollup -c or $ rollup --config — both are the same.

After running one of the commands, open index.html through a browser, then open inspect (ctrl + shift + I) on the browser, and go to console. If you see the text "Tesla Model S", it means everything worked successfully.

Keep in mind that every time you make changes with ES6 files, you must update it by running the command.

Optional

Since you have installed Rollup globally, you can compile ES6 without needing to have the file rollup.config.js . It does exactly the same thing:

$ rollup src/main.js — o dest/bundle.js — f iife

Personally, I would recommend running $ rollup -c as shown in step six since there is less code required. Remember that you must have the file rollup.config.js included when running this command.

If you found this short installation approach setup for ES6 useful, please comment and clap. It’s good karma.

“The key is to embrace disruption and change early. Don’t react to it decades later. You can’t fight innovation.” — Ryan Kavanaugh

Lately, there’s been a lot of buzz around PWAs with many claiming it to be future of web development, especially in terms of mobile devices. At its core, a Progressive Web App (PWA) is simply a web application that uses modern web techniques to deliver a native app-like experience to users. These are web applications with progressive enhancement to implement features like caching, background sync, and push notifications.

Even though PWAs have been around for more than two years now, the response is quite underwhelming. Few big players have adopted this philosophy but most haven’t actually embraced it very much. Chrome and Mozilla are perhaps the best browsers to test out your PWAs as Apple is yet to get into this stuff.

PWA — Is it really good ?

On one hand, we have native apps that are undoubtedly fast and efficient in most of the cases. On the other hand, there are websites that are kinda slow and with the connectivity issues, it only gets worse.

Accelerated Mobile Pages Project (AMP) spearheaded by Twitter and Google was launched in 2016 to solve those slow connection issues only. PWAs work flawlessly in all the possible scenarios. With a good connection, there is never a problem. The problem is when we have no connection and we are greeted with the error page.

But this can become most annoying if we have a slow connection. The page seems to be loading and all we see is a blank screen. We just wait, wait and wait but the page never seems to load. This is where PWA comes to our rescue. The best part about PWAs — you get the best user experience possible in slow connectivity as well as no connectivity (yep , you read it right..).

Why it makes sense to use PWA

According to a study, an average user spends 80% of his total time on apps on only three of his apps (For me its Chrome, Quora and Medium).

The other apps just sit idle for most of this time consuming a precious portion of the memory. Moreover, it costs around ten times to develop an app rather than creating a website for the same. The cost can get much higher if you plan to develop and maintain separate code bases for different platforms like Android, iOS and the web.

Native App features that PWAs can use

• Push notifications
• Full Screen
• Offline working
• Splash screen is supported giving it a more app like feel

PWAs can make use of many more such features. The above points are only to give you a hint of what PWAs are capable of. However, there are some traditional features that only native apps enjoy as of now.

Native App features that PWAs can’t use as of now

• No or highly restrictive access to different hardware sensors
• Alarms
• Phonebook Access
• Modfiying System Settings

PWAs are evolving quite fast and we can hope to see these features come to action pretty soon.

Two Major Components of a PWA

App Manifest
It’s a JSON file that defines an app icon, how to launch the app (standalone, full-screen, in the browser etc), and any such related information. It’s located in the root of your app. A link to this file is required on each page that has to be rendered.

It is added in the head section of the HTML page:
<link rel=”manifest" href="/manifest.json">

Service Worker
Service worker is where most of the magic of happens. Its nothing but JavaScript code that acts as programmable proxies solely responsible for intercepting and responding to network requests. Since it acts as a proxy and can be easily programmable, the application must be served over HTTPS to keep the data secure.

Its worth noting that the service worker caches the actual response, including all HTTP headers, rather than just the response data. This means that your application can simply make network requests and process the response without any specific code to handle the cache.

How do I get started?

The best thing about getting started is that it’s quite easier than it seems. In fact, it’s very much possible to take an existing site and convert into a PWA. I highly suggest you watch this if you intend to develop a PWA.

Thanks for reading! If you liked it, please support by clapping and sharing the post.