
Why is routing so complex? - debbar
https://medium.com/@mdebbar/why-is-routing-so-complex-fd1b316cda23
======
erikpukinskis
The whole notion of putting all of the routes in a single file strikes me as
questionable. I think Express has it right, define the route along with the
code that's going to run on it. If you want to see all of your routes
together, just have some kind of dumpRoutes() call that you can make.

And I don't believe we're saving ourselves any real complexity by creating
standardized API for prefixes and such. The cost of having to type /posts/new
and /posts/favorite seems like a small price to pay for a dramatic improvement
in clarity and decrease in router complexity.

Some programmers take DRY way too far.

~~~
maxdeviant
React Router v4 places a greater emphasis on splitting up your routes, as
opposed to keeping them all in one spot [1].

It also allows you to do really cool stuff like in their recursive routing
example [2].

[1]: [https://react-router.now.sh/basic](https://react-router.now.sh/basic)

[2]: [https://react-router.now.sh/recursive-paths](https://react-
router.now.sh/recursive-paths)

------
arkitaip
Why do we insist on optimizing our config files for machines first and humans
last? Why not the other way around? Because I'm seeing a lot of boilerplate
and unnecessarily complex constructs.

~~~
debbar
That's exactly my point @arkitaip :)

------
iamleppert
I've always favored express.js style routes. Simple, pragmatic, flexible, and
run in the order in which they are declared. Internally they are just
represented as an array of regex's.

For client side routing, I use page
([https://www.npmjs.com/package/page](https://www.npmjs.com/package/page)),
which is a tiny client-side router that supports pushState and has an almost
identical API as express.

There are lots of people and frameworks who try to overcomplicate this problem
when its really just another pattern of inversion of control.

~~~
debbar
Express is definitely better than the others. But I still think it has a
bloated API that's not strictly necessary. For example, you still have to
learn about the gazillion methods on the Response object. Why not simply
return a POJO response object: `{ headers: [...], body: '...' }` ? And if it
needs to be async, we could return a promise that resolves to a simple
response object.

This is the first time I'm hearing about `page`. I'll check it out.

