[astrodust]

I should also add it "only" takes me a day because I can crib from a half dozen other Express projects I've created in the past and cherry-pick cut-and-paste parts that I like.

As one example my web app Gulpfile has evolved significantly from the first iteration and it would take multiple days to recreate all of that from scratch.

The Rails Asset Pipeline might be obnoxiously rigid, but at least it works without having to tear your hair out.

[wcarron]

Forgive me, but what apps do you work on that have such a complex and lengthy gulpfile?

[astrodust]

Nothing exotic but even a routine web application can have 150-250 lines of Gulp directives. Zero of this is provided for you.

Each chunk is fairly small, but they add up. You want linting, auto-restart on changes, tests, your various asset chains to compile things correctly, etc.

[wcarron]

Ok, I see your point. I, too, hate writing boilerplate code. But I did three things to resolve this: I built a `config.js` file, which contains the paths to resource files in a more compact format, and is sourced into the gulpfile. I then replaced long path strings with easier to read code.

I also threw my standard gulpfile into a git repo, so if I need it, it's there.

Lastly, I built a yeoman generator. Now, not only is my gulpfile standardized, but I have the rest of my skeleton application built in a matter of minutes. All my favorite libraries/npm modules, custom scss files, basic routing to the standard pages of a simple site, are all built out for me to my preferences while I make a cup of coffee. You can even provide yourself command line flags to determine whether or not to include tests, which preprocessors for html or css you prefer, etc. Really a worthwhile investment.

Write once, utilize many times.

[astrodust]

Tools like Yeoman can help here, but they're also relatively obscure and there's a lot of yak shaving involved in getting them working correctly.

In a sense complaining about this the Node world is like asking fish how they can stand being wet all the time. It's just part of the terrain.

I'm not saying what Node is doing is fundamentally wrong, but that this almost absurd aversion to making decisions for users is sometimes a bad thing.

For example, I'd love to be able to declare dependencies for an NPM module that are open-eneded, like "any one of A, B, or C will do", but like it is with Ruby, Python, etc. you must declare all or none.

I'm not trying to restrict choice, just cover the base condition of when you don't care of providing a sane default.

To a degree Rails has this: The first thing I do in a new project is jettison all the garbage I don't want (see you later turbolinks) and drop in all the things I do want. It's actually just a few lines to manipulate, so I can hardly complain.

In the Node world there's a lot of hand-holding required to get even the most basic application up and running. I can see this getting cut down dramatically if you had things like "npm install express +extras" where there was some way of saying "plus whatever other stuff you think is a good idea", or even an "express-fully-loaded" version of the package that comes with a bunch of stuff out of the box.

I really like Gulp and when configured it gives you an amazing amount of control over your build process. Although the Rails Asset Pipeline system works as a pretty good default out-of-the-box they really should steal some ideas from Gulp on configurability for those occasions where you want to change the default behaviour.

Vinyl.fs (https://github.com/gulpjs/vinyl-fs) is an amazing thing that the Ruby world desperately needs.

[wcarron]

Yup. I think, as you say, it's a part of the terrain of the ecosystem. Could the makers of Express have created a more comprehensive boilerplate that includes things like Helmet, Async, Moment, gulp, etc., etc.? Yeah, and I definitely think it would be a good addition to the community if they had. On the other hand, I do agree with the general sentiment that by forcing you to include the dependencies you desire, the programmer exerts more control over what is in the app, and it forces them to actually understand what they're doing with each package.

In the end it boils down to: Start with a monolith and chisel away the stuff you don't want - RoR, or start with a skeleton and add what you need as you need it.