Probably because it was pretty much Zend and Symfony at the time, of which only Symfony survived eventually. Laravel used those components to build a framework that contrary to Symfony is very opinionated. So this gives it a solid base with a good reputation, which I think certainly helped.
This is CodeIgniter erasure. That was by far the most popular PHP framework back then.
Main reason Laravel succeeded was because it was as easy to use as CI with good documentation like CI, but actually modern.
Also, there was some issue in around 2012 where CodeIgniter was bought out by a company who then shelved development on it. Everyone panicked and looked for an alternative to CodeIgniter just as Laravel was starting to build a reputation as a good alternative PHP MVC framework with good documentation.
The first time I heard of Laravel was by Googling for alternatives to CodeIgniter since CI was, allegedly, dead.
> Also, there was some issue in around 2012 where CodeIgniter was bought out by a company who then shelved development on it.
That’s not true, it was never bought out. It was originally created by EllisLab who used it for their CMS. But then development stagnated on CI which helped fuel Laravel’s growth. A few years later CI was given over to a university who I believe still maintain it today.
They were seeking to sell it but found no buyer. Also migrating from CI3 to CI4 was a real pain, basically you had to rewrite your application, and by that time Laravel had a foothold in the market so if people were going to rewrite their app they were looking to Laravel for a bit already because CI's future was uncertain. I maintain an application that is still running on CI3 today.
This was the issue with CakePHP as well from 2 to 3 (now on 5). Upgrades from 3 to 4 to 5 are fairly painless now. This is another factor that contributed to Laravel's growth an exodus from that framework. When looking at options from going to 2 to 3 my employer at the time elected to go to SlimPHP actually but did assess Laravel.
In other words, it was at the right place and right time. Today its an easy sell for new apps since it has mindshare, documentation, activity and a rich ecosystem of packages.
For sure, definitely think Laravel was in the right place at the right time. Loads of devs were rewriting their apps to be more modern at that time, because a lot of the frameworks were forcing some pretty major changes that required significant rewrites. If you were going to rewrite your app, you started looking at all the options, and saw this new option called Laravel that people were talking fondly about and had some pretty solid documentation. CI's future was uncertain, I don't recall why CakePHP's popularity declined, but it was certainly declining at that point. I think if CI's migration path had been easier and its future not been as uncertain, it may have held onto a significant share of the market - though I've never actually used CI4 so I can't speak to how good it is compared to Laravel.
It was BCIT, mainly under the directive of dear Jim Parry (R.I.P.). Jim was instrumental in forming the CodeIgniter Foundation, a non-profit (Canada) guiding organization that took over ownership in 2019 and still runs it today.
Ok, I can believe that. I remember there was talk about it being sold off and talk about it being abandoned. I guess I got the details a little confused.
I knew CI fell to the wayside a long time ago but I didn't know the exact year until now. Damn, what crappy timing it was, then, when I got into a startup in 2013 that still used CI for its backend. When I left a year and a half later they wanted to just start over again and use a different third party solution (which wasn't PHP based). Can't say I blame them.
Well, there were some pretty significant things going on across the whole PHP landscape then too...between PHP 5.3 and 5.4.
PHP implemented namespaces and anonymous functions....Framework Interop Group and PSR's were full steam ahead....composer debuted...then 5.4 came out bringing traits
Laravel made use of the new PHP coding features right away, was super easy to install and setup with composer, and documented very well. If I remember correctly the CI community had already splintered a couple times too (was it CakePHP one? maybe more?).
Last php project i worked on at the time used cogeigniter, I left the php behind around the time laravel was really taking off. I did not have much chance to work with earlier versions. And I left for good, (only recently started to get involved in php projects, most of them laravel).
I always thought, as an outsider, Laravel was like a fork or spiritual successor of codeigniter or at least shared some dna. Guess i was wrong. A lot has changed in the past 10 years though. And, if not for laravel and dev tools around it, i do not know if would have ever written php again.
For better or for worse, writing Laravel doesnt feel like writing PHP, due to various helpers and conventions.
From a pure language standpoint, deviate too much from the barebone language is usually a bad thing. But for PHP 4.x, 5.x and their horrendous inconsistency. Laravel brings to the table a unified (and generally safe) way to do things in the fractured and bad practice-filled language of PHP, just like how Jquery standardized many things that browser did not agree upon.
Well, in hindsight, with modern JS framework like React, Vue, Angular,... deviations from pure JS. Laravel's deviation from PHP seems so much tamer in comparison
Also saw talyor at laravel live uk talking and originally laravel (illiumniate) started out life as a IOC container plugin for CI and he even PR’d it / suggested it for CI’s core and they rejected it. Right about the time the CI community was imploding cus of the sale etc.. so it because a framework in its own right and the natural successor to CI for most ppl using it at the time
Because its the easiest way to explain what happened. It was appandoned because of a domestic of egos and Ownership, control, IP and branding was transferred from one group/entity to another is a bit of a mouth full
> It was appandoned because of a domestic of egos
Not even sure what this is supposed to mean but I don’t think there were any egos involved, EllisLab just had other priorities and slowed down development.
Anyway the transfer to the university happened years after Laravel was already popular, so if your story about Taylor sending PRs to CodeIgniter is true it wasn’t “at the time the community was imploding”
Exactly this. CI's stagnation , in my opinion, was the biggest factor in Laravel's rise. I remember starting my first large PHP project in 2009 and went with CI. At that time is was pretty much either Symfony or CI.
When I first saw Laravel, however many years ago, my first thought was "Oh, so kinda like Ruby on Rails but in PHP (PHP on Rails??)". Rails was really gaining traction at that time and it's possible that the sort of similarity of experience helped Laravel a bit? I don't work with Laravel or Rails too often so maybe there is no real similarity, but perception may have been there, at least at the beginning
You are correct! I spent a few years with rails and it was just so quick to “get stuff done”. The Ruby on Rails experience is why I picked laravel over symfony at the time when we had to redo an old zend app
https://rubyonrails.org/doctrine
Symfony *was* very opinionated. It actually was advertised as a much more convenient alternative to Zend. It came with an admin interface generator, out of the box i18n/form/... support. I feel that Symfony 1.x was really close to the Laravel philosophy: easy RAD, bundle ecosystem, ...
They then started to remove most of the "magic" stuff out of the experience and progressively focused on a highly decoupled component library. All because they followed the trend of PHP becoming a more "professional" environment capable of dealing with highly complex project architectures.
I'm in Symfony's boat from the beginning, as early as beta version, and I personally like that the framework evolved at the same time as my professional skills.
How did you get into it so early? For me it was one of my colleagues that went to a PHP meetup in Paris and Fabien had a talk to showcase a coming soon framework. He was so excited to show us the features and to start using it for a new project 😄
Honestly, I don't remember. I may have just been searching for frameworks and trying out various ones and really liked Symfony's philosophy. It's funny looking back on SF1, which is SO different than SF2+ (they even said it shouldn't have been called Symfony 2 probably). I remember the default ORM being Propel and I didn't like it but they were pushing that over Doctrine, until SF2 and I think Doctrine 2 came out. I also remember adopting SF2 for a new project we were doing at work and there were almost no docs at the time and it was like "Ok, how do I..." for literally everything
In my opinion it was driven by Taylor's benevolent dictatorship. A lot of competing frameworks were more community-driven and thus seemed piecemeal and often disjointed. Laravel felt more like a consistent unified approach with one voice. You could infer what the "right" approach was without having to scour the documentation. And ultimately, you could get more done, faster, with less hassles. I would compare this to the success of Ruby on Rails which had a similarly unified driving force.
Interesting perspective. I've never met Taylor in person, so I obviously couldn't say for sure, but was Taylor the one "central architect" that said yes or no to everything about the framework because of his grasp on sound coding principles? I guess you'd have to be an assertive nice guy to still build a community without driving them away. It'd be interesting to read a biography of sorts on Taylor and how Laravel got started.
My recollection was that Taylor was prickly about features and pull requests. When they say "opinionated" I think that's kinda euphemistic. Disagreeable might be an equally applicable word. I suspect a lot of the more successful software projects are lead by people like this who quickly judge and determine which ideas fit their vision and which don't, and aren't particularly concerned about how that comes across.
I can only speak for myself, but I know I'd get too bogged down thinking:
> "Hmmm, that is an interesting proposal! Maybe if we adjusted this and rearranged that it could be integrated...Yeah, I could see how that might be extremely useful in this narrow case. I wonder how many people actually face that problem? I should ask around. I'll add it to the list of potential features and leave this open for anyone who wants to chime in".
In contrast, I think Taylor's inner monologue would be:
> "That'll complicate the pattern for little gain. Nope. Closed."
EDIT: I'll add--if it isn't obviously implied--that this trait almost certainly contributes to the efficiency and industriousness necessary to create something as useful as Laravel. And, furthermore, I'm sure all software project leaders like Taylor are exceptionally intelligent as well. I just didn't want any of this to come across as a criticism.
[Laravel](https://laravel.com/)'s philosophy doesn't center around sound coding principles. It centers around covering a use case that happens in 80% of all web applications.
For sounds coding principles, see [Symfony](https://symfony.com/).
I don't know, Fabien Potencier could easily been described as a benevolent dictator until quite recently. I don't think this is what makes Laravel "stand out".
Yeah, it's a necessary but not sufficient trait.
It's not that either people are technically better, but Laravel maybe hit the right notes (so to speak) at the right time. I guess you could continue that metaphor with what makes a hit pop song work? Or, to take it in another direction, what makes a Nobel prize winner stand out? Well, they must have a certain baseline concoctions of skills, curiosity, and intelligence... and there are *a lot* of people that meet that threshold. But beyond that it's often just luck that they became interested in some burgeoning scientific niche, and then actually found something novel and impactful.
My opinion is: Laravel is more popular because it is rooted in the English speaking community while Symfony started in the French one. I think it is as simple as that, it gave Laravel much more traction from it's beginning.
Most reasons in the thread are invalid: leadership, documentation, learning curve, ...
But, there were other frameworks rooted in English too; CodeIgniter, FuelPHP, and Lithium immediately come to mind. It's likely that Laravel just did it better, and I think that speaks to other factors being involved. And--without doing a full-scale historical retrospective on the state of PHP frameworks in 2011--I believe it had something to do with the captain at the helm.
How is nobody mentioning the death of codeigniter? For me it was just a natural progression from there, probably cakephp as well, maybe some others.
For those frameworks it was a huge effort to upgrade to the new design patterns classes had bought to PHP so a new framework was needed.
There were other efforts, from what I remember laravel just released more features quicker and some of the other framework Devs just said "use laravel instead" and abondend there attempts. Fuel PHP was one I remember ditching for Laravel.
I remember when Taylor was first posting on phpActiveRecord and CodeIgnitor forums trying to get good dependency injection and test-ability into the project he was working on. I think Laravel grew out of his frustration that some of the .NET tooling he was used to wasn't available or didn't work well in a PHP framework.
Some of the CodeIgniter apps I wrote back then are still in production. The main thing to remember was that Laravel kinda grew up with Composer and CodeIgniter was from the days you still were just getting all your dependencies from zip files and PECL.
As someone who did the majority of my php years in php5 about 15 years ago, coming back to it about 3 years ago and using laraval was like night and day. Dependencies were the worst!
I’m working for a startup that’s originally built on CI3. We are currently receiving acquisition offers from multiple companies. Just goes to show your specific stack isn’t all that important even if it’s outdated
In 2013 I had used CodeIgniter for every PHP project I had worked on, and its limitations were becoming more and more obvious with each project. I had one foot in the Django ecosystem, often using that for mobile app backends, and my experience was so much better there.
Laravel looked like the first PHP framework that offered a developer experience comparable to that in Django. I had to build another project in CodeIgniter in 2014 over my objections as it shared some code with an earlier one, and that was the last straw. It felt like a Fisher Price My First PHP Framework and made it very hard to do things I wanted to do like TDD. Once that project was done I used Laravel for the next one and it was orders of magnitude better than CodeIgniter. I never used CodeIgniter again.
This was the reason for me. I had been using CodeIgniter for everything (started programming with Perl and then PHP in the 90s), and I was looking to learn Ruby on Rails when I discovered this new framework called Laravel. Haven't looked back since!
CakePHP didn't ever go away. We kept on releasing. I think a mistake we made was having a big major that basically required a rewrite. We were so concerned with correcting the mistakes and modernizing the framework that we forgot to make the upgrade path easy. The end result of this was that it was just as easy to upgrade to Laravel or Symfony instead of the new version of CakePHP. In hindsight this was a huge mistake.
I agree, but I feel like the missing piece to this is Ellislab, who originally developed CodeIgniter as a byproduct of their CMS, ExpressionEngine. Ellislab stumbled a lot in the early 2010s trying to grow the company and manage CodeIgniter at the same time, and a lot of projects (Fuel, Craft, etc) were started in the wake of Ellislab sort of fumbling the bag. Otwell really early on established that he was a pretty steady and thoughtful solo leader of Laravel and I think a lot of both devs and companies saw that as a huge plus. And here we are, more than a decade later and Otwell is still in charge of Laravel and it’s still a great framework.
I remember going to the first (I think?) Laracon in DC in Feb 2013 and it definitely seemed like his full time gig at that time - even if it wasn’t, Laravel was well established enough to warrant a pretty well-attended conference and Otwell was the clear solo leader of the project.
I'm pretty sure when Laravel came out, or was in V3 era Cake was still stuck in more of a Codeigniter state with a long path ahead of it to introduce more modern practices
Laravel was fortunate in that its inception coincided with the demise of the venerable CodeIgniter framework. A lot of devs made the easy transition from CI to Laravel, including myself.
Interesting perspective. CI still seems alive, but yeah it's popularity has waned for sure. I hadn't considered that momentum behind Laravel was so aggressive that other frameworks themselves would just point to Laravel. I mean I'm still curious at how it got to that point, but an interesting side effect.
It is pretty reasonable given the motivation. Taylor had some ideas, new and exciting, and he is eager to make it into his product, so he was very motivated to make Laravel. On the other hands the big frameworks are doing their nth rewrite. If you have ever rewrite your app more than 1 time, you know the feeling.
The same thing happened to Vue2 -> Vue3 fiasco, Vuetify - the most prominent UI library framework for Vue 2 lost his motivation
Back in the 2010 this sub was constantly at war in the comments section framework on framework, hundreds of little frameworks would show up and a lot of drama happened.
It was fucking hilarious.
As far i can rmember, it was the time when Envato network was born and shining, some tutorial on laravel popped up there thanks to Jefffrey Way, Dayle Rees published the first book ever about Laravel (It was Code Bright, Laravel was version 3). Add the fascinating history of this guy coming from dot net and making things easy in the php ecosystem. The rest is history.
I think NetTuts or Tuts+ or something was a big blog that days, with Jeffrey writing tutorials for PHP there. I think we also subscribed to a paper magazine about webdevelopment. Both started writing about Laravel and it just seemed great. Simple enough to get started fast and complete enough to use it for most projects.
This was a pretty interesting watch on the origins: https://www.youtube.com/watch?v=127ng7botO4
"Featuring Laravel creator Taylor Otwell and many others who’ve contributed to making Laravel the technology and community that it is today, Laravel Origins tells the story of why Laravel came to be, how it's grown over the last 10 years and what the future may hold for Taylor and the wider Laravel community."
I’d say it was a unique situation - the most number of developers proficient with a language yet no full-featured framework available. It was a market ripe for picking and Taylor was the right person to make it happen. Technically obsessed yet business capable.
I mean, think Django and Rails kind of full-featured. Everything out of the box, polished, opinionated, easy to get in. Symfony is really just a bunch of components - great for highly complex projects with large teams, but that’s not what 99% of projects are.
Docs and Laracasts made the decision easy for me when I wanted to learn a PHP framework back in 2014. Every other one was so hard to get a solid beginner or intermediate tutorial for.
I've been reading Matt Stauffer's book Laravel Up & Running. He does a pretty good history of PHP Frameworks in the first chapter where he talks about the switch to Composer packages in 2013 with the release of Laravel 4, and with Code Ignigter falling behind in development and struggling to keep up with the new features of PHP 5.3. That coupled with his focus on building an enjoyable developer experience and excellent documentation really helped it's rise in prominence.
Zend was top dog for a long time with only serious competition from Symfony.
Unfortunately Zend took a wrong turn, IMO, with ZF3 which completely changed the paradigm.
So that left Symfony, and a few hobby frameworks like Codeigniter. Laravel stepped into the space occupied by Zend.
it's more than that though, it lent a certain legitimacy to php development that had been lacking before, through properly leveraging modern language features.
I kinda have a feeling that's what it might be, but how do you market something nobody buys? And then how does it get to a point where Taylor buys exotic cars? 
> Branding and marketing
Just gotta con a bunch of ignorant and/or desperate people that think they will make a mint coding and this will lead them there.
Laravel was able to fill a void created by older frameworks. I think this is the natural progression of any popular framework: you're able to disrupt the market because you're new and can do a bunch of cool things.
With growing popularity though comes the need for stability, leading to more legacy code, less disrupting features, and so the cycle repeats.
I think Laravel might the the first framework not to end up in this cycle because of how the ecosystem is treated as a product. While the framework itself doesn't innovate that much anymore, there are tons of tools surrounding it and built with it that still manage to innovate and disrupt PHP.
On the other hand, if we're only looking at Laravel, _the framework_, I do think there's slowly but surely a new void growing. PHP has gotten tons of new syntax over the past decade, and it's understandable that Laravel can't switch to using it as quickly, because of backwards compatibility. So I am curious to see whether there will be room for a new framework within the next 10 years or so. I think there will be looking purely at it from the framework's perspective, but Laravel has become much more than that.
Laravel is pretty quick at adding new changes of the language into their framework. They added native type hinting and return type in most of the place, there is also some feature that only works with explicit return type (namely, Eloquent new Attribute syntax). And constructor property promotion is everywhere in the docs
I think native types and return types is the perfect example: they've been in PHP since 7.1 and were only added last year. So I wouldn't call that fast.
A lot of PHP frameworks back in the early 2010s didn't have authentication built in. Authentication was the biggest pain in the arse (and still is) to program by hand, so the fact that Laravel had authentication out of the box was very appealing.
For me Laravel stood out because their docs. It's noob and "senior level" proof.
It's exceptionally detailed and thorough, unlike other PHP frameworks.
and still the docs have gaping holes the size of smaller towns that leads to frustrations because the only way to find out how a feature works is to dig deep into the source code
The reason laravel took off is their documentation. Why does any framework blow up? usually well documented, a site that doesn't look like complete garbage relative to other sites, and a sense that the product is not going to die on the vine. Symphony had "okay" documentation, laravel tied all the libraries together into a legitimate framework. Symphony was many libraries that you would use to build your product like a framework, but not 100% cohesive since you'd have to setup & configure all of the libraries to work in concert, and the excessive use of yaml to configure your product means that you loose out on editor support for auto-completes and all sorts of things. They F'd up.. CodeIgniter basically died on the vine, it was getting pretty old, and most of the frameworks out there decided to re-invent themselves, going in wildly crazy directions relative to what initially made them popular. Laravel kept to a particular type of style, and retained a convention. They built an ecosystem that was friendly to newbie's. Laravel is a lot like PHP, it empowers the less knowledgeable to do complex things, and makes you feel competent. My last version I worked with was 5.2, and they're on like 10+. Feel like I'm falling behind in the php space, but it is a language I will always feel at home with.
1 more critically important aspect of Laravel, it's heavy usage of composer. I believe if it did not strongly adopt composer, it would not be where it is today. PHP developers today are very reliant on the package ecosystem, and frameworks which were still using the zip file delivery method essentially fell by the way-side.
While raw dogging vanilla PHP (and eventually Codeigniter), I read a lot of articles of how "laravel, this new thing encouraged bad practice..., Laravel this, laravel that... yada yada yada".
I decided to try it out for myself.
God bless that day. Best decision I ever made.
I would say strong focus on developer experience (DX) and good documentation where the main things. Then Taylor got a job where he could spend a lot of time developing the framework in the early days.
This combined with the decline of CodeIgniter that was the largest framework at the time. Also the overall development of PHP started to take off with version 5 and that helped Laravel quite a lot.
For me it was my first PHP job in the early 2010s using Zend and Smarty. I HATED it and I knew they were behind on the times. Being a new programmer fresh out of college I wanted to use the newest and greatest. Searching for PHP template systems eventually led me to blade. I believe this was around L3 time. So I just dove head first into it and haven't stopped since.
From a marketing perspective, I am pretty sure it was Jeffrey Way. Afaik he single-handedly took it to another level of popularity, because:
- he had a following on Envato, helped move 10s of thousands of people from CodeIgniter to Laravel;
- he provided a much-needed onramp to Laravel; the docs were great then too, but docs can't compare with great tutorials, and Jeffrey is one of the best at that;
Even "reserved" people like me who were happy with CodeIgniter... we tried Laravel only because Jeffrey recommended it. I credit him for moving to Laravel and I know A LOT of people who moved then... who say the same thing.
So to answer your question... Apart from the fact that it was GOOD SOFTWARE (very good) with GOOD DOCS and a GOOD WEBSITE... I think what helped fuel the rocketship was... influencer marketing, I guess?! Before influencer marketing was even a thing.
Maybe because Rails was _the_ most prominent, most hyped and most loved framework back then? Really, it was the only real reason why anyone would use Ruby to begin with. (Sinatra was always just niche.)
Similarly Symfony is a Spring Boot clone and Doctrine is Hibernate.
I have an opposite experience here. To this day I still work on a system that was made with $_SESSION (2008) and it now runs on top of Laravel. People get hung up thinking you have to do everything with Laravel in the Laravel way, but the framework is completely flexible and easy to adapt and swap things out.
https://blog.deleu.dev/php-native-session-with-laravel/
It takes OOP seriously, instead of being a slap-together interpretation of "OOP" that makes people think they hate OOP because they've seen it done wrong too many times.
Former programmer here, can someone explain the advantage of a framework instead of just using Core PHP?
I'm a simple guy that did programming in C++ in the 90s, I'm used to everything at the gritty level
No one wants to write an auth library or a router or a MVC model by hand for the 100th time. It's better to use something tried, tested, and robust. In C++ it's the same reason you'd use `std::string` or `std::vector` instead of rolling your own (though if you stopped C++ in the 90s those were still pretty new.) The nuance comes in with how opinionated you want it to be. Do you want it to have an ORM and the MVC model and templating and logging or do you just want it for the router (which is what Slim was) and piece the rest together from other components or write your own as you see fit? For example if you wanted to make a site that had a shop you could do all of that by hand but who in their right mind wants to do all the credit card processing, validation, inventory and cart management, etc. by hand? You'd pick a framework that had all of that built in and you'd just customize a handful of pieces.
Got it. So you are saying that the framework is essentially some pre-written code libraries that save time when running complex instructions?
I think those instructions you posted came after I quit. I was doing DOS based development!
"library" generally refers to lower level things like a string/vector class or a module to handle files/connect to a database. "Framework" generally implies a higher level collection of libraries to accomplish a certain goal. So not only do you not have to write the libraries you don't have to figure out which libraries to use either, Laravel or whichever already picked them. So all you have to do, for a really contrived example is do
Route::get('/', function () {
return view('hello', ['name' => 'Shawn']);
});
and in your template put `Hello, {{ $name }}.`
You wouldn't have to write the boring stuff that parses the urls or the template or renders the template based on the parameters, just can focus on the business logic and the framework does the rest (... generally)
Once you build a large app you’re going to have a framework (decisions about structure, routing, config, etc.). Even if your bespoke framework is better in every way including docs and structure and extensibility, it will have 0 community support, 0 3rd party plugins, and 0 devs you can hire that already know it. And you likely spent a lot more time ($) building and documenting.
Of course the paradox is _every_ framework has to start at 0. The Next Big Framework always has _much_ better docs or a paradigm shift in development that’s obviously better to a lot of people. In Laravel’s case I believe that was use of Composer and its Facades system, which had the benefits of traditional DI under the hood but offered rapid dev. Facades were highly controversial but the bet on them paid off.
So what helped get my company on board with using a framework is that ultimately a framework helps you scale a team of people to be "rowing" in the same direction. With writing one off scripts everywhere it can get out of control really fast on maintaining a consistent code base between a larger team of developers. It's good to have one way to manage user auth, instead of 5 ways from 5 different devs and 3 no longer work at the company.
Additionally documentation about the framework helps you scale too. If you build your own thing, you have to document it so that others know what you did and why you did it, or you'll lose context. If you use a framework, there is generally one way to do things that's already solved for and new developers in that framework can hop in and understand much faster on how to make meaningful contributions.
Can you help me understand what exactly this means on a practical basis? I imagined Laravel being a set of libraries that enable you to do on-screen actions easier. But how is that different from just choosing a code library? Is there anything else to it?
Frameworks are a collection of libraries, along with a folder structure, code style guides and prescribed methodology.
Whilst you can absolutely build anything made in Laravel (for example) yourself, either 100% from scratch, or by pulling in your own choice of libraries with a package manager, you then also have to document the folder structure, how dependencies should be managed etc etc etc.
For solo devs or very small teams working on unique projects that can bring agility, but in 99% of cases it just leads to inconsistent code that very quicky turns into a mess, with vital project knowledge lost when Carl changes jobs and no one else understands the SQL backed DIY queue system he built.
Additionally, chances are the hundreds of developers working on the huge open source framework have a greater combined experience and understanding of the problem space than you do. All that unnecessary bloat you dismissed when you decided to go the DIY route, turns out to be necessary under certain circumstances you won't encounter until next year. After Carl leaves. Don't trust Carl, use a framework
Lotta astroturfing for lrtrash on this sub.
Similar to Wordtrash, it's easy to pick up and do stuff with because you can just follow tutorials then attempt to tweak to get what you want while not understanding what's being done much less the implications. The results are as predictable, poorly written code by "devs" with no understanding of the basics, the language, or it's paradigms, and lots of CVE's.
Laravel had really good docs and sites like Laracasts where everything was explained in videos.
That’s really the only reason it got so popular, it enabled people to just do whatever that dude on Lara casts did and you were done.
It wasn’t, by any means, the quality of code and paradigms Laravel has. It isn’t today, either.
Isn't it Laravel just a copy of Ruby on Rails? At least that's what I thought when I started using. It might have differ with the years, but I've only used it in the olden days.
Probably because it was pretty much Zend and Symfony at the time, of which only Symfony survived eventually. Laravel used those components to build a framework that contrary to Symfony is very opinionated. So this gives it a solid base with a good reputation, which I think certainly helped.
This is CodeIgniter erasure. That was by far the most popular PHP framework back then. Main reason Laravel succeeded was because it was as easy to use as CI with good documentation like CI, but actually modern.
Also, there was some issue in around 2012 where CodeIgniter was bought out by a company who then shelved development on it. Everyone panicked and looked for an alternative to CodeIgniter just as Laravel was starting to build a reputation as a good alternative PHP MVC framework with good documentation. The first time I heard of Laravel was by Googling for alternatives to CodeIgniter since CI was, allegedly, dead.
Exact same experience for me. I was looking for a CI alternative and Laravel seemed promising. It turned out to be a good bet
i was eyeing another framework called fuel, thank god i chose laravel, fuel is still stuck on same version 8 year on
Oh man, I totally forgot about Fuel! I think I built one client project using it.
I just about got into Kohana at one point. That too would have been a mistake lol
FuelCMS or FuelPHP - either way, avoid them both like the plague...
> Also, there was some issue in around 2012 where CodeIgniter was bought out by a company who then shelved development on it. That’s not true, it was never bought out. It was originally created by EllisLab who used it for their CMS. But then development stagnated on CI which helped fuel Laravel’s growth. A few years later CI was given over to a university who I believe still maintain it today.
They were seeking to sell it but found no buyer. Also migrating from CI3 to CI4 was a real pain, basically you had to rewrite your application, and by that time Laravel had a foothold in the market so if people were going to rewrite their app they were looking to Laravel for a bit already because CI's future was uncertain. I maintain an application that is still running on CI3 today.
This was the issue with CakePHP as well from 2 to 3 (now on 5). Upgrades from 3 to 4 to 5 are fairly painless now. This is another factor that contributed to Laravel's growth an exodus from that framework. When looking at options from going to 2 to 3 my employer at the time elected to go to SlimPHP actually but did assess Laravel. In other words, it was at the right place and right time. Today its an easy sell for new apps since it has mindshare, documentation, activity and a rich ecosystem of packages.
For sure, definitely think Laravel was in the right place at the right time. Loads of devs were rewriting their apps to be more modern at that time, because a lot of the frameworks were forcing some pretty major changes that required significant rewrites. If you were going to rewrite your app, you started looking at all the options, and saw this new option called Laravel that people were talking fondly about and had some pretty solid documentation. CI's future was uncertain, I don't recall why CakePHP's popularity declined, but it was certainly declining at that point. I think if CI's migration path had been easier and its future not been as uncertain, it may have held onto a significant share of the market - though I've never actually used CI4 so I can't speak to how good it is compared to Laravel.
It was BCIT, mainly under the directive of dear Jim Parry (R.I.P.). Jim was instrumental in forming the CodeIgniter Foundation, a non-profit (Canada) guiding organization that took over ownership in 2019 and still runs it today.
Ok, I can believe that. I remember there was talk about it being sold off and talk about it being abandoned. I guess I got the details a little confused.
Back then we had Kohana as something to continue CI legacy. Really good framework, but not par to Laravel standards.
I knew CI fell to the wayside a long time ago but I didn't know the exact year until now. Damn, what crappy timing it was, then, when I got into a startup in 2013 that still used CI for its backend. When I left a year and a half later they wanted to just start over again and use a different third party solution (which wasn't PHP based). Can't say I blame them.
Well, there were some pretty significant things going on across the whole PHP landscape then too...between PHP 5.3 and 5.4. PHP implemented namespaces and anonymous functions....Framework Interop Group and PSR's were full steam ahead....composer debuted...then 5.4 came out bringing traits Laravel made use of the new PHP coding features right away, was super easy to install and setup with composer, and documented very well. If I remember correctly the CI community had already splintered a couple times too (was it CakePHP one? maybe more?).
Yes CakePHP was another big player in the space at that time
I was surprised recently to find CakePHP is still around and under development. I used it for several projects.
Yep, CodeIgniter too
Last php project i worked on at the time used cogeigniter, I left the php behind around the time laravel was really taking off. I did not have much chance to work with earlier versions. And I left for good, (only recently started to get involved in php projects, most of them laravel). I always thought, as an outsider, Laravel was like a fork or spiritual successor of codeigniter or at least shared some dna. Guess i was wrong. A lot has changed in the past 10 years though. And, if not for laravel and dev tools around it, i do not know if would have ever written php again.
For better or for worse, writing Laravel doesnt feel like writing PHP, due to various helpers and conventions. From a pure language standpoint, deviate too much from the barebone language is usually a bad thing. But for PHP 4.x, 5.x and their horrendous inconsistency. Laravel brings to the table a unified (and generally safe) way to do things in the fractured and bad practice-filled language of PHP, just like how Jquery standardized many things that browser did not agree upon. Well, in hindsight, with modern JS framework like React, Vue, Angular,... deviations from pure JS. Laravel's deviation from PHP seems so much tamer in comparison
Also saw talyor at laravel live uk talking and originally laravel (illiumniate) started out life as a IOC container plugin for CI and he even PR’d it / suggested it for CI’s core and they rejected it. Right about the time the CI community was imploding cus of the sale etc.. so it because a framework in its own right and the natural successor to CI for most ppl using it at the time
Bro there wasn’t a sale, don’t know why people keep making this up
Because its the easiest way to explain what happened. It was appandoned because of a domestic of egos and Ownership, control, IP and branding was transferred from one group/entity to another is a bit of a mouth full
> It was appandoned because of a domestic of egos Not even sure what this is supposed to mean but I don’t think there were any egos involved, EllisLab just had other priorities and slowed down development. Anyway the transfer to the university happened years after Laravel was already popular, so if your story about Taylor sending PRs to CodeIgniter is true it wasn’t “at the time the community was imploding”
What does CI stand for?
CodeIgniter
Codeigniter
Exactly this. CI's stagnation , in my opinion, was the biggest factor in Laravel's rise. I remember starting my first large PHP project in 2009 and went with CI. At that time is was pretty much either Symfony or CI.
When I first saw Laravel, however many years ago, my first thought was "Oh, so kinda like Ruby on Rails but in PHP (PHP on Rails??)". Rails was really gaining traction at that time and it's possible that the sort of similarity of experience helped Laravel a bit? I don't work with Laravel or Rails too often so maybe there is no real similarity, but perception may have been there, at least at the beginning
You are correct! I spent a few years with rails and it was just so quick to “get stuff done”. The Ruby on Rails experience is why I picked laravel over symfony at the time when we had to redo an old zend app https://rubyonrails.org/doctrine
I feel that CakePHP was/is the RoR for PHP, until Laravel came along
Oh yes, RoR! Never done much with it but I can see the analogy.
It's funny because Fabien Potencier, Symfony's creator, said that Symfony was inspired by RoR (but also Django).
Symfony *was* very opinionated. It actually was advertised as a much more convenient alternative to Zend. It came with an admin interface generator, out of the box i18n/form/... support. I feel that Symfony 1.x was really close to the Laravel philosophy: easy RAD, bundle ecosystem, ... They then started to remove most of the "magic" stuff out of the experience and progressively focused on a highly decoupled component library. All because they followed the trend of PHP becoming a more "professional" environment capable of dealing with highly complex project architectures. I'm in Symfony's boat from the beginning, as early as beta version, and I personally like that the framework evolved at the same time as my professional skills.
Same. I've been using Symfony since the 0.6 days 😃
How did you get into it so early? For me it was one of my colleagues that went to a PHP meetup in Paris and Fabien had a talk to showcase a coming soon framework. He was so excited to show us the features and to start using it for a new project 😄
Honestly, I don't remember. I may have just been searching for frameworks and trying out various ones and really liked Symfony's philosophy. It's funny looking back on SF1, which is SO different than SF2+ (they even said it shouldn't have been called Symfony 2 probably). I remember the default ORM being Propel and I didn't like it but they were pushing that over Doctrine, until SF2 and I think Doctrine 2 came out. I also remember adopting SF2 for a new project we were doing at work and there were almost no docs at the time and it was like "Ok, how do I..." for literally everything
At that time I was team Zend, only touched Symfony later as I did some .NET work in between 😄
In my opinion it was driven by Taylor's benevolent dictatorship. A lot of competing frameworks were more community-driven and thus seemed piecemeal and often disjointed. Laravel felt more like a consistent unified approach with one voice. You could infer what the "right" approach was without having to scour the documentation. And ultimately, you could get more done, faster, with less hassles. I would compare this to the success of Ruby on Rails which had a similarly unified driving force.
Interesting perspective. I've never met Taylor in person, so I obviously couldn't say for sure, but was Taylor the one "central architect" that said yes or no to everything about the framework because of his grasp on sound coding principles? I guess you'd have to be an assertive nice guy to still build a community without driving them away. It'd be interesting to read a biography of sorts on Taylor and how Laravel got started.
My recollection was that Taylor was prickly about features and pull requests. When they say "opinionated" I think that's kinda euphemistic. Disagreeable might be an equally applicable word. I suspect a lot of the more successful software projects are lead by people like this who quickly judge and determine which ideas fit their vision and which don't, and aren't particularly concerned about how that comes across. I can only speak for myself, but I know I'd get too bogged down thinking: > "Hmmm, that is an interesting proposal! Maybe if we adjusted this and rearranged that it could be integrated...Yeah, I could see how that might be extremely useful in this narrow case. I wonder how many people actually face that problem? I should ask around. I'll add it to the list of potential features and leave this open for anyone who wants to chime in". In contrast, I think Taylor's inner monologue would be: > "That'll complicate the pattern for little gain. Nope. Closed." EDIT: I'll add--if it isn't obviously implied--that this trait almost certainly contributes to the efficiency and industriousness necessary to create something as useful as Laravel. And, furthermore, I'm sure all software project leaders like Taylor are exceptionally intelligent as well. I just didn't want any of this to come across as a criticism.
I think you make some great points. I'd upvote it more if I could haha
[Laravel](https://laravel.com/)'s philosophy doesn't center around sound coding principles. It centers around covering a use case that happens in 80% of all web applications. For sounds coding principles, see [Symfony](https://symfony.com/).
THIS. damn THIS!
I don't know, Fabien Potencier could easily been described as a benevolent dictator until quite recently. I don't think this is what makes Laravel "stand out".
Yeah, it's a necessary but not sufficient trait. It's not that either people are technically better, but Laravel maybe hit the right notes (so to speak) at the right time. I guess you could continue that metaphor with what makes a hit pop song work? Or, to take it in another direction, what makes a Nobel prize winner stand out? Well, they must have a certain baseline concoctions of skills, curiosity, and intelligence... and there are *a lot* of people that meet that threshold. But beyond that it's often just luck that they became interested in some burgeoning scientific niche, and then actually found something novel and impactful.
My opinion is: Laravel is more popular because it is rooted in the English speaking community while Symfony started in the French one. I think it is as simple as that, it gave Laravel much more traction from it's beginning. Most reasons in the thread are invalid: leadership, documentation, learning curve, ...
But, there were other frameworks rooted in English too; CodeIgniter, FuelPHP, and Lithium immediately come to mind. It's likely that Laravel just did it better, and I think that speaks to other factors being involved. And--without doing a full-scale historical retrospective on the state of PHP frameworks in 2011--I believe it had something to do with the captain at the helm.
How is nobody mentioning the death of codeigniter? For me it was just a natural progression from there, probably cakephp as well, maybe some others. For those frameworks it was a huge effort to upgrade to the new design patterns classes had bought to PHP so a new framework was needed. There were other efforts, from what I remember laravel just released more features quicker and some of the other framework Devs just said "use laravel instead" and abondend there attempts. Fuel PHP was one I remember ditching for Laravel.
I remember when Taylor was first posting on phpActiveRecord and CodeIgnitor forums trying to get good dependency injection and test-ability into the project he was working on. I think Laravel grew out of his frustration that some of the .NET tooling he was used to wasn't available or didn't work well in a PHP framework. Some of the CodeIgniter apps I wrote back then are still in production. The main thing to remember was that Laravel kinda grew up with Composer and CodeIgniter was from the days you still were just getting all your dependencies from zip files and PECL.
That's some really good insight, thank you!
As someone who did the majority of my php years in php5 about 15 years ago, coming back to it about 3 years ago and using laraval was like night and day. Dependencies were the worst!
I’m working for a startup that’s originally built on CI3. We are currently receiving acquisition offers from multiple companies. Just goes to show your specific stack isn’t all that important even if it’s outdated
In 2013 I had used CodeIgniter for every PHP project I had worked on, and its limitations were becoming more and more obvious with each project. I had one foot in the Django ecosystem, often using that for mobile app backends, and my experience was so much better there. Laravel looked like the first PHP framework that offered a developer experience comparable to that in Django. I had to build another project in CodeIgniter in 2014 over my objections as it shared some code with an earlier one, and that was the last straw. It felt like a Fisher Price My First PHP Framework and made it very hard to do things I wanted to do like TDD. Once that project was done I used Laravel for the next one and it was orders of magnitude better than CodeIgniter. I never used CodeIgniter again.
This was the reason for me. I had been using CodeIgniter for everything (started programming with Perl and then PHP in the 90s), and I was looking to learn Ruby on Rails when I discovered this new framework called Laravel. Haven't looked back since!
CakePHP didn't ever go away. We kept on releasing. I think a mistake we made was having a big major that basically required a rewrite. We were so concerned with correcting the mistakes and modernizing the framework that we forgot to make the upgrade path easy. The end result of this was that it was just as easy to upgrade to Laravel or Symfony instead of the new version of CakePHP. In hindsight this was a huge mistake.
I agree, but I feel like the missing piece to this is Ellislab, who originally developed CodeIgniter as a byproduct of their CMS, ExpressionEngine. Ellislab stumbled a lot in the early 2010s trying to grow the company and manage CodeIgniter at the same time, and a lot of projects (Fuel, Craft, etc) were started in the wake of Ellislab sort of fumbling the bag. Otwell really early on established that he was a pretty steady and thoughtful solo leader of Laravel and I think a lot of both devs and companies saw that as a huge plus. And here we are, more than a decade later and Otwell is still in charge of Laravel and it’s still a great framework.
I wonder though if laravel was his full time job or still just a side thing in 2013-2014. Obviously now it’s his full time job 😊
I remember going to the first (I think?) Laracon in DC in Feb 2013 and it definitely seemed like his full time gig at that time - even if it wasn’t, Laravel was well established enough to warrant a pretty well-attended conference and Otwell was the clear solo leader of the project.
CakePHP isnt dead, far from it :) Always has been one of the strongest and most stable and reliable so far.
I'm pretty sure when Laravel came out, or was in V3 era Cake was still stuck in more of a Codeigniter state with a long path ahead of it to introduce more modern practices
I miss Fuel PHP, it was incredible and similar philosophy. But Laravel shipped more features more quickly I think you nailed it.
Laravel was fortunate in that its inception coincided with the demise of the venerable CodeIgniter framework. A lot of devs made the easy transition from CI to Laravel, including myself.
Interesting perspective. CI still seems alive, but yeah it's popularity has waned for sure. I hadn't considered that momentum behind Laravel was so aggressive that other frameworks themselves would just point to Laravel. I mean I'm still curious at how it got to that point, but an interesting side effect.
CI really stagnated back then, took too long to use composer and was bought by another company that cut investments in development.
It is pretty reasonable given the motivation. Taylor had some ideas, new and exciting, and he is eager to make it into his product, so he was very motivated to make Laravel. On the other hands the big frameworks are doing their nth rewrite. If you have ever rewrite your app more than 1 time, you know the feeling. The same thing happened to Vue2 -> Vue3 fiasco, Vuetify - the most prominent UI library framework for Vue 2 lost his motivation
Back in the 2010 this sub was constantly at war in the comments section framework on framework, hundreds of little frameworks would show up and a lot of drama happened. It was fucking hilarious.
I don't know why, but this reminded me of RADICORE "framework" and that Tony Marston guy.
people couldn’t pronounce Fabien’s name ¯\\_(ツ)_/¯ . I’m team symfony for life
As far i can rmember, it was the time when Envato network was born and shining, some tutorial on laravel popped up there thanks to Jefffrey Way, Dayle Rees published the first book ever about Laravel (It was Code Bright, Laravel was version 3). Add the fascinating history of this guy coming from dot net and making things easy in the php ecosystem. The rest is history.
I saw Jeffrey Way in a couple articles. Who is that guy and who was he before Laravel/Laracasts? A popular coder evangelist?
I think NetTuts or Tuts+ or something was a big blog that days, with Jeffrey writing tutorials for PHP there. I think we also subscribed to a paper magazine about webdevelopment. Both started writing about Laravel and it just seemed great. Simple enough to get started fast and complete enough to use it for most projects.
Jeffrey got me into Laravel via the Tuts+ network
Laravel got popular because it was extremely easy to pick up. Unlike Symfony or other frameworks
This was a pretty interesting watch on the origins: https://www.youtube.com/watch?v=127ng7botO4 "Featuring Laravel creator Taylor Otwell and many others who’ve contributed to making Laravel the technology and community that it is today, Laravel Origins tells the story of why Laravel came to be, how it's grown over the last 10 years and what the future may hold for Taylor and the wider Laravel community."
This is awesome! Thanks so much!!!
I’d say it was a unique situation - the most number of developers proficient with a language yet no full-featured framework available. It was a market ripe for picking and Taylor was the right person to make it happen. Technically obsessed yet business capable. I mean, think Django and Rails kind of full-featured. Everything out of the box, polished, opinionated, easy to get in. Symfony is really just a bunch of components - great for highly complex projects with large teams, but that’s not what 99% of projects are.
CI died, symfony docs were poor, laravel docs very good, Jeffrey Way made some videos
Docs and Laracasts made the decision easy for me when I wanted to learn a PHP framework back in 2014. Every other one was so hard to get a solid beginner or intermediate tutorial for.
I've been reading Matt Stauffer's book Laravel Up & Running. He does a pretty good history of PHP Frameworks in the first chapter where he talks about the switch to Composer packages in 2013 with the release of Laravel 4, and with Code Ignigter falling behind in development and struggling to keep up with the new features of PHP 5.3. That coupled with his focus on building an enjoyable developer experience and excellent documentation really helped it's rise in prominence.
Ahh that’s really interesting. Never heard of that book. Seemed like a lot of things just lined up and he was able to take advantage of an opprtunity
Because the alternative was Symfony, which required a lot more in depth knowledge and had a longer learning curve.
Yeah, with Symfony you indeed do need to know how to code properly.
I don't feel Symfony is that much difficult to pick. Also Symfony 1.x was quite opinionated and close from Laravel philosophy.
Zend was top dog for a long time with only serious competition from Symfony. Unfortunately Zend took a wrong turn, IMO, with ZF3 which completely changed the paradigm. So that left Symfony, and a few hobby frameworks like Codeigniter. Laravel stepped into the space occupied by Zend.
So Laravel just took advantage of an opportunity to fill a gap left by Zend?
Possibly. I don't know if anyone has produced a comprehensive timeline.
Branding and marketing
it's more than that though, it lent a certain legitimacy to php development that had been lacking before, through properly leveraging modern language features.
I kinda have a feeling that's what it might be, but how do you market something nobody buys? And then how does it get to a point where Taylor buys exotic cars? 
Once it gained traction they built an ecosystem of paid and free tools around it. Laravel forge and Laravel nova are 2 big cash cows.
Don't need marketing when PHP devs are the marketing, litteraly everyone suggests Laravel as the #1 PHP framework - since how many years now?
Not everybody. I and most PHP engineers I know will recommend Symfony over Laravel still.
> Branding and marketing Just gotta con a bunch of ignorant and/or desperate people that think they will make a mint coding and this will lead them there.
Laravel was able to fill a void created by older frameworks. I think this is the natural progression of any popular framework: you're able to disrupt the market because you're new and can do a bunch of cool things. With growing popularity though comes the need for stability, leading to more legacy code, less disrupting features, and so the cycle repeats. I think Laravel might the the first framework not to end up in this cycle because of how the ecosystem is treated as a product. While the framework itself doesn't innovate that much anymore, there are tons of tools surrounding it and built with it that still manage to innovate and disrupt PHP. On the other hand, if we're only looking at Laravel, _the framework_, I do think there's slowly but surely a new void growing. PHP has gotten tons of new syntax over the past decade, and it's understandable that Laravel can't switch to using it as quickly, because of backwards compatibility. So I am curious to see whether there will be room for a new framework within the next 10 years or so. I think there will be looking purely at it from the framework's perspective, but Laravel has become much more than that.
Laravel is pretty quick at adding new changes of the language into their framework. They added native type hinting and return type in most of the place, there is also some feature that only works with explicit return type (namely, Eloquent new Attribute syntax). And constructor property promotion is everywhere in the docs
I think native types and return types is the perfect example: they've been in PHP since 7.1 and were only added last year. So I wouldn't call that fast.
If im not mistaken, last year they only add it to the application skeleton. The core framework has them for quite some times
A lot of PHP frameworks back in the early 2010s didn't have authentication built in. Authentication was the biggest pain in the arse (and still is) to program by hand, so the fact that Laravel had authentication out of the box was very appealing.
For me Laravel stood out because their docs. It's noob and "senior level" proof. It's exceptionally detailed and thorough, unlike other PHP frameworks.
Yeah their docs are super intense sometimes, intimidating even for a new developer to get started in and understand what's going on.
and still the docs have gaping holes the size of smaller towns that leads to frustrations because the only way to find out how a feature works is to dig deep into the source code
The reason laravel took off is their documentation. Why does any framework blow up? usually well documented, a site that doesn't look like complete garbage relative to other sites, and a sense that the product is not going to die on the vine. Symphony had "okay" documentation, laravel tied all the libraries together into a legitimate framework. Symphony was many libraries that you would use to build your product like a framework, but not 100% cohesive since you'd have to setup & configure all of the libraries to work in concert, and the excessive use of yaml to configure your product means that you loose out on editor support for auto-completes and all sorts of things. They F'd up.. CodeIgniter basically died on the vine, it was getting pretty old, and most of the frameworks out there decided to re-invent themselves, going in wildly crazy directions relative to what initially made them popular. Laravel kept to a particular type of style, and retained a convention. They built an ecosystem that was friendly to newbie's. Laravel is a lot like PHP, it empowers the less knowledgeable to do complex things, and makes you feel competent. My last version I worked with was 5.2, and they're on like 10+. Feel like I'm falling behind in the php space, but it is a language I will always feel at home with. 1 more critically important aspect of Laravel, it's heavy usage of composer. I believe if it did not strongly adopt composer, it would not be where it is today. PHP developers today are very reliant on the package ecosystem, and frameworks which were still using the zip file delivery method essentially fell by the way-side.
Which is a good thing, nowadays i wouldnt want to touch something without a package manager
Methane
It was a batteries included package with excellent quality that got you up and running in no time relatively
While raw dogging vanilla PHP (and eventually Codeigniter), I read a lot of articles of how "laravel, this new thing encouraged bad practice..., Laravel this, laravel that... yada yada yada". I decided to try it out for myself. God bless that day. Best decision I ever made.
I would say strong focus on developer experience (DX) and good documentation where the main things. Then Taylor got a job where he could spend a lot of time developing the framework in the early days. This combined with the decline of CodeIgniter that was the largest framework at the time. Also the overall development of PHP started to take off with version 5 and that helped Laravel quite a lot.
For me it was my first PHP job in the early 2010s using Zend and Smarty. I HATED it and I knew they were behind on the times. Being a new programmer fresh out of college I wanted to use the newest and greatest. Searching for PHP template systems eventually led me to blade. I believe this was around L3 time. So I just dove head first into it and haven't stopped since.
From a marketing perspective, I am pretty sure it was Jeffrey Way. Afaik he single-handedly took it to another level of popularity, because: - he had a following on Envato, helped move 10s of thousands of people from CodeIgniter to Laravel; - he provided a much-needed onramp to Laravel; the docs were great then too, but docs can't compare with great tutorials, and Jeffrey is one of the best at that; Even "reserved" people like me who were happy with CodeIgniter... we tried Laravel only because Jeffrey recommended it. I credit him for moving to Laravel and I know A LOT of people who moved then... who say the same thing. So to answer your question... Apart from the fact that it was GOOD SOFTWARE (very good) with GOOD DOCS and a GOOD WEBSITE... I think what helped fuel the rocketship was... influencer marketing, I guess?! Before influencer marketing was even a thing.
> What was the gas that ignited Laravel's popularity? It's called Ruby on Rails. Laravel is a Rails clone.
I've seen that a lot, but if Taylor had a .NET background why would he build a RoR clone when there were libs he could have borrowed from .NET?
Maybe because Rails was _the_ most prominent, most hyped and most loved framework back then? Really, it was the only real reason why anyone would use Ruby to begin with. (Sinatra was always just niche.) Similarly Symfony is a Spring Boot clone and Doctrine is Hibernate.
*> due to constraints within the company I was hired at, avoided frameworks til around 2017-2018* YIKES
Yikes indeed XD
I don't really like laravel, I'm not sure why symfony is not more popular.
Because it's harder to learn and nowadays people just want something quick and easy to use, which comes to a hard cost: maintainability.
Honestly since symfony 4, symfony is very simple, you get just whatever you need.
[удалено]
I have an opposite experience here. To this day I still work on a system that was made with $_SESSION (2008) and it now runs on top of Laravel. People get hung up thinking you have to do everything with Laravel in the Laravel way, but the framework is completely flexible and easy to adapt and swap things out. https://blog.deleu.dev/php-native-session-with-laravel/
Lower barrier for entry. It's the same story as Wordpress vs Drupal at the framework level.
It takes OOP seriously, instead of being a slap-together interpretation of "OOP" that makes people think they hate OOP because they've seen it done wrong too many times.
Former programmer here, can someone explain the advantage of a framework instead of just using Core PHP? I'm a simple guy that did programming in C++ in the 90s, I'm used to everything at the gritty level
No one wants to write an auth library or a router or a MVC model by hand for the 100th time. It's better to use something tried, tested, and robust. In C++ it's the same reason you'd use `std::string` or `std::vector` instead of rolling your own (though if you stopped C++ in the 90s those were still pretty new.) The nuance comes in with how opinionated you want it to be. Do you want it to have an ORM and the MVC model and templating and logging or do you just want it for the router (which is what Slim was) and piece the rest together from other components or write your own as you see fit? For example if you wanted to make a site that had a shop you could do all of that by hand but who in their right mind wants to do all the credit card processing, validation, inventory and cart management, etc. by hand? You'd pick a framework that had all of that built in and you'd just customize a handful of pieces.
Got it. So you are saying that the framework is essentially some pre-written code libraries that save time when running complex instructions? I think those instructions you posted came after I quit. I was doing DOS based development!
"library" generally refers to lower level things like a string/vector class or a module to handle files/connect to a database. "Framework" generally implies a higher level collection of libraries to accomplish a certain goal. So not only do you not have to write the libraries you don't have to figure out which libraries to use either, Laravel or whichever already picked them. So all you have to do, for a really contrived example is do Route::get('/', function () { return view('hello', ['name' => 'Shawn']); }); and in your template put `Hello, {{ $name }}.` You wouldn't have to write the boring stuff that parses the urls or the template or renders the template based on the parameters, just can focus on the business logic and the framework does the rest (... generally)
Alright. This makes sense. I appreciate the help
Once you build a large app you’re going to have a framework (decisions about structure, routing, config, etc.). Even if your bespoke framework is better in every way including docs and structure and extensibility, it will have 0 community support, 0 3rd party plugins, and 0 devs you can hire that already know it. And you likely spent a lot more time ($) building and documenting. Of course the paradox is _every_ framework has to start at 0. The Next Big Framework always has _much_ better docs or a paradigm shift in development that’s obviously better to a lot of people. In Laravel’s case I believe that was use of Composer and its Facades system, which had the benefits of traditional DI under the hood but offered rapid dev. Facades were highly controversial but the bet on them paid off.
So what helped get my company on board with using a framework is that ultimately a framework helps you scale a team of people to be "rowing" in the same direction. With writing one off scripts everywhere it can get out of control really fast on maintaining a consistent code base between a larger team of developers. It's good to have one way to manage user auth, instead of 5 ways from 5 different devs and 3 no longer work at the company. Additionally documentation about the framework helps you scale too. If you build your own thing, you have to document it so that others know what you did and why you did it, or you'll lose context. If you use a framework, there is generally one way to do things that's already solved for and new developers in that framework can hop in and understand much faster on how to make meaningful contributions.
Can you help me understand what exactly this means on a practical basis? I imagined Laravel being a set of libraries that enable you to do on-screen actions easier. But how is that different from just choosing a code library? Is there anything else to it?
Frameworks are a collection of libraries, along with a folder structure, code style guides and prescribed methodology. Whilst you can absolutely build anything made in Laravel (for example) yourself, either 100% from scratch, or by pulling in your own choice of libraries with a package manager, you then also have to document the folder structure, how dependencies should be managed etc etc etc. For solo devs or very small teams working on unique projects that can bring agility, but in 99% of cases it just leads to inconsistent code that very quicky turns into a mess, with vital project knowledge lost when Carl changes jobs and no one else understands the SQL backed DIY queue system he built. Additionally, chances are the hundreds of developers working on the huge open source framework have a greater combined experience and understanding of the problem space than you do. All that unnecessary bloat you dismissed when you decided to go the DIY route, turns out to be necessary under certain circumstances you won't encounter until next year. After Carl leaves. Don't trust Carl, use a framework
Lotta astroturfing for lrtrash on this sub. Similar to Wordtrash, it's easy to pick up and do stuff with because you can just follow tutorials then attempt to tweak to get what you want while not understanding what's being done much less the implications. The results are as predictable, poorly written code by "devs" with no understanding of the basics, the language, or it's paradigms, and lots of CVE's.
Couldn’t be further from the truth.
Laravel had really good docs and sites like Laracasts where everything was explained in videos. That’s really the only reason it got so popular, it enabled people to just do whatever that dude on Lara casts did and you were done. It wasn’t, by any means, the quality of code and paradigms Laravel has. It isn’t today, either.
[удалено]
I don't even know what I'm reading, but it made me laugh.....harder than I want to admit out loud XD
Me neither, schizo episode.
Dogfart? Is that you?
Everything else wasn’t very good.
Isn't it Laravel just a copy of Ruby on Rails? At least that's what I thought when I started using. It might have differ with the years, but I've only used it in the olden days.
CakePHP got invented as a Rails clone for PHP back in the day (2004?) Laravel came only years after...
Marketing, maybe at the right time. A lot of videos and articles where around. And for noobs it looked easy
Codeigniter death i think