The kinds of frameworks

docs.scrimba.com

What is a framework covered the idea: structure plus solved plumbing, with the framework calling your code. This chapter is the map of what actually exists: a tour with a reassurance built in, because nobody knows all of these. Working developers know one or two families well and recognise the rest, and that is the goal here too. Families matter more than names: learn one member well and its siblings come quickly.

The web: front-end and back-end

Web frameworks split along the line the web itself splits on. Front-end frameworks run in the browser and manage what the user sees; back-end frameworks run on a server and manage data, accounts, and everything behind the scenes. If you are heading into web development, one from each side will likely become a daily tool, and which one is usually decided by the team or project you join rather than by you.

The front-end names you will meet:

• React: the most used by a wide margin, with the largest ecosystem and job market. Technically a UI library rather than a full framework, a distinction with a useful core covered below.
• Vue: known for a gentle on-ramp and documentation people actually enjoy; a complete, well-organised middle path.
• Angular: Google's batteries-included framework, opinionated about everything; most at home in large organisations that want one sanctioned way to do each thing.
• Svelte: does its work at build time and ships less code to the browser; smaller community, frequently admired by the people in it.

And the back-end names, where the framework is usually tied to a language:

• Django (Python): batteries included, from database to admin interface; a frequent partner to the Python you may already know.
• Rails (Ruby): the framework that popularised convention over configuration; its ideas echo across most modern web frameworks, Laravel included.
• Laravel (PHP): the modern standard of the PHP world, which still runs a very large share of the web.
• Express (JavaScript): deliberately minimal, closer to a toolkit than a full framework; you assemble the rest yourself.
• Spring (Java): the enterprise workhorse; sprawling, deeply established, and everywhere in large companies.

Once you can see past the logos, the same ideas repeat across every one of these. Front-end frameworks all converged on components: small, reusable pieces of interface that own their look and behaviour. Back-end frameworks all offer routing (which URL runs which code), some way to talk to a database (often an ORM, which lets you work with database rows as ordinary objects), and a slot for your business logic. Learn what these ideas are for in one framework and you have learned most of the next framework already; moving between them mostly means new syntax and new folder names over the same concepts.

The current front end has one more layer. React, Vue, and Svelte handle the interface but leave routing, data loading, and server rendering to you, so each grew a meta-framework: a framework built on top of the library that supplies those missing pieces. Next.js plays that role for React, Nuxt for Vue, and SvelteKit for Svelte, and in practice most new production apps reach for the meta-framework rather than the bare library. This also settles the old "is React a framework or a library" argument in a useful way: React itself only renders UI and inverts control over nothing but your components, which makes it a library by the last chapter's definition; wrap it in Next.js and the pair behaves exactly like a framework. The label matters less than knowing which layer owns which decision, because that is where you look when something misbehaves.

JunoWeb frameworks Front-end frameworks like React and Vue run in the browser and handle what people see; back-end frameworks like Django and Rails run on servers and handle data and accounts. You do not need to pick the perfect one today, and you definitely do not need them all. Most people learn the one their first team uses, and that works out fine!

JunoWeb frameworks The web names differ, the ideas repeat: components on the front end; routing, an ORM, and business-logic slots on the back end. Learn the ideas through one framework and the next one is mostly new syntax over familiar shapes. That transfer is why picking "the wrong one" first costs less than people fear.

JunoWeb frameworks Modern front-end work usually means a meta-framework: Next.js over React, Nuxt over Vue, SvelteKit over Svelte, supplying the routing and server rendering the base library leaves out. Keep straight which layer owns which decision, since that is where debugging starts. And React really is a library by our definition; Next.js is what makes the pair a framework.

Apps and games

Mobile development has its own framework story, and it centres on one question: build separately for iPhone and Android, or once for both? Two frameworks dominate the build-once answer. Flutter (from Google, using the Dart language) draws its own interface pixel by pixel, so apps look identical everywhere. React Native brings React's component model to mobile and drives each platform's native interface pieces, which is a natural continuation if you already know React.

Game engines are frameworks at their most total: they own the loop that runs sixty times a second, and your code fills in what each object does within it. Unity (C#) is the default for indie and mid-sized games and much of mobile gaming. Unreal (C++) leads where visual fidelity is the point, from big-budget games to film production. Godot is the free, open-source engine whose community has grown quickly, and a friendly place to start.

The cross-platform trade deserves its price tag read aloud. One codebase means half the work and one team, which is why businesses love it. The cost is a layer between you and the platform: when a brand-new iPhone feature ships, the framework needs to support it before you can use it comfortably, and squeezing out fully native feel takes extra care. Teams that need every native detail still build separately with each platform's own kit; teams that need to ship on both with a small crew pick Flutter or React Native and rarely regret it.

Game engines push inversion of control as far as it goes, which makes them a clarifying extreme case. The engine owns time itself: it calls your scripts every frame, runs physics between your callbacks, and decides when your object even exists. You also do not primarily write code "in" an engine; you work inside its editor, and scripts are one asset among scenes, materials, and prefabs. That total ownership is exactly why engines exist: rendering, physics, and asset pipelines are years of specialist work no game team wants to rebuild. The same logic scales down: whenever the plumbing dwarfs the product, a framework stops being a convenience and becomes the only sensible path.

JunoApps and games Flutter and React Native let one codebase become both an iPhone and an Android app, which is why so many teams use them. Games have engines like Unity, Unreal, and Godot, which handle graphics and physics while your code says what each object does. Same framework idea as the web, wearing different clothes.

JunoApps and games Cross-platform mobile trades a little native polish for half the work, a deal most teams happily take, while fully native kits remain the answer when platform feel is everything. Game engines are the framework idea at full strength: they run the show sixty times a second and your scripts fill in the behaviour.

JunoApps and games Engines are the extreme that explains the rule: when the plumbing (rendering, physics, asset pipelines) is years of work and dwarfs your actual game, handing over control is the only sensible trade. Keep that ratio in your head, plumbing versus product, and most framework decisions in any field get easier.

The quiet ones: testing and data

Not every framework is about building a product; some organise the work around it. Testing frameworks are the clearest case, and the purest example of the last chapter's definition: pytest (Python), Jest (JavaScript), and JUnit (Java) each find your test functions, run them, and report, with you never writing a program that calls your own tests. You will meet one of these in nearly every professional codebase, usually the one matching the project's language.

Data and machine learning have frameworks too. PyTorch dominates research and increasingly production; TensorFlow is Google's ecosystem with deep production tooling. Both handle the mathematical machinery of training models so that your code describes the model rather than the calculus. If the How AI Works track interested you, these are the tools that world builds with.

Test runners are inversion of control in miniature, and worth a minute of appreciation for that reason. You write functions named test_something, and the framework discovers them by name, runs each one in a fresh setting, catches failures without stopping the rest, and prints the summary. Nobody writes that orchestration per project, which is the framework value proposition at its smallest and least controversial: even developers who avoid product frameworks on principle happily use a test framework.

The ML pair is where the library-versus-framework line gets usefully blurry. Writing a custom training loop in PyTorch feels like using a library: your code steers, and it supplies fast math. Using higher-level layers, trainers, and callbacks flips it back into framework shape, with your code slotting into a loop the tool owns. The boundary depends on which layer of the tool you drive. That framing travels well beyond ML: many big tools are libraries at one altitude and frameworks at another, and knowing which altitude you are flying at tells you who owns control flow today.

JunoTesting and data frameworks Testing frameworks like pytest and Jest find your test functions and run them for you, a small everyday example of a framework calling your code. In machine learning, PyTorch and TensorFlow handle the heavy math of training models. Frameworks organise all kinds of programming work, well beyond building apps.

JunoTesting and data frameworks A test runner is the framework idea at its least controversial: discovery, isolation, and reporting that nobody should rebuild per project. Notice that even framework-skeptical developers use one without complaint; the trade is tiny and the payoff is constant. That asymmetry is a good lens for judging any framework.

JunoTesting and data frameworks PyTorch is a library when you write the training loop and a framework when its trainer runs you, and that is the general lesson: big tools change category depending on which layer you drive. Ask who owns control flow at the altitude you are working at, and the library-or-framework question answers itself.

Where this goes next

That is the map: web on both sides of the wire, mobile, games, testing, and data, all the same idea wearing different uniforms. The remaining question is the practical one, and it has two halves: which one, and whether one at all. Choosing and learning a framework takes both head on, and if the definitions here felt shaky, What is a framework is a short read back.