There needs to be a quick overview of the syntax or how it works. I don't want to read pages of documentation just to figure out how it looks like.

I found the quickest way to learn how to use it was just install it. The code is commented very well and is quite expressive in it's syntax so looking up the docs has been, for the most part, an exercise in "what params does Str::limit take?".

Agreed!

I respect the work, but the samples look a lot like Symfony2, which has a huge community behind it. Sf2 has a learning curve but I'm not sure what problem Laravel solves that Sf2 (or its simplified kid brother Silex) doesn't already solve.

I came away thinking the same. Also, Laravel seems (from first glance at least) to lack the modular design approach of Symfony2 i.e. with Laravel you either take the whole framework or nothing at all - you can't selectively pick which modules you want. Another thing I missed was Silex's approach of using a minimal core and then relying on third party providers for functionality rather than re-inventing the wheel (e.g. Doctrine for db work, Monolog for logging and Twig for templating).

I agree. If someone wants to launch a new PHP framework in 2012, they should at least talk about some of the leading PHP frameworks (Symfony, CodeIgniter, CakePHP, etc) and say why those frameworks are not adequate.

Optionally, one could include a discussion of why one should use PHP, but I realize there is convenience and brevity to be gained from simply assuming you are talking to an audience that is already sold on PHP, rather than Java or Ruby or Python or Clojure.

Do all Java, Ruby, and Python frameworks include a discussion of why one should use those languages? Seems to me that when you're evaluating frameworks, the language decision is probably already made.

Why not PHP?

Imagine the conversation we would have if I hit the reply button and wrote:

Why PHP?

Seriously, it does not take the conversation forward.

I know its not perfect, and has some little loved features. But for me a language is a tool. And tools are meant for specific jobs. Like I wouldn't use a phillips head screwdriver where a set of pliers is needed.

If php is to advance we should welcome all tools that evolve it.

Or ditch it already and write Python/Ruby.

Why don't we ditch Python/Ruby and just go with CLISP?

Because Python/Ruby are decent languages, CLISP isn't objectively better, it's just different.

I think a lot of people, even those who used/use some variation of 1.x, are unaware of the emergence of some really good bundles. I'll post two links about the Sonata bundles:

http://www.chrisshennan.com/2012/02/16/symfony2-and-sonata-p...

http://sonata-project.org/bundles/

For those who don't know what a Symfony bundle is, you can think of them as an attempt to bring something like Rails Engines to the land of PHP.

Not a micro-framework but with small learning-curve. IMHO that is a big win.

ditto. What problem does it solve? None, we don't need another framework! What we need is something that would save us PHP programmers more time than the MVC/Frameworks that are out there already do. How about a sleek CMS on top of Sf2 built on the bundles concept (it would have to be:), or a Magento replacement that integrates with the CMS and Sf2. That would get my attention.

I think you are missing the point. And if we all said such negative comments about something new we wouldn't have made much progress in moving forward. So it solves some problems that have already been solved. It is doing them in new ways and at the very least it is getting people interested and talking about PHP and web development. I am sick of working with CakePHP! I am sick of trying to work with old frameworks that still want to support PHP4! Looking at this framework, gave me new interest in PHP, gave me new interest in the new features offered in recent versions of PHP.

That and keep in mind there are many projects that don't need something like Symfony or Zend. A lot of projects that is the same thing as using a sledge hammer for a thumbtack. Something like Laravel gives me the tools to get a small project up and running quickly without having to do a lot of the mindless/repetitive tasks we all have to do with new projects.

Lastly, your "solution" that gets your attention is nothing new. It is not web development, it is installing software via a web interface. So you say what does it solve when really you are just asking for another e-commerce and CMS solution. Hmm, that hasn't been done thousands of times before...

Something I find really strange/frustrating with a few recent frameworks (Laravel included) is their overuse of static methods. You have these singletons floating through the framework which maintain state (Request, Session, Logging etc) but you can only ever access them statically. Seems like bad practise to me.

What if you want to swap out Request for a mock during unit testing; since you've hard coded the Request class throughout your controllers how would you switch to a RequestMock class? What happens if you were dealing with more than one request (e.g in a HMVC setup).

It looks interesting enough but a few things put me off:

1). Rolling its own ORM rather than using Doctrine.

2). YATL (yet another templating language). I wish the PHP world would just standardise on Twig.

3). Localisation seems a bit basic at the moment and it's a shame you have to define messages in a PHP array rather than something more portable like YAML.

4). Would have been great if it used Monolog for logging.

On the plus side, I like the clean design and their approach for events looks cool.

1. You can use Doctrine bundle http://bundles.laravel.com/bundle/doctrine

2. It's also available. http://bundles.laravel.com/search?q=twig

3. Laravel focus on Event, so you can just set a listener to `laravel.language.loader` event and replace to anything you want it to be. Check http://www.keithloy.me/2012/04/yaml-config-files-in-laravel/

4. Same with Logging, just change https://github.com/laravel/laravel/blob/master/application/c...

Thanks crynobone. Looks like I was too hasty in my criticism.

1) Are you sure Doctrine is the best choice?

2) Why not simply use PHP for templating?

3) Using YAML would be just as bad, if you want to use something use something standard for localization like gettext or XLiff.

1). I'm not an ORM lover in general but, yes, if you're going to use an ORM and are basing your project on PHP, Doctrine is generally accepted as the best.

2). See: http://twig.sensiolabs.org/ (Why yet another template engine?)

3). Personal preference I guess but I hate gettext. I much prefer the pattern of using labels in your template (e.g. menu.item1) and then looking up that label in the desired language file e.g. messages.en.yml. And I've never had a problem with translators working with YAML files (i.e. the syntax is easy for them to grok)

2). I really don't understand why we should use Twig : Smarty is older, why using yet another template engine ? Or I've got a better idea : we could use the template engine used in phpBB2 : he's older !

I'm agree that standardization would be just fine(c), and I like the Twig syntax, but I think the "YATL, we should use Twig" argument is not relevant.

It appears more functional in style: http://laravel.com/docs/routing#the-basics

Good to see that.

What I would like to know is how exactly is this different from the hundreds of open source PHP frameworks available out there?

It takes full advantage of recent advancements in PHP to facilitate more functional programming.

This was what confused me. I look at the home page and the major features seem to be that it is well documented and has "bundles". That doesn't really tell me how it will make my development easy.

Its a good framework but the development cycle is far to fast. Every few months there is a new full iteration where core functionality is added and development practices change.

I feel it would be far more usable and popular if the dev cycle slowed and the framework was allowed to mature and gain some traction.

It will slow down shortly, I expect.

Taylor has only recently started working full-time on the framework and as a result has been able to "fill out" the framework with community-requested features at a quick pace. It's just a matter of time before it tapers off; there's no point in stagnating the development of such a young and novel framework for what IMO are silly reasons.

Why are so many PHP 5.3 frameworks like this ignoring namespaces.

    class Admin_Controller extends Base_Controller

Seriously, someone thinks this is OK?

Laravel makes extensive use of namespaces.

The omission of namepaces in the case of controllers was a calculated decision. PHP's implementation of namespaces is... inadequate, and would have required annoying workarounds, so prefixing controllers was the better evil.

How is PHP's namespace implementation inadequate? Use-as statements are the staple of every PHP library that uses namespaces, and this seems like a half-measure to placate less-experienced programmers.

Sounds more like the skills of the dev involved are inadequate quite frankly.

Base_Controller is an optional controller in Laravel placed between the main Controller and the controllers you create. Normally you'll just extend the main Controller which is namespaced;

<code>class Admin_Controller extends Controller</code>

Why would you need a class name like "admin_controller" if you are using namespaces?

Laravel looks nice but I agree the internal/default naming conventions and structures are a bit odd for 2012. Hopefully this will be changed in an upcoming version.

What naming conventions specifically don't you like?

I guess it is mainly the fact that it's not using CamelCase for directories, all lower-case filenames, underscores in methods and class names (_Task).

I am re-building a project in Laravel right now that I started with Slim, using a couple of Symfony components and own code and it's a bit of a turn-off for me that I ended up with quite mixed naming conventions now.

With so many PSR-0 compliant PHP libraries and Composer on the rise, I just think it's the way to go. This doesn't stop me from trying Laravel though and so far this is the only thing that kind of bugs me. But don't get me wrong, basically I really like it so far.

Hey all, glad you find getlaravel.com useful. You could also checkout my blog which has 22+ Laravel tutorials including tips and tricks : http://daylerees.com . There is also an ebook available, linked from the site. Thanks!

I don't totally agree with the author: coming fresh to php 5.3 without prior contact with the elephant isn't going to protect anyone from php's inherent inconsistencies or legacy way-of-doing-things for very long. I am specifically thinking about the different naming conventions for functions (sometimes underscore, sometimes not ). Of course my remark isn't about Laravel itself.

With that said I used to try every "small but efficient" framework when I was a web developper and I would surely have tried this one with enthusiasm.

You should check out http://getlaravel.com/ for some basic examples. I've been using Laravel for a few weeks now and I love it! The simplicity is next to none and it certainly has sped up my dev time. I'd recommend trying it for a week and see how you get on, I think you'll fall for it too.

That feels very lovely indeed. I really like the URL reverse routing, have been missing it from all the frameworks I tried.

It looks pretty nice! How can I be sure this will continue to be maintained far into the future though? At least with Zend / Symfony I know they are not going anywhere for the foreseeable future.

Definately one of the most clean coding frameworks I've seen.

It isn't new, but it's in the buzz. Let's face it, stateless MVC for the web is a local maximum. We can do much better, but not if we stick with this MVC crap.

Where does it say stateless? seems like a stateful framework, it has fat-bottomed sessions:

http://laravel.com/docs/session/config

What do you suggest as a replacement of MVC?

MVC seems an odd paradigm for the non-realtime web, when you have to instantiate every object on each request, and data update events are the exception, rather than the rule.

For simple cases, I often fall into a (M/C)+(VL/V) pattern: model and controller fused into one layer, view-logic and view into another. If database logic is sufficient complex or used in multiple places, break it out into its own layer, same for view logic. No pattern can or should be a universal panacea for every use case.

All that said, I'm really liking Laravel's approach. It's high time that PHP frameworks started getting wise to closures.

> when you have to instantiate every object on each request,

The thing about this that it lends itself well to HTTP because HTTP is a request-based system.

Once you start breaking down the barriers between requests you get all kinds of horrendous issues with race conditions and memory sharing and pain. Sessions just about get by this because they are per-user and people don't oft do huge amounts of things concurrently.

PHP is also designed on a per-request basis.

Some of the modern PHP frameworks are already wise to closures e.g. Silex.

So is it like making something similar to RoR? If yes then I am interested.

RoR has spoilt me. Anything that is similar to RoR is highly attracted to me.

CakePHP (http://book.cakephp.org/2.0/en/index.html) was initially built on ROR concepts. It follows a brilliant MVC pattern and gets you up and running with 'bake' (think 'rails generate') so if you know RoR and PHP, then you will feel very at home with Cake.

Yes, but their Model layer, in comparison with what ActiveRecord provides you with, is really not that great. One of the main aspects that I really didn't like was that the Model finder methods don't give you object instances back, but instead you get php arrays with the fetched data from the database.

Personally, I have never found this in any way restrictive?

Why do you want object instances?

Try Yii, it is similar to rails in many respects http://www.yiiframework.com/

Just found out about Yii. How would you rate it?

Being a micro framework it's more similar to Sinatra than Rails.

In terms of main differences, it's PHP rather than Ruby which means it's verbose rather than terse and it's less automagical than Sinatra / DataMapper.

If you need to use PHP for a project, then it's a great choice, but if you don't then you're better off with Sinatra (or Express and Node depending on what you're wanting to do).

Laravel does not cache routes defined in routes.php and especially those loaded from disk with Controller:detect(). What a pitty.

It's very similar to Kohana 3.

Not really. Kohana uses static methods to create objects extensively. Laravel looks largely procedural to me with static methods updating static classes.

Kohana uses things like, $foo = Model::factory('Bar');

which does nothing more than

static function factory($model_name) { return new $model_name . '_Model'; }

Exactly, because of how its autoloader/class finder works.

globals, static methods... bad code again.

It needs a 2-minute video to "sell" it to me. There are literally hundreds of PHP frameworks. Your list of "highlights" didn't make me want to try it.

How about a webinar, or a conference call?

I think written documentation is just fine.

You have been conditioned by far too much hype. You need to evaluate your software, not be sold on it.

You could also say "You need to evaluate your software, and be sold on it"

Or not.

I need a reason to evaluate your software. There are hundreds of frameworks. If I start evaluating every single one of them, I will spend the rest of my life doing just that.

Your job is to select the best tool for the task, not the best marketed tool.

Harden up and evaluate software correctly.

whoosh

Makes complete sense, now that you put it that way.

I didn't realize the whole thing was a joke.

Did you just try to pick on his name?

I didn't think he was. I think it was stylistic hyperbole; deliberate heavy-handed response, just I pulled out the "webinar" gun to label someone a "suit" :-)

Thanks. This is pretty good.

"I was looking for a framework that supported PHP 5.3"

You didn't look hard enough - see Lithium

http://lithify.me

Or Symfony2/Silex (based on Symfony, but designed more like Sinatra)

http://symfony.com/

http://silex.sensiolabs.org/

and soon Zend Framework 2.

...which even does not have RC yet...

Validations in routes, you're doing it right https://github.com/laravel/pastes/blob/master/application/ro...

I think the routing in that example is meant to be Sinatra-style routing for lightweight applications.

I really like this approach. It's one of the reasons I like Express in node.js. I am by no means a fan of PHP after using it on several projects, but if I were forced at gunpoint I would look into Laravel.

I also like the DB table creation code. ActiveRecord-type model delcarations are fine, but I'm interested in exploring Mongoose-type ORM, since I suspect it is more flexible in the long run.

Hey, Dayle Rees here, (guy who made the getlaravel.com promo site) I also wrote the pastes app, and the reason I chose to use routes is that its a tiny application, and using routes avoided all the unnecessary "class fluff" allowing me to prototype quickly. On a large scale app I would have used controllers, which are also available. :)

In a real world PHP is more alive than most of other web languages. Our salaries are paid by businessmen and they don't give a shit how it works as long as it works.

PHP is not dying.

Any developer worth his weight should be able to adapt to any framework written in the language he knows.

If you know PHP/Ruby/Python/etc, you should be able to pickup a new framework within a day or two.