Tanvi has just finished her B.Com in Mysuru and wants to move into tech. She opens a job portal and sees "JavaScript" in almost every web developer listing. Her cousin, who works in a bank's IT team, tells her, "JavaScript is just a small version of Java, learn Java first." Then a YouTube video says the opposite. Tanvi writes three questions in her notebook: Is JavaScript related to Java at all? Why is it in every job post? And where should a beginner actually start?
This post answers those questions. It tells the real story of how JavaScript was born, how it survived the "browser wars", why it grew from a small page script into a language used for servers, mobile apps and desktop apps, and what that history means for you as a learner. At the end there is a short, tested first look at the language itself, so you can see what you are getting into.
The Web Before JavaScript
In the early 1990s, web pages were mostly static documents: text, links and a few images. If you filled in a form and made a mistake, the browser sent the whole form to the server, the server found the error, and a new page came back telling you to try again. Nothing on the page could react to you by itself.
Netscape, whose Navigator browser led the market in the mid-1990s, wanted pages that could respond to the user directly inside the browser. Java applets were one answer, but they were heavy and meant for professional programmers. Netscape also wanted a light "glue" language that web designers and part-time programmers could write straight into an HTML page.
Ten Days in May 1995: Brendan Eich at Netscape
Netscape hired Brendan Eich in 1995. He was originally told he might put a version of the Scheme language into the browser, but the management decision changed: the new language had to look like Java, with curly braces and familiar syntax, while staying simple. In May 1995 Eich wrote the first working prototype in about ten days. This "ten days" figure is widely reported and comes from Eich's own accounts, so it is a fair summary, but remember that it describes the first prototype only. The language has been changed and extended for thirty years since.
That speed explains some of JavaScript's famous quirks. Decisions taken in a hurry in 1995, such as typeof null returning "object" (more on that below), could not be fixed later without breaking websites that already depended on them. The web's golden rule is "don't break the web", and JavaScript still follows it.
Mocha, LiveScript, JavaScript: Three Names in One Year
The language was first called Mocha inside Netscape. It shipped in beta versions of Netscape Navigator 2.0 in September 1995 under the name LiveScript, a name meant to suggest "live", interactive pages. In December 1995, Netscape and Sun Microsystems announced it as JavaScript.
The new name was mostly marketing. Java, created at Sun, was the most talked-about language of the moment, and Netscape had a partnership with Sun to support Java in its browser. Calling the new scripting language "JavaScript" tied it to that excitement and presented it as Java's light companion. The cost is a confusion that beginners like Tanvi still face today. The name "JavaScript" is a trademark now held by Oracle (which bought Sun in 2010), which is one reason the official standard uses a different name, as we will see.
JavaScript vs Java: Not the Same Language
Java and JavaScript share part of a name and some C-style syntax (curly braces, if, for, while). Beyond that they were designed for different jobs and work in different ways. The cousin's advice to "learn Java first" is not needed if your goal is web development.
| Java | JavaScript | |
|---|---|---|
| Created by | James Gosling's team at Sun Microsystems (released 1995/96) | Brendan Eich at Netscape (1995) |
| Typing | Static: you declare types, the compiler checks them | Dynamic: a variable can hold any type at any time |
| How it runs | Compiled to bytecode, run by the Java Virtual Machine (JVM) | Run by a JavaScript engine (V8, SpiderMonkey, JavaScriptCore) using just-in-time compilation |
| Objects | Built around classes | Built around prototypes; class (added in 2015) is a friendlier syntax on top |
| Typical use | Android apps, large enterprise back ends, banking systems | Web pages, web apps, Node.js servers, cross-platform apps |
| Runs in a browser today? | No (Java applets are long gone) | Yes, in every major browser |
The typing difference is the one you will feel first. Here is a small Java program. The commented line would stop it from compiling, because age was declared as an int:
// Java (Demo.java)
public class Demo {
public static void main(String[] args) {
int age = 25;
String name = "Alex";
// age = "twenty six"; // error: incompatible types: String cannot be converted to int
System.out.println(name + " is " + age); // Alex is 25
}
}JavaScript has no type declarations. The same variable can hold a number, then a string, then an array, and the language works out the type from the value. This is called dynamic typing:
let value = 10;
console.log(typeof value); // number
value = "Hello World";
console.log(typeof value); // string
value = [1, 2, 3];
console.log(typeof value, Array.isArray(value)); // object trueDynamic typing makes JavaScript quick to start with, but it also lets a whole class of bugs slip through until the code actually runs. That trade-off is why many teams now write TypeScript, a Microsoft language released in 2012 that adds optional type checks and then compiles to plain JavaScript.
The Browser Wars and the ECMAScript Standard
JavaScript was popular almost at once, so Microsoft built its own compatible version, called JScript, and shipped it in Internet Explorer 3.0 in 1996. The two versions were similar but not identical. Developers often had to write one piece of code for Netscape and another for Internet Explorer, and test every page twice.
To avoid a split, Netscape handed the language to Ecma International, a standards body based in Geneva, in 1996. Ecma's technical committee TC39 published the first standard, ECMA-262, in June 1997. Because Sun owned the "JavaScript" trademark, the standardised language was named ECMAScript. In daily speech the two names mean the same thing: ECMAScript is the written specification, and JavaScript is what browsers and Node.js actually implement.
[1, 2, 3].map(...) gives the same answer in every modern browser.From ES1 to Yearly Releases
After ES1 came a short ES2 in 1998 (an editorial update to match the ISO version) and then ES3 in 1999, which added regular expressions and try/catch. ES3 was the version the whole web ran on for about ten years. A very large ES4 was planned, with classes, optional types and much more, but the committee could not agree on it, and in 2008 it was abandoned. Some of its ideas came back later in smaller pieces.
ES5 (2009) was a careful, smaller update: strict mode ("use strict"), built-in JSON.parse and JSON.stringify, and array methods such as forEach, map and filter. Then ES2015, still widely called ES6, was the biggest change in the language's history: let and const, arrow functions, classes, template literals, modules, promises, destructuring, Map and Set. Since 2015 TC39 publishes a smaller edition every year, named after the year (ES2016, ES2017 and so on), so new features arrive gradually instead of in one huge jump.
The difference is easy to see in code. Both halves below give the same total, written in 2009 style and in modern style:
// ES5 style (2009)
var prices = [120, 250, 45];
var total = prices.reduce(function (sum, price) {
return sum + price;
}, 0);
console.log("Total: Rs. " + total); // Total: Rs. 415
// ES2015 and later
const items = [120, 250, 45];
const sum = items.reduce((acc, price) => acc + price, 0);
console.log(`Total: ₹${sum}`); // Total: ₹415
// ES2020: optional chaining (?.) and nullish coalescing (??)
const order = { id: 101 };
console.log(order.address?.pin ?? "PIN not given"); // PIN not givenOld-style code still runs in every browser today. This is important when you read older tutorials or maintain an older project: var and function callbacks are not wrong, just older. For new code, the modern style is clearer and safer.
How JavaScript Grew Up: Ajax, V8 and Node.js
For its first ten years, many programmers saw JavaScript as a toy for image rollovers and pop-up alerts. Three changes turned it into a serious language.
Ajax and Rich Web Apps (2004–2006)
Browsers had gained a way to fetch data in the background without reloading the page, through an object called XMLHttpRequest (first added by Microsoft to Internet Explorer 5). Google's Gmail (2004) and Google Maps (2005) used it to build pages that felt like desktop programs: new emails appeared without a refresh, and the map scrolled smoothly as you dragged it. In 2005 Jesse James Garrett gave this approach a name, Ajax, and suddenly every company wanted it. Libraries like jQuery (2006) then hid the differences between browsers behind one simple API, which made this kind of work much easier for ordinary developers.
V8 and the Speed Race (2008)
Larger apps needed faster engines. In September 2008 Google released Chrome with a new JavaScript engine, V8, which compiled JavaScript to machine code while it ran. Other browser makers answered with faster engines of their own, and within a few years JavaScript ran many times faster than before. That speed is what makes today's online spreadsheets, editors and video calls practical in a browser. Chapter 2 explains how these engines fit inside a browser.
Node.js and npm (2009–2010)
V8 is open source, so in 2009 Ryan Dahl took it out of the browser and built Node.js, a runtime that lets JavaScript run on a server or your own computer. Node.js was designed around non-blocking input and output, so one process can handle many network connections while it waits for disks and databases. In 2010 Isaac Z. Schlueter released npm, the package manager that lets developers share and install libraries with one command. The npm registry grew into one of the largest collections of open-source packages for any language. From then on, a developer could use one language for both the browser and the server.
JavaScript Timeline at a Glance
| Year | Milestone |
|---|---|
| 1995 | Brendan Eich writes the first prototype at Netscape in about ten days (May). Named Mocha, then LiveScript (September), then JavaScript (December). |
| 1996 | Microsoft ships JScript in Internet Explorer 3.0. Netscape hands the language to Ecma International for standardisation. |
| 1997 | ECMAScript 1 (ECMA-262, first edition) published in June. |
| 1999 | ES3: regular expressions, try/catch. The baseline for the next decade. |
| 2004–2005 | Gmail and Google Maps show what in-page data loading can do; the term "Ajax" is coined in 2005. |
| 2006 | jQuery released. |
| 2008 | Google Chrome and the V8 engine released. The ES4 proposal is abandoned. |
| 2009 | ES5: strict mode, native JSON, forEach/map/filter. Ryan Dahl releases Node.js. |
| 2010 | npm, the Node.js package manager, released. |
| 2012 | Microsoft releases TypeScript. |
| 2015 | ES2015 (ES6): let/const, arrow functions, classes, modules, promises. |
| 2016 onwards | One edition per year. Examples: ES2017 added async/await; ES2020 added BigInt, ?. and ??. |
What JavaScript Is Used for Today
On a web page, the three core technologies split the work. HTML gives the structure (headings, buttons, forms), CSS gives the look (colours, spacing, layout), and JavaScript gives the behaviour: it opens menus, checks a form before it is sent, loads new posts as you scroll and updates a cart total without reloading. If HTML is the body of a car and CSS is its paint, JavaScript is the engine. Beyond the browser, the same language now reaches much further:
| Area | What it means | Well-known tools |
|---|---|---|
| Frontend | Interactive pages and single-page apps in the browser | React, Angular, Vue, Svelte; Next.js on top of React |
| Backend | APIs, web servers, real-time chat and notifications | Node.js with Express or NestJS; newer runtimes Deno and Bun |
| Mobile | Android and iOS apps from one JavaScript/TypeScript code base | React Native, Ionic |
| Desktop | Windows, macOS and Linux apps built with web technology | Electron (used by Visual Studio Code, Slack's and Discord's desktop apps) |
| Other | Browser extensions, serverless functions, build tools and scripts | Chrome extensions, AWS Lambda (Node.js runtime), Vite, webpack |
This reach is the real answer to Tanvi's second question. The Stack Overflow Developer Survey has listed JavaScript as the most commonly used programming language year after year, and the reason is simple: every browser runs it, so every company with a website needs people who know it. It also costs nothing to start. Any laptop with a browser can run JavaScript, and Node.js is a free download.
A First Look at the Language
The history above explains why JavaScript looks the way it does. Here is a quick, tested tour of the basics you will meet in the first weeks. Each part has its own full chapter in this series, linked below, so don't worry about mastering everything here. Every snippet runs in Node.js or the browser console (press F12, then open the Console tab).
Variables: let, const and var
A variable is a named box that holds a value. JavaScript has three ways to create one. Modern code uses let for values that will change and const for values that won't; var is the pre-2015 keyword you will see in older code. Names are case sensitive, so name and Name are two different variables.
let age = 25;
age = 26; // let allows reassignment
console.log(age); // 26
const pin = 110001;
pin = 400001; // TypeError: Assignment to constant variable.
const cart = { items: 1 };
cart.items = 2; // allowed: the object changes, the variable still points to it
console.log(cart); // { items: 2 }
let name = "Alex";
let Name = "John";
console.log(name, Name); // Alex JohnNotice the last part of the const example. const stops you from reassigning the variable, not from changing the object inside it. This trips up many beginners. Chapter 3 covers variables, types and memory in detail.
A Classic Interview Question: Copies vs References
What does this print? Many beginners expect 9 twice.
let value = 10;
function test(value) {
value = 9;
console.log(value);
}
test(value); // 9
console.log(value); // 10
const order = { total: 500 };
function applyDiscount(o) {
o.total = 450;
}
applyDiscount(order);
console.log(order.total); // 450The parameter value inside test is a separate variable that receives a copy of the number 10, so changing it does not touch the outer value. Objects behave differently: the function gets a copy of the reference, which points to the same object. Changing a property inside the function changes the original order. Remember both halves; interviewers usually ask the second one next.
undefined, null and the typeof null Bug
Both values mean "nothing here", but for different reasons. undefined means a variable exists but has not been given a value yet. null is a value a developer sets on purpose to say "empty, and I meant it". Think of an empty box (undefined) versus a box with a note inside saying "nothing here" (null).
let username;
console.log(username); // undefined
let user = null;
console.log(user); // null
console.log(typeof undefined, typeof null); // undefined object
console.log(null == undefined); // true (loose equality treats them alike)
console.log(null === undefined); // false (strict equality does not)
console.log(user === null); // true (the reliable way to check for null)Why is typeof null equal to "object"? In the first implementation, values carried a small type tag, and the tag for objects was zero. null was stored as a zero pointer, so it was reported as an object. A fix was proposed years later, but too much existing code depended on the old answer, so the bug stays. Use x === null to check for null.
Strings and Their Methods
A string is text. Each character has a position called an index, and counting starts at zero, so in "JavaScript" the J is at index 0 and the capital S is at index 4. Strings come with built-in methods that you will use daily for forms, search boxes and user input:
const language = "JavaScript";
console.log(language[0], language[4]); // J S
console.log(language.length); // 10
console.log(" Alex ".trim()); // Alex (spaces removed from both ends)
console.log("delhi".toUpperCase()); // DELHI
console.log("DELHI".toLowerCase()); // delhi
console.log(language.slice(0, 4)); // Java (from index 0 up to, not including, 4)
console.log(language.indexOf("S")); // 4
console.log(language.indexOf("s")); // -1 (not found, and case matters)
console.log(language.toUpperCase(), language); // JAVASCRIPT JavaScriptThe last line shows an important rule: string methods return a new string. The original language is never changed, because strings in JavaScript are immutable.
Type Conversion: Strings to Numbers and Back
Let's go back to Tanvi. A few weeks into learning, she builds a small cart page. A customer picks a quantity of 3 from a form field and clicks "Add one more". Her code does qty + 1, and the page shows 31 instead of 4. Nothing crashed, there was no error in the console, and yet the answer was wrong. The cause: everything read from a form field is a string, and + joins strings instead of adding them.
const qty = "3"; // values from form fields are strings
console.log(qty + 1); // 31 (string joining)
console.log(typeof +qty); // number (unary + converts to a number)
console.log(+qty + 1); // 4
console.log(Number("25")); // 25
console.log(Number("25 years")); // NaN (not a number)
console.log(parseInt("25 years", 10)); // 25 (reads digits until it stops)
console.log(Number("")); // 0 (an empty field becomes 0!)
const score = 100;
console.log(typeof (score + "")); // string
console.log(String(score)); // 100The unary + and score + "" tricks work, but Number(...) and String(...) say what you mean and are easier to read. Also watch out for the empty-string case: an empty input quietly becomes 0, which may not be what you want. Chapter 4 explains every conversion rule.
BigInt: When Normal Numbers Are Not Enough
Ordinary JavaScript numbers can store integers exactly only up to Number.MAX_SAFE_INTEGER, which is 9,007,199,254,740,991. Beyond that, some whole numbers cannot be stored and get rounded to a nearby one, so results can be silently wrong. That rarely matters for a shopping cart, but it does for very large IDs, cryptography and some financial or scientific work. BigInt (added in ES2020) stores whole numbers of any size. You create one by adding n to the end of an integer:
console.log(Number.MAX_SAFE_INTEGER); // 9007199254740991
console.log(9007199254740992 === 9007199254740993); // true (!) both round to the same number
const big = 9816543219865252772n;
console.log(big + 1n); // 9816543219865252773n
console.log(typeof big); // bigint
console.log(7n / 2n); // 3n (BigInt division drops the decimal part)
console.log(BigInt(9816543219865252772)); // 9816543219865251840n (already rounded!)
console.log(BigInt("9816543219865252772")); // 9816543219865252772n (exact)
// big + 1 → TypeError: Cannot mix BigInt and other types, use explicit conversions
// 123.45n → SyntaxError: BigInt has no decimalsLook closely at the two BigInt(...) lines. Passing a huge number to BigInt() does not help, because the number was already rounded before BigInt saw it. Pass a string, or use the n suffix, to keep every digit.
Objects, Methods and this
An object groups related data under one name, like a student record with a name, age and city. A function stored inside an object is called a method, and inside a method the keyword this refers to the object the method was called on.
const student = { name: "Alex", age: 22, city: "Delhi" };
console.log(student.city); // Delhi
const person = {
name: "Alex",
about() {
console.log(`My name is ${this.name}`);
},
};
person.about(); // My name is AlexObjects are everywhere in JavaScript: API responses, settings, DOM elements and even functions are objects. Chapter 7 covers objects and arrays fully, and the advanced concepts post explains this, call, apply and bind.
Prototypes and the new Keyword
Remember from the Java table that JavaScript objects are built on prototypes. Suppose a school app creates a thousand student objects that all need a greet() method. Copying the same function into every object would waste memory. Instead, the method is stored once on a shared prototype object, and every student looks it up there:
function Person(name) {
this.name = name;
}
Person.prototype.greet = function () {
console.log(`Hi, I'm ${this.name}`);
};
const a = new Person("John");
const b = new Person("Asha");
a.greet(); // Hi, I'm John
b.greet(); // Hi, I'm Asha
console.log(a.greet === b.greet); // true (one shared function)
console.log(Object.hasOwn(a, "greet")); // false (it lives on the prototype, not on a)
console.log(Object.getPrototypeOf(a) === Person.prototype); // trueWhen you write new Person("John"), JavaScript does four things: it creates a new empty object, links that object to Person.prototype, runs Person with this pointing at the new object, and returns the object (unless the function returns a different object itself). The class syntax from ES2015 does the same work with neater code: class Person { greet() { ... } } still puts greet on the prototype, and typeof Person is still "function".
Destructuring Function Parameters
When a function receives an object, you can unpack the properties you need right in the parameter list. This is called destructuring, and it also lets you give defaults for missing properties:
const user = { name: "Alex", age: 20, city: "Delhi" };
function showData({ name, age, city = "Unknown" }) {
console.log(`${name}, ${age}, ${city}`);
}
showData(user); // Alex, 20, Delhi
showData({ name: "Riya", age: 24 }); // Riya, 24, Unknown
showData(); // TypeError: Cannot destructure property 'name' of 'undefined' as it is undefined.The last call fails because there is no object to unpack. If a function may be called without an argument, give the whole parameter a default too: function showData({ name, age } = {}).
Sets: Collections Without Duplicates
A Set stores each value only once, which suits lists like attendance names or PIN codes where repeats make no sense:
const students = new Set();
students.add("Alex");
students.add("Alex"); // ignored, already present
students.add("John");
console.log(students); // Set(2) { 'Alex', 'John' }
console.log(students.size); // 2 (a property, not a method)
console.log(students.has("John")); // true
students.delete("John");
console.log(students); // Set(1) { 'Alex' }
students.clear();
console.log(students.size); // 0
const pins = ["110001", "400001", "110001"];
console.log([...new Set(pins)]); // [ '110001', '400001' ]The last two lines are the shortest way to remove duplicates from an array, and you will see this pattern in many code bases.
Synchronous Code, Callbacks and Async Code
By default JavaScript runs one statement after another, top to bottom, and each line finishes before the next starts. This is synchronous code, like a single queue at a bank counter. It is simple, but a slow task, such as a network request that takes several seconds, would freeze the whole page if the code had to wait for it.
So slow work is handed to the environment (the browser or Node.js), and your code carries on. When the work finishes, a function you supplied earlier, called a callback, is run with the result:
function task(callback) {
console.log("Task completed");
callback();
}
task(() => {
console.log("Next task");
});
// Task completed
// Next task
console.log("1");
setTimeout(() => {
console.log("2");
}, 1000);
console.log("3");
// 1
// 3
// 2 (about one second later)Callbacks work, but when each step depends on the previous one, they nest deeper and deeper. Developers call this shape callback hell:
function loginUser(cb) { setTimeout(() => cb("user-7"), 50); }
function getProfile(id, cb) { setTimeout(() => cb({ id, name: "Asha" }), 50); }
function loadSettings(profile, cb) { setTimeout(() => cb({ ...profile, theme: "dark" }), 50); }
loginUser((id) => {
getProfile(id, (profile) => {
loadSettings(profile, (settings) => {
console.log(`Dashboard for ${settings.name}, ${settings.theme} mode`);
});
});
});
// Dashboard for Asha, dark modePromises (ES2015) and async/await (ES2017) were added to flatten this. With await, asynchronous code reads like normal top-to-bottom code, while promises still do the work underneath:
// A pretend API call that answers after 100 ms
function getUser(id) {
return new Promise((resolve) => {
setTimeout(() => resolve({ id, name: "Asha" }), 100);
});
}
async function showUser() {
const user = await getUser(7);
console.log(`Welcome, ${user.name}`);
}
showUser();
console.log("Loading...");
// Loading...
// Welcome, AshaNotice that "Loading..." prints first. await pauses only the showUser function, not the whole program. Chapter 13 covers promises and async/await properly.
The Call Stack, Execution Context and Event Loop
Three ideas explain the order of output in the examples above. Every time code runs, JavaScript creates an execution context, a workspace holding that code's variables, functions and this value. The global context is created when the script starts, and a new function context is created on each function call. These contexts are kept on the call stack, which works like a stack of plates: the last one placed on top is the first one removed. In the code below, the global context starts, greet() adds a context on top, it prints and is removed, and control returns to the global code:
function greet() {
console.log("Hello");
}
console.log("Start");
greet();
console.log("End");
// Start
// Hello
// EndJavaScript runs your code on one main thread, so only one thing executes at a time. Timers, network requests and clicks are handled by the environment's APIs (Web APIs in the browser), and when they finish, their callbacks wait in a queue. The event loop keeps checking: when the call stack is empty, it takes the next callback from a queue and runs it. There are two main queues. Promise callbacks go in the microtask queue, which is emptied completely before the next ordinary task (like a setTimeout callback) runs:
console.log("Start");
setTimeout(() => console.log("Timeout"), 0);
Promise.resolve().then(() => console.log("Promise"));
console.log("End");
// Start
// End
// Promise
// TimeoutEven with a 0 ms delay, the timer waits until the script finishes and the promise callback has run. In Node.js, process.nextTick() callbacks have their own queue that runs even before promise callbacks. These topics get full chapters: Chapter 8 (execution context), Chapter 9 (call stack) and Chapter 12 (event loop).
How to Start Learning JavaScript
Frameworks such as React, Angular, Vue and Next.js change every few years, but they are all written in JavaScript, and they all depend on the ideas above: objects, functions, this, promises and the event loop. Learning those first makes every framework easier later. A practical order for a beginner looks like this:
- Set up nothing fancy. Open your browser's console (F12) for quick experiments, and install Node.js and a code editor such as VS Code when you want to save files.
- Understand where your code runs. Read Chapter 2: How Browsers Work and Where JavaScript Actually Runs, the next post in this series.
- Follow the chapters in order: variables and types, operators, conditions, functions, objects and arrays, then execution context, call stack, hoisting, closures, the event loop and promises.
- Build small things after each chapter. A tip calculator, a to-do list or a GST bill splitter will teach more than reading alone.
- Pick a framework or Node.js only after that. The JavaScript From Beginner to Advanced roadmap shows the full path, and the Node.js guide covers the server side.
Common Mistakes (and the Fix)
| Mistake | What happens | Fix |
|---|---|---|
| Thinking JavaScript is a "lite" Java | Learners study the wrong language first, or expect classes and types to work like Java | Treat them as separate languages; for web work, start with JavaScript directly |
| Adding form values without converting them | "3" + 1 gives "31" | Convert first with Number(value) and check for NaN |
Checking for null with typeof x === "object" | It is also true for null, so the check passes wrongly | Use x === null, or x !== null && typeof x === "object" |
Thinking const makes an object unchangeable | Properties can still be changed | Remember const only blocks reassignment; use Object.freeze() if you need a frozen object |
BigInt(9816543219865252772) with a huge number | Digits are lost before BigInt sees them | Use the n suffix or BigInt("...") with a string |
Expecting setTimeout(fn, 0) to run immediately | It runs after the current script and all promise callbacks | Learn the event loop; use await when you need a result before continuing |
My Opinion
Learn the history once, then move on. You don't need to memorise dates for interviews. What matters is the lesson behind them: JavaScript keeps old behaviour so that old websites keep working, which is why odd features like typeof null and var are still around. Knowing that turns "JavaScript is weird" into "this is old, there is a newer way".
Start with JavaScript, not Java, if you want web work. Both are good languages, but they lead to different jobs. If your goal is websites, web apps or Node.js back ends, learning Java first only delays you.
Write modern JavaScript from day one. Use const by default, let when a value must change, arrow functions and template literals, and async/await for asynchronous code. Learn to read var and old callback code, because you will meet it in real projects, but don't write new code that way.
Fundamentals before frameworks. React or Next.js on a CV looks attractive, but interviews for fresher roles ask about closures, this, promises and the event loop. A month spent on these basics saves many months of confusion later.
Add TypeScript after the basics, not instead of them. TypeScript catches the type mistakes that dynamic typing allows, and many companies use it. But it is JavaScript with types on top, so it makes much more sense once plain JavaScript feels comfortable.
Try It Yourself
Answer these first, then check with Node.js or the browser console where code is involved. Answers are hidden below.
1. Who created JavaScript, at which company, and in what year?
2. What was JavaScript called before it got its final name?
3. What is the name of the official standard, and which body publishes it?
4. Which edition is commonly called "ES6", and in what year was it published?
5. What does this print? console.log("5" + 1, +"5" + 1);
6. What does this print? console.log(typeof null);
7. What does this print?
console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));
console.log("D");
8. const s = new Set([1, 2, 2, 3]); What is s.size?Show answers
1. Brendan Eich, Netscape, 1995
2. Mocha (internal name), then LiveScript
3. ECMAScript (ECMA-262), published by Ecma International's committee TC39
4. ES2015, published in 2015
5. 51 6 → "5" + 1 joins strings; +"5" converts to a number first
6. object → a bug from the first implementation, kept for compatibility
7. A D C B → sync code first, then microtasks (promise), then the timer
8. 3 → duplicates are stored only onceFrequently Asked Questions
Is JavaScript the same as Java?
No. They are separate languages created by different companies for different purposes. The similar name came from a 1995 marketing decision when Java was very popular. JavaScript is dynamically typed and runs in every browser; Java is statically typed and runs on the Java Virtual Machine.
Is it true that JavaScript was created in ten days?
The first prototype was written by Brendan Eich in about ten days in May 1995, according to his own accounts. The language you use today is the result of thirty years of standardisation and new editions, so "ten days" describes only the starting point.
What is the difference between ECMAScript and JavaScript?
ECMAScript is the official specification, published by Ecma International as ECMA-262. JavaScript is the language that engines such as V8 and SpiderMonkey implement by following that specification, plus extra APIs from the environment (like the DOM in browsers or fs in Node.js).
Is JavaScript still worth learning?
Yes. Every major browser runs it, it is used on servers through Node.js, and frameworks for mobile and desktop apps build on it. Developer surveys such as Stack Overflow's have ranked it among the most used languages for many years, so demand for the skill is steady.
Should I learn JavaScript or TypeScript first?
Start with JavaScript. TypeScript adds type checking on top of JavaScript and compiles down to it, so every TypeScript concept assumes you already know how JavaScript behaves at run time.
Key Takeaways
- Brendan Eich wrote the first JavaScript prototype at Netscape in about ten days in May 1995; it was called Mocha, then LiveScript, then JavaScript.
- The "Java" in the name was marketing. Java and JavaScript are different languages with different typing, runtimes and object models.
- Ecma International standardised the language as ECMAScript (ES1 in 1997). After ES3 (1999), the abandoned ES4 and ES5 (2009), ES2015 brought modern JavaScript, and new editions now arrive every year.
- Ajax and Gmail made rich web apps popular, V8 (2008) made JavaScript fast, and Node.js (2009) with npm (2010) brought it to servers.
- Today JavaScript runs frontends (React, Angular, Vue), backends (Node.js), mobile apps (React Native) and desktop apps (Electron).
- Dynamic typing is flexible but needs care: convert form input with
Number()and check fornullwith=== null. - Code runs on one main thread; slow work comes back through queues, and promise callbacks run before timer callbacks.
Next, read Chapter 2: How Browsers Work and Where JavaScript Actually Runs to see what happens between typing a URL and your JavaScript running.
References
- MDN Web Docs: JavaScript
- ECMAScript Language Specification (TC39)
- Allen Wirfs-Brock and Brendan Eich, "JavaScript: The First 20 Years" (ACM HOPL, 2020)
- Node.js: About Node.js
){kind=link}
0 Comments