Lecture 12 - Async JavaScript

Asynchronous JavaScript

• needed to handle slow or user-initiated operations
• before ES6 callbacks were used for
  • fetching data from a server (using XMLHttpRequest)
  • waiting for user input (using event listeners)
  • executing long-running tasks (using timers like setTimeout)

Concurrency is hard, check the chefs

Chef Allmight, i.e., Event loop (Loupe demo)

console.log("Good morning!")

function cookPorrage(){
    console.log("I am cooking")
}
function addCoffeeBeans(){
    console.log("beans added")
}
function makeCoffee(){
    addCoffeeBeans()    
}
function breakfast(){
    cookPorrage()
    makeCoffee()
    console.log("All good this far")
}

setTimeout(function enjoy(){console.log("Enjoy")},10)

$.on('button', 'click', function onClick() {
    setTimeout(function timer() {
        console.log('You clicked the button!');
        breakfast();
    }, 2000);
});

Loupe: no support for arrow functions, demo works the best with named functions

Single-Threaded Event-Driven

a programming paradigm that uses a single thread (event loop) of execution and relies on events to manage concurrency

AJAX with XHR

JSON
X in AJAX (Crockford :)

JSON has largely replaced XML

• XML resembles HTML, was thus a natural choice in the beginning
• Has schema support, namespaces ..

Promises

Promise with happy and sad paths

Promise with happy and sad paths

• Promise pends until it is completed, and either
  • fulfilled ✅ or
  • rejected ❌

Promise chain formed of then/catches that return

new Promise((✅,  ❌)=>✅)
       .then(✅[, ❌])
       .then(✅[, ❌])
       .then(✅[, ❌])
       .then(✅[, ❌])
          .catch( ❌) // == .then(null,❌)

AJAX with fetch()

• a light-weight AJAX call that replaced older XMLHttpRequest by having cleaner API
• one mandatory argument: URL
• returns a Promise that resolves to the response

fetch("https://get.geojs.io/v1/ip/country.json")
.then(function(response) {
  return response.json();
})
.then(function(data) {
  console.log(JSON.stringify(data));
})
.catch(err=>console.log(`fetch err :${err}`));

async/await

async function (1/3)

Defined by using async keyword in a function

async function foo(){}; // as conventional f
const bar = async () => {} ; // as arrow f

• Execution still differs from sync functions
  • sync: chef waits beside the oven for ripe meat
  • async/await: meat prepares in queue, once ready, the chef is called

async function (2/3)

• informs about anticipated slowness, such as
  • AJAX, timeouts or calling other async functions
• async function must be awaited
  • await pauses the function execution until a promise is resolved
  • behind the syntactic sugar its implementation uses Promises

.. to end async chain (3/3)

• async mandates calling function to be async too
• ultimately async chain ends at the main level, inside <script>
• if the chain is desired to be cut earlier:
  immediately invoked function expression (IIFE)

  (async () => { /* ... */})();

Refactored fetch with async/await

Below, the value of the first await expression is that of the resolved response, and the second, the parsed json. Parsing may take time.

const fetch = require('node-fetch');
const url ='https://jsonplaceholder.typicode.com/todos/1';
(async ()=>{                          //as IIFE            
let response = await fetch(url);    //the 1st
let parsed = await response.json(); //the 2nd
console.log(parsed);
})()            

Promise.all()

Promise.all()

Starts multiple Promises in parallel and waits for them all to finish.

After all the Promises are fulfilled, returns a single Promise, that contains resolved values as an array:

const proms = [1, 2, 3].map(val => Promise.resolve(val));
Promise.all(proms)
  .then(res=>console.log(res, typeof res, Array.isArray(res)));    
// Array [1, 2, 3] 'object' true

However, Promise.all() rejects if any of the Promises rejects.

More here.

Promise.all() resolves Promises concurrently

Time consumption of await calls inside async block is got as a sum.

Promise.all() makes the calls concurrently, thus, the time approaches the time spent by the longest call:

Same-Origin Policy (SOP) and
Cross-Origin Resource Sharing (CORS)

Same-Origin Policy (SOP)

• protects web applications: a security mechanism that restricts how a web page interacts with resources from other domains
• limits cross-domain requests: by default, web pages can only request resources (DOM, cookies, local storage) from the same origin:
  https://www.domain.com:443
  protocol://domain:port == origin
• helps isolating potentially harmful content
• doesn't involve headers: SOP is a browser enforced policy, not a communication standard. Browsers implement SOP to restrict access, separate from request/response headers

CORS

• server may configure CORS policy to explicitly allow requests from certain domains
• thus, enabling cross-domain requests as a relaxation of same-origin-policy (SOP)
• CORS in fetch API
  • while CORS is primarily configured on the server, the fetch API provides ways to interact with CORS with mode
    • cors (default): this indicates a CORS request and automatically includes the Origin header. The browser will wait for a preflight request (OPTIONS method) to check CORS permissions before sending the actual request
    • no-cors: this mode disables CORS entirely and does not include the Origin header, and leads to so-called opaque responses. Use case: "ping", i.e., existence-check of a resource

No CORS errors

SOP OK
protocol, domain and port match

CORS OK
a server allows it, e.g., by setting Access-Control-Allow-Origin: *

CORS NOT OK
a server disallows with its Access-Control-Allow-Origin and other headers, or by providing no CORS

In case of an error, check the reason from Developer Tools: Network traffic viewer

Client-server transactions with CORS

Client <---------------------> Server

fetch(url, {
  method: 'GET',
  headers: {
      'Content-Type': 
      'application/json'
  },
  mode: 'cors'
})

Express server setting CORS headers

res.set({
  // 'Access-Control-Allow-Origin': '*', //all
  // 'Access-Control-Allow-Origin': 'https://m.yle.fi', //yle
  'Access-Control-Allow-Origin': 'http://127.0.0.1:5500', 
  'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
  'Access-Control-Allow-Headers': 'Content-Type'
});

• If the server CORS does not allow this client, there is nothing that the client can do!
• no-cors only downgrades the request as "ping" replied by an opaque response

AJAX Security: Mitigating JS Injection

Browser's Same-Origin Policy (SOP) and tab isolation prevent cross-site data reading and cross-tab access. But SOP cannot fully prevent successful Cross-Site Scripting (XSS) attacks. In XSS, injected malicious JavaScript impersonates a user and operates with the privileges of the trusted origin.

Key to security: prevent JS injection:

• Practice code discipline: enforce "use strict", utilize arrow functions, and embrace FP principles
• Avoid dynamic code: eval(), new Function(), and setTimeout(string)
• Favor textContent over potentially dangerous innerHTML/outerHTML
• Crucially, escape all untrusted input (HTML, JS, CSS, URL) before rendering it
• Sanitize HTML using trusted libraries like DOMPurify before insertion

⚠️ Library Hygiene

• Use well-maintained libraries and regularly check for known security vulnerabilities.
• Keep libraries up to date.
• Avoid using external libraries when handling sensitive data.
• Implement Subresource Integrity (SRI) for scripts loaded from CDNs:

  <script src="..." integrity="..." crossorigin="anonymous"></script>

  The browser fetches the CDN script, calculates its hash, and only executes it if the calculated hash matches the integrity attribute.