It's hard to say as I (and most of us) haven't worked with the route annotations yet. I would vote to include it by default in Laravel 5.0, except for the case that route annotations will be the defacto way to deal with routing now.

I vote to keep it there by default

What I've seen so far, annotations just generates a routes.php file, it's just great to keep it for those that don't want to use annotations.

@JeffreyWay I would rather we keep annotations as an option and (as usual) make excellent documentation about their usage.

Let the application's requirements determine methodology, and documentation guide the best practice for implementation.

My experience with Laravel has always been "this code is getting long/messy: I'll read the docs (or visit Laracasts) to find what solutions exist." After that I can proceed quickly and efficiently :-)

@TaylorOtwell Yes +1 for keeping, everything else folder structure likes awesome! Can't wait for it's 'stable' release.

+1 for 'Include by default' - For first time installers it should give guidance.

In the interest of progression I think it should be removed. Just make sure to document that it can be added if you want to go that route.

I would keep it but if you think is better keep it out, I think would be useful in the documentation tell the options to manage those Routes.

Another option would be an artisan command to create that file in the current place.

@JeffreyWay you should record a new video about how to create a poll website with Laravel 5 :)

I'd like the file to stay, but I don't like the current position. Everything else is ordered inside a directory structure while the routes.php just lies there. A nice approach would be a routes folder, where we can create multiple route files (eg. an extra file for the admin area) and the new scan command will scan these files too and send them all together in the generated routes.php.

Edit: maybe even with some extra functions (automatic namespacing) like in the post above, so that he doesn't need this boilerplate code anymore.

I think the current routes.php file location is actually correct because is more related with HTTP Requests.

Keep routes.php and tell about the alternative (link to docs) in the comment block in it ;)

+1 for keeping it in place by default, location is good

Yes and perfect

+1 for keeping the file and location.

@TaylorOtwell a suggestion: edit the routes provider so that you can map routes files to namespaces, like this:

[ 'MyApp\Http\Controllers' => 'MyApp\Http\routes.php' ]

So it's easy either to move the default routes file or create others. For example an Api, Admin or vendor namespace.

I normally end up creating a routes folder to organize the routes in several files.

And +1 for keeping the routes.php anyway.

In my opinion, if Laravel intends to recommend and encourage the route annotations approach, then the presence of the routes.php file is a problem. It should go...with the understanding that you can always manually create the file, if you really hate annotations.

Keep by default.

Maybe keep by default but have it renamed to something like "routes.old.php" with details in there about the new annotation style routes, benefits etc. Also state that to use the old style routes rename the file to simply "routes.php" -- I think that is the best of both worlds, as it encourages the use of annotations without being forceful, and almost hints/suggests that the use of the "old" routes isn't something that is recommended.

@JeffreyWay

Why should laravel recommend and encourage the route annotations? It's just another way to define routes. If in a next version Taylor adds support for xml or yaml annotations what will happen?

My opinion is that Laravel should follow Symfony's approach. Give the user many ways to do something and that's it. Do not recommend anything.

You can recommend personally as a teacher but Laravel should not.

@psampaz I saw multiple times that people wanted symfony to be a little more opinionated (hightlight one of multiple options), to lower the learning curve for new users.

Laravel encourages all sorts of things. That's not weird.

The problem is that routing is step 1. To a newcomer, he/she is immediately presented with two different options. That's not good, in my mind.

Simply giving people a bunch of different ways to do basic tasks, and then saying "Pick one" isn't overly helpful. Laravel should choose which approach it recommends, and then provide an incredibly simple fallback for those who want to opt out.

Can someone explain what advantages are gained by using the route annotations?

+1000 for keeping it as default!

Keep it. If it's removed where else is Jeffrey going to demo random tidbits of functionality ;)

@joshuahornby - For me, these are the primary benefits:

1. Workflow gets faster. You're no longer browsing to routes.php, declaring a URI, directing it to a controller, switching back to the controller, and then loading your view (or whatever). Instead, you add a short @get('/') above the method, and you're done. Less work.
2. Sometimes, when you're viewing a controller method, you forget which URI endpoint it corresponds to. With this approach, you'll never have that problem.

@tomschlick - Ideally, I'd prefer the routes.php to be removed. However, the RouteServiceProvider would still check to see if this file exists. If it does, then it pulls it in, per usual. That way, in two seconds, I can create that file to test out some ideas and such.

I agree with Jeff. Having too many ways to accomplish something is bad, m'kay.

Although, it seems to me that at the same time as you're encouraged to keep your controllers thin, you're dumping the responsibility of handling routes into annotations.

I really like the file and all it represented for Laravel 3 and 4 (for me), but I think it may be now placed in a different location. I still like a simple and plain routes.php, but having many "services" in an application this is how I'm organizing mine:

├── Services
│   ├── Home
│   │   └── Http
│   │       ├── Controllers
│   │       │   └── Home.php
│   │       └── routes.php
│   ├── Dashboard
│   │   └── Http
│   │       ├── Controllers
│   │       │   └── Dashboard.php
│   │       └── routes.php

Those routes are namespaced in the routes.php file.

<?php

Route::group(['before' => 'auth', 'namespace' => 'App\Services\Dashboard\Http\Controllers'], function()
{
    Route::get('/dashboard', ['as' => 'dashboard', 'uses' => 'Dashboard@index']);
});

This way I just have to care about controller namespaces inside the service itself and not outside, in the core application level. Then I load them in the RoutesServiceProvider.php file:

public function map()
{
    // Once the application has booted, we will include the default routes
    // file. This "namespace" helper will load the routes file within a
    // route group which automatically sets the controller namespace.

    $me = $this;

    $this->app->booted(function() use ($me)
    {
        $me->loadApplicationServiceProviders();
    });
}

And I load all of them by scanning all application services folders in file:

private function loadApplicationServiceProviders($path = null)
{
    $path = $path ?: app_path().'/Services';

    $loadable = [
        'routes.php',
        'filters.php',
        'listeners.php',
        'handlers.php',
        'events.php',
    ];

    $files = $this->app->make('files')->allFiles("{$path}");

    foreach ($files as $file)
    {
        if (in_array($file->getFileName(), $loadable))
        {
            include $file->getPathName();
        }
    }
}

What I'm trying to say is: we should not encourage people to use the same routes.php file and the same App/Http/Controllers folder to all of their routes and controllers. I like routes.php, but I like it better when I'm looking only to what I need while I'm changing or fixing some of my services.

About Annotations: I don't like it very much, because it's PHP being generated by comments. It feels like a hack or a workaround, because you'll probably have to configure other services to make it look smooth, and also because it may have some side effects and stop being that smooth.

You need some kind of compilation to built routes based on them (artisan route:scan), right? And, during development, to compile things you have just changed, you'll also need some kind of automation, probably based on disk events (file system observers). And in my experience this something that may not work, as we would like, in every single environment. Like in my own: I develop on Windows an write things to an SSD hard drive (because PHPStorm is slow on a network drive), this hard drive is shared with a Linux box, my nginx server, wich sometimes just don't keep up with all Samba events fired by the Windows file system, and timestamps simply doesn't update if you change-save-change-save, they are cached or whatever. Because of that I had to disable, in my dev environment, the most common Laravel thing: View Caching:

class BladeCompiler extends IlluminateBladeCompiler {

    public function isExpired($path)
    {
        if (Config::get('view.cache') === false)
        {
            return true;
        }

        return parent::isExpired($path);
    }

}

Also Route Annotations are excitingly cool and would love them to feel more like code than comments, because when the new guy look at your code and ask: "where is the code which load those routes?", you'll have to say: "I told you they are in the comments, and that you have to run artisan route:scan to create the actual code, remember?", there's nothing really wrong with this, and I think this is an option Laravel has to have, but I just don't feel very comfortable looking at code this way.

If asked the question a couple of days ago, I would have strongly erred on the side of keeping the file. Now, having spent some time using with the new annotations I'm now leaning the other way.

As Jeffrey says, the inclusion of the file may be problematic to newcomers. It creates a point of friction at a very early stage of learning and for what should be a very straight forward subject.

Having read through the thread so far, I can see that this is definitely not the popular opinion. I would however be very interested in seeing how peoples answers would change if you asked the same question in a month or so, when people have had a chance to use them and Jeffrey had done a video or 2 outlining the changes and some of the benefits to using them.

How would we handle route groups now? With routes.php it was simple as we could just wrap all routes in a closure. So it was easy to set up routes that could only be accessed by admins, members and/or guest. Wouldn't we have to define the filters and prefixes on each and every controller method with route annotations?