[throwanem]

If you want to build a house, go to Home Depot. If you want to buy one and move in, go to a real estate agent. Standing in the middle of Home Depot complaining about how no one there seems to want to talk about about plats or points doesn't seem like a very worthwhile use of time.

There are a large number of projects offering a Rails-style OOTB experience in Node. None of them is blessed as the Node framework. This is because there is no one to do the blessing. Node's developer culture being one you find unsatisfactory is not an example of "resistance". It is an example of difference. And if you do not find the Node style to provide you comfort, there is absolutely no requirement anywhere that you partake of it.

[astrodust]

> There are a great number of projects offering a Rails-style OOTB experience in Node.

Which would these be? Even the best tend to fall far short of the full Rails experience.

> And if you do not find the Node style to provide you comfort, there is absolutely no requirement anywhere that you partake of it.

Translation: "If you don't like it, fuck off."

That's not how the Node community has treated me as long as I've been a part of it. The people I've interacted with are often very welcoming, encouraging and responsible. I'm talking about cultural conventions, not individual attitudes.

The difference is that the Node world is used to things taking time to put together. The Rails world finds this to be unbelievably fussy. Python people from the Django realm are in the middle.

To promote a new way of doing things, like Rails did, is an effort way beyond my singular capability. It will require a lot of like-minded individuals to go "You know, maybe we could make something that wraps around Express and gives you a Rails-like experience for those that want it." and then work towards making that happen.

[throwanem]

> Translation: "If you don't like it, fuck off."

If you like, but that's not what I'm saying. What I'm saying is instead that you're not going to find value in Node the same way you do in Rails, and complaining that Node is not Rails will not change that in the slightest. Neither will approaching Node as though the first thing to do is make sure your project tree contains every piece of functionality your app might ever conceivably need. Gulp, for example, is extremely powerful, but also has an enormous complexity cost. NPM is a task runner, too, and shell scripts can be fine for a surprisingly long while. I'm not sure what led you to think you need Gulp to get to "Hello, World". But part of using Node effectively is understanding that you are, in the end, responsible for the choices of tooling you make. If Gulp seems like more work than necessary to solve a simple problem, it probably is! Think about using something simpler instead. No one will force a choice on you, either in favor of Gulp or against it. The other side of that is that no one will make a choice for you, either. That's on you. If you'd rather it not be, this may not be the toolset for you.

Although, again, there are a lot of seeds and starters. I don't use them myself much, because I already have a battle-hardened stack that's simpler than most of them anyway, but I hear very good things of Sails. I wouldn't expect it to replicate Rails in full, but what I've heard suggests it will get you closer than most. Even here, though, you have to choose; there are no BDFLs and no One Right Way.

I'm not here to suggest a One Right Way, either. I do think the Node style is better in a few ways, not least of which is that, in exchange for paying a higher setup cost up front, you become less likely to run into teething troubles later on, especially in the realms of scaling and keeping the codebase up to date where I've observed Rails very frequently to have major problems. On the other hand, it can be considerably easier to start with Rails, especially if you're unfamiliar with it, and not strongly or at all supported by people who are - precisely because it relieves its user of the responsibility of making choices that user may not yet be prepared or equipped to make.

But all of that is an opinion that I'm having, and opinions certainly do differ. That doesn't gravel me. What does gravel me is seeing someone complain at considerable length about one style because it isn't exactly the same as another. That seems unlikely to produce any especially worthwhile result, either for the one who does it or for his interlocutors.

[astrodust]

I'm not complaining that Node isn't Ruby, or that Express isn't Rails. What I'm saying is that there's an opportunity in the Node space to create something as fast, friendly, and forgiving as Rails is.

The "translation" there is how comments like that are perceived. "Put up or shut up" is not a good way to build community. Yes, obviously we have options, but the amount of commitment it takes to go with some of them is a lot higher, and in many cases needlessly so.

> I'm not sure what led you to think you need Gulp to get to "Hello, World".

If you have a non-trivial plan for what your application is going to do and you're intending to iteratively deploy it then you really do need an asset handling plan. Gulp does a great job of this if you spend the time to configure it correctly. With ~200 lines of configuration I get minification, compression, asset hashing, linting, auto-starting, and more. In some important areas that's ahead of Rails, especially in terms of control.

I'm talking about cultural concerns here, about the experience of someone new trying to build a Node application and needing to cobble this all together themselves. It took me about six months of iterative work to come up with a reasonable environment to build Node + Express apps. It took me two weeks to get settled into Rails back in 2005, and I've walked people through the same process with every version since Rails 1 and it's rarely more than a few days of coaching. This friction is something that's a serious problem and no amount of hand-waving dismissal of "that's just how Node is" will change that.

If you want to bring new people into your platform, into your culture, into your community you should make a better effort to lay out how things can or could be done. It shouldn't involve foraging through blog posts, Stack Overflow answers, and pestering co-workers for snippets of code, assembling a veritable quilt out of them that you pass on to others like some sacred heirloom.

For example, I'm consistently impressed with the quality of the documentation Node projects have, even humble ones with obviously limited appeal. The Ruby world is filled with crusty, opaque code with half-assed documentation that's often wildly out of sync with the shipping version, even for foundational components like Rake, Rack, or Rubygems.

If Node had a softer start for those that wanted it, respecting the culture of being able to pick and choose on a very granular level, I'm sure people would be more productive, use it on more projects, and contribute more back into the community. This is a lost opportunity.

[throwanem]

It's interesting to me that your experience with Rails sounds a whole lot like my experience with Node, and vice versa. Granted, I was able more quickly to become productive in Rails for trivial tasks, but the additional time cost it imposed on nontrivial tasks more than swamped the early gain; while I have also found a knee in the efficiency curve for Node, it goes the other way.

But, in general, "friendly, fast, and forgiving" is exactly how I've always found the Node/Express tooling and ecosystem to be, while Rails has been among the least welcoming stacks I've ever had the displeasure to use - and, to your point about having to commit, in deciding "Rails: never again" I essentially threw away most of a year's worth of professional experience, which was so Rails-specific as to offer nothing useful in any alternate context. That's a choice I'm glad I made, rather than chasing the sunk cost, but if we're going to talk about things that require a lot of commitment, I think we have to talk about that kind of thing, too.

Based on the apparently almost mirror-opposite nature of our experiences with these platforms, I'm inclined to wonder whether the characteristics of either are strongly to blame, or whether instead it's a question of preference, or congruence between personal style and that of the platform, or just good vs. bad first impressions.

Not least to that last point, I do agree that a more reliably findable onboarding experience might be warranted. But it does sort of come down to "put up or shut up", harsh as that may sound; again, without a BDFL or a One Right Way, there is no one to mandate such a thing must be done, and thus, until someone comes along with the knowledge and the passion to do it, that thing does not get done. There's some degree of cost in that, to be sure. But the difference in engagement makes it reasonable to ask whether it's as much of a problem as it might seem.

[tracker1]

I've known several of the main devs behind gulp for some time... and tbh, I switched away from gulp to direct scripts some time ago. If I can run it straight in npm, I'll do that... if I need more, I'll favor running a script in a directory for that purpose. glob, shelljs and mz give you a lot of what you might need. And it's often less code than gulp scripts might be.

An example[1] work in progress boilerplate I've been heading towards as time permits, will probably have it flushed out by the end of next month, including migrating to the latest webpack.

Of course a lot of the reason for options, is there are so many... server rendering, react v angular, angular 1 or 2+, bootstrap or foundation or ??? In the end, it's great in some was and not so much in others. I, like you prefer to have the choice/control.

Frameworks like rails are great at getting you 85-90% of the way to done... but that other 10-15% is so painful, you're often better off with DIY in the long run.

https://github.com/tracker1/react-redux-materialui-boilerpla...