Programming languages and runtimes Explained and Compared

Which parts of your app need a language choice?

Start with something a person needs to do, such as choosing a time and finding the saved booking again. Find out what displays the page, what receives the choice and where the result is kept. Then check what your project already uses for each job.

Can the same language run in the browser and on the server?

Yes. A booking page can use JavaScript to show which time a person selected, then use JavaScript in a server environment such as Node.js to handle the request. The two parts can speak the same language and still do different jobs.

A build tool may also use Node.js to prepare the page files. That alone says nothing about what runs when someone visits the site. Ask what runs after they choose a time.

A service that receives a booking has to check the request even when the page already checks it. The browser helps the visitor fix a mistake. The receiving service decides whether to accept and save the request.

What each part does in a booking app
Part	What it does
Language	Gives you the words and rules for writing instructions, such as checking whether a name is blank.
Runtime	Runs those instructions. The browser can change what is on the page. A server runtime can do work after a request arrives.
Framework	Gives the project a structure for pages, requests or both. It helps you find where the booking rule belongs.
Host	Delivers the prepared page or runs the service visitors talk to. Shared bookings still need a place to be saved.

How can you trace one booking through the app you already have?

Start on paper with made-up names and times. If you want to repeat it in a running app, first confirm that the copy uses a disposable booking store and cannot send real messages or take payments. If sign-in is required, confirm it uses a separate test account store before creating accounts. Keep the exercise on paper if you cannot verify those connections.

Follow the visitor’s choice
Write down the three times the page shows and where you think the choice goes. Ask whoever maintains the project to show which code displays it and which code receives it.
Try a missing name
The page can point out the missing name. Ask the maintainer to check the receiving rule separately in the test harness. An incomplete request should produce a useful error and leave the booking list unchanged.
Save one complete booking
Use one fictional name and confirm the expected time. In a test copy, look up the saved booking after a fresh page load. If a reply goes missing, check the saved result before trying again.
Write down what ran
Record the language, the runtime and the service used for each step. Leave an item open if you cannot verify it from the project or the host. This gives you a baseline for a later upgrade.

Compare tools

Scroll the table sideways to read every column.

Where languages and runtimes fit in a web or mobile app
Tool	Where does it fit?The job it can do in your app.	When can it catch a mistake?What checks the code or the submitted value.	What would a change involve?What you can keep and what you need to retest.	What has to run?The execution and hosting requirements for that job.	What support should you check?Which platform, project or release has to be compatible.
JavaScript	Browser interactions or code in a JavaScript server runtime.	Runtime checks handle form values. A separate checker can inspect JavaScript code.	Keep existing files and try a change to one form or module.	A browser runs the page. Server work needs a suitable runtime.	Check the browser features or the server runtime the project uses.
Node.js	A runtime for JavaScript outside the browser.	Its built-in TypeScript mode can strip types without checking them.	Check the dependencies and retest the build and the running app.	Install Node where that code runs. A build-only project can ship prepared files.	Check an upstream LTS line that the host and project support.
PHP	Receives web requests on the server or runs a command-line job.	Check submitted values in the receiving PHP code.	Check the project’s libraries, PHP extensions and database setup.	A live site needs PHP-capable hosting. The built-in server is for development.	Check the host’s PHP branch and its upstream support window.
Python	Reads or transforms data in scripts, or runs a separate web service.	For a CSV report, check the actual fields and rows the script reads.	Try one file-based job before splitting a working app into services.	A local script needs Python. A deployed web app needs a production setup.	Check CPython support and compatibility with your required packages.
Ruby	Runs local scripts and web app code, including Rails apps.	Use an actual form and check the response and saved result.	Keep the dependency files and test the same app flow on the target platform.	Install Ruby, its dependencies and the production setup the app needs.	Check Ruby’s maintenance branch, Rails and required packages.
Swift	Builds Apple platform apps and other targets with the relevant SDK.	The build can catch code errors. Try the screen and save separately.	Recheck the app’s target, packages and release settings.	For the Xcode workflow, use a Mac with supported macOS and the SDK for the target device.	Check the Xcode, target OS and current store requirements.
TypeScript	Adds checks to code that is used as JavaScript.	A checker catches code mismatches. The app still checks real input.	A project can migrate incrementally without renaming everything.	A build or runtime handles conversion. Confirm a type check also runs.	Check the compiler version your framework and editor tools support.

Why might your project use TypeScript?

TypeScript can flag a mistake before you try the page. If your code expects a booking count as a number and another part supplies text, a type check can tell you where the two parts disagree.

Ask which command actually checks types in your project. A tool can turn TypeScript files into JavaScript without checking them. A successful preview can therefore miss errors that the project’s checker would report.

When a visitor submits a real form, the receiving code still has to check the actual data. TypeScript can describe what a booking should look like. It cannot tell you whether the next request has a valid name or whether the selected time was saved.

When is another language worth adding?

Give it one job that the existing project cannot do well. A one-off report from a spreadsheet can start as a local script. If it just needs to run once a week, it can stay a scheduled job. Add a web service when another part of your app needs to ask it for a result on demand.

When a separate program might earn its place
You need	First thing to check
A weekly report from saved bookings	Start with a fake CSV file. See whether a small script can produce the result on demand before adding a live service.
A change to a working site	Use the project’s current language and framework for one small change. Check that the saved result still behaves as before.
A feature inside an existing iPhone app	Check the device features, build tools and store requirements you actually need before replacing a working web page.

What should you keep before upgrading or changing hosts?

Keep the code, the versions it uses and a way to restore the test data. Start by checking the version that actually runs on the host. The version on a laptop may differ.

Record how the project installs dependencies and runs its checks. Keep any lockfile it uses, which records the package versions the project resolved. Verify that the host supports those versions and test a small release in a private copy.

Keep saved records, uploaded files and access settings in your recovery plan too. A copy of the code does not contain them. If you plan to change hosts, check what the new service charges for running the app, keeping data and restoring backups.