Live data from Hacker News

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

quora.com

81–90 of 135 posts

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

#81

Earlier quoted context omitted.

Node is like walking into a Home Depot when you want a house. Technically you can build one out of the bits they can provide, but it's a ton of work. The thing is Node could offer the Rails out-of-the-box experience through a package that provided sane defaults. There's nothing preventing people from doing this but cultural resistance.

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 i…

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

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

#82
post #79

Earlier quoted context omitted.

Node is like walking into a Home Depot when you want a house. Technically you can build one out of the bits they can provide, but it's a ton of work. The thing is Node could offer the Rails out-of-the-box experience through a package that provided sane defaults. There's nothing preventing people from doing this but cultural resistance.

People do this, Node isn't a framework. Walmart labs has contributed some great out-of-the-box, with hapi.js and now http://www.electrode.io/

I'm not saying Node is or should be a framework, but that Node itself lacks frameworks that do what Rails does.

Those are good examples of steering in the right direction, but it's still a long way off.

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

#83
> You get to use Ruby, which [...] remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter.

I've used Ruby sporadically as gap-fill in small projects, but I didn't feel the language has any qualities that sets it apart from others.

Perhaps I missed something, any Ruby devs care to comment?

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

#84
post #53
post #44

Earlier quoted context omitted.

I am a rails dev. I inherited a legacy application. The biggest problem with Ruby/Rails is that anything Ruby will allow, someone will do. Ruby is the language I learned data structures and algorithms in, built my first significant projects in. It has a generous wealth of helpful builtins. But it makes me long for strictness, static typing, a language where not just anything can completely modify any other.

This. Often, you can't find where this variable or function comes from. You read the sources only to discover that there is no trace of this variable and it is probably defined dynamically in some callback. You can only find this kind of stuff with the help of debugger. The dynamism, which allows one to create beautiful interfaces, and is often advertised as a programmer's friend, is actually the enemy of the program…

I've actually run into methods defined from names concatenated from multiple strings, i.e. methods you can't even use grep over the whole codebase to find. This has left me with a lingering vague fear ever since.

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

#85

Maybe Rails has changed from when I last used it five years ago, but I dealt with many of the issues DHH makes against other technology. > That people spent hours, if not days, just setting up the skeletons. The basic build configurations. I spent hours everyday getting the asset pipeline to work, or it would break again, meaning I would have to fix it again. > The vast majority of activity today is for yet another o…

For many years I tried to install Rails in my computer and it just refused to play well with the installation of MySQL on my Mac. I looked on SO and tried some CLI commands and configurations that I could barely understand for a couple of hours and then, when nothing worked, I just stopped and went back to CakePHP (which I used to love). I did this like every six months for maybe 5 years and then I became mostly a front end developer and I stopped caring. Nowadays with most of my projects there's somebody providing me with a REST API and I don't care what they are using to generate it.

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

#86

Each user today commands a personal fleet of many devices. "You get to use Ruby" is a weak justification for a monolithic architecture.

Perhaps, but what about this: 1. Easy to deploy 2. Integration tests are a breeze 3. Debugging is a breeze We use a distributed architecture in clojure and python where I work, but it has its own downsides, and for a lot of people monoliths are a much better solution.

There's a separate argument to be had about single process vs multi process backends, but that gets away from the core premise of Rails. Part of that premise included opinions and defaults about client-side development.

Rails was unique in its time in that it shipped with solid client-side DOM manipulation (prototype.js). It supplied a "full-stack" framework that made it easy to build a dynamic, AJAX Ux.

But lately the "best practices" in the node ecosystem move so fast that any default may soon be outdated. What would today's javascript Ux best practice be? Vue.js? React? Angular? Which state management solution is "best" ? Which CSS framework is "best" ?

Any choice you make will be out of date by the time you ship. There's a ton of activity. It's a decision that belongs on the project, not the framework.

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

#87

> You get to use Ruby, which [...] remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter. I've used Ruby sporadically as gap-fill in small projects, but I didn't feel the language has any qualities that sets it apart from others. Perhaps I missed something, any Ruby devs care to comment?

This article might be helpful: https://martinfowler.com/bliki/HumaneInterface.html. I use Ruby occasionally only, but agree with DHH's point. At least compared to the languages I knew before I learned Ruby, I found it to be designed to be aesthetically pleasing to humans. This might be even be the cause for the parse ambiguities.

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

#88
post #76

Earlier quoted context omitted.

Agreed. Would love to see DHH build an opinionated framework for node rather than waxing poetic about Ruby.

This is the first time I've seen someone complain that Ruby is a worse language than JS(ES5). Care to elaborate for those curious?

JS(ES5) runs across a wider range of devices than Ruby. If the core premise is to build a single framework to consolidate all development JS(ES5) is a better run-time to target.

One can argue that Ruby is prettier, but JS can be very good with thoughtful api design.

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

#89
post #75

Earlier quoted context omitted.

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

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.

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.

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

#90

Earlier quoted context omitted.

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 i…

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

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

Post reply on HN