Languages and frameworks

Sooner or later, every AI tool you work with is going to ask you a version of this question.

What language do you want to use for this?

And here is the actual, honest, useful answer most of the time, which almost nobody will say out loud.

It does not matter. Pick whichever the AI suggests first. Move on.

That probably sounds like a cop-out. It is not. Let me explain why it is the right answer for the kind of building you are going to do in this course.

There are 100+ languages and they all do mostly the same thing

A programming language is just a set of words and grammar rules that the computer agrees to take seriously. There are a lot of them (Python, JavaScript, TypeScript, Ruby, Go, Rust, Swift, Java, C#, PHP, Kotlin, Elixir, and on and on), and they differ from each other roughly the way English differs from German: same job, different costumes.

Some languages are popular because they are easy to read (Python). Some are popular because they are fast (Go, Rust). Some are popular because a giant company committed to them and now there are millions of jobs (JavaScript, Java, C#). Some are popular for the same reason a bar is popular: people you trust were already there (Ruby).

For most things you are going to build with AI as a non-engineer, the choice of language is roughly as important as the choice of font you write your grocery list in. The list still says what to buy.

What actually matters: frameworks

When AI asks you "what language" it is usually really asking "which framework do you want," and that is a much more meaningful question, even though most people do not realize they are being asked it.

A framework is a pre-baked set of decisions that someone else made for you. They picked the structure, the conventions, the libraries to include, and they wrote a lot of boilerplate so you do not have to. You arrive, you fill in the parts that are specific to your idea, you ship.

Examples by language:

• JavaScript or TypeScript with React, Next.js, or Vue. Heavily used for websites and web apps.
• Python with Django, Flask, or FastAPI. Heavily used for backends, data work, and ML.
• Ruby with Rails. Heavily used for small-to-medium web apps.
• Swift with SwiftUI. iOS apps.
• Kotlin with Jetpack Compose. Android apps.

When you tell Claude I want to build a marketing website, what Claude actually hears is closer to should I pick Next.js or Astro? than should I pick TypeScript or Python? The language is downstream of the framework, which is downstream of the kind of thing you are building.

A useful heuristic when AI insists you choose

Some AI tools will not let you skip the language question, they want a specific answer. Here are the answers that will work for most builds the average reader of this course is doing, in rough order of frequency.

• A website or web app: TypeScript with Next.js.
• An iPhone or Android app: start by asking yourself if it actually needs to be an app (Day 16). If it does, Swift for iOS or Kotlin for Android.
• A script that does one thing on your laptop: Python.
• A small internal tool used by a few people: TypeScript with Next.js, again.
• An AI workflow that runs once a day: Python.

These are not the only answers, they are defensible defaults. When Claude asks the question, type the answer for your bucket and proceed. You can always change the language later, and most people never do.

Why we are not going deeper

It is tempting, in a course like this, to do a comparative tour. Python versus JavaScript, static versus dynamic typing, compiled versus interpreted, and so on.

We are not going to. Three reasons.

First, every comparison gets stale within two years, because the relative quality of language ecosystems shifts constantly. Whatever is true in 2026 will not be true in 2028.

Second, the comparison is mostly aesthetic for people at your stage, comparable to spending three hours choosing between two restaurant menus that are 90% the same.

Third, the AI tools that will help you build will themselves have strong opinions about what they prefer. You let them pick, you build the thing, and when you build your fourth or fifth thing you might develop a preference of your own. Not before then.

Things "framework" is not

Worth a quick disambiguation before Day 6.

A framework is not a library. A library is a single package of code that does one specific thing (parse a date, send an email, encrypt a password). You use many libraries inside a framework.

A framework is not a language. A framework is built in a language.

A framework is not an operating system. The operating system (macOS, Windows, iOS, Android) is the thing your laptop or phone runs. Your code runs on the operating system, possibly inside a framework, possibly using a bunch of libraries.

You will hear all of these words used loosely in conversation. The right move when you hear them is to ask "what flavor of the thing are we talking about?" Most builders will respect the question.

Forward references

Day 6 takes "code is just files" and turns it into something you can hold in your head. Day 8 will show you a specific framework (the one we use as our worked example for most of the course) without making you learn it. By Week 3 you will pick your own framework, defensibly, without spending a weekend agonizing over it.

Day 5 wrap

The thing you can now say plainly. Programming languages are different costumes for the same basic job, and frameworks are pre-packaged decisions someone else made for you. The framework choice usually matters more than the language choice.

The thing you can now do. When an AI tool asks you "what language do you want to use," give it a confident, defensible default for the kind of thing you are building, and stop debating with yourself.

The guardrail to remember. Spending more than a minute on this question is a tell that you are procrastinating on the actual hard work, which is deciding what you are building.

See you on Day 6, where we look at where all this code actually lives, on disk.