Laravel 5 released(laravel-news.com)
laravel-news.com
Laravel 5 released
https://laravel-news.com/2015/02/laravel-5-released/
21 comments
Thanks. I always find the release notes far more informative than a commit.
Thanks, we changed the URL from https://github.com/laravel/laravel/releases.
After using Laravel 4 for an internal company tool I have a hard time recommending it (sadly, I was hopeful). I found the docs to be uneven in quality/scope, some key features (mostly around the ORM) missing and the 'feel' to be slightly off.
It's hard to quantify, but I have used CakePHP, Yii, Rails (0.9 through 4), Django and plenty of home-grown 'frameworks'. From all those the most cohesive and understandable to me was Rails followed by Yii (surprisingly).
Maybe it's the docs or structure, but Rails and Yii have a strong opinion and it seems their developers have both CS smarts and industry experience, which shows in the structure and code.
I'm sure in time Laravel will mature and improve. Currently it just feels like there's a lot more hype than it merits.
It's hard to quantify, but I have used CakePHP, Yii, Rails (0.9 through 4), Django and plenty of home-grown 'frameworks'. From all those the most cohesive and understandable to me was Rails followed by Yii (surprisingly).
Maybe it's the docs or structure, but Rails and Yii have a strong opinion and it seems their developers have both CS smarts and industry experience, which shows in the structure and code.
I'm sure in time Laravel will mature and improve. Currently it just feels like there's a lot more hype than it merits.
Maybe it's a matter of taste?
I have worked with Symfony2, Zend Framework, Yii, Kohana and Laravel and find Laravel the most intuitive to work with.
I like that you can start using it for very rapid prototyping and refactor into more complicated structures as the application grows.
I have worked with Symfony2, Zend Framework, Yii, Kohana and Laravel and find Laravel the most intuitive to work with.
I like that you can start using it for very rapid prototyping and refactor into more complicated structures as the application grows.
Totally agree. I think that Symfony2 is a pain in the ass.
Laravel lets you have something working really fast. Then you can improve the code later on.
Agreed, Symfony2 is great, but I see it being used more in an open source project capacity. Working on it at a company where time frames are key, rapid development is huge. Plus, laravel is far more intuitive and I can ramp up new team members much faster.
That's because Laravel is a website framework and Symfony2 is an application framework.
I concur. Symfony 2 is incredibly powerful, but at the same time incredibly messy to work with.
I don't see how Laravel lends itself to "rapid prototyping" than any other framework. Sure, Symfony2 or ZF2 has best practices on how to do things, but at the end of the day it's just MVC - you can skip any best practice you want to just get something done. This isn't unique to Laravel.
I think it tends to do with the marketing. Lots of hand-holding walk-through tutorials and help people get "rapid" prototyping with laravel, moreso than the actual code itself. And, to an extent, when you present yourself as being good for "rapid dev", that's what people will associate with the framework. (by comparison, zf has never promoted itself as allowing for rapid development, AFAIK).
> by comparison, zf has never promoted itself as allowing for rapid development, AFAIK
Well, no, because everyone would laugh at them.
Well, no, because everyone would laugh at them.
It's less verbose than Symfony2 and, being pretty opinionated, requires much less configuration for new applications.
Facades, macros and route closures supports rapid prototyping and are pretty easy to replace as needed. Included libraries like Flysystem, Cashier, Elixir and the new cron wrapper also eases rapid development.
There are also a few tools around it, like Homestead and Forge, that makes it easy to set something up quickly.
It's not like you can't do rapid prototyping with other frameworks, but Laravel, to me, is the first PHP framework that actively supports it while providing a flexible enough structure to grow in.
Facades, macros and route closures supports rapid prototyping and are pretty easy to replace as needed. Included libraries like Flysystem, Cashier, Elixir and the new cron wrapper also eases rapid development.
There are also a few tools around it, like Homestead and Forge, that makes it easy to set something up quickly.
It's not like you can't do rapid prototyping with other frameworks, but Laravel, to me, is the first PHP framework that actively supports it while providing a flexible enough structure to grow in.
It strikes me as a project that should've been an internal framework, not a public one. Too many things break and change constantly. Rapid release cycles is a good thing for smaller libraries with specific tasks, but I expect a framework to remain largely unchanged (except bugfixes, of course) for longer periods of time.
Unless Taylor gives away control of the project, I don't see it happening. It'll keep being a popular framework, though.
Unless Taylor gives away control of the project, I don't see it happening. It'll keep being a popular framework, though.
As a Core developer of CakePHP, I'll tell you that the community at large loves major releases more than they like stability. Something about using the newest toy really gets a lot of people going. We actually have had quite a few developers tell us our framework is dead, despite ongoing development on a new major release and monthly minor/patch releases for the current stable line for 3+ years.
I can't comment on Laravel though, as my only experience with it was a negative one. I had a rejected bugfix for which Taylor decided to ignore the PHP documentation I linked to verifying the issue, and several other developers saying they have experienced the issue/would like to see my PR merged in.
I think it'll stay a popular PHP framework until the next popular framework comes around (CI => FuelPHP => Laravel).
I can't comment on Laravel though, as my only experience with it was a negative one. I had a rejected bugfix for which Taylor decided to ignore the PHP documentation I linked to verifying the issue, and several other developers saying they have experienced the issue/would like to see my PR merged in.
I think it'll stay a popular PHP framework until the next popular framework comes around (CI => FuelPHP => Laravel).
The vocal community is likely in the realm of 5-10% of the actual active userbase. You should cater to most of your users, not just the bored ones.
Your framework is dead because you've continued to prove that you don't understand what PHP 5.3+ is and means. I say that as someone who has been forced to use CakePHP for ~10 years. You've always lagged far behind in the concepts that other frameworks have down pat.
Your framework is dead because you've continued to prove that you don't understand what PHP 5.3+ is and means. I say that as someone who has been forced to use CakePHP for ~10 years. You've always lagged far behind in the concepts that other frameworks have down pat.
5.4+ Version, which is currently being actively developed (RC2 around the corner): https://github.com/cakephp/cakephp/tree/3.0
And a general list of changes between the current stable and our upcoming release: https://github.com/cakephp/cakephp/wiki/3.0-Roadmap
And a general list of changes between the current stable and our upcoming release: https://github.com/cakephp/cakephp/wiki/3.0-Roadmap
What could be those ORM features that you're missing? I've been working with Laravel 4 since before it had documentation when I had to go through all of the code to understand how it works and I know that besides what is described in documentation - there's a number of features that are available, but not listed.
Joining and querying efficiently on relations is probably the most obvious omission.
Do you mean these two things?
http://laravel.com/docs/5.0/eloquent#relationships
http://laravel.com/docs/5.0/eloquent#querying-relations
> EDIT and this for making them effective
http://laravel.com/docs/5.0/eloquent#eager-loading
http://laravel.com/docs/5.0/eloquent#relationships
http://laravel.com/docs/5.0/eloquent#querying-relations
> EDIT and this for making them effective
http://laravel.com/docs/5.0/eloquent#eager-loading
Never had any problems with Eloquent relations and querying on them. I find them very powerful.
Yes, they aren't done in a single query format - which should be a problem since it may be faster just to do two simple queries then one complex.
Besides that relations could be eager loaded for when you have number of items in first query and want to load relations to all of them. With eager loading you won't have problems with N + 1 queries.
Yes, they aren't done in a single query format - which should be a problem since it may be faster just to do two simple queries then one complex.
Besides that relations could be eager loaded for when you have number of items in first query and want to load relations to all of them. With eager loading you won't have problems with N + 1 queries.
I am going to have to completely disagree with you. I have been using it for several years now and I have nothing but good things to say about it.
The ORM is basic yes, but that's the purpose of it. If you want a bigger one do what you do with Symfony and use Doctrine or something more robust.
The ORM is basic yes, but that's the purpose of it. If you want a bigger one do what you do with Symfony and use Doctrine or something more robust.
I just tried to two days ago and did a complete project with it. Auth, CRUD, file management, etc. It's an instant love for me. Docs is mostly ok, Google provides instant answers. I'm happy to ditch CodeIgniter for this.
I spent two days just trying to get the thing installed and gave up. Kept hitting a snag somewhere. Such a bummer because I was excited about using it.
CodeIgniter... isn't exactly a high bar to beat.
In my experience people who love Laravel are typically CI or WP refugees. I am yet to encounter a single person who has switched from Symfony2 or ZF2 to Laravel and liked what they saw.
I switched from mostly Symfony2 to mostly Laravel and like it.
I doubt there are a lot of people switching from WP though, since WP and Laravel solve two different types of problems.
I doubt there are a lot of people switching from WP though, since WP and Laravel solve two different types of problems.
If you're new to Laravel or want to learn more check out http://Laracasts.com. Jeff Way does a great job. (Just a fan/current subscriber).
I agree, awesome resource which is rapidly levelling up many modern php developers.
Jeffrey Way is the best. Back at Tuts+ I'd only watch his courses—no one else was as good of a teacher as him. Laracasts is even better.
His 30 days to learn jQuery was a critical growing tool for me - if you're at all interested in low-level front end JS, definitely check it out. Its free.
That's actually the first course I took by him. I took a few of his other HTML/CSS courses and I am doing PHP Fundamentals (to get into Laravel later) because of the "jQuery and PHP" parts of the 30 days course. All good stuff.
Agreed. Definitely worth paying for.
Laravel represents what modern PHP can do and be. Clean, organised, fully object-oriented. Kudos to what Taylor Otwell has created both from a marketing perspective and technical standpoint.
I was a little scared by the heavy use of static method calls in Laravel 4. L5 has made the statics easier to ignore if that is not your thing.
But after understanding the Facade pattern that is widely used by the framework, I've concluded that the use of the static method calls is not an antipattern at all.
But after understanding the Facade pattern that is widely used by the framework, I've concluded that the use of the static method calls is not an antipattern at all.
It really is less of an antipattern in PHP than other languages. With every request being its own process you don't have to worry about singletons as much, and as long as it's easy to swap with mocks/fakes/whatever it's all good.
>Laravel represents what modern PHP can do and be. Clean, organised, fully object-oriented.
In a JavaEE circa 2003-5 way. Not exactly what modern programming is about...
In a JavaEE circa 2003-5 way. Not exactly what modern programming is about...
We got it the first time https://news.ycombinator.com/item?id=8997114
Different subthread, answering to another person.
Besides, it's not like https://news.ycombinator.com/item?id=8656965 is some gem of a comment that hasn't been written 200 other times on HN for example.
Besides, it's not like https://news.ycombinator.com/item?id=8656965 is some gem of a comment that hasn't been written 200 other times on HN for example.
Laravel is the shame of modern PHP - ZERO OOP, almost all methods are static, no DI, array-oriented programming everywhere, a lot of hardcoded "new" (so you can't mock and test).
Having watched Laravel 5 throughout development, I'm personally unhappy with the fact that most of the nice features of Laravel have been removed.
For example, the default version of Laravel 4.x shipped with the "Whoops" PHP stack trace view, which is far superior to the L5-default Symfony stack trace view. Other features were removed too, including the HTML library. Blade tags were changed for no reason.
Overall, it feels like instead of adding requested features, Taylor decided to redesign the architecture for no reason.
For example, the default version of Laravel 4.x shipped with the "Whoops" PHP stack trace view, which is far superior to the L5-default Symfony stack trace view. Other features were removed too, including the HTML library. Blade tags were changed for no reason.
Overall, it feels like instead of adding requested features, Taylor decided to redesign the architecture for no reason.
The single maintainer just didn't want to maintain them, which goes to show how Laravel really just is his personal project that got really popular, not a community-driven effort.
IMO, that fact has helped make Laravel successful. Sometimes, software projects benefit from a benevolent dictator rather than design-by-committee.
FUD.
The "architecture" change is the bootstrap repository, which has a new folder structure. I know, scary stuff! Folders!
The "architecture" has some enhancements to middleware and fleshing out events/commands to a "command bus". Basically, you get more sugar on top of the (mostly) same architecture.
Whoops caused a lot of headaches behind the scenes, and did stupid things like convert ALL http error responses to 500, even on a 404 error (which showed up in Whoops, as HTTP errors are converted to exceptions within Symfony's HTTP stack).
Blade tags have one new tag, and the old ones still works.
This point might be the subjective one - HTML library. HTML libraries create an enormous amount of support for people's edge cases and generally are better pushed out as a third-party add on to suit your needs. The upgrade guide explains how you can add them back in if you want. https://github.com/illuminate/html
The "architecture" change is the bootstrap repository, which has a new folder structure. I know, scary stuff! Folders!
The "architecture" has some enhancements to middleware and fleshing out events/commands to a "command bus". Basically, you get more sugar on top of the (mostly) same architecture.
Whoops caused a lot of headaches behind the scenes, and did stupid things like convert ALL http error responses to 500, even on a 404 error (which showed up in Whoops, as HTTP errors are converted to exceptions within Symfony's HTTP stack).
Blade tags have one new tag, and the old ones still works.
This point might be the subjective one - HTML library. HTML libraries create an enormous amount of support for people's edge cases and generally are better pushed out as a third-party add on to suit your needs. The upgrade guide explains how you can add them back in if you want. https://github.com/illuminate/html
That's a shitty explanation for dropping Whoops. The first time I remember the discussion of it being dropped got brought up was because of a bug in the framework relating to the assets, where Taylor didn't hesitate to blame Whoops and deleted comments on Github pointing out that the problem was actually in his own code.
It would've been super easy to add some code that sets the HTTP code for Whoops's response if that was the problem - but the fact is you should demand your framework users define their own 404 handlers.
The old Blade tags now escape all HTML, that hardly counts as working.
It would've been super easy to add some code that sets the HTTP code for Whoops's response if that was the problem - but the fact is you should demand your framework users define their own 404 handlers.
The old Blade tags now escape all HTML, that hardly counts as working.
You can easily change the config to make the Blade tags work as they previously did. I'm unhappy about this change as well though. It's very reminiscent of some design decisions PHP has taken:
1. Create feature X.
2. Users don't understand feature X, and use it when they should be using feature Y (for safety.)
3. Update the API so that feature X does what feature Y did, and create feature Z that now does what feature X did.
4. Old users using feature X incorrectly are now protected, while users who correctly used feature X must now convert to feature Z.
1. Create feature X.
2. Users don't understand feature X, and use it when they should be using feature Y (for safety.)
3. Update the API so that feature X does what feature Y did, and create feature Z that now does what feature X did.
4. Old users using feature X incorrectly are now protected, while users who correctly used feature X must now convert to feature Z.
Not being familiar with Laravell, having a look at[1], I see what you mean:
> In Laravel 4 Blade included the following two styles: {{ and {{{. > The double curly bracket was a raw echo and the triple curly bracket escaped. > > Now both the double and triple curly brackets escape the variable and a new {!! $var !!} is for raw.
I'd argue that having unescaped output be shorter/easier than escaped output was probably a design error in earlier versions -- but I'm not sure I like the "fix"... If it was a green-field design, I must admit I like the "danger!"-feel that unescaped output has in L5 though.
[1] https://laravel-news.com/2015/01/laravel-5/
> In Laravel 4 Blade included the following two styles: {{ and {{{. > The double curly bracket was a raw echo and the triple curly bracket escaped. > > Now both the double and triple curly brackets escape the variable and a new {!! $var !!} is for raw.
I'd argue that having unescaped output be shorter/easier than escaped output was probably a design error in earlier versions -- but I'm not sure I like the "fix"... If it was a green-field design, I must admit I like the "danger!"-feel that unescaped output has in L5 though.
[1] https://laravel-news.com/2015/01/laravel-5/
https://plus.google.com/events/ctgh4ss551t10kg4fktqood9t3o, about 12:30 in on why removed Whoops.
HTML library is now optional, more info on that here also here you will find why the blade tags have changed: http://laravel.com/docs/5.0/upgrade#upgrade-5.0
Whoops stack trace: https://laracasts.com/discuss/channels/general-discussion/wh...
Can we stop complaining? I see a ton of improvements and nicer features than the ones you are talking about in this new release.
Whoops stack trace: https://laracasts.com/discuss/channels/general-discussion/wh...
Can we stop complaining? I see a ton of improvements and nicer features than the ones you are talking about in this new release.
I don't know the reasoning behind the decision to not use Whoops by default, but I considered the beautiful and informative error pages to be a nice trait of Laravel that I will miss. It is also a feature that almost anyone who has used Laravel has come in contact with, so I am sure that it will be widely missed. I remember a non-developer coworker who was using Laravel 4.x for the first time commenting on how it was one of their favorite features.
Adding it back should be trivial http://mattstauffer.co/blog/bringing-whoops-back-to-laravel-...
I usually add the Raven PHP client [https://github.com/getsentry/raven-php] to report errors to Sentry when starting a new project and will likely do the same with Whoops by default.
Adding it back should be trivial http://mattstauffer.co/blog/bringing-whoops-back-to-laravel-...
I usually add the Raven PHP client [https://github.com/getsentry/raven-php] to report errors to Sentry when starting a new project and will likely do the same with Whoops by default.
I really like Laravel, it makes getting things started easier. I am glad I finally have a good way to manage my assets from within Laravel so that I don't have to deal with all of that myself every time. The only thing I find Laravel lacking is Web Socket support and every time I tried to implement something I would basically give up and switch to Node.js. Is there anything that can get web sockets working in Laravel?
I love the `Architecture Foundations` section in documentation [1]. I wonder why more frameworks don't do this. It happens a lot that I have no idea where to put files when I start with some frameworks. I am still not sure how good it is but I am reading through it right now.
[1] http://laravel.com/docs/master/providers
[1] http://laravel.com/docs/master/providers
I tend to use Laravel when the client/project forces me to use PHP rather than Rails. It's not bad when coming from the Rails world.
I also have a bit of pride that it's made in Arkansas. Yes, we have computers and the internet here.
I also have a bit of pride that it's made in Arkansas. Yes, we have computers and the internet here.
Laracasts has a series of introductory screencasts on Laravel 5: https://laracasts.com/series/laravel-5-fundamentals
I'm a fan of Symfony but love that there are several advanced frameworks pushing the state of the art forward (Symfony, Laravel, ZF2).
What are the main advantages of Laravel over say Cake or Symfony?
Let's add Codeigniter to the list too. Need a pitch for the employer.
I thought codeigniter was dead? I could have sworn they announced 2 years ago it was no longer going to be developed.
The framework found a new home and its now under active development again. Unfortunately, since v3 which is still not officially out, the framework has fallen behind its competitors.
no longer developed by EllisLab, perhaps..
https://github.com/bcit-ci/CodeIgniter
It was revived a while ago: http://forum.codeigniter.com/thread-650.html
I just started with Laravel and can't compare it really well to the other frameworks, but this is what I like so far:
- it's well-documented
- it has an active community
- I simply enjoy working with it. It feels lightweight, although it probably isn't, if I take a good look at the "vendor" folder and the dependencies
- I get stuff done relatively quickly
Edit: So I started porting my small Laravel 4 project to 5 and to be honest, my first impression is: Laravel 5 is more like Zend Framework than the small and nice PHP framework. It lost a bit of its lightweight flair for a potentially more structured architecture, but I kind of hate to put everything in "Service Providers" and "Middleware" and whatnot.
E. g. before, you had a folder "app/controllers", now you have "app/Http/Controllers" and "app/Http/Middleware" and "app/Http/Requests". While this might make sense for bigger projects, it also loses a bit of its lightweight charm.
With Laravel 4, things seemed to be more straight forward.
- it's well-documented
- it has an active community
- I simply enjoy working with it. It feels lightweight, although it probably isn't, if I take a good look at the "vendor" folder and the dependencies
- I get stuff done relatively quickly
Edit: So I started porting my small Laravel 4 project to 5 and to be honest, my first impression is: Laravel 5 is more like Zend Framework than the small and nice PHP framework. It lost a bit of its lightweight flair for a potentially more structured architecture, but I kind of hate to put everything in "Service Providers" and "Middleware" and whatnot.
E. g. before, you had a folder "app/controllers", now you have "app/Http/Controllers" and "app/Http/Middleware" and "app/Http/Requests". While this might make sense for bigger projects, it also loses a bit of its lightweight charm.
With Laravel 4, things seemed to be more straight forward.
Laravel changes.. er.. updates a lot more often
Highly active community with awesome mentors like Jeffery Way (laracasts.com).
Over cake, it's modern, widely used and supported.
Over Symfony, not a lot tbh (large parts of Laravel are built on Symfony), it's a lot more opinionated out the box than Symfony and Eloquent has a flatter learning curve than Doctrine.
Over Symfony, not a lot tbh (large parts of Laravel are built on Symfony), it's a lot more opinionated out the box than Symfony and Eloquent has a flatter learning curve than Doctrine.
So having looked into php frameworks a bit.
There are 2 main packages of reusable components in php. Symfony and Zend.
Somewhat confusingly Zend and Symfony also make frameworks built on top of these components. But you can use the components on their own. Use the Composer to install the ones you need. You don't even need a framework to use them.
Laravel is built on top of Symfony components.
I think the main advantage to Laravel is people who use it really tend to like it... a lot. I hear a lot of complaining about other frameworks, but Laravel people enjoy. People that figure it out tend to get sites up really quickly. The main downside I hear about is performance.
For me documentation is key. I tried using Zend components, and while they worked I find the documentation really lacking. Zend have some great stuff like an api builder, but documentation is really important and its why I'll probably end up trying Laravel
There are 2 main packages of reusable components in php. Symfony and Zend.
Somewhat confusingly Zend and Symfony also make frameworks built on top of these components. But you can use the components on their own. Use the Composer to install the ones you need. You don't even need a framework to use them.
Laravel is built on top of Symfony components.
I think the main advantage to Laravel is people who use it really tend to like it... a lot. I hear a lot of complaining about other frameworks, but Laravel people enjoy. People that figure it out tend to get sites up really quickly. The main downside I hear about is performance.
For me documentation is key. I tried using Zend components, and while they worked I find the documentation really lacking. Zend have some great stuff like an api builder, but documentation is really important and its why I'll probably end up trying Laravel
As some other commenters wrote - there's not that many differences with Symfony approach-wise. But it's more fun to write code in Laravel, Symfony on the other hand is incredibly verbose which is not a good thing in my opinion. You have to write way more code to achieve same thing in Symfony compared to Laravel.
Laravel has very reasonable and easy to understand structure and you don't need to use .xml or .yml for configuration.
I've had experience in CodeIgniter, Symfony, FuelPHP and I've been sticking with Laravel for over two years because of how simply nice it is to work with.
Laravel has very reasonable and easy to understand structure and you don't need to use .xml or .yml for configuration.
I've had experience in CodeIgniter, Symfony, FuelPHP and I've been sticking with Laravel for over two years because of how simply nice it is to work with.
Having worked with Kohana, CodeIgniter and WP, Laravel is the reason I started writing PHP again. Also being a node developer, Laravel feels at home with Express(both influenced by Sinatra).
Artisan command line utility, Migrations for DB version control, Blade template engine and the neat directory structure are some of the things I like apart from the community ofcourse
Artisan command line utility, Migrations for DB version control, Blade template engine and the neat directory structure are some of the things I like apart from the community ofcourse
What is the thing you don't like about Laravel community? (or is this what you say when other PHP devs are involved?)
I think that he actually likes the community. The wording might be quite confusing but I think that's what he meant.
Sorry, meant to say "some of the things I like and the community ofcourse"
More info: http://laravel.com
For those currently using Laravel, here are some upgrade guides due to the large changes from 4 -> 5
http://laravel.com/docs/master/upgrade
http://mattstauffer.co/blog/upgrading-from-laravel-4-to-lara...
http://laravel.com/docs/master/upgrade
http://mattstauffer.co/blog/upgrading-from-laravel-4-to-lara...
Looks like some links are broken.
For example http://laravel.com/docs/authentication redirects to -> http://laravel.com/docs/4.2/authentication which is 404.
Seems to be working fine here. Try again?
It wouldn't be the first time. When Laravel 4 came out, they decided the best way to announce that would be to make all the old URLs for Laravel 3 documentation point to Laravel 4 pages, and then take down the Laravel 3 documentation completely.
Yes. Completely. Not just "put it in a less prominent place" or "hide it six levels deep in the directory hierarchy" -- it was gone, overnight. Poof! Vanished.
I happened to be in the middle of a Laravel 3 project at the time, so the sudden removal of all documentation for the version I was working with was more than a little painful.
Yes. Completely. Not just "put it in a less prominent place" or "hide it six levels deep in the directory hierarchy" -- it was gone, overnight. Poof! Vanished.
I happened to be in the middle of a Laravel 3 project at the time, so the sudden removal of all documentation for the version I was working with was more than a little painful.
Deal-breakers for me with Laravel:
- Blade templating language. I don't need yet another templating syntax to learn, especially one that isn't analogous to others I know and are common among other frameworks.
- I really can't imagine going back to an active record based ORM. I've learned too many hard performance lessons from Doctrine1 and rails at this point.
- Facade/proxy pattern based classes. I think as they are implemented in the actual framework, these are done correctly. However, I think the userland understanding of this pattern is often lacking and leads to a lot of glorified singletons that are some how touted as acceptable because they call them facade/proxy based.
In the giant lineup of frameworks, ranging from something as simple as SlimPHP or silex, all the way to enterprise targeted frameworks like Zend Framework 2, I just don't see why I'd ever pick Laravel as the go-to solution in any use case.
- Blade templating language. I don't need yet another templating syntax to learn, especially one that isn't analogous to others I know and are common among other frameworks.
- I really can't imagine going back to an active record based ORM. I've learned too many hard performance lessons from Doctrine1 and rails at this point.
- Facade/proxy pattern based classes. I think as they are implemented in the actual framework, these are done correctly. However, I think the userland understanding of this pattern is often lacking and leads to a lot of glorified singletons that are some how touted as acceptable because they call them facade/proxy based.
In the giant lineup of frameworks, ranging from something as simple as SlimPHP or silex, all the way to enterprise targeted frameworks like Zend Framework 2, I just don't see why I'd ever pick Laravel as the go-to solution in any use case.
Those don't have to be deal-breakers.
- You don't have to use Blade. Use Twig or Smarty or whatever you want
- You don't have to use Eloquent. Use raw queries or Doctrine or whatever you want
- You don't have to use Facades - use the IOC container to get whatever you want
Its so easy to plug-and-play with composer, and there are so many other features to laravel.
- You don't have to use Blade. Use Twig or Smarty or whatever you want
- You don't have to use Eloquent. Use raw queries or Doctrine or whatever you want
- You don't have to use Facades - use the IOC container to get whatever you want
Its so easy to plug-and-play with composer, and there are so many other features to laravel.
Yeah, at that point why use Laravel?
All the major frameworks are just as decoupled, but as soon as you start selecting off the "native" defaults for things like templating and ORM you lose integration features that have been built into other areas of the framework to support that specific library.
All the major frameworks are just as decoupled, but as soon as you start selecting off the "native" defaults for things like templating and ORM you lose integration features that have been built into other areas of the framework to support that specific library.
what the point of it then? just use Silex,it's better,faster and simpler.
Ive been so excited about this! Though I kinda miss the call to action buttons that they had on the old site. Scrolled down the page looking for the quickstart button before I had a "duh" moment and clicked on documentation.
Bad to see, Laravel still doesn't have an LTS version. Upgrading is a pain.
Might be a business opportunity, ala https://railslts.com/.
Awesome news, been expecting this since a mysterious twit last week, Laravel is awesome, can't wait to check v5
thanks!
thanks!
i dont want to depend on a framework by one person.
Can you really write beautiful code in PHP?
Sure. PHP, especially post 5.4 has matured a lot and offers as many niceties as your favorite blub language. It has its warts, but at this point, nothing worse than what Javascript has for example.
That said, while you can write beautiful code in PHP, IMHO, Laravel is not that.
It full of "string typing", over-applied and mis-applied Design Patterns, and poorly thought abstractions.
It just saddens me that Laravel is considered well designed and advanced codebase, or, worse, a standard of how PHP should be coded.
While it's not as bad as the Wordpress spaghetti, it is mostly Java EE (circa 2004) in PHP, sans the strong typing assurances (and, fortunately, sans the gobs of XML too).
On the other hand, Laravel works and has a strong community going for it, which, as in the case of Wordpress, makes all the difference in the world.
That said, while you can write beautiful code in PHP, IMHO, Laravel is not that.
It full of "string typing", over-applied and mis-applied Design Patterns, and poorly thought abstractions.
It just saddens me that Laravel is considered well designed and advanced codebase, or, worse, a standard of how PHP should be coded.
While it's not as bad as the Wordpress spaghetti, it is mostly Java EE (circa 2004) in PHP, sans the strong typing assurances (and, fortunately, sans the gobs of XML too).
On the other hand, Laravel works and has a strong community going for it, which, as in the case of Wordpress, makes all the difference in the world.
A lot of the over engineering in Laravel comes from Symphony, which in turn inspires how Laravel is built. And with the Proxy pattern in use everywhere, it inspires high coupling in your code in a way that doesn't quite look like coupling but is nonetheless.
I would argue that Symfony is well engineered, not over engineered. The fact that Laravel is already at version 5 demonstrates just how poorly engineered it was in the first place.
That's an odd argument. Is Rails poorly designed because it's had 4 versions, or Django because it's had 8? Seems much more to do with the pace of the development than the architectural quality, to me.
EDIT: It depends on what the versioning represents.
I don't think there have been as many breaking changes in Rails vs Laravel, and Rails at v4 has been over ... 9-10 years? Laravel is < 6 years old, with, from what it seems to be, rather significant philosophical changes between major versions. Doesn't mean it's bad, but perhaps closer to using gentoo vs centos.
I don't think there have been as many breaking changes in Rails vs Laravel, and Rails at v4 has been over ... 9-10 years? Laravel is < 6 years old, with, from what it seems to be, rather significant philosophical changes between major versions. Doesn't mean it's bad, but perhaps closer to using gentoo vs centos.
It is a well known fact that one can deduce the quality of a software product simply by the the number that comes after its name.
So Internet Explorer is a better engineered product than Chrome and Firefox?
Killswitch(1)
Can you give an example of a well designed PHP codebase?
Are any of the other frameworks (Symfony2, Zend, etc..) better?
Are any of the other frameworks (Symfony2, Zend, etc..) better?
Not a framework per se, but several independent packages, http://thephpleague.com/ has some well written and nice code.
When I tried SF2 I found it to be a terrible, Java-like, pile of abstractions. This might work for some people, but if you prefer thinking about business logic (as opposed to "where do I extend this IoC dependency container so that it can find my ControllerFactory), it's not for you. It left me bitter.
Yii is supposed to be nicer, I heard from colleagues, but I left PHP programming the moment I saw the opportunity so I can't vouch for that.
Yii is supposed to be nicer, I heard from colleagues, but I left PHP programming the moment I saw the opportunity so I can't vouch for that.
Extending the IoC container?? A ControllerFactory?? You never do anything like that in Symfony. The thing I appreciate most about Symfony2 is how it enforces good design patterns.
One might argue that the SOLID principles applied in Symphony and inherited by Laravel are in fact anti-patterns which only serve to add massive cognitive overhead. They've wrecked countless Java projects over the years and are now going to do PHP the same favor.
There's even less reason for a scripting language with a GIL to be saddled with this level of complexity, than there is for Java.
There's even less reason for a scripting language with a GIL to be saddled with this level of complexity, than there is for Java.
Much of the complexity in Symfony comes from its "dependency injection" component (a misnomer, really) and the inclusion of annotation magic in the standard framework distribution.
These days, I'd rather use the basic components (e.g. Symfony's HttpFoundation library) with something like league/container (formerly orno/di) and a simple routing library like nikic/FastRoute.
These days, I'd rather use the basic components (e.g. Symfony's HttpFoundation library) with something like league/container (formerly orno/di) and a simple routing library like nikic/FastRoute.
> They've wrecked countless Java projects over the years and are now going to do PHP the same favor.
Oooh do enlighten. I made an argument when Symfony2 first came out that PHP isn't Java, and now I've been brainwashed to think the Symfony community is right.
Very refreshing to here an alternative point of view :)
Oooh do enlighten. I made an argument when Symfony2 first came out that PHP isn't Java, and now I've been brainwashed to think the Symfony community is right.
Very refreshing to here an alternative point of view :)
Can you elaborate on "the SOLID principles [...] are in fact anti-patterns"? I don't see this point of view exposed often, can you point me to some resources in this regard?
I really enjoy using Yii. It's not perfect, but it seems underrated to me.
Take a look at phabricator's source code, which was originally developed in house at facebook but is currently open sourced. It's not using any of the big MVC frameworks, but it's very well written (despite using PHP 5.2 compatible only syntax) and I think a good example of a well designed PHP codebase.
[deleted]
No, they also suffer from the pattern misuse pattern and are also slow as hell.
It would benefit the whole community if you documented your complaints (and suggestions for improvements) in a blog post we can all read & comment on.
Though the Symfony2 community hasn't been open to criticism and suggestions for improvement.
And eventually, when they've taken some of the original criticisms on-board (at v2.6) [0], they themselves get shot down by parts of the community for spoiling the architecture.
0: http://symfony.com/doc/current/best_practices/index.html
And eventually, when they've taken some of the original criticisms on-board (at v2.6) [0], they themselves get shot down by parts of the community for spoiling the architecture.
0: http://symfony.com/doc/current/best_practices/index.html
[deleted]
[deleted]
https://laravel-news.com/2015/02/laravel-5-released/
It might be a better way to get an overview of this release as it links to various other articles about v5.
An article specifically on the changes:
https://laravel-news.com/2015/01/laravel-5/