The defer and async attributes were introduced to give developers a way to tell the browser which scripts to handle asynchronously. Both of these attributes tell the browser that it may go on parsing the HTML while loading the script in background, and then execute the script after it loads. This way, script downloads don’t block DOM construction and page rendering. So the user can see the page before all scripts have finished loading.

The difference between defer and async is which momemt they start executing the scripts. defer execution starts after parsing is completely finished, but before the DOMContentLoaded event. It guarantees scripts will be executed in the order they appear in the HTML and will not block the parser. async scripts execute at the first opportunity after they finish downloading and before the windows load event. This means it’s possible that async scripts are not executed in the order in which they appear in the HTML. It also means they can interrupt DOM building. async scripts load at a low priorty. They often load after all other scripts, without blocking DOM building.

References

• Building the DOM faster: speculative parsing, async, defer and preload
• Scripts: async, defer
• Async vs Defer - Which Script Attribute is More Efficient When Loading JavaScript?

An HTTP cookie is a small piece of data that a server sends to the user’s web browser. The browser may store it and send it back with later requests to the same server. Typically, it’s used to tell if two requests came from the same browser, keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol.

Lifetime of a cookie

• Session cookies - They are deleted when the current session ends.
• Permanent cookies - They are deleted at a date specified by the Expires attribute or after a period of time specified by the Max-Age attribute.

Cookie security

A cookie with Secure attribute is sent to the server only with an encrypted request over the HTTPS protocol. A cookie with HttpOnly attribute is inaccessiblt to the JavaScript Document.cookie API, it is sent only to the server.

Cookie scope

The Domain attribute specified which hosts are allowed to receive the cookie. If unspecified, it defaults to the same host that sets the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. The Path attribute indicates a URL path that must exist in the requested URL in order to send the Cookie header. The SameSite attribute lets servers specify when cookies are sent with cross-origin requestes, which provides some protection against cross-site request forgery attacks.

Third-part cookies

A cookie is associated with a domain. If this domain is the same as the domain of the page you are on, the cookie is called a first-party cookie. If the domain is different, it is a third-party cookie.

Cookies and web performance

When a browser sends a HTTP request, the HTTP request headers are usually 400-500 bytes. Adding a cookie to that will increase the size of the request header. If we add more than 1KB of cookies to that request, then we exceed 1500bytes, which is the standard maximum transmission unit (MTU) used by TCP. This means that the HTTP request would span multiple TCP packets, which may result in multiple round trips and increase the risk of retransmission. This can potentially increase the time to first byte (TTFB) of the response since it would take longer to make the request. Because of impact of cookie size on the first flight of requests and responses, it is beneficial to use smaller cookies. 900 bytes seems like a good budget for a total cookie size, which leaves room for other headers such as user-agent.

References:

• A re-introduction to HTTP cookies
• Using HTTP cookies
• An analysis of Cookie Sizes on the Web

A side effect is any application state change that is observable outside the called function other than its return value. For example modifying any external variable like global variable, logging to console, writing to file, writing to network, calling other functions with side effects.

function printSomething(foo) {
    console.log(foo);
}
// printing to console make this function to have a side effect.

Side effects are mostly avoided in functional programming, which makes the program easier to understand and to test.

References:

• Master the JavaScript Interview: What is Functional Programming?
• 3 common approaches to side-effects in Redux apps
• Redux side effects and me
• Preventing Side Effects in JavaScript
• HOW TO DEAL WITH DIRTY SIDE EFFECTS IN YOUR PURE FUNCTIONAL JAVASCRIPT
• Dealing with side effects and pure functions in javascript

Monorepo, is a single repository which contains more than one logical project like a web application and its iOS application.

Benefits:

• Single build system
• Easy to refactor
• Code sharing

Disadvantages

• Tight coupling and unclear ownership boundaries
• Source control system scalabity issues

References:

• Guide to Monorepos for Front-end Code
• Monorepos: Please don’t!
• Monorepos in Git
• Awesome Monorepo

Dependency Injection is a pattern where instead of creating or requiring dependencies directly inside a module, we pass them as paramaeters or reference.

// foo.js
export default class Foo {
    print() {
        console.log('Hello world!');
    }
}

//baz.js
import Foo from './foo.js';

export default class Baz {
    constructor() {
        this.foo = new Foo();
    }
}

//app.js
import Baz from './baz.js';

let b = new Baz();

// Using Dependecy Injection
// Updated baz.js
export default class Baz {
    constructor(foo) {
        this.foo = foo;
    }
}

//app.js
import Foo from './foo.js';
import Baz from './baz.js';

let b = new Baz(new Foo()); // Foo instance is passed as parameter to Baz

Benefits

• Unit testing - Avoid need for stubbing
• Flexibility - Freedom to change implementation at any point

References:

• Dependency Injection in JavaScript
• JavaScript dependency injection in Node.js – friends or foes?
• Dependency Injection & Inversion Explained
• Handling dependencies