Il BOM in JavaScript: origine, storia e scopo

In ambito Web, con BOM (Browser Object Model) si indica l’insieme di oggetti e API che un browser espone a JavaScript per interagire con l’ambiente di esecuzione: la finestra, l’URL corrente, la cronologia, lo schermo, i prompt/alert, i timer e molte altre funzionalità “attorno” alla pagina. A differenza del DOM (Document Object Model), che rappresenta la struttura del documento HTML e consente di leggere/modificare nodi ed elementi, il BOM riguarda tutto ciò che è esterno al documento ma necessario per fare applicazioni web reali.

Che cos’è (e che cosa non è) il BOM

Storicamente, il BOM è nato come concetto pratico più che come specifica formale: un nome ombrello per descrivere ciò che i browser mettevano a disposizione oltre al DOM. Per questo motivo:

  • Il BOM non è un singolo standard monolitico: molte sue parti sono oggi definite in specifiche diverse (HTML, URL, History, Storage, ecc.).
  • Nel linguaggio comune, “BOM” include API molto usate (per esempio location o history), anche quando tecnicamente sono definite in specifiche moderne specifiche e non in un documento “BOM”.
  • Il punto d’ingresso tipico è l’oggetto globale del browser, spesso esposto come window. In molte situazioni, proprietà di window sono accessibili anche senza prefisso.

Origine: i primi browser e la necessità di un “modello” dell’ambiente

Nei primi anni del Web dinamico (metà anni ’90), la spinta era rendere le pagine più interattive: cambiare contenuti, gestire finestre e frame, navigare tra pagine, reagire a eventi. JavaScript nasce in questo contesto come linguaggio di scripting lato client. Per poter fare qualcosa di utile, però, non bastava il linguaggio: servivano oggetti che rappresentassero l’ambiente del browser.

I browser dell’epoca introdussero quindi oggetti “di contorno” con cui:

  • aprire e controllare finestre;
  • leggere e modificare l’indirizzo della pagina;
  • ottenere informazioni sul sistema o sul browser;
  • gestire la cronologia di navigazione;
  • mostrare finestre di dialogo e messaggi;
  • eseguire azioni a tempo (timer).

Questo insieme di oggetti, in seguito, verrà chiamato “Browser Object Model”. Il nome aiuta a distinguere tra ciò che descrive il documento (DOM) e ciò che descrive il contenitore (browser).

Storia: dalla frammentazione alla convergenza sulle specifiche moderne

1) Implementazioni proprietarie e compatibilità

Negli anni delle “browser wars”, diversi produttori introdussero API simili ma non identiche. Gli script dovevano spesso includere controlli e rami condizionali per funzionare su browser diversi. In quel periodo, parlare di BOM significava spesso “quello che questo browser offre”, più che “quello che la piattaforma Web garantisce”.

2) La crescita del DOM e la separazione concettuale

Con l’evoluzione del DOM e la sua standardizzazione, diventa più chiaro che l’albero del documento è solo una parte dell’esperienza: l’utente naviga, cambia URL, usa i tasti avanti/indietro, ridimensiona la finestra, lavora con più tab. Il BOM resta il modo pratico per descrivere queste interazioni.

3) Standardizzazione “a pezzi” nella piattaforma Web

Col tempo, molte funzionalità storicamente attribuite al BOM sono confluite in specifiche più precise e interoperabili. In pratica, il “BOM” moderno è un insieme di API definite e mantenute separatamente, ma che nel browser si incontrano tutte in un unico ambiente globale.

Scopo del BOM: cosa permette di fare in una web app

Lo scopo del BOM è consentire a JavaScript di:

  • interagire con la finestra e il contesto di navigazione;
  • conoscere e controllare l’URL e la navigazione;
  • gestire la cronologia (e in generale lo stato di navigazione);
  • leggere informazioni sul dispositivo o sulla superficie di rendering;
  • offrire funzionalità di utilità come timer e dialoghi;
  • memorizzare dati sul client (in coordinamento con le politiche di sicurezza del browser).

Oggetti e API tipiche del BOM

window: il punto d’ingresso

In un browser, l’oggetto globale è tipicamente window. Storicamente ha rappresentato la finestra del browser, e ancora oggi è il contenitore di molte proprietà e funzioni globali. Ad esempio, timer e dialoghi sono spesso metodi di window. 

// Esempi: molte API sono proprietà/metodi di window
window.setTimeout(() => console.log("Dopo 1 secondo"), 1000);
window.alert("Messaggio di esempio");

// Spesso il prefisso window è opzionale:
setTimeout(() => console.log("Prefisso omesso"), 500);

location: leggere e cambiare l’URL

location consente di ispezionare le parti dell’URL e di innescare navigazioni. È fondamentale per costruire logiche basate su query string, hash e percorsi. 

// Leggere informazioni dall'URL corrente
console.log(location.href);
console.log(location.pathname);
console.log(location.search);
console.log(location.hash);

// Navigare verso un'altra pagina (causa un caricamento)
location.assign("https://example.com");

// Ricaricare la pagina
// location.reload();

history: navigazione e gestione dello stato

L’oggetto history permette di muoversi avanti e indietro nella cronologia e, nelle applicazioni moderne, di manipolare l’URL senza ricaricare la pagina (pattern tipico delle SPA). 

// Spostarsi nella cronologia
history.back();
history.forward();
history.go(-2);

// Aggiornare l'URL senza ricaricare (SPA)
history.pushState({ view: "profilo" }, "", "/profilo");
history.replaceState({ view: "home" }, "", "/");

navigator: informazioni sul browser e capacità

navigator espone informazioni sull’agente utente e su alcune capacità della piattaforma. In passato si è abusato di userAgent per fare “browser sniffing”; oggi, quando possibile, è preferibile la feature detection (verificare se una API esiste) invece di dedurre capacità dal nome del browser. 

// Esempi tipici
console.log(navigator.userAgent);
console.log(navigator.language);

// Feature detection: controllare se una API è disponibile
if ("geolocation" in navigator) {
  navigator.geolocation.getCurrentPosition(pos => {
    console.log(pos.coords.latitude, pos.coords.longitude);
  });
}

screen e dimensioni della viewport

L’oggetto screen descrive caratteristiche dello schermo (risoluzione, profondità colore, ecc.). Per la UI responsive, spesso sono più utili le dimensioni della viewport (ad esempio innerWidth e innerHeight), che rappresentano l’area disponibile per il contenuto nella finestra. 

console.log(screen.width, screen.height);
console.log(window.innerWidth, window.innerHeight);

// Reagire al ridimensionamento
window.addEventListener("resize", () => {
  console.log("Nuova viewport:", innerWidth, innerHeight);
});

Timer: setTimeout, setInterval, requestAnimationFrame

I timer consentono di pianificare lavoro nel tempo. setTimeout e setInterval sono storici e semplici, ma per animazioni e aggiornamenti sincronizzati al refresh del display è preferibile requestAnimationFrame. 

// setTimeout: esegue una volta
const idTimeout = setTimeout(() => console.log("Una volta"), 1000);

// setInterval: ripete finché non lo annulli
const idInterval = setInterval(() => console.log("Ogni 2s"), 2000);

// Annullare
clearTimeout(idTimeout);
clearInterval(idInterval);

// requestAnimationFrame: ideale per animazioni
let start;
function step(timestamp) {
  if (start === undefined) start = timestamp;
  const elapsed = timestamp - start;
  // ... aggiornare lo stato dell'animazione ...
  if (elapsed < 1000) requestAnimationFrame(step);
}
requestAnimationFrame(step);

Dialoghi: alert, confirm, prompt

Queste API sono storiche e ancora presenti. Sono però bloccanti (interrompono l’interazione finché l’utente non risponde) e poco personalizzabili; nelle applicazioni moderne si preferiscono modali HTML/CSS/JS, ma i dialoghi nativi restano utili per debug o casi molto semplici. 

alert("Operazione completata");

const ok = confirm("Vuoi continuare?");
console.log("Scelta:", ok);

const nome = prompt("Come ti chiami?", "Ada");
console.log("Nome:", nome);

Storage: persistenza lato client

Anche la persistenza locale è spesso inclusa nel “BOM” in senso lato. Le API più note sono localStorage e sessionStorage, semplici key-value sincronizzati col dominio. La piattaforma Web offre anche soluzioni più potenti come IndexedDB (oltre lo scopo delle API basilari). 

// localStorage: persiste tra sessioni
localStorage.setItem("tema", "scuro");
console.log(localStorage.getItem("tema"));
localStorage.removeItem("tema");

// sessionStorage: dura finché resta aperta la tab
sessionStorage.setItem("bozza", "testo temporaneo");

BOM e sicurezza: perché alcune cose sono limitate

Il BOM è strettamente legato alle politiche di sicurezza del browser. Alcune API sono soggette a permessi espliciti (ad esempio geolocalizzazione), altre sono vincolate dall’origin (protocollo + host + porta), e molte operazioni su finestre/tab sono limitate per prevenire abusi (pop-up, phishing, clickjacking).

Un esempio classico: la manipolazione di window.open o di finestre “figlie” può essere consentita solo se l’apertura avviene in seguito a un gesto dell’utente e se le pagine coinvolte rispettano vincoli di sicurezza.

BOM nel 2026: concetto utile, confini più sfumati

Oggi si parla spesso di Web APIs o platform APIs più che di BOM, perché la piattaforma si è ampliata: rete (Fetch), storage avanzato, multimedia, sensori, clipboard, notifiche, service worker, e così via. Tuttavia, “BOM” resta una scorciatoia terminologica efficace per indicare l’ambiente browser e le sue primitive storiche centrali (window, location, history, navigator, screen, timer, dialoghi).

Relazione con il DOM e differenze con altri ambienti JavaScript

È importante ricordare che JavaScript è il linguaggio, mentre BOM e DOM sono API dell’ambiente. In un browser trovi DOM e BOM (oltre a molte altre Web API). In altri ambienti, come Node.js, l’oggetto globale e le API sono diverse: non esiste window né document, perché non c’è una finestra del browser né un documento HTML da manipolare. Questa separazione concettuale aiuta a capire perché uno stesso linguaggio può funzionare in contesti differenti.

Conclusione

Il BOM nasce per rendere possibile lo scripting in un browser: fornire a JavaScript un set di oggetti per dialogare con la finestra e con la navigazione, oltre il documento. Storicamente è stato un insieme pragmatico e talvolta frammentato; con l’evoluzione della piattaforma Web, molte sue parti sono state formalizzate e standardizzate. Nonostante i confini moderni siano più sfumati, il concetto di BOM resta utile per orientarsi: quando il tuo codice non sta “tocando il DOM”, ma sta interagendo con l’ambiente di esecuzione del browser, quasi certamente stai usando (in senso lato) il BOM.

Torna su