New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove router #262

Closed
tj opened this Issue Apr 22, 2011 · 50 comments

Comments

Projects
None yet
@tj
Member

tj commented Apr 22, 2011

in the 2.x it will most likely be gone, nearly every edit made to this is express specific, so it really belongs in express, it's becoming less and less general each time

@dready92

This comment has been minimized.

Show comment
Hide comment
@dready92

dready92 Apr 26, 2011

Sad news. I use connect & connect router a lot, but don't use express at all. I'll have to maintain the router middleware separately from connect :-(

dready92 commented Apr 26, 2011

Sad news. I use connect & connect router a lot, but don't use express at all. I'll have to maintain the router middleware separately from connect :-(

@wankdanker

This comment has been minimized.

Show comment
Hide comment
@wankdanker

wankdanker Apr 26, 2011

I agree with dready92. This is one of the main features that I use with connect. Seems like a better way to go would be to encourage express to maintain their own router and revert the connect router to something generic and fast. Just my 2 cents. :-)

wankdanker commented Apr 26, 2011

I agree with dready92. This is one of the main features that I use with connect. Seems like a better way to go would be to encourage express to maintain their own router and revert the connect router to something generic and fast. Just my 2 cents. :-)

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Apr 26, 2011

Member

its not slow, and neither is express, it's just doesn't make sense to maintain within connect. Connect was never meant to be used directly, it exists to support frameworks like Express

Member

tj commented Apr 26, 2011

its not slow, and neither is express, it's just doesn't make sense to maintain within connect. Connect was never meant to be used directly, it exists to support frameworks like Express

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Apr 26, 2011

Member

It's one thing to use connect to set up a small file server or something but if you are using the router, you might as well be using express

Member

tj commented Apr 26, 2011

It's one thing to use connect to set up a small file server or something but if you are using the router, you might as well be using express

@wankdanker

This comment has been minimized.

Show comment
Hide comment
@wankdanker

wankdanker Apr 26, 2011

I'm sorry, I didn't mean to imply that anything was slow. :) I just want to understand your point of view: So, if I create my own framework that uses Connect then I should maintain my own router middleware? That's fine with me, I'll just use the current version from connect. I just don't understand why remove a generic feature that could be used by other frameworks who don't have the specific routing needs of Express.

In all honesty, this doesn't really matter to me as I already have the code for it and I'll be able to make my end work without difficulty. And looking at your amount of of commits to Express, I imagine that you are the better judge here. :)

wankdanker commented Apr 26, 2011

I'm sorry, I didn't mean to imply that anything was slow. :) I just want to understand your point of view: So, if I create my own framework that uses Connect then I should maintain my own router middleware? That's fine with me, I'll just use the current version from connect. I just don't understand why remove a generic feature that could be used by other frameworks who don't have the specific routing needs of Express.

In all honesty, this doesn't really matter to me as I already have the code for it and I'll be able to make my end work without difficulty. And looking at your amount of of commits to Express, I imagine that you are the better judge here. :)

@masylum

This comment has been minimized.

Show comment
Hide comment
@masylum

masylum Apr 26, 2011

Someone can create/mantain a repo with a router middleware. It will just don't belong to the core.
TJ will probably maintain his own router middleware on express.

masylum commented Apr 26, 2011

Someone can create/mantain a repo with a router middleware. It will just don't belong to the core.
TJ will probably maintain his own router middleware on express.

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Apr 26, 2011

Member

yeah, it's really sloppy so I'll be rewriting it for express. When we wrote connect it had merit but im not so sure anymore

Member

tj commented Apr 26, 2011

yeah, it's really sloppy so I'll be rewriting it for express. When we wrote connect it had merit but im not so sure anymore

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Apr 26, 2011

Member

but like @masylum said, there is no reason third-party routers could not be used, if anything removing it from core just enforces the fact that connect is a utility framework

Member

tj commented Apr 26, 2011

but like @masylum said, there is no reason third-party routers could not be used, if anything removing it from core just enforces the fact that connect is a utility framework

@dready92

This comment has been minimized.

Show comment
Hide comment
@dready92

dready92 Apr 26, 2011

The main problem I have with express is that it automagically parses POST & PUT bodies, and my application (that allows audio uploading & pipe it to different processing tools) have to access the "data" & "end" events.

Perhaps you can tell me how we tell to express "when having a POST/PUT to this URI don't pre-parse body and let me deal with "data"/"end" events" ?

dready92 commented Apr 26, 2011

The main problem I have with express is that it automagically parses POST & PUT bodies, and my application (that allows audio uploading & pipe it to different processing tools) have to access the "data" & "end" events.

Perhaps you can tell me how we tell to express "when having a POST/PUT to this URI don't pre-parse body and let me deal with "data"/"end" events" ?

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Apr 26, 2011

Member

@dready92 no it doesn't.. people just use bodyParser if they wish, otherwise it is no different than using node only

Member

tj commented Apr 26, 2011

@dready92 no it doesn't.. people just use bodyParser if they wish, otherwise it is no different than using node only

@dready92

This comment has been minimized.

Show comment
Hide comment
@dready92

dready92 Apr 27, 2011

Ah ok so I missed up with my early tests of express... Will reconsider using it when I got some time. Thanks for the info.

dready92 commented Apr 27, 2011

Ah ok so I missed up with my early tests of express... Will reconsider using it when I got some time. Thanks for the info.

@beatgammit

This comment has been minimized.

Show comment
Hide comment
@beatgammit

beatgammit Jun 4, 2011

@visionmedia Why not just take out all of the middleware and make them separate modules? I'm a big fan of small frameworks anyway, and using only what I need is why I use ender on the client instead of jQuery or the like.

If it's an issue of needing access to functions inside connect, then the API should be opened up a little more. I've found myself wanting access to some of the functions there anyway.

beatgammit commented Jun 4, 2011

@visionmedia Why not just take out all of the middleware and make them separate modules? I'm a big fan of small frameworks anyway, and using only what I need is why I use ender on the client instead of jQuery or the like.

If it's an issue of needing access to functions inside connect, then the API should be opened up a little more. I've found myself wanting access to some of the functions there anyway.

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Jun 4, 2011

Member

@beatgammit the core mods are lazy-loaded via getters so there's little reason to do that as far as performance goes but I think it's nice to have a reasonable core set of modules. The questionable ones for me are compiler and router

Member

tj commented Jun 4, 2011

@beatgammit the core mods are lazy-loaded via getters so there's little reason to do that as far as performance goes but I think it's nice to have a reasonable core set of modules. The questionable ones for me are compiler and router

@beatgammit

This comment has been minimized.

Show comment
Hide comment
@beatgammit

beatgammit Jun 4, 2011

@visionmedia Yeah, I don't understand why compiler is in connect, but I really do like router. If I were the one making the decisions, I'd either keep router or strip out all of the middleware.

Even if they were all loaded at server start, the memory usage is negligable. it just seems easier to maintain separate middleware.

If I like one version of a single middleware better than the current one, then I can load that one. I can't do that if they're all part of a framework. I'll have to separate out the middleware I like, publish it, then include it. It just seems simpler to strip everything off and make connect more into a platform than a full framework.

In this regard, connect would be more like ender for the server than a full framework.

beatgammit commented Jun 4, 2011

@visionmedia Yeah, I don't understand why compiler is in connect, but I really do like router. If I were the one making the decisions, I'd either keep router or strip out all of the middleware.

Even if they were all loaded at server start, the memory usage is negligable. it just seems easier to maintain separate middleware.

If I like one version of a single middleware better than the current one, then I can load that one. I can't do that if they're all part of a framework. I'll have to separate out the middleware I like, publish it, then include it. It just seems simpler to strip everything off and make connect more into a platform than a full framework.

In this regard, connect would be more like ender for the server than a full framework.

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Jun 4, 2011

Member

@beatgammit yeah that's the main concern. The middleware that do not have a very distinct and specific functionality are likely to change dramatically so they are not great candidates for core. Compiler scratched an itch but yeah I shouldn't have had it in core, it works fine for basic stuff like sass/less but for more complicated configurations like stylus needs it isn't great.

Member

tj commented Jun 4, 2011

@beatgammit yeah that's the main concern. The middleware that do not have a very distinct and specific functionality are likely to change dramatically so they are not great candidates for core. Compiler scratched an itch but yeah I shouldn't have had it in core, it works fine for basic stuff like sass/less but for more complicated configurations like stylus needs it isn't great.

@TooTallNate

This comment has been minimized.

Show comment
Hide comment
@TooTallNate

TooTallNate Jun 4, 2011

Contributor

@beatgammit, something like stack might be what you're looking for...

Contributor

TooTallNate commented Jun 4, 2011

@beatgammit, something like stack might be what you're looking for...

@beatgammit

This comment has been minimized.

Show comment
Hide comment
@beatgammit

beatgammit Jun 4, 2011

Well, not everybody uses sass/less. It just seems like more of a headache to keep it in than to keep trying to fix it.

So far I'm loving the middleware, and I hardly use any 'third-party' modules, so to that extent connect is great for me. It just seems to me that router is such a core feature that it should be considered standard. If express needs something else, let it do it's own thing. But for me, all I need is a simple resource router. Maybe router could be simplified and just support regular strings and regex? (take out the Sinatra support for example)

@TooTallNate Yeah, I've seen it, but I'm not ready to ditch connect just yet. I may play with it in the future though.

beatgammit commented Jun 4, 2011

Well, not everybody uses sass/less. It just seems like more of a headache to keep it in than to keep trying to fix it.

So far I'm loving the middleware, and I hardly use any 'third-party' modules, so to that extent connect is great for me. It just seems to me that router is such a core feature that it should be considered standard. If express needs something else, let it do it's own thing. But for me, all I need is a simple resource router. Maybe router could be simplified and just support regular strings and regex? (take out the Sinatra support for example)

@TooTallNate Yeah, I've seen it, but I'm not ready to ditch connect just yet. I may play with it in the future though.

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Jun 4, 2011

Member

@beatgammit exactly, I'm not disagreeing with that at all, though some fundamentals have a good home in core IMO, such as session, basicAuth, logger, etc, these are things that with the exception of performance tweaks etc will not be changing much at all. Perhaps I could revert to an older version of the router before I started adding more Express specifics, but again there are sooooo many different ways to deal with routing.

Member

tj commented Jun 4, 2011

@beatgammit exactly, I'm not disagreeing with that at all, though some fundamentals have a good home in core IMO, such as session, basicAuth, logger, etc, these are things that with the exception of performance tweaks etc will not be changing much at all. Perhaps I could revert to an older version of the router before I started adding more Express specifics, but again there are sooooo many different ways to deal with routing.

@beatgammit

This comment has been minimized.

Show comment
Hide comment
@beatgammit

beatgammit Jun 4, 2011

@visionmedia Right, like there are soooo many different ways to deal with auth, but there's a basicAuth middleware. Why not have a basic router middleware?

I like the idea of taking everything out except what is necessary for a basic, functional server (like basic SSL and static file handling) and open the API more. Those two don't change. Everything else is just "nice to have", so they would make more sense as separate modules anyway.

beatgammit commented Jun 4, 2011

@visionmedia Right, like there are soooo many different ways to deal with auth, but there's a basicAuth middleware. Why not have a basic router middleware?

I like the idea of taking everything out except what is necessary for a basic, functional server (like basic SSL and static file handling) and open the API more. Those two don't change. Everything else is just "nice to have", so they would make more sense as separate modules anyway.

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Jun 4, 2011

Member

@beatgammit yes... but basic auth is definitive, other methods like digest belong here as well, we just need small, common, maintainable and crucial portions in core, routing is much more opinionated.

Member

tj commented Jun 4, 2011

@beatgammit yes... but basic auth is definitive, other methods like digest belong here as well, we just need small, common, maintainable and crucial portions in core, routing is much more opinionated.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 18, 2011

If the router is to remain in the core, it should be completely decoupled from Express. It should be generic, fast, and simple, leaving room for more robust 3rd party routers focused on more specific use cases.

I use Connect and I'm extremely grateful for all the functionality it offers, and I don't have the prerogative to speak on Connect's direction as a project but IMHO, Connect's greatest contribution is the idea of server middleware. I think the project should be focused on extending and perfecting the middleware API and encouraging 3rd parties to develop and maintain the bulkier modules like the router.

ghost commented Jul 18, 2011

If the router is to remain in the core, it should be completely decoupled from Express. It should be generic, fast, and simple, leaving room for more robust 3rd party routers focused on more specific use cases.

I use Connect and I'm extremely grateful for all the functionality it offers, and I don't have the prerogative to speak on Connect's direction as a project but IMHO, Connect's greatest contribution is the idea of server middleware. I think the project should be focused on extending and perfecting the middleware API and encouraging 3rd parties to develop and maintain the bulkier modules like the router.

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Jul 18, 2011

Member

@dreamdust yeah, that's the issue, it was getting very Express specific, it has been moved to Express and extended, so the one remaining should either be removed entirely or dumbed down for simple use. Even then I'm not a huge fan because it promotes less modular middleware, I'd like to remove it but I wanted to see if any of the auth middleware use it first

Member

tj commented Jul 18, 2011

@dreamdust yeah, that's the issue, it was getting very Express specific, it has been moved to Express and extended, so the one remaining should either be removed entirely or dumbed down for simple use. Even then I'm not a huge fan because it promotes less modular middleware, I'd like to remove it but I wanted to see if any of the auth middleware use it first

@tj tj closed this in 2ca7ec3 Aug 19, 2011

@clyfe

This comment has been minimized.

Show comment
Hide comment
@clyfe

clyfe Aug 29, 2011

We need a generic Router standalone package that can be reused across projects.
For example in Rails land the generic router part was extracted into Rack-mount https://github.com/josh/rack-mount .
It would also be nice to be able to generates a route condition from identifiers or significant keys (as in urlFor, the reverse of routing, in rack-mount it's called #generate). I'm pondering on how to do that for my (future) sugar_cube framework:

https://github.com/clyfe/tweet_express/blob/master/lib/sugar_cube/router.coffee#L71

trying to steal from Rack-mount but the code is pretty complicated parsing regexes and such.

clyfe commented Aug 29, 2011

We need a generic Router standalone package that can be reused across projects.
For example in Rails land the generic router part was extracted into Rack-mount https://github.com/josh/rack-mount .
It would also be nice to be able to generates a route condition from identifiers or significant keys (as in urlFor, the reverse of routing, in rack-mount it's called #generate). I'm pondering on how to do that for my (future) sugar_cube framework:

https://github.com/clyfe/tweet_express/blob/master/lib/sugar_cube/router.coffee#L71

trying to steal from Rack-mount but the code is pretty complicated parsing regexes and such.

@DamonOehlman

This comment has been minimized.

Show comment
Hide comment
@DamonOehlman

DamonOehlman Sep 19, 2011

Hey All,

If someone else isn't creating a standalone router, then I'm probably going to take it on. Placeholder project created here and I'm going to do some work on it tonight.

https://github.com/DamonOehlman/connectables

I haven't come from a Ruby background so it may not be a perfect likeness of Ruby Rack middleware, but I'll do my best and given I've used the router in both connect and express I think it should go close. Plus I don't

If someone else is already working on something, then I'd love to know sooner rather than later...

Cheers,
Damon.

DamonOehlman commented Sep 19, 2011

Hey All,

If someone else isn't creating a standalone router, then I'm probably going to take it on. Placeholder project created here and I'm going to do some work on it tonight.

https://github.com/DamonOehlman/connectables

I haven't come from a Ruby background so it may not be a perfect likeness of Ruby Rack middleware, but I'll do my best and given I've used the router in both connect and express I think it should go close. Plus I don't

If someone else is already working on something, then I'd love to know sooner rather than later...

Cheers,
Damon.

@clyfe

This comment has been minimized.

Show comment
Hide comment
@clyfe

clyfe Sep 19, 2011

Hey, I'm struggling for about 2 weeks to write some extensions to the Express router, namly related to url generation (that is create a url string given some segmens).

I have gathered here: https://github.com/clyfe/tweet_express/wiki/TODO some projects that already do this (but not sure how "good" they do it), and some nice articles. Not sure how close our goals are, but I'll try to help.

clyfe commented Sep 19, 2011

Hey, I'm struggling for about 2 weeks to write some extensions to the Express router, namly related to url generation (that is create a url string given some segmens).

I have gathered here: https://github.com/clyfe/tweet_express/wiki/TODO some projects that already do this (but not sure how "good" they do it), and some nice articles. Not sure how close our goals are, but I'll try to help.

@DamonOehlman

This comment has been minimized.

Show comment
Hide comment
@DamonOehlman

DamonOehlman Sep 19, 2011

Thanks for the link to that page - having a look over it now. My intended approach was to use Sinatra routing as the basis for what I did and work from there.

DamonOehlman commented Sep 19, 2011

Thanks for the link to that page - having a look over it now. My intended approach was to use Sinatra routing as the basis for what I did and work from there.

@clyfe

This comment has been minimized.

Show comment
Hide comment
@clyfe

clyfe Sep 19, 2011

I would say that there are many routers more or less Sinatra-like https://github.com/joyent/node/wiki/modules#wiki-web-frameworks-routers . What's missing is the equivalent of ruby's rack-mount https://github.com/josh/rack-mount

clyfe commented Sep 19, 2011

I would say that there are many routers more or less Sinatra-like https://github.com/joyent/node/wiki/modules#wiki-web-frameworks-routers . What's missing is the equivalent of ruby's rack-mount https://github.com/josh/rack-mount

@DamonOehlman

This comment has been minimized.

Show comment
Hide comment
@DamonOehlman

DamonOehlman Sep 19, 2011

Cool, thanks again for the info. From having a quick look I'd say escort goes close to being a reasonable replacement, but uses slightly different syntax.

I'll try and get an understanding of the way rack-mount behaves. I think I get the overall gist of it, which I have to admit would be useful in things I have been doing with connect (i.e. dynamically generating routes post initial configuration).

DamonOehlman commented Sep 19, 2011

Cool, thanks again for the info. From having a quick look I'd say escort goes close to being a reasonable replacement, but uses slightly different syntax.

I'll try and get an understanding of the way rack-mount behaves. I think I get the overall gist of it, which I have to admit would be useful in things I have been doing with connect (i.e. dynamically generating routes post initial configuration).

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 19, 2011

Member

IMO url generation can be as simple as adding helpers:

exports.user_url = function(id){ return '/users/' + id }

not something I personally like to over-complicate. I usually dont use them at all, unless you don't design your urls well and plan on changing them often, certainly not worth making routes more difficult to read

Member

tj commented Sep 19, 2011

IMO url generation can be as simple as adding helpers:

exports.user_url = function(id){ return '/users/' + id }

not something I personally like to over-complicate. I usually dont use them at all, unless you don't design your urls well and plan on changing them often, certainly not worth making routes more difficult to read

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Sep 19, 2011

There's https://github.com/caolan/dispatch. Maybe you can get in touch with the author and take it over, seems like it was abandoned.

I'm building a framework leveraging Connect, Socket.IO, and jQuery, and my router is very similar to rack-mount. It's just another piece of middleware, so maybe I'll spin that off and put it up here.

ghost commented Sep 19, 2011

There's https://github.com/caolan/dispatch. Maybe you can get in touch with the author and take it over, seems like it was abandoned.

I'm building a framework leveraging Connect, Socket.IO, and jQuery, and my router is very similar to rack-mount. It's just another piece of middleware, so maybe I'll spin that off and put it up here.

@DamonOehlman

This comment has been minimized.

Show comment
Hide comment
@DamonOehlman

DamonOehlman Sep 19, 2011

I had a look at dispatch, and while I liked the general approach, I have become quite accustomed to the way the connect router works, so I guess I'm keen to preserve that syntax.

At any rate, I've made a few final tweaks to the first cut of my replacement router this morning and pushed the code up:

https://github.com/DamonOehlman/connectables/blob/master/lib/router.js

I'm sure there are lots of things it doesn't do but its a start for what I need. I'll go about putting together a readme for the repo now...

DamonOehlman commented Sep 19, 2011

I had a look at dispatch, and while I liked the general approach, I have become quite accustomed to the way the connect router works, so I guess I'm keen to preserve that syntax.

At any rate, I've made a few final tweaks to the first cut of my replacement router this morning and pushed the code up:

https://github.com/DamonOehlman/connectables/blob/master/lib/router.js

I'm sure there are lots of things it doesn't do but its a start for what I need. I'll go about putting together a readme for the repo now...

@kainosnoema

This comment has been minimized.

Show comment
Hide comment
@kainosnoema

kainosnoema Sep 20, 2011

How'd I miss this? Too bad... the elegantly simple router was one of the primary reasons we use Connect for our API endpoint. Express is too much, all we're doing is routing requests to our backend services. Time to look for something else I guess.

kainosnoema commented Sep 20, 2011

How'd I miss this? Too bad... the elegantly simple router was one of the primary reasons we use Connect for our API endpoint. Express is too much, all we're doing is routing requests to our backend services. Time to look for something else I guess.

@DamonOehlman

This comment has been minimized.

Show comment
Hide comment
@DamonOehlman

DamonOehlman Sep 20, 2011

Agreed. Basically, I was hunting through the master repo wanting to investigate the internals of the router and well couldn't find it. Then searched for issues and found this...

DamonOehlman commented Sep 20, 2011

Agreed. Basically, I was hunting through the master repo wanting to investigate the internals of the router and well couldn't find it. Then searched for issues and found this...

@kainosnoema

This comment has been minimized.

Show comment
Hide comment
@kainosnoema

kainosnoema Sep 20, 2011

@DamonOehlman I like where you're going with connectables, but we need most of what the Connect router provided (optional params as well). Is there any reason you couldn't start with the old Connect router code and go from there? If we can't find a good replacement, we'll probably just split our own project off based on that, as I don't see any good alternatives.

kainosnoema commented Sep 20, 2011

@DamonOehlman I like where you're going with connectables, but we need most of what the Connect router provided (optional params as well). Is there any reason you couldn't start with the old Connect router code and go from there? If we can't find a good replacement, we'll probably just split our own project off based on that, as I don't see any good alternatives.

@DamonOehlman

This comment has been minimized.

Show comment
Hide comment
@DamonOehlman

DamonOehlman Sep 20, 2011

@kainosnoema Optional params should work, I'm definitely using them. Maybe raise an issue against the connectables repo for your specific case and I'll take a look. The readme doesn't have an example, but they do work. I'll add an example now.

The only reason that I didn't spin off the connect router (which I did have a look at) was due to @visionmedia 's own comments pointing to the fact that he felt it should be re-written. I'm all for using existing code, but if the author reckons it needs a redo, I generally won't use it...

DamonOehlman commented Sep 20, 2011

@kainosnoema Optional params should work, I'm definitely using them. Maybe raise an issue against the connectables repo for your specific case and I'll take a look. The readme doesn't have an example, but they do work. I'll add an example now.

The only reason that I didn't spin off the connect router (which I did have a look at) was due to @visionmedia 's own comments pointing to the fact that he felt it should be re-written. I'm all for using existing code, but if the author reckons it needs a redo, I generally won't use it...

@kainosnoema

This comment has been minimized.

Show comment
Hide comment
@kainosnoema

kainosnoema Sep 20, 2011

@DamonOehlman gotcha. Sorry, just took a glance at the Readme and it mentioned optional params were still in the works. I'll move this conversation over there now. Thanks!

kainosnoema commented Sep 20, 2011

@DamonOehlman gotcha. Sorry, just took a glance at the Readme and it mentioned optional params were still in the works. I'll move this conversation over there now. Thanks!

@DamonOehlman

This comment has been minimized.

Show comment
Hide comment
@DamonOehlman

DamonOehlman Sep 20, 2011

Cool :) Also, I've updated the readme to include the optional parameters example...

DamonOehlman commented Sep 20, 2011

Cool :) Also, I've updated the readme to include the optional parameters example...

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 21, 2011

Member

If you're doing routing like that, use Express, there's little reason not to, it's not slower, it's not more complex than the old connect router, because it used to use the old router haha, very very naive comments...

Member

tj commented Sep 21, 2011

If you're doing routing like that, use Express, there's little reason not to, it's not slower, it's not more complex than the old connect router, because it used to use the old router haha, very very naive comments...

@DamonOehlman

This comment has been minimized.

Show comment
Hide comment
@DamonOehlman

DamonOehlman Sep 21, 2011

@visionmedia I will definitely have a more in depth look at Express. I'm not sure though that I'm quite ready to add express in as a dependency for my project. While it may seem naive, there are definitely some of us who feel more comfortable with connect as a dependency than express.

I will admit once you dive into the dependencies though you aren't talking about a lot of difference so I can understand your perspective.

DamonOehlman commented Sep 21, 2011

@visionmedia I will definitely have a more in depth look at Express. I'm not sure though that I'm quite ready to add express in as a dependency for my project. While it may seem naive, there are definitely some of us who feel more comfortable with connect as a dependency than express.

I will admit once you dive into the dependencies though you aren't talking about a lot of difference so I can understand your perspective.

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 21, 2011

Member

yeah I mean if the argument is having less deps, then you might as well bundle everything into node core and call it a day. Being comfortable with something sure, but that doesn't mean it's the "right" tool for the job, Connect is an abstraction layer, most of which originated in Express anyway, so they co-exist quite well and Express is much nicer for web services, without adding a lot of complexity.

Connect is for building frameworks, not apps. Much like you could write an app with Rack directly, you never (very rarely) would. The new Express router evolved from what was in Connect (which ported from Express to Connect originally haha..), the functionality is very similar, though it's written in a maintainable way now, and provides additional functionality that connect.router did not.

Member

tj commented Sep 21, 2011

yeah I mean if the argument is having less deps, then you might as well bundle everything into node core and call it a day. Being comfortable with something sure, but that doesn't mean it's the "right" tool for the job, Connect is an abstraction layer, most of which originated in Express anyway, so they co-exist quite well and Express is much nicer for web services, without adding a lot of complexity.

Connect is for building frameworks, not apps. Much like you could write an app with Rack directly, you never (very rarely) would. The new Express router evolved from what was in Connect (which ported from Express to Connect originally haha..), the functionality is very similar, though it's written in a maintainable way now, and provides additional functionality that connect.router did not.

@kainosnoema

This comment has been minimized.

Show comment
Hide comment
@kainosnoema

kainosnoema Sep 21, 2011

Connect may have evolved into a tool for building frameworks, which makes a lot of sense (definitely well suited for it), but I don't think it was originally "advertised" as such? What drew us to it was its simplicity, and it fit our use case perfectly. Sorry to sound naive, but I think you misunderstood my comments. I wasn't implying that the Express router was in any way slower or more complex than Connect's, just that we didn't need Express—we've got an extremely lightweight network service (just a couple pieces of middleware) that mostly just proxies to other backend services (neither "framework" or "app" really). Back when it included the Express router, Connect was definitely the right tool for the job.

At this point, it doesn't really matter whether we switch to Express or use a separate router, its not a big deal really. I just wasn't expecting to see it dropped from Connect. Again though, I understand the motivation for a clear separation of focus between the two projects. It makes a lot of sense. They're both really great projects, and we'll still be using them!

kainosnoema commented Sep 21, 2011

Connect may have evolved into a tool for building frameworks, which makes a lot of sense (definitely well suited for it), but I don't think it was originally "advertised" as such? What drew us to it was its simplicity, and it fit our use case perfectly. Sorry to sound naive, but I think you misunderstood my comments. I wasn't implying that the Express router was in any way slower or more complex than Connect's, just that we didn't need Express—we've got an extremely lightweight network service (just a couple pieces of middleware) that mostly just proxies to other backend services (neither "framework" or "app" really). Back when it included the Express router, Connect was definitely the right tool for the job.

At this point, it doesn't really matter whether we switch to Express or use a separate router, its not a big deal really. I just wasn't expecting to see it dropped from Connect. Again though, I understand the motivation for a clear separation of focus between the two projects. It makes a lot of sense. They're both really great projects, and we'll still be using them!

@contra

This comment has been minimized.

Show comment
Hide comment
@contra

contra Sep 21, 2011

I think it might be a little arrogant to assume everybody wants to use Express. Just my opinion.

contra commented Sep 21, 2011

I think it might be a little arrogant to assume everybody wants to use Express. Just my opinion.

@chjj

This comment has been minimized.

Show comment
Hide comment
@chjj

chjj Sep 21, 2011

I think it might be a little arrogant to assume everybody wants to use Express. Just my opinion.

That doesn't strike me as arrogant, seeing as they're already using connect, which is developed by the same people/person.

Anyway, if that's you're opinion, you should be happy that this change happened: maybe not everyone wants to use the express router and instead wants to build their own library on top of connect, using whatever router they want to design.

chjj commented Sep 21, 2011

I think it might be a little arrogant to assume everybody wants to use Express. Just my opinion.

That doesn't strike me as arrogant, seeing as they're already using connect, which is developed by the same people/person.

Anyway, if that's you're opinion, you should be happy that this change happened: maybe not everyone wants to use the express router and instead wants to build their own library on top of connect, using whatever router they want to design.

@contra

This comment has been minimized.

Show comment
Hide comment
@contra

contra Sep 21, 2011

@chjj - My point being that not everyone wants to use ALL of Express. I don't use Express so I'm probably talking out of my ass right now but it seems a little strange to remove functionality people clearly use and tell them to use something else

contra commented Sep 21, 2011

@chjj - My point being that not everyone wants to use ALL of Express. I don't use Express so I'm probably talking out of my ass right now but it seems a little strange to remove functionality people clearly use and tell them to use something else

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 21, 2011

Member

That was the original point of Connect yes, I've been with it since day one.

Yeah exactly what @chjj said, people seem happy enough to use the Express router, and yet they fear the "large and massive" Express haha, even though it's essentially just slightly larger tool with more sugar to make common things less of a PITA.

@contra I'm not saying you have to use Express, I'm saying if you're building a web app, or even a web service there's almsot no reason not to. The fact is the routing doesn't belong in Connect core because there are 100+ different ways you can approach routing, and it only existed to support Express in the first place. "All" of express is less code than Connect, but if you prefer to write 4 lines instead of res.redirect(url), or several lines instead of res.json(obj), if you dislike streaming files, http cookies etc then by all means dont use it

Member

tj commented Sep 21, 2011

That was the original point of Connect yes, I've been with it since day one.

Yeah exactly what @chjj said, people seem happy enough to use the Express router, and yet they fear the "large and massive" Express haha, even though it's essentially just slightly larger tool with more sugar to make common things less of a PITA.

@contra I'm not saying you have to use Express, I'm saying if you're building a web app, or even a web service there's almsot no reason not to. The fact is the routing doesn't belong in Connect core because there are 100+ different ways you can approach routing, and it only existed to support Express in the first place. "All" of express is less code than Connect, but if you prefer to write 4 lines instead of res.redirect(url), or several lines instead of res.json(obj), if you dislike streaming files, http cookies etc then by all means dont use it

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 21, 2011

Member

@kainosnoema sure, for things like proxies it's definitely fine, but you most likely wouldn't need a larger opinionated router, so for something like that I think it's fine, but it's still simple enough to switch on a pathname or write a tiny ~50 line router

Member

tj commented Sep 21, 2011

@kainosnoema sure, for things like proxies it's definitely fine, but you most likely wouldn't need a larger opinionated router, so for something like that I think it's fine, but it's still simple enough to switch on a pathname or write a tiny ~50 line router

@kooyeed

This comment has been minimized.

Show comment
Hide comment
@kooyeed

kooyeed Mar 5, 2012

I am so sorry to hear that.My LADY GAGA....

kooyeed commented Mar 5, 2012

I am so sorry to hear that.My LADY GAGA....

@mratzloff

This comment has been minimized.

Show comment
Hide comment
@mratzloff

mratzloff May 31, 2012

Probably want to remove the router examples in mount.js and vhost.js. Was a bit confused until I checked the change log and saw it was removed. :-)

mratzloff commented May 31, 2012

Probably want to remove the router examples in mount.js and vhost.js. Was a bit confused until I checked the change log and saw it was removed. :-)

@footya

This comment has been minimized.

Show comment
Hide comment
@footya

footya Aug 16, 2012

Please update the examples.

footya commented Aug 16, 2012

Please update the examples.

@paulbjensen

This comment has been minimized.

Show comment
Hide comment
@paulbjensen

paulbjensen Jan 18, 2013

For those wanting to use router with connect, I recommend having a look at this npm module: https://github.com/baryshev/connect-route

paulbjensen commented Jan 18, 2013

For those wanting to use router with connect, I recommend having a look at this npm module: https://github.com/baryshev/connect-route

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment