JavaScript is the programming language that makes web pages interactive; its official standard is ECMAScript (ECMA-262).

JavaScript was created at Netscape in 1996 to bring life to otherwise static HTML pages — letting them react to the user instead of just sitting there. Because so many browser vendors implemented it, the language was standardised so that everyone's version behaves the same way. That standard is ECMA-262, and the language it defines is called ECMAScript. In everyday speech people say "JavaScript"; the formal spec is "ECMAScript" (which is why language versions are named ES2015, ES2020, and so on).

Typical jobs people use JavaScript for:

• Reacting to user input — clicks, key presses, mouse movement
• Validating form values before they are submitted
• Dynamic HTML: changing the page's content and structure on the fly (DOM manipulation)
• Single-Page Applications, where the browser itself acts as the whole app's GUI
• Multimedia and graphics — video, audio, visual effects

A common gotcha: despite the name, JavaScript has nothing to do with Java. The name was a 1990s marketing decision to ride on Java's popularity; the two are unrelated languages.

Go deeper:

• JavaScript (Wikipedia) — history, the Ecma TC39 committee, and how the language relates to the wider web platform.

Client-side means the server sends the code but the user's browser runs it — so it is fast and visible, but never trustworthy.

When a page loads, the web server delivers the JavaScript as plain text along with the HTML, but the actual execution happens on the visitor's machine inside their browser (the "client"). Understanding where the code runs explains both its powers and its limits:

• No load on the server — the user's own computer does the work.
• Access to the page — the script can read and change the HTML document the user is looking at.
• The code is fully visible — anyone can choose "View Source" or open dev tools and read every line. There are no secrets in client-side JS.
• The server can't verify what ran — it has no way to know whether the script actually executed, or whether the user tampered with it.
• Sandboxed — for safety the browser confines scripts to a limited area ("sandbox"); a normal web script cannot read or write files on the user's disk.

The security lesson follows directly: never rely on client-side validation alone. A login check or password rule written only in JavaScript is worthless, because the user can disable, edit, or bypass the script. Use client-side checks for instant, friendly feedback, but always re-validate everything on the server, which the user cannot touch.