@BenSmith, for what it's worth, no change on my part in a month or two. Not bcoz I'm backward but I still find the arguments in favor of annotations amazingly light, considering that this is likely to be promoted as default approach. @JeffreyWay - on 1. I'd argue that the thought process that usually goes into routes during the course of a project (even small one) will far outweigh the actual editing/typing, so not sure I care about these few seconds I might save. Plus I lose code completion. Plus I have to run a command. Plus I can easily imagine scenarios where editing routes in a central place is rather the most efficient approach. Isn't this the usual trouble with central vs. decentral discussions - there's always valid arguments for both.

I'm with Jeffrey on this too. It's a simpler workflow.

It would also be nice for tutorials/learning if everybody is singing from the same hymn book, rather than some using the route file and others using annotations.

Lets start as we mean to go on.

@Cocoon, You can add filters (middleware) and prefixes to all methods in a controller:

/**
 * @Controller(prefix="admin")
 */
class RequestsController { }

And here we go again. Topic started as a poll on routes.php file and now it is all about annotations :P

I am pretty sure annotations are at the moment much more popular than Britney Spears and Christina Aguilera combined.

I'd argue that the thought process that usually goes into routes during the course of a project (even small one) will far outweigh the actual editing/typing, so not sure I care about these few seconds I might save.

True, but I do think there's value in a streamlined workflow that requires as little effort as possible.

Plus I have to run a command.

We'll be recommending Elixir in Laravel 5. This will do it automatically. You'll never run that command.

Plus I can easily imagine scenarios where editing routes in a central place is rather the most efficient approach.

Possibly. I want to play around with the route annotations approach more to see if this is the case.

@BenSmith not quite efficient when the prefix is a locale prefix = subdomain and affects all controller methods but a few. So much for perceived efficiency gain - it really is depending on scenario.

@keevitaja The reason for the routes.php question is because of route annotations. :)

@BenSmith Hmm, okay but I would still have to define this for every controller and maybe add exceptions. I think it was just easier to digest to see all the routes and route groups in on overview.

On the other hand, I guess I will be able to have a look at the routes.scanned.php for the overview.

Currently, I am pretty much undecided if I should use annotations or a single routes.php file.

Yeah, it's important to remember that, if you do choose the route annotations approach, you can view the routes.scanned.php file to see all registered routes, and you can also, like always, run php artisan route:list.

Call me sentimental but I liked most what seems to have vanished in favor of POPOs (that I don't care about) - before filters in constructors. @JeffreyWay - learned about the approach here at Laracasts and loved it immediately. That to me has been by far most efficient - routes.php for routes, constructors for before filters, where I see them close to the methods they correspond to. Mentioning this rather as an anecdote and to prove there's all sorts of angles on the subject. No hope that Illuminate\Routing\Controller will survive, except maybe in a legacy package.

If Laravel is promoting annotations as the way to do routing (with "traditional" routing (routes.php) as an option) then it would be a mistake to include routes.php, it would be confusing and inconsistent with the previous approach Laravel has taken with optional features. Providing clear documentation that covers the available routing options is more than enough if there are multiple options available.

That said personally I'm not confident in the use of "annotations" because they are not supported by PHP -- it's ultimately a hack -- and the benefits discussed are all very woolly, but if they are a positive improvement to the framework when version 5 releases perhaps that will be the pressure required to ensure that PHP 7 implements annotations... but until then I won't be using them.

@citricsquid Maybe thats why most of the users in this thread vote in favor of the routes.php. They don't want annotations to be the way to do routing.

@PatrickBauer - But it's also possible that some people are reacting too quickly, without giving it the proper thought. "This is the way I've always done it. I read a blog article that said PHP annotations are bad. As a result, I must protest."

I'm curious to learn how many people who don't want to use route annotations have ever tried using route annotations... It's worth tinkering with first, right? Before we make up our minds and throw them to the wolves? :)

include by default +1. although I like having only files with classes under the app dir.

Yes, thats my point. I'm curious why the people vote for or against the routes file. Maybe they are against annotations, maybe its just like you said "that's how we've always done it".

@rspahni You probably didn't notice, but Illuminate\Routing\Controller is back as an option (with beforeFilters and everything). At least for the time being. :)

https://github.com/laravel/framework/blob/master/src/Illuminate/Routing/Controller.php

For what it's worth I'm arguing based on my ongoing "L4.5" (= L5 freeze from early Oct) project whereby I have made several rather time-consuming attempts of converting filters into middleware[s] and routes into annotations. The latter wouldn't work on Windows at all (empty routes.scanned.php, probably fixed meanwhile) but universally - the best I could accomplish was, it did what it used to do before with no seeming benefit coming from the port and no clear advantage for eventual new projects that I can think of. So some of us have made an effort to build our opinion upon practical experience.

@anzze I know, Taylor once mentioned it will be included in a "legacy" package in the eventual L5 release. But with the notion of legacy, I think it's off the table as one of the options for default, to say the least.

@rspahni No, it seems like Taylor decided against legacy package. See this commit from yesterday: https://github.com/laravel/framework/commit/1e5bf11e6e7d8698e4069874db7281a7c4034640

After "legacy" usually comes "deprecated" and then "removed"!

@anzze - hey THAT I missed indeed! So I might be able to run composer again on laravel/framework anytime soon! :))

Keep as is.

Make routes.php + $this->beforeFilter() the default. routes.php incl. filters as alternative for those who prefer centralization. Move on to annotations when PHP7 launches with official support and PhpStorm 10 recognizes and completes the code. ;-)

I haven't read all the replies yet but my opinion is to remove the routes.php file if the goal is to push annotations. I'm still not sold on the idea of annotations because I think it's better to keep all route definitions together, but it should be one or the other and if annotations are here to stay then remove routes.php by default so not to confuse.

@puzbie hit the nail - probably, annotations have been trying to solve a problem where there was none and existing L4 options sufficed. Good night (CET).

If we are thinking about newcomers, than I think routes.php should probably stay the default. While I can see a huge benefit in annotations, I think that that they should be provided as an option for all those who (after some time spent on the framework) begin to see the benefit in using them.

The problem is that most of the Laravel newcomers don't know anything about gulp and nodejs and they already need to learn a lot - not just the framework, but probably also composer. So adding gulp to that mix makes it even harder to get started for e.g. ex CodeIgniter folks. Also, most of these people are probably using Windows and I can tell you first hand that they are not comfortable using a console too much. And Windows doesn't make it any easier (random errors all the time).

I think it should be made very easy for newcomers to create their first Laravel app using the tools they know (probably something like Wamp). Then they will move gently to the next step and experience all of the Laravel awesomeness.

The problem is that most of the Laravel newcomers don't know anything about gulp and nodejs and they already need to learn a lot - not just the framework, but probably also composer. So adding gulp to that mix makes it even harder to get started for e.g. ex CodeIgniter folks.

Yeah, that's a valid point. They don't really need to learn Gulp, but it's true that they'd need to do some more setup.

How about when you need to build dynamic routes? For example with loading locales from some kind of config file? Will this be possible somehow with annotations?

Just a question. If we are talking about several methods to establish the routes, one more manual and another more automated, which will prevail in case of conflict with routes when they are scanned? Thinking in team enviroments.

I think the preset value of the routing method selection or one config value would be useful.

+1 for removing the file. I don't think annotations are too complex to pick up for a newcomer, so it would be better to encourage a single approach for more consistency across learning material and examples being produced after L5 drops.