There's always the argument of abstraction vs simplicity. I appreciate both and I didn't used to like using routers. But I do use it these days for most of my

There's always the argument of abstraction vs simplicity. I appreciate both and I didn't used to like using routers. But I do use it these days for most of my work. Apps often don't have a physical URL that you could map to in .htaccess like /foo/bar.php. There's only index.php and the appropriate controller/method is executed based on the URL. Of course you could just map .htaccess to something like /index.php?method=foobar instead. But then you're still dealing with a router in your index.php, perhaps a simple switch statement or something. It wouldn't bother me to see this kind of setup but I think having a router is just a bit cleaner. You can also abstract retrieving values from the URL like /account/1234 (obtaining "1234") so that the router does all the parsing and the controller isn't aware of the URL implementation. Perhaps useful for altering URLs later without affecting the controller code. Keeping things separate also can make unit testing somewhat easier as you can substitute the router with a mock object and get your controller to respond to all the variations of user input.