Programming Languages Behind Websites and Apps, and Files, Builds and Packages

Why You Should Know the Languages

You have now seen what a website is, how an app is arranged, and how to plan a build and prompt the AI. Today we go one level deeper and name the languages underneath all of it. Not so you can write them — you will not write code in this program — but so that the words stop being noise and start being information.

This is the difference between someone who says the app is broken and someone who can say the form is not sending the customer's details to the database. The second person gets their problem fixed in one message. Naming things is most of the skill.

There is a useful comparison here. You do not need to be a mechanic to know that your car needs fuel, oil and tyres, and that the noise under the bonnet is not normal. That knowledge does not let you rebuild the engine, but it lets you describe the problem, judge the quote, and know when you are being told nonsense.

The languages of the web work the same way. Knowing what HTML, CSS and JavaScript each do — and knowing that a database is not the same thing as a website — turns you from someone who can only say it is not working into someone who can describe exactly what they want and what has gone wrong. In this program the AI writes the code; you are the one who has to brief it, judge it and correct it.

Every language carries assumptions. Choosing one quietly decides how the app will be built, how easy it will be to change later, and who will be able to maintain it. When a developer tells you we will build this in React Native, they are not being technical for the sake of it — they are telling you that one build will run on both iPhone and Android, which changes the cost and the timeline.

The names also matter when you are comparing quotes or reading a job description. A builder who can hear Flutter and React Native and understand that both mean one codebase, two phones is in a much stronger position than one who nods politely and hopes for the best. You are buying understanding, not code.

The Three Languages of Every Website

Every website you have ever opened — no matter how complicated it looks — is made of three languages working together. They map neatly onto the three questions you already ask about any page: what is on it, what does it look like, and what does it do when touched.

HTML is the structure: the words, the headings, the images, the links, the form fields and the order they sit in. It is the skeleton of the page, and on its own it is plain and unstyled — black text on white, one line after another. That plainness is the point: HTML says what things are, not what they look like.

When you describe a page to the AI as a heading, a paragraph, a picture, three product cards and a button, you are describing HTML. Nothing about colour or layout has entered the conversation yet. Getting the structure right first is what stops a page from being pretty and useless.

CSS is the styling: the colours, the fonts, the spacing, the widths, the rounded corners and the way the page rearranges itself on a phone. Everything you learned in the design classes — palettes, type scales, white space, responsive layout — is expressed in CSS. It takes the skeleton HTML gives you and dresses it.

The important thing about CSS is that it is separate. You can restyle an entire site without touching its structure, and you can restructure a page without losing its look. That separation is why a business can rebrand without rebuilding, and why changing one colour in the right place can update a hundred pages at once.

JavaScript is the behaviour: what happens when a visitor does something. Tapping a menu and having it open, typing into a search box and watching results filter, adding an item to a basket and seeing the total change — all of that is JavaScript. It is the only one of the three that runs after the page has loaded and responds to the user.

This is where a page stops being a document and starts being an app. A form that checks the phone number before it lets you continue, a button that shows a loading spinner while a payment is processed, a cart that remembers what you added — every one of those is JavaScript doing work in the background. When someone says a website feels alive, they are describing JavaScript.

The Tools Built on Top of JavaScript

Plain JavaScript works, but building a large app with it becomes difficult — the same problems get solved in slightly different ways, and mistakes slip through. So a layer of tools has grown on top of it. You will hear these names constantly, and they are worth knowing.

TypeScript is JavaScript with rules attached. Where JavaScript lets you put anything anywhere, TypeScript lets you say that this field holds a price, this one holds a name, and this one holds a date — and it complains immediately if the app tries to treat a name as a price.

The benefit is fewer silent mistakes. In a small project the difference is barely noticeable; in an app with hundreds of screens it is the difference between a bug you find in seconds and a bug you hunt for a day. Most modern tools, including the ones behind the builders you will use, are written in TypeScript.

React is the most widely used tool for building what a user sees and touches. Instead of thinking of a page as one big document, React lets a builder think in pieces — a card, a form, a header — each of which can be reused and rearranged. That is why the same product card can appear in a shop, in a search result and in a wishlist without being written three times.

React is not the only one; Vue and Angular solve the same problem differently, and Svelte is a lighter, newer take on it. They are all called front-end frameworks, and the front end simply means everything the user can see. Base44 builds its interfaces with React, which is why the screens you generate feel like an app rather than a document.

The Languages Behind the Scenes

The three languages of a website all run in the visitor's browser. But some things must never happen on the visitor's own device — checking a payment, storing an order, deciding who is allowed to see what. That work happens on a computer you never see, and it has its own languages.

The backend is the part of an app that runs on a server rather than in the browser. It is where orders are saved, payments are verified, and rules like only an admin can see all orders are actually enforced. If the front end is the shopfront, the backend is the stockroom and the till.

Node.js lets JavaScript run on that server, which is why JavaScript appears on both sides of so many modern apps. It is a popular choice because one language can cover the whole build — but the important idea is not the name, it is the split. Anything a user must not be able to tamper with belongs on the backend, never in the browser.

PHP and Python are two other backend languages, and both are extremely common. PHP still powers a very large share of the web, including WordPress, which runs a huge number of business websites. If you have ever hired someone to make a small change to a WordPress site, that change was PHP.

Python is the other big one, and it is often chosen when the app has to do something clever with data — recommendations, reports, automation, or the AI features you will meet later in this program. You are unlikely to be asked to choose between them yourself, but you will meet them when you inherit or extend an existing system, and knowing which is which stops the conversation from being intimidating.

A database is where the app keeps its information permanently: customers, products, orders, bookings, messages. It is not a file on your computer and it is not the same thing as the website — it is a separate system the app talks to when it needs to remember or retrieve something.

SQL is the language used to ask a database questions: show me every order placed this week, give me the total spent by this customer, list the products with fewer than five in stock. You will not write SQL in this program — the builder writes it for you — but understanding that the data lives in a database, and that a database can be asked questions, is what makes reports, dashboards and analytics make sense.

Examples of the databases you will hear about most often: MySQL, PostgreSQL, MongoDB, SQLite, Microsoft SQL Server, Oracle, Firebase and Supabase. MySQL, PostgreSQL, Microsoft SQL Server and Oracle store information in tables and are asked questions in SQL. MongoDB and Firebase store it as flexible documents, which is what people mean when they say NoSQL. SQLite is a small database that lives as a single file inside the app itself, which is why it is used on phones. Supabase sits on top of PostgreSQL and adds the ready-made pieces — login, storage, real-time updates — that a new app usually needs.

The Languages of Mobile Apps

Mobile apps use a different set of languages, mainly because iPhones and Android phones are different machines. This is where the single biggest practical decision in app building lives: build twice, or build once and hope it fits both.

Swift is Apple's language for building iPhone and iPad apps, and SwiftUI is the modern way of describing an app's screens in it. Together they are the native route on Apple's side — native meaning built specifically for that platform, using its own tools.

The advantage is that the app feels exactly like an iPhone app should, with Apple's own gestures, animations and performance. The cost is that this code does nothing on Android. If you want an Android app as well, someone has to build it again in a different language.

Kotlin is Google's recommended language for Android, with Java as the older language still found in a great deal of existing Android code. Together they are the native route on the Android side, the equivalent of what Swift and SwiftUI are to the iPhone.

The same trade-off applies in reverse: excellent fit with the platform, but no reuse on iOS. A business that goes fully native has two separate apps, two sets of code and often two teams — which is realistic for a bank and rarely realistic for a small business.

Flutter is Google's tool for building one app that runs on both iPhone and Android. It uses a language called Dart, and it draws its own interface rather than borrowing each phone's, so the app looks identical on both.

That consistency is Flutter's strength, and it is why it is popular with businesses that want one build, one budget and one look across every phone. The trade-off is that the app can feel slightly less native than one built specifically for the platform — usually a small price to pay.

React Native takes a different route to the same goal. It lets a developer build both apps using JavaScript and React — the same tools used for websites — so a team that already builds web apps can build a mobile app without learning two new languages.

Because it uses each phone's real interface elements rather than drawing its own, apps built with React Native often feel closer to native than a drawn interface does. It is one of the most common choices for startups, and it is the reason a single small team can ship an iPhone app and an Android app at once.

So there are two roads. Native means one build per platform: the best possible fit and feel, at roughly double the cost and effort. Cross-platform means one build for both: faster and cheaper to make and to maintain, with a small compromise on how perfectly native it feels.

The practical rule for the businesses in this program is simple. If the app is your product — a game, a camera tool, something that leans hard on the phone's hardware — go native. If the app is a business tool, a shop, a booking system or a customer portal, cross-platform is almost always the right answer. You get both stores, one build, one budget.

What Base44 Writes for You

This is the part that matters most, and it is the reason you have spent today learning names rather than syntax. Everything described in this class is written for you when you build in Base44 — but you still have to know what you are asking for.

When you build in Base44, you are building a web app in React and TypeScript, with a backend and a database behind it. The same build is then wrapped so it can be published as a mobile app on both the App Store and Google Play — the cross-platform route, without you writing or choosing any of it.

That means the language question that used to decide your budget has already been answered for you. You are not choosing between Swift and Flutter. You are choosing what your app does, who it is for and what it must remember — which is exactly where your attention belongs.

It helps because prompting is briefing. When you tell the builder that the order form should check the phone number before the customer can pay, you are asking for JavaScript behaviour and a backend rule. When you say only an admin should see all orders, you are asking for something that must live on the backend, not in the browser where a visitor could reach it.

It also helps you judge what you are told. If someone offers to build you a native app for both iPhone and Android for the price of one, you now know that is not how it works. And if a change you want turns out to be styling rather than structure, you know it will be quick — which is exactly the kind of judgement that saves money.

This is the complete list of what Base44 uses to build your app, in plain terms. Each line names a tool and then says what it actually does in your project.

For mobile, there is no separate language to learn, and this is the part worth remembering. The very same React build that runs as your website is wrapped in a native shell and packaged into the files the stores accept — one codebase producing the Android package and the Apple package, exactly the cross-platform road from earlier in this class. So the honest answer to what Base44 builds with is short: JavaScript and TypeScript, React on the front, TypeScript on the backend, Tailwind CSS for styling, a MongoDB-compatible database for memory, and the same build wrapped up for the phones.

Your app does not have to live only inside Base44. Base44 can be connected to GitHub — the platform where professional developers store and track their code. Once connected, the two stay in step: your app is kept as a repository on GitHub, and changes made on either side are synchronised between them.

Why that matters is simple: it means you own the code and you are never locked in. You can take the whole project out, open it in any code editor, and hand it to a developer who works outside Base44. A designer can work on the styling in their own tools, a developer can add a feature in their own environment, and the result still comes back into your app. GitHub also keeps a history of every change, so you can see what was altered, when and by whom — and return to an earlier version if something breaks.

The one thing to know in advance is that keeping two copies of the same project in step can occasionally produce a conflict, when the same file has been changed on both sides at once. Base44 handles this inside the editor: it shows you which files are conflicting and offers to resolve them with AI, so you are never left to untangle it by hand. For most builders this is a detail rather than a daily concern — the point is simply that your code is portable, and your work can grow beyond this platform whenever you want it to.

Getting your code out is not a technical procedure you need to prepare for. It is a few clicks, and you can do it at any point, whether your app is half built or already live.

One thing worth saying plainly: exporting does not remove your app from Base44 and does not switch anything off. You are simply taking a copy of what already exists. Your live app, your users and your data all carry on exactly as they were.

Source Code and the Built File

Day 10 begins with a question that surprises almost everyone: the file you install on a phone is not the app you built. It is something made from it. Understanding the difference explains a whole category of confusion that otherwise shows up at the worst possible moment — the day you try to publish.

Before an app is built, it is a folder of files: the code for every screen, the images, the fonts, the settings, and a list of the packages it depends on. This is the working version, and it is the version you change. It is written for humans and for the tools that run it, not for a phone.

This matters because this folder is the app's true home. Everything else — the installed app, the store listing, the update a user downloads — is produced from it. If this folder is lost and not backed up, the app cannot be changed again, only rebuilt from scratch. It is the single most valuable thing in the whole project.

Source code is what you write and edit; a built file is what a phone runs. The build step takes the source, gathers everything it needs, removes what it does not, and compresses the result into one package that a phone can install. The same source can produce a test build for your own phone and a release build for the store.

The practical consequence is that a built file is one-way. You cannot open it, fix a typo and rebuild — the human-readable version is gone. This is why a change is always made in the source and then built again, and why the answer to I want to change one word is never to edit the installed app.

The File You Actually Install

Each platform has its own package format, and the names are worth recognising because they come up in every conversation about launching. Two belong to Android and one belongs to Apple.

An APK — Android Package Kit — is the classic Android app file. It is the single file that contains the whole app, and it is what gets installed on an Android phone. If you have ever sent an app to a friend as a file rather than through the store, you sent an APK.

Its weakness is that it is one size for everyone: the same package carries the code and images for every kind of Android device, so each phone downloads parts it will never use. That waste is exactly what the newer format was created to fix.

An AAB — Android App Bundle — is the modern Android format, and it is the one Google Play now requires for new apps. It is not installed directly. Instead, you upload it to Google Play, and the store builds a tailored version for each device, sending a phone only what that phone actually needs.

For you the practical effect is a smaller download and a better install experience for your customers, with nothing extra to do. The name is worth remembering simply because you will be asked for it: when Google Play asks for your app file, it wants the AAB, not the APK.

An IPA is Apple's equivalent: the packaged file for an iPhone or iPad app. Like the AAB, you do not hand it to a customer directly — you upload it to the App Store, and Apple reviews it before it becomes available to anyone.

The important difference is the gatekeeping. Apple's review is stricter and slower than Google's, and an app can be rejected for reasons that have nothing to do with whether it works. Knowing that an IPA must pass review before it reaches a single user is what stops the last-minute surprise on launch day.

Signing, Builds and Updates

The last piece is the one that causes the most panic, because it involves a file you must never lose. Signing is how a phone knows that an app genuinely came from you and has not been tampered with.

Before an app can be installed or published, it is signed with a key — a long, unique code that identifies you as its author. The phone checks that signature every time the app updates, and refuses the update if it does not match. It is the app's identity card.

Which is why the rule is absolute: back up your signing key and its password somewhere you will not lose them, and never share them. If the key is lost, you cannot publish updates to the existing app under the same identity — you would have to publish a brand-new app and ask every customer to install it again. This is the most common avoidable disaster in app publishing.

A development build is the one you make to test on your own phone: it carries extra tools for catching errors, it runs faster to build, and it is not meant for customers. A release build is the trimmed, optimised version prepared for the store.

The two are made from the same source, but they behave differently, and that is the trap. Something can work perfectly in a development build and fail in a release build because the extra safety tools are gone. This is why the final check is always done on a release build, on a real phone, before submitting — never on the version you have been testing with all week.

Every app carries a version number, and it goes up every time you publish. Users do not see the number itself; they see Update available in their store, or the app quietly updating in the background. Underneath, the store is comparing your new build's number against the one they already have.

This is why a published app can never be replaced silently with a different app. An update must be the same app, signed with the same key, with a higher version number. Once you understand that, the whole publishing process stops being mysterious: you are not uploading a file, you are handing the store the next version of an app it already knows.

Publishing is the moment all of this comes together. Your project is built into a release package, signed with your key, and uploaded to the store. The store checks it, and on Apple it is reviewed by a person before anyone can download it. Once approved, it appears in search, and customers install it like any other app.

And from then on, every change you make follows the same path: edit the source, build a new signed release, upload it, and wait for approval. Nothing about that loop is difficult once it is understood — and that understanding is exactly what today was for. You now know every word in that sentence.