DHH answers: What makes Rails a framework worth learning in 2017?

JS is simply the language that runs in the browser... even with newer options for compiled code coming close to being a reality, it'll be a while before tooling catches up.

JS is actually a decent language, and imho with more recent advancements better still. Combined with npm there is simply anything you might need available (for the most part). Not that there aren't a lot of gems out there.

In the end, having one language to think about, rather than how to shoehorn communications and logic between two languages is simply more difficult. I went, similarly from C# to node, not because I didn't like C#, but because the friction in writing JS on the server and the client was so reduced from two differing languages throughout the day.

Similarly a lot of devs went to simpler data stores so they don't have to deal with layers of ORMs that only half work, and can simply store and query basic data forms. Mongo fits this development model well, early hiccups in the technology aside.

In the end, it allows you to build web apps in one language, and not have to write translations to get from one to the other on the client.

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...

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.

Absolutely agree.

I've helped maintain REST APIs in both Java and NodeJS at different points in time.

Doing so in Java was always a painful iterative process; ask the ORM for data, painstakingly map the data to Java DTOs created mostly for defining JSON structure, pass it off to RESTEasy or some similar framework, see how the JSON turned out. Adjust and repeat until satisfied. Yuck.

In NodeJS, by contrast, fire off the SQL to get the data, map into the JS object that you need and return it.

Kind of funny how, years back, a selling point of GWT was that you could use the same language across the stack. It wasn't a bad idea, just a poor choice of language.

Ok but then we are talking about Java, .NET and JavaScript. They all more or less work on many more devices than Ruby but at some points are so huge and complex and do not perform the same on all of these devices that you still kinda want to pick a specific technology.

Hell Ruby has RubyMotion that allows you to write native apps.