AV
HomeAboutProjectBlog

© 2026 Ave syah Shina. All rights reserved.

  1. Home
  2. Blog
  3. 01 — JavaScript — The Only Language the Browser Runs

01 — JavaScript — The Only Language the Browser Runs

August 13, 20266 min read
Download as Markdown

"Just a language that runs in the browser" was my JavaScript definition, and it was missing the mechanism. The idea that everything else hangs off: JavaScript is one implementation of a specification called ECMAScript, and its only genuinely special property is that browsers ship a JS engine and run nothing else. [1]

The framing that finally landed is the separation between the spec and the language. ECMAScript is the standard — a document that says "these are the types, these are the operators, this is how scope works." JavaScript is what actually ships in engines like V8 (Chrome, Node), SpiderMonkey (Firefox), and JavaScriptCore (Safari). When someone says "ES6" or "ES2024," they mean the spec version. When they say "JavaScript," they mean the language you write, which now follows that spec. The distinction matters because it explains why features land unevenly across browsers — each engine implements the spec on its own schedule [3].

ECMAScript the specification types · operators · scope V8 Chrome · Node.js SpiderMonkey Firefox JavaScript the code you write

What JavaScript actually does

Mechanically, JavaScript is a high-level, interpreted (technically, just-in-time compiled) language created to add interactivity to web pages [1][2]. It can manipulate HTML and CSS, respond to user events, talk to servers, and update content without reloading the page. Three things worth pinning down because they shape every line I write:

  • Single-threaded. JS runs one statement at a time on one main thread. Long work blocks everything — which is why async patterns exist at all.
  • Runs in a host environment. The language itself has no DOM, no fetch, no file system. Those are host APIs the environment provides. The browser hands JS the DOM; Node hands it fs and http. The core language — types, functions, closures — is the same in both.
  • Follows the spec. New syntax (arrow functions, optional chaining, async/await) is added by ECMAScript revisions, not by browser vendors acting alone.

The bizarre history

JavaScript has a naming history that confused me for years, and the confusion isn't cosmetic — it explains why the name is misleading. The language was created by Brendan Eich at Netscape in 1995, originally named Mocha, then LiveScript [4]. In 1996, about a year after release, Netscape renamed it to JavaScript purely to ride the marketing wave around Java — despite JavaScript having no technical relationship to Java. The name stuck; the confusion persisted.

The clean-up came in 1997, when JavaScript was submitted to ECMA International and standardized as ECMAScript (the spec) to keep the trademark clean [5]. So today: ECMAScript is the standard, JavaScript is the implementation, and the two words are almost, but not quite, synonyms.

The versions that matter

The version history is short once you know the one breakpoint. Early ECMAScript (ES1–ES3, 1997–1999) was incremental. ES5 (2009) added strict mode and array methods. The transformative release was ES6 / ES2015 — it added let/const, arrow functions, classes, modules, promises, destructuring, template literals, and more [5]. After ES6, the spec moved to yearly releases (ES2016, ES2017, … ES2024), each shipping a handful of small additions instead of one giant dump.

The practical effect: "modern JavaScript" usually means "post-ES6," and the language now evolves in small, predictable yearly steps rather than decade-long waits.

How I actually run it

Three places, depending on what I'm doing:

  • Browser console / DevTools — the fastest scratchpad. Any modern browser's DevTools console runs JS against the current page's environment, DOM included [6].
  • <script> tag in HTML — how JS gets into a real web page. Inline or linked, the browser fetches and executes it.
  • Node.js — a JS runtime built on V8 that runs JS outside the browser, with file system and network access. This is the server-side and tooling side (build tools, CLIs, my own scripts).

For quick experiments, the browser console or a snippet in an online playground is enough. For real work it's either a <script> in a page or a Node process — and which one I pick determines which host APIs are available.

How I use this

The separation between spec and implementation is the part I reach for most. When a feature doesn't work in some browser, it's not "JavaScript is broken" — it's that engine hasn't shipped that spec revision yet, and I check a compatibility table. When I see "ES2022 feature," I know to treat it as a spec addition that may or may not be implemented everywhere I target. And the host-environment framing keeps me honest: document.querySelector is not JavaScript — it's the browser's DOM API, and it won't exist in a Node script.

References

[1] Mozilla, "JavaScript — Dynamic client-side scripting," MDN Web Docs, 2024. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/JavaScript

[2] I. Kantor and the javascript.info team, "The Modern JavaScript Tutorial," javascript.info, 2024. [Online]. Available: https://javascript.info/

[3] K. Simpson, You Don't Know JS Yet, 2nd ed., getify, 2020. [Online]. Available: https://github.com/getify/You-Dont-Know-JS

[4] roadmap.sh, "Brief History of JavaScript," 2023. [Online]. Available: https://roadmap.sh/guides/history-of-javascript

[5] Educative, "JavaScript Versions: How JavaScript has changed over the years," 2023. [Online]. Available: https://www.educative.io/blog/javascript-versions-history

[6] DigitalOcean, "How To Use the JavaScript Developer Console," 2020. [Online]. Available: https://www.digitalocean.com/community/tutorials/how-to-use-the-javascript-developer-console

Knowledge check · Question 1 of 5

What is the relationship between ECMAScript and JavaScript?

Comments

Leave a Comment

You must be signed in to comment

0 Comments

No comments yet. Be the first to comment!