Was it really cumbersome to declare a route in laravel? Isn't it just one line in a web.php file where you associate an endpoint to a Controller function?

The issue is that routes are declared in web.php.

In some cases, web.php routes aren't automatically updated if you use `artisan serve`, so you have to restart that sometimes.

And of course, it means there is a lot of distance between the file in which the controller and function are defined and the route definition. The route definition is in "routes/web.php" and the controller will likely sit in "app/Http/Controllers/Something.php", so if your Laravel project is moderately sized, you'll be scrolling a bit if you don't find the editor tab.

On the other hand, I don't think it's a good idea to mix the controllers with the route definitions. How I configure or set up the routes should not be in the controller classes, that should be a separate thing.

It's easier to see all the routes in that file instead of searching for them in the controller, especially as you said, in a moderately sized project, I can't be bothered to search or check the controllers. (You can counter argue that I can just Ctrl+F it). When you open up the routes file, you can see all your definitions in one place, which might ease the onboarding of new devs for example.

Well, I'd still argue it would be cleaner if they're defined at the controller (I would also say the controller does not define them, the controller has them defined as attributes to it's class). Java devs don't seem to have a problem handling the "look for what path this is" either, in reality it's a grep or global search from your IDE away to be found.

The routes file for any moderately sized project will likely be sufficiently complex that you cannot simply Ctrl-F it.

> Being able to write @@Path("/users") over their listUsers function to have it be called when someone accesses the URL "/users" on the host.

That is exactly how Flask works by using Python decorators, example:

    @app.route('/hello')
    def hello_world():
        return 'Hello, World!'

That would let you access /hello in a browser. There's also abstractions in place to prefix URL namespaces to a group of functions and add behaviors too (like requiring authentication).

It's nice, especially when the framework comes with an ability to get a dump of all of your routes / URL endpoints in a single command, along with what function it's associated to and the HTTP method. You end up not missing a single routes file that other frameworks have (Rails, Phoenix, etc.).

People already do that today with annotations in comments, at least with Symfony.

I much prefer the Laravel way, because it's much easier to get an overview of all the routes in an app. With your method you'd have to go through every single file! Most editors have "goto file" functionality, so you can type e.g. Cmd-P, "web", Enter, and be directly in the routes file.

Plenty of frameworks can spit out a list of all routes and some IDEs have tooling for that.

Wouldn’t using annotations for routing require the framework to pre-“require” every single controller though before matching? I haven’t worked with Laravel or Symfony but that seems super inefficient, particularly for sites with hundreds or thousands of controllers. Sure pre-warming exists that’s still a lot of memory.

The router we use, we setup in our bootstrap $router->set(“users”, users/listAll::class); and listAll is then only required when matched. Our controllers also receive a default route based on their namespacing so we only configure them if it varies.

For dev environments, the performance hit would be IMO acceptable, for prod you can generate routes already to not have to parse routes/web.php.

In theory if you have APCu or any other cache setup, you can use that to store routing information outside PHP, or just write it into a file. So only the first access is slow, then no longer and you can still manually scan if you can't find a function, controller or if you don't know the file involved.

It would atleast make code a lot cleaner.