Skip to content

Instantly share code, notes, and snippets.

@halbgut
Last active August 29, 2015 14:26
Show Gist options
  • Select an option

  • Save halbgut/c6e2355be4ffbb324dc3 to your computer and use it in GitHub Desktop.

Select an option

Save halbgut/c6e2355be4ffbb324dc3 to your computer and use it in GitHub Desktop.
Connect vs. Express for meteor

Should Meteor continue to use connect or should it switch to Express

connect

Pro

  • ~30x smaller than express
  • Separation of concerns Meteor is trying to follow this principle by splitting up the core into different packages. We should do the same in its dependencies.

Con

  • Requires more work when handling HTTP methods This would preferably also be done by a middleware

express

Pro

  • More popular The greater popularity might drive more people to Meteor.
  • Nicer API to handle HTTP-Methods
  • More middlewares written for it

Con

  • Comes with a lot of extra features (view system, router)
  • Extra router could cause confusion Since most Routers written for Meteor also do server-side router, this would be duplicate functionality.
  • A lot of dependencies (~20) Express's many dependencies make quality control hard.

Numbers

  • SLOC: 120 vs. 3'000
  • GH Stars: 5'000 vs. 20'000
  • Age (years): 5 vs. 4
  • Middlewares: 700 vs. 1100 (counted by searching for connect- and express middleware on npm)

My opinion

The points listed above are (mostly) facts. Here's my take on the question:

Connect provides exactly what we need. An discrete, extensible component which handles HTTP requests. Nothing more and nothing less. Express is a nice point for people to start off. You don't have to go through the hassle of evaluating what middlewares/components you need and how they hold up qualitatively. Meteor's use-case is very different. We can easily put the time into evaluating middlewares for it. I believe, the fact that Sencha still actively maintains connect supports this argument.

Another point I raised above, is that of routing. Express comes with a server-side solution. When writing the Meteor core router, the following decision would have to be made: Should we lock our-selfs in to Express's syntax, or should we bake our own solution and leave Express's routing solution lying around. I know that this argument isn't all to strong, but I think it adds to the other two.

There are more middlewares written for Express that for Connect. But relative to their popularity, Connect seems to be better of. Newer might be exclusively written for Express but porting these to Connect is mostly pretty easy. Sometimes it can even be done by simply adding some other middleware (like qs).

TL;DR; I would update connect, integrate more of it's middlewares and provide a nicer API to Connect.

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