Front-End Interview Notes: Promises, Security, Performance, and the Browser

Promises

What is a Promise?

A Promise is an object and programming model for representing the eventual result of an asynchronous operation.

How is a Promise used?

Create one with new Promise(), passing an executor that receives resolve and reject. Consumers handle its result with then() and errors with catch().

Promise APIs include:

• Instance methods such as chained promise.then() and promise.catch().
• Static methods such as Promise.all(), which waits for all inputs, and Promise.race(), which settles with the first settled input.

A Promise has three states:

• It begins as pending.
• Calling resolve() changes it to fulfilled.
• Calling reject() changes it to rejected.

Cross-origin requests

An origin consists of a scheme, hostname, and port. A difference in any of these makes two URLs cross-origin. A request may reach the server successfully but still be unavailable to browser JavaScript because of the same-origin policy.

The policy limits how a document or script from one origin interacts with another origin. It is a key isolation mechanism for potentially malicious content. Depending on the resource and API, restrictions can affect:

1. Cookies, localStorage, and IndexedDB.
2. DOM access.
3. AJAX or Fetch responses.

Without origin isolation, browsers would be far more exposed to attacks such as XSS and CSRF. See this same-origin policy discussion.

Defending against CSRF

Cross-Site Request Forgery tricks a trusted user’s browser into sending an unintended request.

• CAPTCHA for sensitive actions
• Referer or Origin checking
• CSRF tokens

Defending against XSS

Cross-Site Scripting injects script into content viewed by other users. See this introductory XSS course.

Common cross-origin techniques

• CORS, configured by the server
• JSONP for older script-based GET requests
• URL fragments in specialized integrations
• postMessage() for controlled window-to-window communication
• WebSocket connections

Website performance checklist

Content

• Reduce HTTP requests by combining appropriate files, using sprites, or inlining small assets.
• Reduce DNS lookups while balancing hostname sharding against parallel downloads.
• Avoid unnecessary redirects.
• Cache AJAX responses where appropriate.
• Lazy-load nonessential components and preload resources needed soon.
• Reduce excessive DOM elements and iframes.
• Avoid broken 404 resource requests.

Server

• Use a CDN.
• Configure Expires or Cache-Control.
• Enable gzip or modern compression.
• Configure validators such as ETag.
• Flush useful response data early where supported.
• Avoid empty image src attributes.

Cookies

• Keep cookies small.
• Serve static resources from hosts that do not receive unnecessary cookies.

CSS

• Load critical styles early.
• Avoid CSS expressions, legacy IE filters, and excessive @import.

JavaScript

• Defer noncritical scripts.
• Minify JavaScript and CSS.
• Remove unused scripts.
• Reduce repeated DOM queries.
• Design event listeners carefully.

Images

• Choose an appropriate format and color depth, then compress the image.
• Optimize sprites where they are still used.
• Do not stretch images in HTML.
• Keep the favicon small and cacheable.

Mobile

• Keep components small.
• Older mobile guidance also recommended multipart packaging to reduce requests.

From URL entry to rendered page

A simplified HTTP navigation flow is:

1. The user enters a URL.
2. DNS resolves the hostname.
3. The client establishes a TCP connection.
4. The browser sends an HTTP request.
5. The server processes it.
6. The server returns a response.
7. The browser parses and renders the page.
8. The connection is reused or closed.

Responsive mobile pages

1. Configure the viewport:

<meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">

2. Use flexible layout tools such as Flexbox, percentages, and rem.
3. Combine responsive breakpoints with viewport units such as vw.

How rem works

rem is relative to the root element’s font size. If html { font-size: 100px; }, then 1rem equals 100px throughout the document. On the root element itself, rem resolves relative to the initial font size.

JavaScript this

Unlike many languages, a JavaScript function’s this value is generally determined by how the function is called, not where it was defined.

• Direct function call
• Method call
• Constructor call with new
• Explicit binding with bind()