JavaScript and TypeScript — The Language of the Web

If you're building anything for the web — and as a vibe coder, you almost certainly are — JavaScript is the language working behind the scenes. It's the language that makes websites interactive, that powers the tools you're building with, and that AI generates when you describe your app.

You don't need to learn to write JavaScript. But understanding what it does and recognizing it when you see it will make you a significantly more effective vibe coder.

What JavaScript Actually Does

HTML creates the structure of a web page (the headings, paragraphs, buttons). CSS makes it look good (colors, fonts, layout). But neither HTML nor CSS can make things happen.

Want a dropdown menu that opens when you click it? That's JavaScript. Want to validate that someone entered a real email address before submitting a form? JavaScript. Want to show a notification when a new message arrives? JavaScript. Want to load new data without refreshing the entire page? JavaScript.

JavaScript is the language that makes web pages interactive.

Every browser — Chrome, Safari, Firefox, Edge — has a JavaScript engine built in. When you visit a website, your browser downloads the JavaScript code and runs it right on your device. This is why JavaScript holds a unique position in the programming world: it's the only traditional programming language that every browser can run natively.

A Quick Taste

You don't need to write this, but seeing what JavaScript looks like helps demystify it. Here's a tiny example:

let userName = "Sarah";
let itemCount = 3;
 
if (itemCount > 0) {
  alert("Welcome back, " + userName + "!");
}

Even without any programming knowledge, you can probably guess what this does: it checks if the item count is more than zero, and if so, shows a welcome message with the user's name.

That readability is part of why JavaScript became so popular. It's not always this simple, but the basics are approachable.

JavaScript Everywhere: The Node.js Revolution

Originally, JavaScript could only run in browsers. It was purely a frontend language. Then in 2009, something called Node.js was created, which let JavaScript run on servers too.

This was a big deal. Suddenly, developers could use the same language for both the frontend (what users see) and the backend (server-side logic). Before Node.js, you had to learn different languages for each side.

Today, a massive portion of web development uses JavaScript on both the frontend and backend. When AI tools generate a full-stack application for you, there's a very good chance both halves are written in JavaScript (or TypeScript).

This is why JavaScript is so dominant: it's the only language that works everywhere web software exists.

Enter TypeScript: JavaScript with Guardrails

TypeScript was created by Microsoft in 2012 to solve a specific problem: JavaScript is too forgiving.

Here's what that means. In JavaScript, you can write code like this:

let price = "29.99";
let total = price + 10;
// total is "29.9910" — a string, not 39.99!

JavaScript happily combines a text string and a number without complaining, producing a completely wrong result. It doesn't tell you something is wrong until the user sees a broken total.

TypeScript adds type checking — it makes you specify what kind of data each variable should hold. If you say price is a number, TypeScript will catch it immediately if you accidentally assign text to it.

let price: number = 29.99;
let total: number = price + 10;
// total is 39.99 — correct!

Think of it this way: JavaScript is like a spell checker that's turned off. You can write whatever you want, and it won't complain — even if there are errors. TypeScript is the spell checker turned on. It flags problems while you're writing, before anyone else sees them.

Why TypeScript Has Taken Over

Almost every modern web project uses TypeScript instead of plain JavaScript. The AI tools you use will almost certainly generate TypeScript. Here's why:

Fewer bugs. TypeScript catches a whole category of errors before the code even runs. This is especially valuable for vibe coders because the AI occasionally makes mistakes, and TypeScript helps catch them.

Better AI assistance. AI tools work better with TypeScript because the type information gives them more context about what the code should do. It's like giving the AI a better map.

Easier to understand. Ironically, the extra "annotations" in TypeScript make code easier to read. When you see function getUser(id: number): User, you know it takes a number and returns a User, even if you don't understand the implementation.

Industry standard. Most companies and open-source projects have moved to TypeScript. The tools and libraries you'll use expect it.

Where You'll See JavaScript and TypeScript

When you build a project with an AI tool, here's where JavaScript/TypeScript shows up:

React components — The building blocks of your user interface. Files ending in .tsx (TypeScript + React) or .jsx (JavaScript + React) contain the visual components of your app.

API routes — Server-side code that handles data requests. Usually in files inside an api folder.

Configuration files — Files like next.config.ts or tailwind.config.ts that control how your project is set up.

Utility functions — Shared code that performs common tasks like formatting dates, validating inputs, or calculating values.

React and Next.js: The Dynamic Duo

Two names you'll hear constantly in the vibe coding world:

React is a JavaScript library (created by Meta, formerly Facebook) for building user interfaces. It lets you create reusable "components" — a navigation bar, a card, a form — and compose them together like building blocks. Almost every modern web app uses React.

Next.js is a framework built on top of React that adds essential features: page routing, server-side rendering, API routes, and much more. It's the most popular way to build React applications, and it's what most AI tools generate by default.

When an AI tool builds you a web app, it's almost certainly using React (for the UI components) and Next.js (for the overall structure). Understanding this helps you navigate the generated code — even if you can't write it yourself.

The "package.json" File

Every JavaScript/TypeScript project has a file called package.json at its root. Think of it as the project's resume — it lists:

• The project's name and description
• All the libraries and tools it depends on (called "dependencies")
• Scripts you can run (like "start the development server" or "build for production")

When you see package.json, you know you're looking at a JavaScript/TypeScript project. We'll learn more about this when we cover npm in the tools module.

Try this now

• Open one .ts or .tsx file in your project and identify the component name, the props, and one function call.
• Find one place where TypeScript is telling you what kind of data is expected.
• Ask your agent to explain the difference between the JavaScript behavior and the TypeScript guardrail in that file.
• Notice how much easier review becomes once the shapes of the data are explicit.

Prompt to give your agent

"Explain this JavaScript or TypeScript file to me before changing it.

1. Tell me what runs in the browser and what runs on the server
2. Explain any important types, props, or return values
3. Tell me what TypeScript is protecting me from in this file
4. Point out the highest-risk area for silent bugs
5. Stop before converting between JavaScript and TypeScript unless there is a strong reason

I want clarity about behavior and data shape, not just a summary."

What you must review yourself

• Whether the types reflect the real data coming in from forms, APIs, and databases
• Whether the agent is bypassing type errors instead of fixing the underlying mismatch
• Whether browser-only and server-only code are staying in the right runtime
• Whether a type-safe file is still doing something logically wrong despite compiling cleanly

Common mistakes to avoid

• Turning off or weakening types just to make an error disappear. That removes signal instead of fixing the problem.
• Converting files between JavaScript and TypeScript casually. Migrations add churn and should pay for themselves.
• Treating TypeScript as decoration. The whole point is to make bad assumptions visible early.
• Assuming passing types means the feature is correct. Type safety helps, but it does not replace business-logic review.

Key takeaways

• JavaScript powers interactivity across the web, and TypeScript adds useful guardrails on top of it
• Most modern web projects will ask you to review .ts and .tsx files more often than any other format
• The fastest way to guide an agent well is to ask about data shape, runtime boundary, and type intent up front

What's Next

JavaScript handles the interactive behavior, but what about the visual structure and styling? In the next lesson, we'll look at HTML and CSS — the building blocks that every web page is made of, and the ones you'll recognize most easily when reading your app's code.