What Laravel Is and Why It Beats Plain PHP

Lessons 1 through 5 gave you plain PHP: syntax, arrays, OOP, and Composer, the tool that installs and autoloads packages. From here on, the course is Laravel. This lesson explains what Laravel actually is, why it exists, and specifically what it buys you over writing the same application in plain PHP.

What A Framework Gives You

Laravel is a web application framework, which is a precise term worth unpacking. A framework is not a library you call when you need it; it is a structure that calls your code. With a library like Guzzle (an HTTP client package), you decide when to call it. With Laravel, Laravel decides the overall shape of the request-handling process, and your code fills in specific slots within that structure: this route maps to this controller, this model represents this database table, this middleware runs before this group of routes. You are writing code that lives inside Laravel's architecture, not code that happens to use Laravel.

The Problem Laravel Solves

Here is the concrete problem Laravel solves. Imagine building a small web app in plain PHP, the way the web actually worked for its first fifteen years: every URL maps to an actual .php file on disk. A request to /users/5/edit would need a file at that exact path, or some manual routing logic you write yourself, from scratch, in every project. Database access means writing raw SQL queries and manually handling the connection, escaping, and error cases, every single time, in every file that touches the database. Form submissions need manual validation code, repeated per form. User login needs session handling, password hashing, and "remember me" cookies, all written by hand, and all extremely easy to get subtly wrong in ways that create real security holes.

Laravel provides a maintained, tested, consistent answer to every one of those problems, so you solve them once (by learning Laravel's way of doing it) instead of solving them badly, slightly differently, in every project you ever build. That's the trade: you give up some flexibility and accept Laravel's conventions, and in exchange you get routing, database access (Eloquent, lesson 9), validation (lesson 12), authentication (lesson 14), background job processing (lesson 15), and dozens of other solved problems, all built by a team that has spent over a decade hardening them against real-world edge cases and security issues you have likely never even thought of.

A Minimal Request Response Cycle

A minimal Laravel request-response cycle looks like this. A route file declares that a URL pattern maps to a piece of code:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\HeroController;

Route::get('/heroes/{name}', [HeroController::class, 'show']);

A controller holds the actual logic for that route:

namespace App\Http\Controllers;

class HeroController extends Controller
{
    public function show(string $name)
    {
        return "You asked about: " . $name;
    }
}

Visit /heroes/iron-man and Laravel matches the route, extracts iron-man as the {name} parameter, instantiates HeroController, calls its show method with that value, and sends whatever the method returns back as the HTTP response. Compare that to plain PHP, where you would need to either create a literal file at that path (impossible, since the URL is dynamic) or write your own router from scratch that inspects the request URL and dispatches to the right code. Laravel's router, tested across millions of production applications, does this reliably so you never have to write or debug your own.

Security And Trade-offs

This matters even more once you consider security specifically. Writing raw SQL by concatenating user input directly into a query string is the single most common way real applications get hacked, through SQL injection. Eloquent (lesson 9) uses parameter binding underneath, by default, meaning user input is never concatenated directly into SQL text; it is passed separately to the database driver, which handles it safely. You do not have to remember to do this correctly every single time, because the path of least resistance in Laravel, the way the framework naturally wants you to write code, is already the safe way. In plain PHP, the safe way requires deliberate, disciplined extra effort on every single query, and it is exactly the kind of thing that gets skipped under a deadline.

It is worth being honest about the trade-off's other side, too, since this course won't pretend Laravel is free. Laravel has real overhead: a request goes through more layers (routing, middleware, service container resolution, and more) before your actual logic runs, compared to a bare PHP script. For a tiny single-page script that genuinely never needs a router, a database layer, or authentication, plain PHP can legitimately be the better choice, faster to write and faster to run. Laravel earns its overhead specifically on applications with real complexity: multiple pages, a database, forms, users, background work, exactly the kind of application most businesses actually need, which is why Laravel dominates professional PHP development today despite that overhead.

One structural detail worth knowing immediately, because every single lesson from here depends on it: Laravel organizes code into predictable folders. Routes live in the routes/ directory, controllers in app/Http/Controllers/, database models in app/Models/, views in resources/views/, and database migrations in database/migrations/. This is not arbitrary; it is Laravel's "convention over configuration" philosophy. Rather than configuring, by hand, where every piece of code lives (as some frameworks require), Laravel assumes a standard layout and just works once you follow it, which is also exactly why an unfamiliar Laravel codebase is far easier to navigate on day one than an unfamiliar plain-PHP codebase with its own ad hoc structure.

Try it yourself: if you have a local Laravel install (the same one powering this course's own codebase, using XAMPP as noted in this site's project notes), run php artisan route:list from the project root and look at how every URL the application responds to maps to a specific controller method, all declared explicitly in route files rather than inferred from a folder of loose PHP files.