[fleitz]

Yet the framework docs say none of this. Look at rails, it tells you, put your gems in the gemfile.

Laravel says, hack shit directly on your webserver.

If you're supposed to use composer, why don't the docs say this? Instead the docs say, unzip and hack.

[memla]

The docs don't say that you would update the framework via composer (though this may change when Laravel 4 is released) but they do say that you should just replace the "laravel" folder with a new version using whatever method suits you best, which can be even easier. It certainly seems easier than upgrading Rails, since then you can update your whole remote application code and framework in a single push.

The docs clearly explain that your bundles go to the "bundles" directory, controllers go to the "controllers" directory, views belong in "views" and so on. And your whole application resides in a directory called... "application". You'd actually have to be pretty advanced and amazingly stupid at the same time to make a functional app in the framework core folder and than destroy it by overwriting.

Rails docs don't tell me to unzip the framework and start hacking, but they do instruct me to run "gem install rails", wait a couple of hours till it's done, then run "rails new blog", "cd blog" and then start hacking. Neither set of docs tell me how to setup version control before i begin my work, and they shouldn't. That's not the job of the framework docs.

And of course you're gonna hack your application directly on the server, albeit a local one, as PHP applications are typically developed. This in no way prevents you from using version control and proper deployment techniques.