Laravel
Your quote says Laravel, and the word underneath it is PHP
The short answer
Laravel is a free, open-source framework for building web applications in PHP. It supplies the parts most business software needs already written: routing, database access, background jobs, login, email and testing. It suits ordinary business applications with a database behind them. It stops where an application has to hold connections open.
Somebody quoted a Laravel build, so you have two words to judge rather than one. Laravel is the framework. PHP is the language it's written in, and PHP carries a reputation formed about fifteen years ago. Here's what the tool does, what comes with it, and where it runs out.
A framework sits on a language, and the language here is PHP
PHP is a programming language built for the web in the 1990s and never left it. W3Techs, which surveys what the web runs on, has put PHP on roughly three quarters of the sites where it can identify a server-side language, and it's been in that range for years. WordPress is written in it.
A framework is the layer above the language. On its own, PHP gives you a file that runs when somebody visits a URL and almost no opinion about anything else, so every project invents its own arrangement. Laravel supplies the arrangement. It first appeared in 2011, it's free and open source, and it decides where things live so nobody has to.
The reputation gets one paragraph. The PHP people remember is the PHP of 2010. PHP 7 arrived in 2015 and made it much faster, PHP 8 in 2020 tightened it further, and the type declarations most of the old criticism was about have been in the language for years. A current Laravel application looks nothing like a fifteen-year-old PHP file. None of that tells you whether it fits your build.
What Laravel adds to a language that already worked
Most business software needs the same dozen things before it does anything specific to you. Somewhere to match URLs to code. A way to read and write database records without writing queries by hand. A record of every change to the database structure. Page templates. Logins and permissions. Email. Work that runs in the background instead of making somebody wait. Tasks on a schedule. A test setup.
Laravel arrives with all of it, plus a command-line tool that generates new pieces in the standard shape. That's the offer, and the weeks a team would spend assembling and arguing about those parts are already spent.
The second effect shows up at handover. Because the framework decides the arrangement, a developer who has never seen your project can open it and find things. That isn't true of an application written in plain PHP to one person's habits, and it's the property you most want when a supplier relationship ends.
Laravel
PHP with no framework
- Starting a feature
Laravel: The parts are already written, so you build inside decisions somebody else made.
PHP with no framework: Nothing is assumed, so early weeks go on plumbing before a feature appears.
- Handing it to a new team
Laravel: A stranger finds files where they expect them, once they know the framework.
PHP with no framework: A stranger reads the whole thing first, because the shape is unique to its author.
- Staying current
Laravel: A major version roughly once a year, so upgrades are a recurring piece of work.
PHP with no framework: No framework upgrades to do, and no framework fixing anything on your behalf.
- Hosting
Laravel: Wants somewhere it can install dependencies and run background work.
PHP with no framework: Runs on the cheapest hosting there is, including hosting too limited to grow into.
The company behind it sells the rest of the stack
This is unusual and worth knowing before you read a proposal. The same company maintains a catalogue of products around the framework: an admin panel you point at your database, a queue dashboard, a debugging tool, a billing package, and tools that provision servers and deploy to them.
Some are free and open source. Some are sold as a subscription or a licence, and that pricing moves, so check the vendor's own page rather than an article about it, this one included.
The upside is real: a small team gets a working admin interface and a deployment pipeline in days instead of building either. The cost is concentration. The more of that catalogue a build leans on, the more of your operations sits with one company's roadmap and one company's invoice.
You can host it almost anywhere, and that's a practical advantage
PHP runs on nearly every web host there is, it's on the cheapest shared plans, and people who can keep a PHP server running are not a scarce specialism. Against a stack that needs one particular runtime on one platform, that matters the day a supplier disappoints you and you want to move.
One caveat that proposals skip. Hosting PHP is trivial. Hosting a Laravel application that does background work is a step up: it needs somewhere to install its dependencies, a process that keeps running to work through the queue, and a scheduled trigger. The cheapest shared plans allow none of those.
So ask early whether the application needs background jobs, because that settles what kind of hosting you're buying.
Where it stops
The limit follows from how a request works. Somebody loads a page, PHP starts from nothing, your code runs, the page goes out, and everything it built is discarded. That's why PHP is cheap to host. It's also why anything depending on a connection staying open, like collaborative editing or a dashboard pushing constant updates to thousands of browsers, isn't what this was designed for. Laravel ships first-party answers, including a runtime called Octane that holds the application in memory, but they hand back some of the hosting simplicity you came for.
The second boundary is data work. Statistical modelling, training a model, heavy scientific computation. That world grew up in Python and the tools live there. An application that needs it usually calls out to a separate service, which is a second thing to build.
The third is a convenience that turns on you. Reading database records as though they were ordinary objects is one of Laravel's most pleasant features, and it makes it easy to write code that quietly runs one query per row. Slow Laravel applications are usually slow for that reason, not because of the language.
Last, the people. The talent pool is large, and its range is large with it. PHP's low barrier to entry is why so much of the web runs on it, and why the code you inherit could be anything.
01
A request arrives
One entry file takes every visit. Nothing from the last visitor is still loaded.
02
Laravel routes it
The address is matched to a piece of your code, and checks run before it does.
03
Your code runs
It reads and writes the database, then fills in a page template.
04
The page goes out
The response is sent and everything it built is thrown away.
Worth knowing before you start
Ask which of the first-party products the build assumes, and which of those carry their own bill. A free framework with a paid admin panel and paid deployment tooling is normal, but it belongs in the conversation before the first invoice.
Ask to see the migrations folder. If every change to the database structure is recorded there in version control, anyone can rebuild the database from scratch. If those changes were made by hand, only the person who made them knows the structure.
Ask which PHP version the application targets and whether it's still getting security fixes. PHP publishes an end-of-life date for every version, so it's a checkable fact, not an opinion.
Ask what happens at the next major version. Laravel ships one about once a year and each release's support window ends. Upgrading is ordinary work, but it is work, so it goes in the plan or it goes undone.
Before anyone argues about languages, ask how many database queries the busiest page runs. That number decides performance far more often than the language does, and it's measurable in an afternoon.
Common questions
The language people remember isn't the language in use. PHP 7 in 2015 made it much faster, and PHP 8 in 2020 tightened the type system that most of the old criticism was aimed at. What's fair to say is that PHP is easy to start with, so code written in it spans decades and every level of care. Judge the codebase, not the language.
The framework is, under an open source licence. Hosting isn't, and several of the products sold around it are paid, as a subscription or a licence.
Yes, and it's one of the strongest practical arguments for it. PHP and Laravel have one of the largest developer pools in web work, so three firms can quote the same job and the code can be handed on. The range of skill inside that pool is wide, so test candidates on your own codebase.
For almost every business application, the language isn't what makes a page slow. Database queries are, along with images nobody resized and work done during a request that belongs in the background. Check those three before anyone proposes a rebuild.
Three situations. When the product is mostly live connections held open, like collaborative editing or a constantly updating dashboard. When the core of it is data modelling or machine learning, which grew up elsewhere. And when what you're describing is really a marketing website, where a content platform your team can edit serves you better.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.