
Node and Express Tips - ianstormtaylor
http://calv.info/node-and-express-tips/
======
drunken_thor
I would also recommend everyone to check out express-on-railway
<https://github.com/1602/express-on-railway> a rails like mvc framework for
node with intuitive design to be adaptable for sockets.

------
mcantelon
Good tips. Another I'd add is using the express-resource module for routing.

<https://github.com/visionmedia/express-resource/>

~~~
calvinfo
Express-resource is cool - I haven't gotten the chance to use it in a project
yet so I can't comment too much on it.

Our app isn't grouped strictly into resources, though it's something we might
be able to benefit from. Currently we use different pieces of middleware to
load whatever items the route needs.

------
nailer
Nice! 'async' is almost essential for me: the 'waterfall' style in particular.
I modularize everything too, but using AMD modules.

\- I move between client and server fairly frequently, and AMD works in both
via RequireJS.

\- I often share code between client and server, eg, my current app has a
shared models module that is augmented by the client and server-specific
modules that import it.

I avoid adding methods by a string for the simple fact that JSHint warns about
using [] rather than . wherever it can (I think the only time I use [] is for
Express' badly named 'static' plugin - 'static' is a reserved word.

Following you on Twitter (I'm @mikemaccana). Hope to catch you about someday!

~~~
calvinfo
Thanks! I haven't been using AMD so much since I've mainly been working on the
server-side js, but it seems like a similar structure.

The shared code between client and server is definitely an interesting
concept. I'd be interested to see some of your posts on how this ends up
working!

------
geuis
If Calvin is reading this thread:

I am sure you are a most upstanding, interesting, and funny fellow. I respect
that you appear to possess a love of hats.

Despite my sincerest regards for your person and well being, I must say that
the UI of your site is somewhat hard to use. I, and others like me, read the
web as much from our small screen devices as we do from our big screens.

Your site, when viewed on an iPhone, has a large overlay at the bottom
containing a photo of you wearing a hat and your name, and it takes up nearly
1/3 of the entire viewable screen. It makes reading the content of your site
uncomfortable, and nigh impossible. This is at least the 2nd article from your
site which I have had to avoid from Hacker News. This is disappointing, since
having made the homepage several times indicates you are someone I might find
interesting. As it stands, I am bereft of being able to discovering your
thoughts and reflecting on them myself.

Please, consider a modification to your UI for those of us who only have small
viewports with which to interact with the world.

~~~
ianstormtaylor
Designer here. Good point about mobile styles! I got frustrated with the media
queries and stopped short of fixing em, but as soon as Calvin pulls now he
should have a more lenient header on small screens.

And you're right, he is a hat connoisseur.

~~~
geuis
Great update Ian. Site is fabulous now. I'm enjoying your article on black.
Thanks!

~~~
ianstormtaylor
thanks man!

------
moocow01
"Instead of including modules by complicated pathing like
require('../../../shared/utils'), it’s much simpler to require('utils'). Utils
can be symlinked from another folder in the source tree so that you can
continue to actively develop it and the changes will be reflected in the
dependent modules."

This sounds like a maintenance nightmare when you start juggling lots of code.

~~~
beck5
Also important to not fall down the hole in a couple of years where these
shared libraries are being used all over the place and changing them becomes
hard. Good to always question if they should be a module or perhaps their own
api.

~~~
nailer
Agreed re: shared libraries being used all over the place, but I don't think
that requires changing a module to an API.

git submodules are designed to solve this problem and do so very well,
allowing each project that uses a shared module to include whatever version it
pleases, yet allowing the project using the shared module to update/rollback
to a newer/older version.

