11 ms·

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

200 points by gavingmiller 10y ago

dharamgollapudi 10y ago
Its DHH, not DDH. Mods, please update the title.
- gavingmiller 10y ago
  corrected - thanks
vcryan 10y ago
It's always important to study history :)
- GavinMcG 10y ago
  Snarky, low-content comments really aren't valued highly here.
meesterdude 10y ago
This reinforces what I see a lot too - people creating yet another XYZ, but rarely I see someone go and create an integrated solution to streamline development processes or make things easier or clearer. There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you, but I want nothing to do with either, and do not have problems that those are meant to solve. I love ruby, and I love rails. DHH regularly sounds the drum of rationality - in a community at large of idealists and extremists. He is the reason I got into programming, and constantly serves to remind me that what I'm doing is, in fact, perfectly fine; and that everyone else puts up with a lot of nonsense for no great reason. There are other frameworks out there, but you'd be hard pressed to find one with a leader that has such a sense of direction and reason for why the framework does what it does, and does not.
- allover 10y ago
  > There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you Can you give examples of the 'lot of vocal people' saying 'you should be doing everything in Go or Angular'? I don't see this. I only hear this kind of black/white sentiment when filtered via junior devs. Experienced devs I know get there are trade-offs. And I don't see anyone on the React/Angular/Vue teams saying that server-sidey Django/Rails/etc. apps are 'wrong'.
  - johnbellone 10y ago
    At least once a week I read comments or a submission about how X should be written in Rust. That's a pretty common occurrence here; if you stay long enough it'll be another language.
    - allover 10y ago
      I've seen a lot of Rust posts on HN lately, but none saying you must ditch mature frameworks like Rails for Rust equivalents (there aren't any yet, and they know that, for one). Where's the evidence for this claim DHH/Rails is the only rational force in a sea of extremists? (Of course the dull reality with real apps is "it's complicated" and most devs are busy grappling with that).
      - ethbro 10y ago
        > Rails for Rust equivalents (there aren't any yet, and they know that, for one) ... Can we please call it Rusty Rails?
    - srssays 10y ago
      Before Rust it was Haskell, before Haskell it was Erlang, and before Erlang it was Lisp.
    - dgfgfdagasdfgfa 10y ago
      Do you have any examples?
currywurst 10y ago
I admire the way DHH writes .. confident and persuasive. However, I'd just like to point out that in the same span of time JavaEE has undergone significant simplification (omakase API standards, anyone ;)) and if you check out the work of Adam Bien, you'll quickly find old myths of bloated memory consumption and fiddly XML configuration debunked. Java is also lucky to have a parallel full-featured stack in the Spring ecosystem. Projects like JHipster do an opinionated take on how to wire things up and take you to quickly to orbit. So basically, I disagree with DHH that there is "Very little activity in integrated solutions."
- dceddia 10y ago
  I took his comment about "very little activity in integrated solutions" to mean "[in the JavaScript world]" but maybe that's not what he meant. I do think that's pretty true of the JS ecosystem though. There are things like Sails, but most of the "new" stuff that comes out is build systems, tools, small libraries, and view libraries. As to why... it's anyone's guess. My guess is that making a full-stack opinionated framework like Rails is a big undertaking, and most people are focused on what they see as "quick wins" -- solutions to the obvious surface-level pains like "npm is slow" and "making forms with React is hard" that can gain traction quickly and rise to stardom on Github. Maybe this is cynical to mention, but fame and recognition (and maybe interesting job offers) seem to be a big driving force behind the constant influx of new and better JS libraries/tools.
  - headcanon 10y ago
    > As to why... it's anyone's guess. I think its because recreating rails in javascript just doesn't make sense in the current ecosystem. Either you are rewriting stuff like express from scratch (and why are you doing that?), or you're building on top of those modules and adding configuration conventions and scripts, in which case, congratulations, you've just written Sails. When Rails first got started, ruby didn't have anything close to the ecosystem that JS enjoys today, so DHH et al. had to write most of the individual components themselves, with the intention of making them all work together. So in my view, its similar to how Humans and Gorillas evolved from a common ancestor, but you won't see Gorillas becoming Human anytime soon.
0xsnowcrash 10y ago
Rails, as any backend system such as Drupal or Symfony, is inevitably a dead end technology. The web is increasingly moving frontend and the system of 2018 onwards will simply be the M in MVC. Note, I'm not saying Rails is not worth learning. I'm just saying it's now the Cobol of web technology.
- eternalvision 10y ago
  Can you provide examples of the move you describe?
- pyrophane 10y ago
  If I read your comment correctly, I believe you are suggesting that backends will provide APIs, which would leave us with the MC in MVC, the controller is still needed to map data structures to API endpoints. My question to you is this: why do you believe that? I think we have all witnessed a growth in popularity in front-end MVC frameworks, but are they the correct solution to all problems?
  - BOBOTWINSTON 10y ago
    Not to mention Rails has an API only generator for new apps now... so this problem is framework destroying 'use case' is solved with a single flag.
  - whyileft 10y ago
    > the controller is still needed to map data structures to API endpoints. I mean, kind of. You don't really need much controller logic most of the time anymore. Last Rails backend I wrote probably involved personally writing a few lines of code here and there. Generally, I'm just pushing a JSON object back and forth. Auth and emails can just be 3rd party. The vast majority of controller type behavior ends up client side at this point. Partly, because its way simpler to scale with you push as much processing to the client as you can. Also, look at something like Firebase or Hoodie as examples of simple stores that require no backend logic. Its not that Rails and Symfony are useless, I use them all the time, its just that they are kind of dated concepts. Heck even Wordpress solves a specific problem on the backend enough to be useful sometimes. That said Drupal at this point is such a dated concept(superseded by things like Rails and Symfony many years ago) that is should no longer be used.
newsat13 10y ago
So, I have seen rails code and I did not fall in love with the code. Instead what I saw just black magic and all sorts of conventions. Reminded me of perl. You have to invest a lot of time knowing all the magic stuff.
- hekker 10y ago
  What's wrong with conventions? It seems to me that code conventions would make code more maintainable.
  - bobbytherobot 10y ago
    newsat13 wasn't complaining about using conventions. newsat13 was complaining about how Rails uses black magic with conventions. I can't speak to Rails, but I've worked in other codebases that used reflection to dynamically attach different pieces of code together. It was hard to trace code because I couldn't do a search for the value being generated nor could I use the static analysis to find the value. I had to manually trace through the whole stack to find the bit of reflection that was generating a value.
    - rhizome 10y ago
      I've never worked in a codebase like that, but in all my years of helping people with Ruby and Rails I've concluded that reflection is a code smell. It's one of those things that is taught in CS and winds up appearing where conventions might not have been immediately apparent, a fallback to training.
- pmontra 10y ago
  There isn't much black magic. Most of it is pretty sane naming conventions which could be OK in any sw project, plus database schema autodiscovery. The bonus is increased maintainability.
  - cies 10y ago
    > The bonus is increased maintainability. It will never have strong-typed discipline though... (sad)
deleted 10y ago
[deleted]
vinhboy 10y ago
> formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application Maybe I've drank the kool-aid too much, but I agree with this whole-heartedly. It reminds me of when I want to paint a room. I can go to Home Depot and spend an hour picking out all the tools I need, or I can buy one of those pre-packed toolkit and get to the actual painting immediately. Rails + Heroku = My product will be ready to demo by end of the week. Obviously this mentality only applies to people like me who wants to get things done quickly. People who value craftsmanship and specificity should do what pleases them. (That's not to say you can't do quality work with pre-packed toolkits)
- astrodust 10y ago
  In the last few months I've built a brand new Node + Express application, and I've built a brand new Rails 5.x one. ES6 has taken the edge off of some of the more obnoxious parts of JavaScript, but it still has a long way to go to catch up to Ruby, and Express is a cheap imitation of Rails. It takes me over a day to get an Express application up and running. There's dozens of dependencies to wrangle into place. There's hundreds of lines of code to sketch in even the most basic of applications. So many directories to create, so many new files you have to basically build by hand. There's Gulpfiles to configure. There's a lot of work to integrate Passport. It's a lot of work to get as far as "Hello, world". Meanwhile rails new and some Gemfile dependencies get you almost all the way there within an hour. Then you're making database migrations and laying in CSS and layouts. I love both Node and Ruby for different reasons, but the out-of-the-box experience for Express is total garbage. You can't even parse a cookie without installing a module for that. Node is way easier to create real-time services, like a Socket.io server in JavaScript is way less fuss than Ruby+EventMachine. It absolutely kills it when writing thin JSON APIs, and in terms of performance it's ridiculous. There's nothing preventing Node from having a Rails-like easy start for web applications but the attitude of the community where making decisions for people and having sane defaults is apparently against the rules.
  - tcfunk 10y ago
    > It takes me over a day to get an Express application up and running. I feel so much better after seeing this sentiment here. I've tried to dip my toe into the node.js world repeatedly only to feel like I'm trudging through setup for hours. Of course I may have incorrect memories of how difficult/easy it was to set up my first rails app however long ago.
patsplat 10y ago
Each user today commands a personal fleet of many devices. "You get to use Ruby" is a weak justification for a monolithic architecture.
- jrs95 10y ago
  He considers the monolithic architecture to be an advantage: https://m.signalvnoise.com/the-majestic-monolith-29166d022228 https://m.signalvnoise.com/the-majestic-monolith-29166d02222...
  - patsplat 10y ago
    Agree with your comment, but am not sure there is a more potent monolith than AWS or GCP.
  - patsplat 10y ago
    If he really believed that, then the thing todo would be to re-write rails to run on top of node. Then he'd have a runtime that spanned nearly every possible use case and device. Sticking with Ruby betrays that aesthetics are really the core premise of Rails, rather than aspirations of being the one framework to link all run times and in the darkness bind them. Frankly, node needs such a framework.
    - cutler 10y ago
      Why on earth is Node considered the default for concurrency with its shitty single-threaded callback execution model? Anyone switching from Rails for improved concurrency would surely be better advised to choose Elixir?
      - patsplat 10y ago
        Was referencing the run-time's viability on devices as small as a Beagle Bone micro controller, a mobile app, up to a backend service, etc. There's an attractive opportunity for code reuse. Have a preference for process pools over thread pools so don't mind the execution model. Would not be surprised that some applications are better served by other backends like akka etc. Elixir is on my list to learn. That does of course play into the position that a great "full stack" framework is a thing of the past.
eranation 10y ago
I completely agree on one aspect, anywhere I go, the kitchen sink is missing. You want to compress responses? well, there is an npm / jar / pip library for that. Want to have ORM? just npm / pip / "your package manager here" and you are done. You can say a lot about Rails but I like the idea that everything I commonly need as a web developer is most likely already in the framework, and there is usually a best practice way to do things. Options are great, but moving out of plumbing and into generating value to customers is still having a value. If you don't like opinionated, batteries included solutions then Rails is not for you. However there are other solutions that kind-of cloned some aspects of Rails. Playframework (Scala has a lot more similarities to Ruby IMHO than to Java, at least in philosophy). Also Spring Boot or JHipster (Spring boot + Yeoman - super opinionated)
elcapitan 10y ago
Rails has become so much more enjoyable since all the hipsters left for node.js. [What makes Rails a framwork worth learning in 2017]
Glyptodon 10y ago
The only thing I'd really take much issue with is the "provides great defaults" statement made in passing. There are several things that are defaulted more to what I'd call "lowest common denominator" than "great." For example, sessions.
- patsplat 10y ago
  This a great point that gets to the heart of the problem with the premise of a full-stack framework. Defaults end up more "good enough" rather than "great"
  - Daishiman 10y ago
    But a collection of consistently good enough components is better than tying together two dozen different things of wildly different quality and conventions. I hear this a lot about Django. The ORM is really good but "not as good as SQLAlchemy". The templates are great but "Jinja is better". The thing is that as an engineer I value that the components are incremental improvements with sane defaults where change is deliberate and the benefits of what I'm missing out on are truly, honestly irrelevant. There's really very few times where I said to myself, "Oh of only my templating language had better support for these idioms". I just write a decent workaround because I've been using the same tool for years and it's maintainable and the total number of workarounds is so small that there are no good reasons to switch to an alternative even in the long term. This is much better than the alternative of looking for 5 alternatives for the same component, discarding the first 3, using one for a month until I find it has fatal flaws, and finally settling for the last one.
    - patsplat 10y ago
      Once one critical component in the framework is no longer good enough it can be very difficult to upgrade. Frameworks aggregate many dependencies. Managing the dependencies that deliver value while ignoring those that are irrelevant can net out as more productive.
horsecaptin 10y ago
Ember.js attempts to do what the front-end what Rails has done for server-side application development. Worth a look, if you're trying to choose between React / Angular / something else.
rco8786 10y ago
What does Ruby have to do with immutability
- wrsh07 10y ago
  Let's consider the quote: > You get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter. He's saying there are other beautiful paradigms - especially of the FP variety. However, Ruby is really, really damn elegant. And he's right; it's a joy. [I say as a C++ dev]
- cies 10y ago
  ".freeze" :) it's all runtime baby, love it (at least accept it), or move on
mountaineer 10y ago
DHH also answers a few other questions about Ruby and Rails in the same Q&A https://www.quora.com/session/David-Heinemeier-Hansson/1?srid=pvwn&share=1 https://www.quora.com/session/David-Heinemeier-Hansson/1?sri...
bobbytherobot 10y ago
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 option on the a la carte menu. Every week the developers want to switch out some module for another module within Rails because it was the hot new thing. Maybe I worked on a bad project. Maybe I didn't get it. Maybe it was a growing pain that has passed. Rails was a pain in the ass to get to work. The ORM was cool, but did it save me time or mistakes from writing SQL - no. I would love other people's opinions who have stuck with Rails.
- deedubaya 10y ago
  > I spent hours everyday getting the asset pipeline to work, or it would break again, meaning I would have to fix it again. I used to have this problem too -- more so in the early days of asset pipeline. Mostly when trying to use some client side framework. Rails is working on (or maybe already available, I'm not sure) yarn/webpack support. > Every week the developers want to switch out some module for another module within Rails because it was the hot new thing. Replacing the batteries which are included can be painful at times. If you want to use the new hotness in Rails, it comes at a price of extra work getting it working... but it only seems painful when comparing to the included batteries -- they just work. Support for different test frameworks, orms, templating languages are pretty good anymore though and are easier to swap out. You'll definitely have a better experience with Rails if you forego the desire to run the latest and greatest and just use what Rails already has.
  - throwanem 10y ago
    Until a new point release comes out and everyone forgets about the one you're running. Then you get to find out how much of your code you'll need to rewrite so it'll run with the Rails chefs' wild new menu. And there's no point even trying with an app written for an earlier major version. Just give up now, because the whole ocean's been boiled and recondensed since then, and now occupies but few of the basins it once did. Granted, it's been a couple years since I dealt with any Rails apps. That's in large part by design, because every Rails app has a relatively high curation cost just to keep it up to date with the latest and greatest, and you have to do that if you want to be able to add features or usefully maintain anything without undue agony, because the Rails community has the collective memory of a goldfish and even less interest in maintaining continuity with the past. I get that that's the big selling point, the drum DHH and his fans never stop beating: "Rails is omakase." This is a fundamentally broken metaphor, because sushi is dead by the time it gets to you, and all you have to do with it is eat it; the history of the ingredients is of little consequence. Would that software were so simple.
mark_l_watson 10y ago
I have been thinking of rails lately. I used both Rails and Merb way back when, but for many years now I have just used Ruby + Sinatra. I wish that I had a more complex web app to do because it would be fun to get reacquainted with Rails. That probably won't happen since I have been going it the opposite direction, having updated a few Sinatra and PHP sites to be 100% static, and using cloud storage and CDNs.
- cyberferret 10y ago
  If you are familiar with Sinatra, have you checked our Padrino [0] ?? Padrino gives you a lot of the Rails goodies without too much bulk added. I've developed and deployed several 'real world' web apps in Padrino now. I looked at Rails in the early days, but for some reason could never really get to grips with it (probably because it was too opinionated for me). Sinatra/Padrino's DSL methodology seemed to sit better with me, and I ran with it. [0] - http://www.padrinorb.com http://www.padrinorb.com
ahallock 10y ago
Here's a reason: money. Rails is still very popular, so there's plenty of work out there.
- cutler 10y ago
  See my top-level comment about this. Rails' presence in the job market is definitely declining and dwarfed by both PHP and Node.js.
throwanem 10y ago
Rails showed us all that web development didn't have to be PHP and Apache and constant headaches. Node and Phoenix and the modern paradigm in general wouldn't have come into existence, or achieved the popularity they have, without an act like Rails to follow. That's awesome, and I respect it for that. But can it truly be said that Rails has a purpose today? Its default performance remains lousy with any kind of load. Its convention-first approach means Rails knowledge doesn't easily generalize, as can be seen in this very comment thread from the experience of those who've approached the Node ecosystem as though it were "Javascript on Rails". The "history? what history?" attitude of its BDFL and his clique makes cause for trepidation out of the prospect of maintaining a Rails app over a significant length of time. And even by comparison with ES5, Ruby is a hot mess. I get that DHH has to defend it. It's his baby, after all. But it's been a long time indeed since Rails had anything unique to offer beyond an ideology which is, in its own way, every bit as much a straitjacket as RMS' - and Rails' inheritors have innovated in ways that straitjacket makes it very hard at best for Rails to match.
- patsplat 10y ago
  Agreed. Would love to see DHH build an opinionated framework for node rather than waxing poetic about Ruby.
  - wyaeld 10y ago
    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?
    - deleted 10y ago
      [deleted]
    - patsplat 10y ago
      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.
hogrammer 10y ago
Other frameworks don't have the DHH Problem. https://codon.com/the-dhh-problem https://codon.com/the-dhh-problem
hhandoko 10y ago
> 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?
- mavelikara 10y ago
  This article might be helpful: https://martinfowler.com/bliki/HumaneInterface.html 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.
  - hhandoko 10y ago
    Thanks! I agree Ruby looks to be far user-friendly in this context. Just to add, my work revolves around the JVM ecosystem, but mostly in Scala and some Kotlin... Both already provide a nicer interface for Java :) e.g. in the context of collections both have `list.head` or `list.first` and `list.last`.
spoiledtechie 10y ago
This answer sounds a lot like what Microsoft's answer to Java was. C#. Everything in this answer reminded me of c#.
blueside 10y ago
I think Rails is always worth learning, but is it worth learning right now if you want to find a job?
cutler 10y ago
Maybe a more relevant question is whether Rails is worth learning if you're looking for a job. Searching Indeed.com's API by title, which removes duplicates, there are currently 133 Rails jobs in the USA compared with 763 PHP (excl. WP, Drupal etc.) and 467 Node.js. In the UK there are 104 Rails jobs compared with 1013 PHP (excl. WP, Drupal etc.) and 230 Node.js. However, if you deleve deeper it turns out that half of the Rails jobs are in London. Outside the capital there are 22 PHP jobs to every Rails job (35 including WP, Drupal etc.) and 3 Node.js jobs to every Rails job so it would appear that unless you have a particular preference for the Ruby language Rails is not a good bet in today's job market.
- hashmal 10y ago
  I don't think indeed.com is representative of the market, many rails jobs aren't even online. Besides, if for 133 rails jobs and 763 PHP jobs there are 60 and 1500 rails and PHP candidates (respectively,) you're clearly better off choosing rails.
  - cutler 10y ago
    That's not very scientific until you can establish that Rails jobs are more likely to be posted offline than PHP jobs. I don't see any evidence for this.
- appleiigs 10y ago
  So you are saying that PHP is worth learning in 2017? I think it goes beyond job posting counts.
  - cutler 10y ago
    Have you looked at Laravel recently? With Vue.js integrated into the framework and adopting the best bits of Rails I'd say it's looking in better shape than Rails right now.
- matthewking 10y ago
  I find for the jobs market usually Java and C# dominate.
holydude 10y ago
What stack do you recommend if not rails for a person that dislikes JavaScript (well rather ecosystem than the language / syntax itself) ? I love Rails and Ruby do not take me wrong but I am not sure if the sole existence of Rails can make Ruby relevant in 2017. In terms of jobs prospects and similarity to Rails/Ruby what do you guys recommend ? Java ?

200 points by gavingmiller 10y ago

dharamgollapudi 10y ago

Its DHH, not DDH. Mods, please update the title.

gavingmiller 10y ago
corrected - thanks

vcryan 10y ago

It's always important to study history :)

GavinMcG 10y ago
Snarky, low-content comments really aren't valued highly here.

meesterdude 10y ago

This reinforces what I see a lot too - people creating yet another XYZ, but rarely I see someone go and create an integrated solution to streamline development processes or make things easier or clearer. There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you, but I want nothing to do with either, and do not have problems that those are meant to solve. I love ruby, and I love rails. DHH regularly sounds the drum of rationality - in a community at large of idealists and extremists. He is the reason I got into programming, and constantly serves to remind me that what I'm doing is, in fact, perfectly fine; and that everyone else puts up with a lot of nonsense for no great reason. There are other frameworks out there, but you'd be hard pressed to find one with a leader that has such a sense of direction and reason for why the framework does what it does, and does not.

allover 10y ago
> There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you Can you give examples of the 'lot of vocal people' saying 'you should be doing everything in Go or Angular'? I don't see this. I only hear this kind of black/white sentiment when filtered via junior devs. Experienced devs I know get there are trade-offs. And I don't see anyone on the React/Angular/Vue teams saying that server-sidey Django/Rails/etc. apps are 'wrong'.
- johnbellone 10y ago
  At least once a week I read comments or a submission about how X should be written in Rust. That's a pretty common occurrence here; if you stay long enough it'll be another language.
  - allover 10y ago
    I've seen a lot of Rust posts on HN lately, but none saying you must ditch mature frameworks like Rails for Rust equivalents (there aren't any yet, and they know that, for one). Where's the evidence for this claim DHH/Rails is the only rational force in a sea of extremists? (Of course the dull reality with real apps is "it's complicated" and most devs are busy grappling with that).
    - ethbro 10y ago
      > Rails for Rust equivalents (there aren't any yet, and they know that, for one) ... Can we please call it Rusty Rails?
  - srssays 10y ago
    Before Rust it was Haskell, before Haskell it was Erlang, and before Erlang it was Lisp.
  - dgfgfdagasdfgfa 10y ago
    Do you have any examples?

currywurst 10y ago

I admire the way DHH writes .. confident and persuasive. However, I'd just like to point out that in the same span of time JavaEE has undergone significant simplification (omakase API standards, anyone ;)) and if you check out the work of Adam Bien, you'll quickly find old myths of bloated memory consumption and fiddly XML configuration debunked. Java is also lucky to have a parallel full-featured stack in the Spring ecosystem. Projects like JHipster do an opinionated take on how to wire things up and take you to quickly to orbit. So basically, I disagree with DHH that there is "Very little activity in integrated solutions."

dceddia 10y ago
I took his comment about "very little activity in integrated solutions" to mean "[in the JavaScript world]" but maybe that's not what he meant. I do think that's pretty true of the JS ecosystem though. There are things like Sails, but most of the "new" stuff that comes out is build systems, tools, small libraries, and view libraries. As to why... it's anyone's guess. My guess is that making a full-stack opinionated framework like Rails is a big undertaking, and most people are focused on what they see as "quick wins" -- solutions to the obvious surface-level pains like "npm is slow" and "making forms with React is hard" that can gain traction quickly and rise to stardom on Github. Maybe this is cynical to mention, but fame and recognition (and maybe interesting job offers) seem to be a big driving force behind the constant influx of new and better JS libraries/tools.
- headcanon 10y ago
  > As to why... it's anyone's guess. I think its because recreating rails in javascript just doesn't make sense in the current ecosystem. Either you are rewriting stuff like express from scratch (and why are you doing that?), or you're building on top of those modules and adding configuration conventions and scripts, in which case, congratulations, you've just written Sails. When Rails first got started, ruby didn't have anything close to the ecosystem that JS enjoys today, so DHH et al. had to write most of the individual components themselves, with the intention of making them all work together. So in my view, its similar to how Humans and Gorillas evolved from a common ancestor, but you won't see Gorillas becoming Human anytime soon.

0xsnowcrash 10y ago

Rails, as any backend system such as Drupal or Symfony, is inevitably a dead end technology. The web is increasingly moving frontend and the system of 2018 onwards will simply be the M in MVC. Note, I'm not saying Rails is not worth learning. I'm just saying it's now the Cobol of web technology.

eternalvision 10y ago
Can you provide examples of the move you describe?
pyrophane 10y ago
If I read your comment correctly, I believe you are suggesting that backends will provide APIs, which would leave us with the MC in MVC, the controller is still needed to map data structures to API endpoints. My question to you is this: why do you believe that? I think we have all witnessed a growth in popularity in front-end MVC frameworks, but are they the correct solution to all problems?
- BOBOTWINSTON 10y ago
  Not to mention Rails has an API only generator for new apps now... so this problem is framework destroying 'use case' is solved with a single flag.
- whyileft 10y ago
  > the controller is still needed to map data structures to API endpoints. I mean, kind of. You don't really need much controller logic most of the time anymore. Last Rails backend I wrote probably involved personally writing a few lines of code here and there. Generally, I'm just pushing a JSON object back and forth. Auth and emails can just be 3rd party. The vast majority of controller type behavior ends up client side at this point. Partly, because its way simpler to scale with you push as much processing to the client as you can. Also, look at something like Firebase or Hoodie as examples of simple stores that require no backend logic. Its not that Rails and Symfony are useless, I use them all the time, its just that they are kind of dated concepts. Heck even Wordpress solves a specific problem on the backend enough to be useful sometimes. That said Drupal at this point is such a dated concept(superseded by things like Rails and Symfony many years ago) that is should no longer be used.

newsat13 10y ago

So, I have seen rails code and I did not fall in love with the code. Instead what I saw just black magic and all sorts of conventions. Reminded me of perl. You have to invest a lot of time knowing all the magic stuff.

hekker 10y ago
What's wrong with conventions? It seems to me that code conventions would make code more maintainable.
- bobbytherobot 10y ago
  newsat13 wasn't complaining about using conventions. newsat13 was complaining about how Rails uses black magic with conventions. I can't speak to Rails, but I've worked in other codebases that used reflection to dynamically attach different pieces of code together. It was hard to trace code because I couldn't do a search for the value being generated nor could I use the static analysis to find the value. I had to manually trace through the whole stack to find the bit of reflection that was generating a value.
  - rhizome 10y ago
    I've never worked in a codebase like that, but in all my years of helping people with Ruby and Rails I've concluded that reflection is a code smell. It's one of those things that is taught in CS and winds up appearing where conventions might not have been immediately apparent, a fallback to training.
pmontra 10y ago
There isn't much black magic. Most of it is pretty sane naming conventions which could be OK in any sw project, plus database schema autodiscovery. The bonus is increased maintainability.
- cies 10y ago
  > The bonus is increased maintainability. It will never have strong-typed discipline though... (sad)

deleted 10y ago

[deleted]

vinhboy 10y ago

> formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application Maybe I've drank the kool-aid too much, but I agree with this whole-heartedly. It reminds me of when I want to paint a room. I can go to Home Depot and spend an hour picking out all the tools I need, or I can buy one of those pre-packed toolkit and get to the actual painting immediately. Rails + Heroku = My product will be ready to demo by end of the week. Obviously this mentality only applies to people like me who wants to get things done quickly. People who value craftsmanship and specificity should do what pleases them. (That's not to say you can't do quality work with pre-packed toolkits)

astrodust 10y ago
In the last few months I've built a brand new Node + Express application, and I've built a brand new Rails 5.x one. ES6 has taken the edge off of some of the more obnoxious parts of JavaScript, but it still has a long way to go to catch up to Ruby, and Express is a cheap imitation of Rails. It takes me over a day to get an Express application up and running. There's dozens of dependencies to wrangle into place. There's hundreds of lines of code to sketch in even the most basic of applications. So many directories to create, so many new files you have to basically build by hand. There's Gulpfiles to configure. There's a lot of work to integrate Passport. It's a lot of work to get as far as "Hello, world". Meanwhile rails new and some Gemfile dependencies get you almost all the way there within an hour. Then you're making database migrations and laying in CSS and layouts. I love both Node and Ruby for different reasons, but the out-of-the-box experience for Express is total garbage. You can't even parse a cookie without installing a module for that. Node is way easier to create real-time services, like a Socket.io server in JavaScript is way less fuss than Ruby+EventMachine. It absolutely kills it when writing thin JSON APIs, and in terms of performance it's ridiculous. There's nothing preventing Node from having a Rails-like easy start for web applications but the attitude of the community where making decisions for people and having sane defaults is apparently against the rules.
- tcfunk 10y ago
  > It takes me over a day to get an Express application up and running. I feel so much better after seeing this sentiment here. I've tried to dip my toe into the node.js world repeatedly only to feel like I'm trudging through setup for hours. Of course I may have incorrect memories of how difficult/easy it was to set up my first rails app however long ago.

patsplat 10y ago

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

jrs95 10y ago
He considers the monolithic architecture to be an advantage: https://m.signalvnoise.com/the-majestic-monolith-29166d022228 https://m.signalvnoise.com/the-majestic-monolith-29166d02222...
- patsplat 10y ago
  Agree with your comment, but am not sure there is a more potent monolith than AWS or GCP.
- patsplat 10y ago
  If he really believed that, then the thing todo would be to re-write rails to run on top of node. Then he'd have a runtime that spanned nearly every possible use case and device. Sticking with Ruby betrays that aesthetics are really the core premise of Rails, rather than aspirations of being the one framework to link all run times and in the darkness bind them. Frankly, node needs such a framework.
  - cutler 10y ago
    Why on earth is Node considered the default for concurrency with its shitty single-threaded callback execution model? Anyone switching from Rails for improved concurrency would surely be better advised to choose Elixir?
    - patsplat 10y ago
      Was referencing the run-time's viability on devices as small as a Beagle Bone micro controller, a mobile app, up to a backend service, etc. There's an attractive opportunity for code reuse. Have a preference for process pools over thread pools so don't mind the execution model. Would not be surprised that some applications are better served by other backends like akka etc. Elixir is on my list to learn. That does of course play into the position that a great "full stack" framework is a thing of the past.

eranation 10y ago

I completely agree on one aspect, anywhere I go, the kitchen sink is missing. You want to compress responses? well, there is an npm / jar / pip library for that. Want to have ORM? just npm / pip / "your package manager here" and you are done. You can say a lot about Rails but I like the idea that everything I commonly need as a web developer is most likely already in the framework, and there is usually a best practice way to do things. Options are great, but moving out of plumbing and into generating value to customers is still having a value. If you don't like opinionated, batteries included solutions then Rails is not for you. However there are other solutions that kind-of cloned some aspects of Rails. Playframework (Scala has a lot more similarities to Ruby IMHO than to Java, at least in philosophy). Also Spring Boot or JHipster (Spring boot + Yeoman - super opinionated)

elcapitan 10y ago

Rails has become so much more enjoyable since all the hipsters left for node.js. [What makes Rails a framwork worth learning in 2017]

Glyptodon 10y ago

The only thing I'd really take much issue with is the "provides great defaults" statement made in passing. There are several things that are defaulted more to what I'd call "lowest common denominator" than "great." For example, sessions.

patsplat 10y ago
This a great point that gets to the heart of the problem with the premise of a full-stack framework. Defaults end up more "good enough" rather than "great"
- Daishiman 10y ago
  But a collection of consistently good enough components is better than tying together two dozen different things of wildly different quality and conventions. I hear this a lot about Django. The ORM is really good but "not as good as SQLAlchemy". The templates are great but "Jinja is better". The thing is that as an engineer I value that the components are incremental improvements with sane defaults where change is deliberate and the benefits of what I'm missing out on are truly, honestly irrelevant. There's really very few times where I said to myself, "Oh of only my templating language had better support for these idioms". I just write a decent workaround because I've been using the same tool for years and it's maintainable and the total number of workarounds is so small that there are no good reasons to switch to an alternative even in the long term. This is much better than the alternative of looking for 5 alternatives for the same component, discarding the first 3, using one for a month until I find it has fatal flaws, and finally settling for the last one.
  - patsplat 10y ago
    Once one critical component in the framework is no longer good enough it can be very difficult to upgrade. Frameworks aggregate many dependencies. Managing the dependencies that deliver value while ignoring those that are irrelevant can net out as more productive.

horsecaptin 10y ago

Ember.js attempts to do what the front-end what Rails has done for server-side application development. Worth a look, if you're trying to choose between React / Angular / something else.

rco8786 10y ago

What does Ruby have to do with immutability

wrsh07 10y ago
Let's consider the quote: > You get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter. He's saying there are other beautiful paradigms - especially of the FP variety. However, Ruby is really, really damn elegant. And he's right; it's a joy. [I say as a C++ dev]
cies 10y ago
".freeze" :) it's all runtime baby, love it (at least accept it), or move on

mountaineer 10y ago

DHH also answers a few other questions about Ruby and Rails in the same Q&A https://www.quora.com/session/David-Heinemeier-Hansson/1?srid=pvwn&share=1 https://www.quora.com/session/David-Heinemeier-Hansson/1?sri...

bobbytherobot 10y ago

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 option on the a la carte menu. Every week the developers want to switch out some module for another module within Rails because it was the hot new thing. Maybe I worked on a bad project. Maybe I didn't get it. Maybe it was a growing pain that has passed. Rails was a pain in the ass to get to work. The ORM was cool, but did it save me time or mistakes from writing SQL - no. I would love other people's opinions who have stuck with Rails.

deedubaya 10y ago
> I spent hours everyday getting the asset pipeline to work, or it would break again, meaning I would have to fix it again. I used to have this problem too -- more so in the early days of asset pipeline. Mostly when trying to use some client side framework. Rails is working on (or maybe already available, I'm not sure) yarn/webpack support. > Every week the developers want to switch out some module for another module within Rails because it was the hot new thing. Replacing the batteries which are included can be painful at times. If you want to use the new hotness in Rails, it comes at a price of extra work getting it working... but it only seems painful when comparing to the included batteries -- they just work. Support for different test frameworks, orms, templating languages are pretty good anymore though and are easier to swap out. You'll definitely have a better experience with Rails if you forego the desire to run the latest and greatest and just use what Rails already has.
- throwanem 10y ago
  Until a new point release comes out and everyone forgets about the one you're running. Then you get to find out how much of your code you'll need to rewrite so it'll run with the Rails chefs' wild new menu. And there's no point even trying with an app written for an earlier major version. Just give up now, because the whole ocean's been boiled and recondensed since then, and now occupies but few of the basins it once did. Granted, it's been a couple years since I dealt with any Rails apps. That's in large part by design, because every Rails app has a relatively high curation cost just to keep it up to date with the latest and greatest, and you have to do that if you want to be able to add features or usefully maintain anything without undue agony, because the Rails community has the collective memory of a goldfish and even less interest in maintaining continuity with the past. I get that that's the big selling point, the drum DHH and his fans never stop beating: "Rails is omakase." This is a fundamentally broken metaphor, because sushi is dead by the time it gets to you, and all you have to do with it is eat it; the history of the ingredients is of little consequence. Would that software were so simple.

mark_l_watson 10y ago

I have been thinking of rails lately. I used both Rails and Merb way back when, but for many years now I have just used Ruby + Sinatra. I wish that I had a more complex web app to do because it would be fun to get reacquainted with Rails. That probably won't happen since I have been going it the opposite direction, having updated a few Sinatra and PHP sites to be 100% static, and using cloud storage and CDNs.

cyberferret 10y ago
If you are familiar with Sinatra, have you checked our Padrino [0] ?? Padrino gives you a lot of the Rails goodies without too much bulk added. I've developed and deployed several 'real world' web apps in Padrino now. I looked at Rails in the early days, but for some reason could never really get to grips with it (probably because it was too opinionated for me). Sinatra/Padrino's DSL methodology seemed to sit better with me, and I ran with it. [0] - http://www.padrinorb.com http://www.padrinorb.com

ahallock 10y ago

Here's a reason: money. Rails is still very popular, so there's plenty of work out there.

cutler 10y ago
See my top-level comment about this. Rails' presence in the job market is definitely declining and dwarfed by both PHP and Node.js.

throwanem 10y ago

Rails showed us all that web development didn't have to be PHP and Apache and constant headaches. Node and Phoenix and the modern paradigm in general wouldn't have come into existence, or achieved the popularity they have, without an act like Rails to follow. That's awesome, and I respect it for that. But can it truly be said that Rails has a purpose today? Its default performance remains lousy with any kind of load. Its convention-first approach means Rails knowledge doesn't easily generalize, as can be seen in this very comment thread from the experience of those who've approached the Node ecosystem as though it were "Javascript on Rails". The "history? what history?" attitude of its BDFL and his clique makes cause for trepidation out of the prospect of maintaining a Rails app over a significant length of time. And even by comparison with ES5, Ruby is a hot mess. I get that DHH has to defend it. It's his baby, after all. But it's been a long time indeed since Rails had anything unique to offer beyond an ideology which is, in its own way, every bit as much a straitjacket as RMS' - and Rails' inheritors have innovated in ways that straitjacket makes it very hard at best for Rails to match.

patsplat 10y ago
Agreed. Would love to see DHH build an opinionated framework for node rather than waxing poetic about Ruby.
- wyaeld 10y ago
  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?
  - deleted 10y ago
    [deleted]
  - patsplat 10y ago
    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.

hogrammer 10y ago

Other frameworks don't have the DHH Problem. https://codon.com/the-dhh-problem https://codon.com/the-dhh-problem

hhandoko 10y ago

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

mavelikara 10y ago
This article might be helpful: https://martinfowler.com/bliki/HumaneInterface.html 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.
- hhandoko 10y ago
  Thanks! I agree Ruby looks to be far user-friendly in this context. Just to add, my work revolves around the JVM ecosystem, but mostly in Scala and some Kotlin... Both already provide a nicer interface for Java :) e.g. in the context of collections both have `list.head` or `list.first` and `list.last`.

spoiledtechie 10y ago

This answer sounds a lot like what Microsoft's answer to Java was. C#. Everything in this answer reminded me of c#.

blueside 10y ago

I think Rails is always worth learning, but is it worth learning right now if you want to find a job?

cutler 10y ago

Maybe a more relevant question is whether Rails is worth learning if you're looking for a job. Searching Indeed.com's API by title, which removes duplicates, there are currently 133 Rails jobs in the USA compared with 763 PHP (excl. WP, Drupal etc.) and 467 Node.js. In the UK there are 104 Rails jobs compared with 1013 PHP (excl. WP, Drupal etc.) and 230 Node.js. However, if you deleve deeper it turns out that half of the Rails jobs are in London. Outside the capital there are 22 PHP jobs to every Rails job (35 including WP, Drupal etc.) and 3 Node.js jobs to every Rails job so it would appear that unless you have a particular preference for the Ruby language Rails is not a good bet in today's job market.

hashmal 10y ago
I don't think indeed.com is representative of the market, many rails jobs aren't even online. Besides, if for 133 rails jobs and 763 PHP jobs there are 60 and 1500 rails and PHP candidates (respectively,) you're clearly better off choosing rails.
- cutler 10y ago
  That's not very scientific until you can establish that Rails jobs are more likely to be posted offline than PHP jobs. I don't see any evidence for this.
appleiigs 10y ago
So you are saying that PHP is worth learning in 2017? I think it goes beyond job posting counts.
- cutler 10y ago
  Have you looked at Laravel recently? With Vue.js integrated into the framework and adopting the best bits of Rails I'd say it's looking in better shape than Rails right now.
matthewking 10y ago
I find for the jobs market usually Java and C# dominate.

holydude 10y ago

What stack do you recommend if not rails for a person that dislikes JavaScript (well rather ecosystem than the language / syntax itself) ? I love Rails and Ruby do not take me wrong but I am not sure if the sole existence of Rails can make Ruby relevant in 2017. In terms of jobs prospects and similarity to Rails/Ruby what do you guys recommend ? Java ?