What Is Angular and Why Does It Exist? The Reason Behind the Framework

One Morning, When You Woke Up with Vanilla JavaScript

Let's say you're a developer named Mert Özen, and you sit down to get a small job done: display a list of users on a page, add a search box, and filter the list as the user types. Simple, right?

You start with plain JavaScript. First you fetch the data with fetch. Then, with a for loop, you manually create a DOM element for each user with document.createElement and append it. You bind an input event to the search box. When the user types a letter, you wipe the list and redraw it. Then a "selected user" feature comes along, and an "add to favorites" button... and before you know it, half your code is nothing but an effort to manually keep the HTML on screen in sync with the data in memory.

This is exactly the pain Angular exists to relieve. But before we get there, let's define clearly what it is.

What Is Angular? The One-Sentence Answer

Angular is a TypeScript-based frontend framework, developed by Google, used to build single-page applications. In other words, it handles the side that runs in the browser and produces the interface the user sees.

Every word in that sentence matters, but the most critical one is "framework." Because the key to understanding Angular lies in grasping that it is a framework, not a library.

Framework vs Library: Who Calls Whom?

These two are constantly confused, yet the difference comes down to a single question: who's in control?

When you use a library, control is yours. You write your own code and, when you need it, you call the library's function. It's like a screwdriver in your toolbox; you decide when and how to use it. React, at its core, leans closer to this side.

With a framework, control is inverted. You place your code according to the framework's rules and structure, and the framework calls your code. In software this is called "Inversion of Control." As the famous saying goes: "Don't call us, we'll call you."

Let's expand the analogy. A library is like a store where you pick out furniture one piece at a time while furnishing your home; where each couch goes is entirely up to you. A framework is like a turnkey house with the floor plan already drawn; the kitchen goes here, the bedroom there, decided up front. You just fill those rooms with your own belongings. It may feel restrictive, but it has a huge advantage: when a team of ten works in the same house, everyone knows where the kitchen is.

What Problem Does Angular Solve?

Let's return to the scenario at the top. With plain JavaScript, the thing that wore you out most was keeping the data and the screen in sync. This is exactly the core problem Angular solves, and it's called data binding.

In Angular, you change the data (a variable) and the screen updates automatically. No manual document.createElement, no manual DOM updates. You say "this user's name is now Mehmet," and the name on screen changes by itself. Here's a small example:

@Component({
  selector: 'app-user',
  template: `
    <h3>{{ userName }}</h3>
    <button (click)="changeName()">Change Name</button>
  `
})
export class UserComponent {
  userName = 'Mert';

  changeName() {
    this.userName = 'Mehmet';
  }
}

That's it. When the button is clicked, the userName variable changes and the text inside <h3> automatically turns from "Mert" into "Mehmet." There isn't a single line where we touch the DOM by hand. Don't worry, we'll take apart every piece of this code (component, selector, template, those curly braces) one by one in the coming articles. For now, it's enough to feel the sensation of "I changed the data, and the screen updated itself."

Why TypeScript? Why Mandatory?

Angular is written in TypeScript, not JavaScript, and this is not a preference but a requirement. TypeScript is a language that adds a type system on top of JavaScript; that is, you declare up front whether a variable is a number, a string, or a user object.

Why bother? Because in large applications, most bugs are of the "I didn't get what I expected" kind. You expect a number in a function but a string arrives, and you only notice it when the app crashes in the user's hands. TypeScript catches these bugs while you're still writing code, without ever opening the browser. It's like checking the steel before you build the wall; it's far cheaper than waiting for the collapse later.

The Angular team placed this safety so centrally that the framework itself was written top to bottom in TypeScript. You'll write it that way too. Good news: if you know JavaScript, 90% of TypeScript will already feel familiar.

So When Is Angular the Right Choice?

Not every tool fits every job. Let's honestly lay out where Angular shines and where it doesn't.

Angular is tailor-made for large, long-lived applications. Think of a banking dashboard, an enterprise management system, a project that will live for years and be touched by dozens of developers. Angular's "everything has its place" structure isn't a burden here, it's a blessing; someone new joining the team figures out how the project is organized from day one.

On the other hand, if you're building a single landing page or spinning up a small weekend experiment, Angular can feel too heavy. The cost of setting up that structure can outweigh the job itself. In such cases, lighter tools make more sense.

In short: Angular is like a truck. You don't drive a truck to go buy bread around the corner, but you don't move a house on a bicycle either.

A Quick Comparison with React and Vue

Angular is hard to understand in isolation; it falls into place when compared with its neighbors. All three do the same job (build interfaces) but their philosophies differ.

React is actually not a full framework but a library. It gives you only the interface layer; things like routing, form management, and HTTP you add from outside and architect yourself. It's free, but it leaves the decisions to you. Vue sits in between the two; more structured than React, more flexible than Angular.

Angular follows the "whole package" philosophy. Routing, form management, and the HTTP client all come out of the box. You don't bother picking separate libraries and gluing them together; they all arrive compatible from the start. The price for this is a slightly steeper learning curve at first, and the reward is consistency and order in large projects.

A Small Experiment

We didn't write a single line of code in this article, but there's something I want you to think about. Open a web application you use or admire (an email client, an admin panel, social media, whatever it is). Ask yourself: "On this screen, when I do something (click a button, type in a box), how does the rest of the interface update instantly?"

For example, when you mark a message as read, the "unread" counter at the top drops instantly. That synchronization is a nightmare if written by hand in plain JavaScript; with a framework, it comes almost for free. Hold onto that feeling, because in the next article we'll install Angular on your machine and create our first project. There, you'll see this "automatic sync" magic with your own eyes.

And think about this too: Why do you suppose that app might have been written with Angular (or React, or Vue)? The size of the project, the size of the team, how long it will live... The answer to these questions is also the answer to choosing the right tool.