4 ms·

Why is routing so complex?

9 points by debbar 10y ago

erikpukinskis 10y ago
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 10y ago
  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 10y ago
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 10y ago
  That's exactly my point @arkitaip :)
iamleppert 10y ago
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 10y ago
  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.

9 points by debbar 10y ago

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 10y ago
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 10y ago

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 10y ago
That's exactly my point @arkitaip :)

iamleppert 10y ago

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 10y ago
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.