Hacker News new | comments | show | ask | jobs | submit login
Rails is omakase (heinemeierhansson.com)
251 points by martinbc 1788 days ago | hide | past | web | 195 comments | favorite



What is this post responding to? And who is the target audience?

Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. We get it, Rails is "opinionated", sorry I guess we're saying "omakase" these days. Who really gives a fuck?

The reason DHH is getting loud complaints is because people feel that they carry a legitimate grievance but also feel no way to voice that opinion (or are trolls). Douchetastic talking down to them like exemplified in this post won't help (and will encourage trolls).

People with limited knowledge and understanding of something and/or restricted mobility in tech aren't in a place to see things the way you see them. Help them get to that place, instead of just telling them how to see things with metaphors that only work once you're at that place. Or just don't engage them at all.

Edit: Huh. This DHH blog post doesn't really feel on par as a response to the conversation in that github issue. But if it is, know that my post was written assuming the criticism was of the type he describes, not the type that transpired.



Thanks. I'm not really a rails person, so forgive me if I have some questions. Am I correct in interpreting that thread as DHH not wanting to support multiple ruby package managers in the rails codebase? In particular, DHH has 'blessed' rbenv and that commit wants to support rvm?

If this is the case, then I have to wonder: why is there any dependency on a package manager at all in the rails codebase? This just seems odd to me, and perhaps is the source of the conflict. E.g. people are fine with 'omakase' frameworks, but these menus typically don't include toolchain dishes. It would be like going into a restaurant and being told that you must use chopsticks, no forks allowed.


> In particular, DHH has 'blessed' rbenv and that commit wants to support rvm?

No. Two things are going on:

1. 'binstubs' will now be checked into source control. If I use MRI and you use JRuby, they'll start with different things, and therefore, cause conflict.

2. Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now.

David maintains that if I use MRI and you use JRuby, or if I use rvm and you use rbenv, this is an 'organizational failure.'


"Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now."

Incorrect. It is support for an enhancement that rbenv provides.

You often want to invoke an application binstub from another program such as cron, and you want to use the per-project Ruby version specified in the application's root directory. Other version managers require you to spawn a subshell and load the version manager into the shell or otherwise set up the per-project Ruby version environment, then `cd` into the application directory, and finally run the binstub.

rbenv requires an environment set-up step too—set `RBENV_DIR` to the application root—but provides a wrapper that eliminates the need for such gymnastics. When you change a binstub's shebang to `#!/usr/bin/env ruby-local-exec` rbenv automatically searches up the binstub's directory tree to find the right Ruby version.


Thank you for clarifying the exact circumstances, Sam. I don't use rbenv, I was going by discussions on the ticket and in Campfire. I was referring to that difference in the binstub, but maybe should have been more clear that that's a conflict with the enhancement and not the base features of rbenv.


If a team is using different versions/runtimes of ruby I would have to agree this is an organizational feature in some cases. If you're working on a webapp you should be aiming to make as few differences between a development box & production as possible. Its unlikely that you have jruby & mri in production, wherein lies the failure.


Square is one example of a company which famously develops in MRI but deploys JRuby to production.


That sounds crazy to me, but I have very little experience with ruby. In PHP/python doing that can be unpleasant.


And also the corresponding reaction on Twitter:

https://twitter.com/jon_lemmon/status/284075141967790080


@dhh: @jon_lemmon Why don’t you go ahead and fork rails so you can change the default gitignore file for new apps? You can call it Rails on Drama.

ROFL, DHH has cajones.


Apparently somebody has bigger cajones.

@sbartholomew: @dhh the the Rails community has it relatively easy: http://article.gmane.org/gmane.linux.kernel/1414106 … :-)


It's funny, though the comparison isn't perfect, DHH is basically doing what Linus got infuriated about here. He's making a minor change for what seems like very little gain, meanwhile breaking third party projects that rely on Rails.


A very imperfect comparison, as Linus is maintaining a kernel and DHH is maintaining (the next major version of) a highly opinionated web framework.


Typical Linus.

Linus was right, though.

And DHH was wrong.

Not a fan of the way Linus handled that, though he sure did set the tone and expectations for everyone else!


you know, while i don't talk to people like that (and especially not in public), i have considerable sympathy for linus's position there. it is clearly a deeply held philosophical belief of his that kernel changes should not break working userspace code, and here is someone who is evidently a long-standing kernel maintainer trying to blame a user app for breaking against a technically bad kernel patch.

i'm betting he made that mail public very deliberately, as a way of telling the world at large that as kernel dictator he would not tolerate his "staff" treating users like that.


The mail is always public... It's part of the Linux kernel newsgroup...


he could always have sent that mail to Mauro privately and a toned-down version to the list.


Doesn't that defeat the purpose of having a public list?

I think a big reason it's on the public list is because it should be. Linux is Linus' baby, he has every right to yell at someone for doing pretty much anything. And in this case, it was deserved. If you're going to break the first commandment of Linux development (don't break userspace), and blame the userspace for breaking, you should be reprimanded.


its amazing anyone commits to the kernel after seeing that. i sure the hell wouldn't.


The Linux kernel is one of those top open-source projects, big, old, well oiled and with lots of contributions, both from companies and individuals.

So Linus must be doing something right.


It makes me less likely to want to commit code to the Linux kernel, but more likely to want to run it.


Lol, imagine the flames if DHH had that kind of personality. People are being molly-coddled by DHH for stupid stuff like a default in .gitignore.


This 'stupid stuff' breaks every single new Rails app on Heroku that uses rbenv.


Exactly zero of the Rails apps on Heroku will break.

When you create a new app you'll need to remove a line from the autogenerated .gitignore in order to work the way you expect.

No?


I am repeating what Heroku's Ruby platform lead said here: https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...


You actually removed the word "new" from the middle of his sentence, which IMO changes the meaning substantially.


It does, yes. This is my bad. I do not use rbenv, personally. Let's see if HN will let me edit it.


Mexican-beaner grammar nazi here, is "COJONES" not "CAJONES". xD


That's a spelling issue, not a grammar issue :)


Actually, it's neither: http://en.wikipedia.org/wiki/Euphemism


Does Rails not provide a way to customize the scaffolding used to make a new app, without forking?


Yes, you can using `rails new app_name -m template_name`.

But that would be way overkilled, here, because we just speak of adding a line to the .gitignore file.

If you don't know git, .gitignore is a file you're expected to edit, you put there anything you don't want to commit in the repository.

So, once again, all the trolling is about changing a default option. Which can be changed back with one line of four characters ("/bin"), in a configuration file. Change to be made only once in the whole life of your application.


It does have some features to do this, but the point is that the default operation is simply broken for many, many people. That suggests that it should not be the default.


I'm not knee-deep in this specific issue with the binstubs, but I generally agree about the legitimate grievances. The Merb effort and the Rails 3.0 refactor resulted from people unable to voice what they need. We seem to keep repeating history.

Asset Pipeline is also the wrong area of innovation to focus on. Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end. There are more smartphone-like devices in the world than personal computers; there are kids growing up with a smartphone as their first computing device; people of our generation have a bias towards thinking of UX and web-apps as desktop-first; when the tooling around API-only Rails apps mature, then template-driven apps will start dying into irrelevance.

But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses, and it won't be in apps.


> Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end.

This has never been Rails' focus. Let Rails keep doing what it kicks ass at. Sinatra works great for API endpoints. There's probably an opportunity for an API-focused extension to Sinatra. Of course, Grape works too (https://github.com/intridea/grape).

The nice thing is that all of these are built on Rack now. GitHub.com runs as a Unicorn rack app that mounts over 30 Sinatra apps and a massive Rails app together. I'm not saying this is an optimal solution, it's just where the app is at in its current evolution. But it is very possible :)


For things like APIs, Rails has https://github.com/rails-api/rails-api, an excellent project.


I've taken a look at it. It does not really use the Rails 3 architecture (Russian Doll Pattern) to its fullest potential. I have written https://github.com/intermodal/intermodal back in 2010 to demonstrate it, and have put that code into production.

There are some people trying to revive Rails-API. I have already sent them an email begging them to steal ideas from Intermodal. https://groups.google.com/forum/#!topic/rails-api-core/LoJap...

Maybe they will, maybe they won't. I got a polite brush-off so I doubt they really looked at it, but since I am exiting, whatever.

In writing Intermodal, I've had to muck around with some of the guts of Rails. I've found that Rails 3.0 very much follows the principle of Russian Doll Pattern, but Rails 3.1 onwards started moving away from it. There are baked-in assumptions in the code for a template-driven app. This is where the Rails leadership is focused on.


Sinatra is not actually all that good for writing API endpoints.

The Rails 3 architecture is very modular. It was designed as framework to write frameworks, of which a template-driven app is one such framework. I have written a different framework specifically for just an app focused on SASS that has an abundance of CRUD operations.

However, when Rails 3.1 started transitioning into Rails 3.2, the assumption that Rails is specific for a template-driven app started being baked deeper into it. It was moving away from the "Russian Doll Pattern" that was so useful for me.


>> Rails should be baking in support for creating API only apps

Right now, I can create a rails app that doesn't use templates at all. I can start with a basic rails 4 install and quickly prototype an API that communicates through JSON or any other format I can think of. I can leverage handlebars and ember.js if I want to go that route, or I can stick with dumb old 'templates' to display my data. When you start coding ruby on rails you quickly realize that 'template' is just a word and that you are free to do literally anything you can think of, easily.

>> people of our generation have a bias towards thinking of UX and web-apps as desktop-first

Let us assume this is absolutely true. Why does rails keep you from writing code that honors this bias? Rails gives you abstractions you can use to decouple. If I want local data persistence perhaps I'll need support from other libraries--but only if I'm too shy to take a shot at writing a tool myself. I think you're on to something with the 'desktop-first' remark. We do need to be able to store data browser-side. We do need to address performance issues--especially as it relates to decoupling server-side data logic and application data logic. Rails is a very good tool for supporting solutions to these types of problems and packaging them in easy to implement applications.

>> But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses..........

Obviously rails is useless if you don't want to make applications, but otherwise you can really do anything and it's not actually hard to configure rails.

I used to think that david hh and many other experts in the community were mean. Then I realized they have to deal with people all the time; not the 'grievances', but the attitudes. There are many trolls and one cannot be too careful.


If you're going to do API only apps then there are much better alternatives than Rails. Rails is heavy. It's like using a cruise ship to navigate a small creek.


Rails is "heavy" because it does a lot of things that you'll end up having to recode by hand with any other "lighter" solution.


Not so much recode by hand as actively choose components that provide the functionality. Sure, you might have to recode a bit of the between-components wiring if the separate components you choose don't natively support each other, but its hardly as if you'll generally have to recode the major components themselves.

Sure, Sinatra doesn't come with ActiveRecord like Rails does, but you can use ActiveRecord on its own with Sinatra -- or use Sequel or DataMapper or whatever other ORM [or non-ORM persistence solution] you prefer -- with Sinatra, you don't have to code your own by hand. Similarly with other components.


Sure. If you're building a traditional web app. The sort of web app Rails is good at. But if you are constructing an api, you can use ligher and alternate technologies that will get the job done faster and better.


Like what? Rails is great for APIs, because APIs, especially RESTful and Hypermedia APIs, can literally be a standard webapp with JSON views instead of HTML.

I've never built a SOAP API in Ruby, so maybe Rails wouldn't work with that very well. XML-RPC might also be a little tough, but I honestly can't think of any significant difference between a "traditional web app" and a RESTful API. They're a perfect example of code reuse in MVC (or Model2 if you want to be pedantic).



People keep repeating that like it's some commercial gimmick, but what does it really mean? How is Rails or rails-api not suited for APIs? What's lightweight? What's easy?

And more particularly since you seem to know about this, what other option would you favor?


Well Sinatra seems pretty nice. I'm a node.js developer so I use Restify and Express. But I practically build api's exclusively. I've spent a lot of time cleaning up after terrible Rails applications. Replacing bits that are too slow or difficult to maintain with smaller more nimble node applications.


"what does it really mean?"

It means he's a node troll. They take a shot at the dominant frameworks any chance they can get. Node trolls have reached the level of obnoxious arrogance that early Rails developers were once mocked for. Don't feed the trolls.


It's about using the right tool for the job. Most developers never seem to understand that. Everyone seems to want the same magic bullet for everything.



I read that entire comment thread, and maybe my perspective is skewed, but I saw none of the behavior that DHH described there. The discussion was generally polite, the participants were mostly experienced Ruby developers with open-source and community track records, and their objections were well-supported. I have less sympathy now for the original post than I did.


Exactly my thoughts. For example, I know for certain that José Valim is (or at least was last time I checked) a core ruby dev and he's against this change for example. DHH wants to sound like he's talking to trolls and the casual Rails user, but it's clear from the github thread that he's responding to seasoned members of the community as well, which quite frankly is a pretty shitty way to treat people who are known contributors. It's not a community, it's whoever screams loudest. To me that thread and this posts shows that DHH is willingly wearing horse blinders instead of keeping his opinions being open to being amended through thoughtful discussion with others as talented as he is.

The biggest problem with this "omakase" attitude is that it's causing Rails developers to miss the boat on many new developments in the state of the art in web app development because legacy is now baked in via opinion. 37Signals hasn't been the forefront of web-app design for a few years now. There are plenty of single page web apps out there that are far more responsible and present a better user experience than tools from 37Signals. Don't get me wrong, they are still decent, but they aren't demonstrative of what is achievable insofar as excellent user experiences are concerned.

Maybe this has changed, but I spent a year working on a single page webapp built on Rails and the asset pipeline was excruciatingly painful to debug to get your javascript and other assets handled properly.


Rails Core. I don't think he actually has Ruby core access like Aaron Patterson (Tenderlove)

Actually, I think he's sort of on vacation from Rails for the most part. He's got Elixir to work on.

As for the matter at hand, Bundler author Yehuda Katz said that checking in binstubs is actually not a good idea and is not recommended. DHH is going against the grain here.


Aaron and Yehuda are the only two people on both teams, Jose is on Rails Core only. He is also a maintainer of Bundler, as is Terence, who is also on the thread.


"37Signals hasn't been the forefront of web-app design for a few years now."

Exactly.

This shift isn't just "single page web apps" either. It is a generational shift. When people say "apps" now, it isn't a "web app". For all the thousands of hours of experience DHH says he has, it is stuck in a very narrow view while the rest of the world has moved on.

That's ok though. The neat thing about open source is that developers and users do not have to suffer dinosaurs for long.

It does mean that I can no longer depend on my Rails skill to put food on the table. Recruiters, desperate for Rails developers, will no longer be knocking on my door. It's a good thing I've been laying in the groundwork for the inevitable irrelevancy of Rails.


"The rest of the world has moved on"?

Good lord man, there's more than one way to skin a cat, and the web is not simply "apps". If you think Rails is irrelevant today than you are practicing fad-driven-development moreso than developing any real insight about the lay of the software land.


Yes. The rest of the world has moved on. If you've characterized what I am saying here as "web is simply apps", then you do not understand what I am saying.

I've written this in one other comment, I suppose I will repeat myself:

(1) There are more mobile units being sold than personal computers.

(2) More importantly, there are 2 year olds whose first experience with a personal computing device will be a smartphone or a tablet. When the start going to school, they will be forced to use a keyboard and will resent it. They will see this as a problem to be solved, and will solve it. This is a generation gap, something between 10 - 18 years from now.

(3) Our generation tend to think of the "web" as experienced primarily through a desktop or a laptop. We also like to think that we are at the cutting edge. We are not: these two year olds are.

(4) Rails is designed and used by people who experience the "web" through a desktop, and refuses to see where the world will be heading in the following years.

There are a lot more.

So yes. The direction Rails is going will lead it to its irrelevance.


You're backpedaling.


How am I backpedaling?


Sorry I was severely jetlagged when I posted that and don't remember wth I was thinking.

At any rate, I don't see mobile-first making Rails irrelevant. Rails has never been cutting edge on front-end development except at the very very beginning when they bundled the brand-new Prototype library. But by the time they hit 1.0, seven years ago or whatever it was, they were already going down dead-end alleys like RJS in an attempt to avoid javascript. Since then Rails hasn't done anything amazing with front-end development, but they've stayed relevant in their own way with the asset pipeline, coffeescript, and generally staying out of your way to implement whatever front-end strategy you like.

Server-side development isn't going anywhere, so I don't see how the shift to mobile makes Rails irrelevant.


I agree, this is a good example of why I think the complaints about criticism in the open source space need to be put back in check. Some are deserved, but these guys aren't trolls or well-intentioned idiots they're all trying to build the best rails they can.

I've been in and witnessed plenty of disagreements in closed source development, they always get much much more heated than this before someone pulled rank.


>I read that entire comment thread, and maybe my perspective is skewed, but I saw none of the behavior that DHH described there. The discussion was generally polite, the participants were mostly experienced Ruby developers with open-source and community track records, and their objections were well-supported. I have less sympathy now for the original post than I did.

My thoughts exactly. I read the DHH post first and thought, "I totally agree. That's why I like rails."

But the thread was perfectly civil and the people in it were experienced and well known in the Ruby world.


I think the analogy broke down somewhere in the upscale restaurant analogy, but let's continue with food joints.

In a town where you have only 1 big cafeteria (Rails), a pizza joint (Sinatra) and a few tiny snack stands, if you have friends, you'd probably have to get with the gang and head to the cafeteria for lunch. Now when the head cook decides to not offer disposable utensils anymore because of environmental concerns, but then the large Jewish community complaints about the bowls aren't kosher, then the head cook comes out and post a notice on the entrance that says, "If you can't eat out of the bowls I cleaned, get out of my cafeteria." Ok never mind, analogies can only work up to a point, it's almost 2013 and the world didn't end, chill out Rubyists...


>What is this post responding to? And who is the target audience?

People making comments like yours? E.g

>Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. We get it, Rails is "opinionated", sorry I guess we're saying "omakase" these days. Who really gives a fuck?

Well, a lot of people don't give a fuck, and that's the problem the post addresses. They want Rails to not be opinionated, or to cater to _their_ opinion.

>The reason DHH is getting loud complaints is because people feel that they carry a legitimate grievance but also feel no way to voice that opinion (or are trolls). Douchetastic talking down to them like exemplified in this post won't help (and will encourage trolls).

I don't see anything bad (sorry, I guess we're saying "douchetastic" these days) about the post. Sounds like a legitimate complain from the creator of a popular framework.

I also fail to see how people feel they "carry a legitimate grievance" but at the same time "feel no way to voice that opinion".

If they don't participate in the Rails project, then, no, they don't have a "legitimate grievance". They just have a personal grievance.

If, on the other hand they do participate, then they have lots of ways to voice their opinions.


I also fail to see how people feel they [...]

This is the kind of thinking I was referencing. You don't see it because you're not in their shoes, that doesn't mean it doesn't exist. It's fine and all that people do disagree, that's just the context for my post.

If you want someone to see things your way, build a bridge over the gap in their misunderstanding. DHH's blog post its just preaching to the converted. That's why I asked the context and audience. Saying "Rails is omakase" is a lot like saying "git stores a directed acyclic graph of revisions" or "A monad is just a monoid in the category of endofunctors". Almost nobody gets it unless they already get it, and the behavior he seemed to be complaining about was critcism from the unwashed masses. It just doesn't fit. I asked who gives a fuck because what small sliver of his audience is going to both understand what he is trying to express AND take anything new away from the post?

My initial read was wrong, because (to stretch his abused metaphor) he is actually talking about the fact his chefs and regular customers really seem to think 2 tsp of spice in the soup would be better than the 1 tsp he is insistent on using. Which makes his post make even less sense. He could have have ditched the flowery prose, meandering critcisms of criticism and just said "This is important to me, I'm pulling rank."


Maybe it's just something to link to when people complain to him about coffeescript (or any other Rails default) for the umpteenth time.


>The reason DHH is getting loud complaints is because people feel that they carry a legitimate grievance but also feel no way to voice that opinion (or are trolls). Douchetastic talking down to them like exemplified in this post won't help (and will encourage trolls).

I don't see anything bad (sorry, I guess we're saying "douchetastic" these days) about the post.

"My pet theory is that it feels like meaningful activism in the moment. They haven't really paid much attention to how things are run on a day-to-day basis, but here's an opportunity to paint some signs and get on the barricades. Yeah, I've done my part! I've taken a stand! Down with.. uhm.. Turbolinks? Or was it CoffeeScript we're protesting this week? Or Bundler? Oh fuck it, down with SOMETHING! YEAH!!!"

I mean, you really don't see this as douchey or talking down? How? To me it actually seems impossible to read that and say "Sounds like a legitimate complaint from the creator of a popular framework" unless you already had your mind made up DHH was right no matter what.


you're completely passing over the fact that there are people with illegitimate grievances, the response to which genuinely should be "well, don't use rails then". i thought dhh's post provided a good analogy for people who don't get that on a software stack level to relate to.


So? There are tons of people, including both rails core and ruby core contributors with legitimate grievances, in the exact thread in question, that are lumped in with this group DHH is mocking. Its an absolutely terrible analogy and is completely disingenuous to the current situation.

This summed it up best in my eyes:

"Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. "


> If they don't participate in the Rails project, then, no, they don't have a "legitimate grievance".

Why don't non-contributing users of a software project have a 'legitimate' opinion?

I wonder if this attitude in the late 90s / early 2000s accounts for Linux's level of success as a desktop OS.


>Why don't non-contributing users of a software project have a 'legitimate' opinion?

Because their opinion gets any legitimacy only by what you paid for it, either by money or work.

Some core developers of OSS are accommodating enough to listen to the opinions of random users, but this only happens if said developers are either:

1) really nice guys than enjoy the interaction and/or pushovers.

2) getting something back from it (i.e they play nice because they also sell support or extra stuff and don't want to alienate potential customers)

Other than those 2 cases, non-contributing users can have whatever "grievances" they want, but it means nothing at all.


> Because their opinion gets any legitimacy only by what you paid for it, either by money or work.

I think this confuses validity of opinion with obligation. Certainly nobody from Rails has any obligation to a stranger. But it's another thing to tell Rails users their opinions are invalid.

For the record, I run a reasonably sized OSS project and constant get bombarded for feature requests and free assistance. I'm not a pushover, I don't sell support (although I've been asked to) but I am polite to people and I do believe user's opinion carries some weight, because I want my app to be successful.

I know very little about Rails. It's just that 'Rails is Omakase' reminds me of 'Debian is By Developers for Developers', which didn't work out well for the folks that wanted Debian to take over the world.


I really don't understand this point of view - why release open source software if you don't care about your users, and only care about your contributors? To me you'd be better off NOT releasing it, and just keeping it all wrapped up and closed, then you wouldn't have to deal with the non-contributing users who want changes.

This is one of the fundamental problems around many (most?) OSS projects. The elitism that comes with believing you are somehow better than everyone else because you contributed, or started an OSS project.

This attitude also stumps your growth - many people who probably would contribute often end up staying in the shadows, not wanting to look stupid, or offend the sensibilities of the OSS team.

Perhaps a more welcoming attitude might not only make people more supporting of OSS, but might find you some more willing contributors as well?

What are you building open source software for, if not to be used by consumers? If you're building it for some sense of self-aggrandisement, why make it open source in the first place? Just keep it nicely closed, so that only the elite chosen few ever get access to it, and keep out those who's opinions apparently don't matter.

Open source (for many) is a way to pay it forward, and give back. Kinda strange that the very people you're supposedly helping by providing free software don't matter.


>I really don't understand this point of view - why release open source software if you don't care about your users, and only care about your contributors? To me you'd be better off NOT releasing it, and just keeping it all wrapped up and closed, then you wouldn't have to deal with the non-contributing users who want changes.

What is there NOT to understand?

You release it, because (not all at the same time):

1) You want and value the CONTRIBUTING users (that's your actual software's community).

2) You want it to be used by people but as it bloody is.

3) You want to make money off of it, and think the open source + support/extra services model works.

What I really don't understand are the complaints. Isn't one of the core benefits of open source that you can _change_ the source? If you don't like what DHH is doing, fork rails to your liking. But no, they want it there way AND in the upstream repository.


And that's exactly the reason Linux never took off on the desktop. It's very difficult to gain new users if you're constantly dismissing them and asking them to put up or shut up with code.


These things aren't built for users, they're built for developers scratching their own itches. DHH built rails for himself first, and happened to share it for those who like his way of doing things. If you don't like his way, use another framework.


>And that's exactly the reason Linux never took off on the desktop. It's very difficult to gain new users if you're constantly dismissing them and asking them to put up or shut up with code.

And it's also why lots of OSS developers could not give a flying duck is Linux took over the desktop or not. They do it for their own fun and benefit, not for some entity called Linux to gain market share.


That is a completely understandable view and one that I hold myself. However, it's difficult to hold that view, and then simultaneously complain about things like driver support, which only come from attaining a modicum of popularity.


> Because their opinion gets any legitimacy only by what you paid for it, either by money or work.

I'm sorry, but that is just fallacious. There are plenty of people who aren't involved in any given project, but would still be qualified to give decent advice.

Developers should consider random opinions, just not if they conflict with the direction of the software. If a number of users have similar grievances, that is an indicator that something needs to be fixed, or maybe the direction of the software should be changed slightly.

That's if the developer intends the software to be widely-used, of course


>I'm sorry, but that is just fallacious. There are plenty of people who aren't involved in any given project, but would still be qualified to give decent advice.

It's not about qualifications. It's about the willingness to hear them. I'd rather write my OWN project, MY way, that a better project in some other's terms. That's why people start their own projects after all.

So, the might be qualified, but the open source project creator could not care less about their advice, valid or not.

He might have his own opinions and long term ideas about the project. He didn't start to write software to be a slave to other people's ideas.

If he _wants_ other people's opinions, he'll ask for them.

And if he, like DHH, even posts a lengthy blog post telling them to shove them, then it's clear that he doesn't want them in this particular case.

>That's if the developer intends the software to be widely-used, of course

Developers can also intend for their software to be "widely-used" but only if it's _in their own terms_.

E.g RoR is widely used just fine, for example, despite being "opinionated".

So, "wanting your software to be widely used" does not necessarily imply that you "should consider random opinions".


It's contradictory that you would do whatever you like regardless of anyone else's opinions, ever and expect your software to be used by a large number of people.

Obviously you aren't obligated to accomodate anyone when you are doing your own project, even if you are doing your own project and then making it available publicly. But acting like a tiny dictator on a power trip is not the correct behavior if your purpose is to make a tool for public consumption.

If you want to "write your OWN project, YOUR way" you are not making a public tool, you are making a private tool that is available publicly.


>It's contradictory that you would do whatever you like regardless of anyone else's opinions, ever and expect your software to be used by a large number of people.

Who said you expect or want "a large number of people" in the first place?

You might put your project out there just for the potential valuable contributors to help with the code, not for the end users.

And one can imagine someone creating something unique with no regard for what people are saying, and still expecting them to embrace it. Because he thinks his vision is perfect or better than what exists. Kind of like Ford's quote "If I had asked people what they wanted, I would have given them faster horses".

But the problem with all the above is the absolutism. You don't have to "_never_ listen" as you imply. A project leader might listen to user opinions sometimes, and don't care at all about their opinions on other aspects of his program that he feels adamant about.

E.g it's not like DHH _never_ listens and does whatever he likes "regardless of anyone else's opinions". He only does that for FEW aspects of the project.

>If you want to "write your OWN project, YOUR way" you are not making a public tool, you are making a private tool that is available publicly.

Yes. A lot of projects are like that and people should understand that and respect your decision, instead of bitching about it.


You are the one that stated absolutely you shouldn't listen to random opinions, with rhetoric such as "If he _wants_ other people's opinions, he'll ask for them" and "developers can also intend for their software to be "widely-used" but only if it's _in their own terms_."


If you follow the mass of Rails community, you'll get it. Mostly. And perhaps this piece also explains how painful and yet very commonly faced situation (being trolled with expertise) this if for most open source creators/leaders in their line of work.

A sort of professional hazard.

Sooner or later, this has to get better I am sure.


Basically, here's the deal: this is a change that every member of Rails core (and others with commit, like me) who is not an employee of 37 Signals disagrees with, as well as the entire maintenance team of Bundler. Every single one. And DHH's response is that we all 'haven't really paid much attention to how things are run on a day-to-day basis.'

This change 'breaks every single new Rails app on Heroku that uses rbenv', in the words of Heroku's Ruby platform lead. It is not a trivial change. This is David going against the wishes of every other maintainer of every other piece of software Rails works with, as well as other Rails maintainers, and then painting their comments as 'nerd rage' and 'organizational failures.'

Ugh.


Since I cannot edit this post:

After lots of discussions in Campfire, we're working through all these conceptual issues as a team, and steps are being taken so that EVERYONE is happy with what happens with regards to this feature.


Why is it such a big deal? It's not like you can't add a line to gitignore?


Because sane defaults matter. Defaults that get in the way of people being productive are bad defaults.


Why does Rails do anything related to git anyway? What if I use some other version control system?


I think DHH's article succinctly addresses exactly your question from his perspective.


Alright, somebody has to draw the line somewhere.

Every time DHH goes off on one of his little rants and angers a lot of people in the process it's not just those people that get affected, and not just emotionally either. These Ruby [on Rails] dramas have a real-world impact on the rest of us, the hundreds of thousands of us that use Rails every day to make a living. It affects us in that it makes us all look like unprofessional schoolground children. Rails already has a stigma of "hipster" developers that tend to be up their own asses, and episodes like this really don't help our image. Especially not when the global developer community is not as massive as you'd like to believe, especially when people talk - to other developers, to potential and existing clients that then get per-conceptions of unprofessionalism, and to newbie developers that shy away and look into alternative languages and frameworks because they don't want to be associated with this wankery.

DHH's post, particularly the second paragraph, seriously comes across as if the core "team of chefs" is doing us all a massive favour and if we want to keep benefiting from the really beautiful thing that Rails is then we should shut the fuck up and take what we're given. Well this isn't Pyongyang (if we're going to play with metaphors) and DHH is not our dear leader. Yes of course I, and all the other Rails developers and immensely grateful for the framework's existence, but it's OSS now. There are thousands of contributors and so many more times commits than that to the projects since it did become OSS.

The community either needs a revolution or a fork because this downward spiral of foul air is just going to continue spreading and affecting us all. I'm sure if a couple of well respected individuals decided to take that route, a whole lot of people would back them up - I know I sure as hell would.

Pawel - a Rails developer.


>Pawel - a Rails developer.

I'd like people adding those kinds of claims to also give an estimate of how much they have contributed to the project.

I.e.

John S., Linux Kernel developer, contributed maybe 10 lines of code, or 0.0001% of the kernel source

or:

L. Torvalds, Linux Kernel developer, wrote the kernel code from scratch, that's my name on the project, biatches

Else, this "a Rails developers" signature tells us we should give extra credit to your opinion, but we don't know how much compared to DHH.

I don't mean it about you, Pawel, or your comment (I don't follow Rails that much anyway the last 2-3 years), I mean it in general.


Are you sure they're all claiming the same thing? Maybe one "Rails developer" actually works on the framework itself, while another "Rails developer" is a developer who merely uses it to accomplish something else.

Either way, you're looking at a brag-fest as people try to one-up each other. That can't be productive. I don't think any good would come of this.


Just read the whole thread here and on github (https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...)

Technical: DHH is wrong, plain and simple. No amount of defending the decision makes it right.

Community Management: DHH, while not as abrasive as Linus (another thread here linked to a kernel thread), IMO, DHH is (much) worse than Linus. Linus is abrasive and swears and yells. DHH is dismissive and condescending. DHH thinks he has better opinions, more depth of experience, smarter, more insight and generally "gets it" more than everyone around him, including the other maintainers.


> DHH thinks he has better opinions, more depth of experience, smarter, more insight and generally "gets it" more than everyone around him, including the other maintainers.

Well, he does. He's been doing Rails for literally 10 years now, so, strictly speaking, he is the most qualified opinion on the world in the topic of "Rails the application framework".

I agree that he sound condescending, but I understand his viewpoint. He's pushed a lot of changes through rails that at the time felt a lot like this one - a very vocal subset of the community got up and screamed bloody murder, and nowadays everyone realized it was the right idea.

Anyway, "DHH is wrong, no possible way he's right" isn't really a productive attitude to take in this discussion. He's been doing this for 10 years. Maybe you don't agree entirely, but DHH always has very good reasons for his opinions.


10 years is a long time, I'm sure we can all agree, but having the most logged hours doesn't automatically make you the most qualified opinion in the world. There is a vast realm of other factors that should be considered.

In my personal experience, oftentimes the people who have been around the longest are somewhat incapable of completely understanding an outside or new perspective. The fact that they often dismiss it because "I've been doing this for 10 years, I'm the most qualified" is a large part of that reason.


I really don't see how you could say he is wrong. It's his open source project that he's put thousands of hours into and is providing for free to everyone that wishes to use it. You might not agree with what he says or decides on, that's completely fine. In that case you're completely free to use a different framework. Plenty of choice out there.


I find it interesting that development products/projects are probably the only place where no one will allow you to have a valid opinion as a non-contributing user. And people will defend this lunacy to amazing extremes, presumably because it's easier to tell everyone to fuck off than to filter and respond to the valid points.

I find this a bit disappointing because in any other situation, feedback and constructive criticism is welcome and typically acted on, even if you weren't involved in the production process. You might not be listened to, but you won't be silenced by your peers.

To use the silly analogy in the OP: you don't need to be a chef to say the food tastes like shit.


It's not completely his. Other developers have put in much more than him alone into rails, and you need to respect them for that.


You're absolutely right. The thing is if, as he (DHH) writes in his post, if they were to make a suggestion he would take them very serious.


But they did, and he didn't.


So you don't think it is possible to have an opinion on a project you maintain and be objectively wrong in that opinion[1]?

For instance, the GNOME3 guys and the design direction they are taking. No matter what, they can't be "wrong" (whatever that means in this case) in that opinion?

I get that objective right/wrong can get complex and murky rather rapidly, though I feel with experience people can actually make judgement calls on these. And in this case, checking in binary assets is wrong, from experience. It causes many more problems that it solves. So, DHH is "wrong" in this instance even if he himself feels that it is the way to go.

[1] - "wrong" might have been an improper word to use, though for the sake of consistency, I'm going to continue ;)


This site doesn’t tell its encoding (neither via HTTP nor via meta tags), so my Firefox displayed the first sentence as “There are lots of ГЎ la carte software...”.

Also, I don’t understand why the article was written, every software developer makes their own decisions that not everyone will like — isn’t that obvious?


> This site doesn’t tell its encoding

Same problem here. So much for the master chef with a decade of experience...


This is just his blog. He's the chef of a framework, not an avowed HTML guru.

Have you seen the design for YCombinator.com? 1998 called and it wants its Arial font, <table> and <center> tags back. By your logic, YCombinator is worthless for helping Web startups launch.


Yes, but frameworks are supposed to solve issues like UTF8 encoding by setting up sane defaults automatically. If I wanted to deal with solved problems myself, I wouldn't be using a framework.

Also, YC's crappy HTML doesn't make the site less useful for visitors. This blog's poor unicode support does.


If you wanted your password reset for the first couple of years, didn't you have to email pg personally?


haha


Aren't all frameworks like this? The designer picks what he/she thinks is the best architecture and builds it around that idea. That's why there are a thousand different frameworks. I think DHH is experiencing what I call "Linus Hell." Which is the hell Torvalds has to go through every n amount of time when dealing with obtuse programmers.


From where I'm sitting, this isn't to do with the framework much. It's more that DHH has made a coding decision based on an assumption about how the organisation using the framework does its development: specifically in this case that it's forced all its developers to use the same ruby and gems provisioning system. That's valid for 37S, and completely wrong for a whole bunch of other places. DHH then says:

    It's imo an anti-pattern to have developers working on the same app use different 
    tool chains like that. If your organization can't decide on rvm vs rbenv, then 
    you have deeper problems than what binstubs are checked in to your repository.
and

    Second, if you are unable to use the same Ruby manager in production and development, 
    I feel bad for you. We rely on .rbenv-version to ensure that the same Ruby point 
    release is used in both places.
Now, say you don't force all your developers through the same toolchain, or you're not using the same Ruby manager in production and development. Given these opinions, how likely is it that at some point there's going to be a Rails design decision based on them which isn't so trivial, and which causes a lot of pain for anyone on the wrong side of them? The fear is that you could be organisationally barred from using Rails for reasons that have been totally irrelevant before now.

These aren't the cut-and-dry truths that DHH is presenting, although I can see the logic in them, and I think this problem has only happened because of binstubs, which are a really bad idea.


Hasn't Rails always been like that? The "Trust us, we know what's best for you" line of thinking. Its part of their marketing, because they sell the "magic" of Rails. It drives people to Rails and it drives people away from Rails. Plus, anyone who uses Rails in production and does not agree with the way the Rails people run things is just asking for trouble. When you choose a framework you dont do so because its popular or nice. You first check the culture behimd the development team and their credos. If they believe in backwards compatibility and you value that, then pick that one. But dont pick something becuase its cool and then argue when the people in charge make decisions that make no sense for you. Its your problem, not theirs. DHH can wake up one day and say that Rails will now be written in Algol. You either re-factor to Algol or jump ship. Either way, you were doomed from the start. Thats why Im always wary of programmers who join into a framework too quickly.

Not aimed at anyone in particular.


Well, that's the point. We're talking about rails 4 here. It's a mature framework at this point, and yet apparently here is the DFL saying that people who historically have had no problems running Rails are now - without warning - deemed to have made a mistake.

    Thats why Im always wary of programmers who join into a framework too quickly.
How long should a framework be given, then? Or is your point that anyone who picked Rails made a mistake precisely because it's an opinionated framework, and they aren't a DHH/37S clone?


Rails culture has always been about change. There is focus on backwards compatibility but its not job #1. If you can't change along with Rails, then you should not use it. DHH can do as he pleases because thats his framework. It powers his business. If he needs to change anything to fit his needs, then he will do so. Thats the culture of Rails.

I use Rails, and its a nice framework. But I'm not a fanboy. Its just another tool for the job. Just like Django, Symfony, Flask, Sinatra, Laravel, Slim, etc.

Now, I'm not getting into a pissing match with you. We are arguiing the same point, just from two different perspectives. I do agree that Rails 4 is mature enough. But the culture is not. And that's what keeps Rails from replacing shitty Enterprise frameworks. A shame because Ruby is fun to write and very powerful.


It's ruby. Just change your load path. The beauty of that language is that almost no one can really force you to do anything you don't want to do.


Not necessarily. Some authors think that the best thing they can provide is a small framework that does the most basic stuff and then you plug-in the rest of the components you need. An example of this is Sinatra where you get a router, some helpers and not much more. You choose your ORM, testing library, etc. Others (like Rails) choose to include the 8 AA batteries.

In general, this is aligned with the author way of thinking and it also applies to stuff like languages (think C vs. Java) or even window/desktop environments (Fluxbox vs. Gnome).


Not necessarily. Padrino [http://www.padrinorb.com/] builds a rails-style framework from components which are exchangeable. You get to pick your testing library, the templating engine and the orm of your choice. If you don't like the router you can swap it out. It offer more flexibility and freedom of choice in that respect, but on the flip side doesn't achieve the same level of deep integration. It's more "a la carte" in DHH words.


Rails allows you to choose your own testing framework [1][2][3] and plugins[4][5][6], templating engine[7][8][9], and ORM[10]. It's my understanding that before Rails 3, swapping out many default Rails was a bit hacky, but it's pretty standard now.

[1]: https://github.com/rspec/rspec-rails [2]: https://github.com/cucumber/cucumber-rails [3]: https://github.com/thoughtbot/shoulda [4]: https://github.com/thoughtbot/factory_girl [5]: https://github.com/nulldb/nulldb [6]: https://github.com/notahat/machinist [7]: https://github.com/haml/haml [8]: https://github.com/josh/mustache-rails [9]: https://github.com/stonean/slim [10]: https://github.com/brasten/sequel-rails [11]: https://github.com/datamapper/dm-rails [12]: http://mongomapper.com/documentation/getting-started/rails.h...


I know that and it's been posted often enough. However, the rails approach is fundamentally different from the padrino approach: Rails is very opinionated about which component should be used - as DHH stresses in his blog post. Padrino asks you when you generate your project. Both approaches have their advantages and disadvantages.


Changing the defaults takes 2 minutes in Rails. What's the problem? Besides, there are gems like Rails Composer [1], which allow you to create new projects based on a template.

[1] - https://github.com/RailsApps/rails-composer/#your-options


Nobody ever said it's a problem. It's a different view of the world, that's all.


And what is the fundamental difference?

You can tell Padrino what you want during the creation of a new project.

You can tell Rails what you want immediately after the creation of a new project. Rails simply saves you time by having sane defaults. Convention over configuration at its best.


Padrinos fundamental philosophy is to be a framework built up of independent components and with limited opinions. Rails is by default opinionated: You can swap out certain components but all in all you're expected to do stuff "The Rails Way". That's the difference. It may or may not matter to you and in many ways produce the same end results, but the approach still differs.


Padrino is excellent and does not get enough coverage.


I don't think that DHH is feeling that his experience is any different than other maintainers.

He's just trying to explain it to the masses. Maybe he's hoping that a few borderline whiners will catch a clue and decide to put up or shut up... maybe he's just venting.

Regardless, I sympathize with him. I love rails. I love where his leadership has taken the framework steadily over the years.


> that a few borderline whiners will catch a clue

Just so you know, those 'borderline whiners' are mostly other members of the core team.


Clearly this post is not primarily aimed at the core team, but the random people harassing him on Twitter and elsewhere.


Re: Whiners.

They never shut up. :)

Given the size and pop culture around Rails I think he gets to deal with more stuff than the usual maintainer. I mean, there are people who actively celebrate when there is a security issue in Rails. When github was hacked due to a foolish mistake people where celebrating! This is the sort of thing that keeps me from joining any Framework community. Fanboyism.


No. Others have pointed out a few, but I can't let Pyramid go unmentioned. The ideal framework; gives you what you need to bind your code to the web, without being obtrusive. You write pure Python with whatever components you choose or with the sensible defaults provided and use Pyramid's config systems to bundle it all together into a cohesive "website". It's awesome, and the only framework I've used like that. Truly simple (not "simple" like Rails, Django, or other frameworks where simple means "a million abstractions, assumptions, and exclusive language expansions that practically turn it into a derived DSL"), fast, and smooth.


I switched to Pyramid for this exact reason. Django and Rails were both getting in my way where as Pyramid is just as powerful but without getting in my way.


This is where interfaces come in, in OOP. Too bad Ruby does not have interfaces, and more importantly, Ruby people don't really understand interfaces and say they don't need them. And then they dare mock PHP, lol.


This is why I like the Clojure community, which in this regard is very different from Rails. Clojure has developed a culture that favors small libraries over monolithic frameworks. The eco-system of Clojure is all about picking and choosing among a variety of tasty dishes, which is the exact opposite of this:

"Rails is not that. Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework. The menu can be both personal and quirky. It isn't designed to appeal to the taste of everyone, everywhere."

The folks who like omakase are of course free to enjoy Rails. More power to them. I personally learn more, and enjoy more, when I get to assemble a different menu for each project -- a menu suited to the project.


Rails has a lot of moving parts, which is certainly daunting for the beginner, and having worked in it professionally for three or however many years it's been I have a certain cognitive bias going on here but bear with me:

What part of Rails is… monolithic? I don't understand this complaint. Rails 3 these days is pretty modular.

For the same reason I can't stand Sinatra et al; two-to-four hours into most projects I find myself saying "Oh yeah, I could really use an ORM, and some route helpers, and a view layer would be nice and how do I get this testing framework to play nice?" and before you know it you've wasted more time trying to cobble something together.


After you've done it once or twice, you will have a list of the components you prefer and that works for your style, as a starting point. I find that for my personal projects, that list is very different both in size and contents of what Rails pulls in.

Another big difference to me is coupling: In theory Rails might be modular, but because of what Rails is, while you may be free to tear out ActiveRecord for example, it takes very little before you're knee deep in dealing with shit from 3rd party code that assumes the default stack. If you can't rely on all the Rails plugins and extensions, and you want to replace a major component of Rails, then there's suddenly a lot less reason to use it at all.


The prevention of bikeshedding is one of rail's greatest strengths.


Same with the Node.js community. When I moved from Rails to Node.js, the focus on small libraries held together by an exceptional package manager was a huge breath of fresh air.

If anything, Rails poisons things in the Ruby community because the monolithic approach of the biggest framework in the community simply works against small libraries with small interfaces that are very compatible and remixable.

In fact, one of the best developments in the Ruby community lately has been the increase of other frameworks like grape, padrino, rack, sinatra, etc. I know some of these have been around for a long time, but it wasn't until Rails started getting long in the tooth that they started getting more and more attention.


You really can't lump Rack in there, given that it's a meta framework, and a meta framework to which Rails has been built around since 2.3.


Same with Symfony2. All of its components are decoupled and can be used as standalone libraries. They even have their own separate docs.


You're comparing a language to a framework. Rails is but one of rubys web-frameworks. There's sinatra and built on top of that padrino. There's camping, static page generators like octopress and that's just the web-world. Even rails is not a monolithic bloc: You can use activerecord or activesupport as libraries and rails itself uses a ton of libs itself. The ruby community values small libraries that can be plugged together to a bigger whole - and rails is basically a very opinionated collection of libraries with some glue code (and magic) to form a cohesive API. It's good for some kind of projects and it's certainly the oldest and biggest ruby framework, but it's by far not the only one.



But for agency type developers, where you are working on many different crud websites at once, you have different needs from a framework.

If you are starting your own startup then clearly you want to pick the individual libraries that best suit your problem. You have to deal with them for a long time and the payoff from a small improvement gets large. You write a little glue code and you are good to go.

If you are working on a large number of CRUD sites all the time then you want a stable set of libraries that cover most of the problems you will encounter and having scaffolding and other glue code replacing mechanisms is preferrable, even if they aren't as flexible or efficient or elegant as could have been done manually. When you write the same glue code over and over again you end up automating it, and generalizations have tradeoffs.

There is really no comparison between the framework needs of single site developers and developers working for a web agency or who are working on many sites or spinning up a few new sites a month.


Sounds like the trend is to follow Java (to certain extend, if you ignore the debacle of the old J2EE, Struts, and Tapestry).

ORM? Hibernate or JPA2 can be run anywhere: inside or outside container (i.e.: desktop app, web-app, or simply daemon/service)

DI? Spring or CDI

Unit-test? JUnit or TestNG or others

Mocking? EasyMock, Mockito

Message Queue? Pick one out there

Templating? JSP, JSF(ish), Velocity, FreeMarker.

RESTful? Restlet, Jersey

Everybody plays well with one and the other.


Not exactly. The current trend is towards the JVM, but not Java. I wrote about this last week: http://www.smashcompany.com/technology/the-jvm-is-part-of-a-...

Even the cutting edge of Ruby is now on the JVM, as Rubyists see a need for threads and find jRuby the most convenient way to move forward: http://tonyarcieri.com/2012-the-year-rubyists-learned-to-sto...

Rails took off in 2004 as a rebellion against the overly-heavy Java frameworks like Struts. But now what good ideas Rails offered have been incorporated into languages that run on the JVM, and a lot of innovation, in particular with concurrency, is happening on the JVM, and some of those things are areas where Ruby (other than JRuby) is weak.


I see 2 trends here:

Trend #1: modular components

Trend #2: platform (performance optimization as well)

What you described falls into #2 while what I refer to falls into #1.


there's sinatra and padrino for the pick-and-choose way. rails expresses the philosophy that it's more productive to pick a stack and stick to it, and then let the ecosystem optimise itself against that stack. it's true that the ruby webdev community has tended to coalesce around rails rather than sinatra, but that's because the rails community has solved a lot of genuine real-world problems that keep cropping up in its target space and has been able to write them as libraries that will work with anyone's rails setup.


DHH vexes me on a few issues but I respect his passion for what he believes Rails should be.

The conventions being enforced result in existing Rails code being easier to penetrate for new team members and more maintainable over time than was the case pre-Rails for web apps.

Rails is stronger for it.


But if you actually read through the github thread, you will see that DHH is going against conventional practice in this case.


The analogy here is just off. DHH might consider just saying "I have good intentions. Rails is my thing. I will ultimately make the choices but do consider feedback."

The reason the analogy is off: when was the last time you went into a restaurant and said, "i'm going to base my work/livelihood on this menu"? Never. Sometimes when I go for a meal I know what I want and I order that. Often I'm looking for an experience and I'll ask, "If the chef were going to die tomorrow what would they eat tonight?". Omakase is a formalized way to see what the chef recommends at that moment in time.

Rails is not the same as me going into a restaurant looking for a great experience at that moment. I might have a mind-blowing meal but I'm not going to base my livelihood on it.

I'm not saying that DHH or Rails are flaky. I am saying that comparing a serious tool for serious work to omakase/the whims of the chef does Rails a disservice.


DHH has long held that Rails meets his (Basecamp's) needs first, so the whims of the chef hold true. Implicit in this post was the idea that it's not the only serious tool for serious work, and if you don't like the chef's choices, you're better served in a different restaurant than complaining about the menu in this one.

Even if you've staked your career on Rails, it's important to realize it's your choice, but his framework.


He lost me at "á la carte". Incidentally, no proper unicode support is why I never used rails (or ruby) for anything more than a tutorial. Yes, that was a long time ago.


This is FUD. Rails actually does have UTF-8 support, and it's on by default, to the point of fixing bugs in IE to make sure everything is UTF-8: http://intertwingly.net/blog/2010/07/29/Rails-and-Snowmen


This has nothing to do with Ruby or Rails. Setting a proper HTML encoding (UTF-8) would fix it.


Another way to phrase this is that DHH forgot to add

    <meta charset="utf-8" />
Beyond that, the expression isn't "á la carte". It comes from the french "à la carte" (grave accent, not acute).


Hence "incidentally". Couldn't help but to make a connection.


Yes, you could help it. The connection you made applies to any language/framework.


There's an old saying that goes something like, the lower the stakes, the more bitter and destructive the disagreement. It goes along with that old anecdote about how the disputes among people involved in volunteer organizations are more charged than in situations where money is involved.

In this case, this drama was triggered by... a one-line change to the default gitignore file.


This 'low stakes' change breaks every single new Rails app on Heroku that uses rbenv.


Honest question: how popular is rbenv? Should I be using it rather than rvm? https://github.com/sstephenson/rbenv lists apparently bad things that rvm does; are those significant reasons to prefer rbenv?


It doesn't really matter.

I switched for a little while and ran into all sorts of path issues. As I was working through my issues, I noticed there seemed to be a lot of attitude around it and what I thought was unwarranted criticism of rvm. Soured me, and I haven't bothered with it since.

I'm sure it works great for some people though.


I personally use chruby.


Rails doesn't have to be a one size fits all framework if you use it as a web delivery mechanism. That is the point of the Obvious Architecture http://obvious.retromocha.com/ You can see an example "twitter" app here: https://github.com/RetroMocha/obvious_status

In the case of my example you could swap out the /delivery/web/app.rb or delivery/api/app.rb out for rails no problem. You wouldn't need to change any of the code in /app or /external to do so whatsoever.

Just because DHH thinks you should write your code one way and you don't agree doesn't mean you have to throw rails away entirely to have a different or better structure. Rails might be opinionated, but that's just like their opinion man.


I think it'd be funny if one day they even start prescribing the production environment via a Vagrant box.


So use Sinatra instead of Rails and create the stack and build system that works for you.

People are way too into Rails...


I don't know about you, but every time I've attempted to use Sinatra for a project, it's either been for something that wouldn't ever see the light of production, or I've just ended up with franken-rails.

We had this problem at work: a Sinatra app that had pieces and pieces of ActiveSupport bolted on, and it got to the stage where we needed a beefier database than Redis before the CTO eventually generated a new rails app and transplanted the Sinatra app on top of it.

It's all well and good saying "use Sinatra", but when you get to the stage where you're adding ActiveRecord because it's the most mature ORM out there, it's usually late enough in the game that you're actually writing a poor excuse for a Rails application.


I hear that sentiment a lot (I blogged about it here: [1]). Basically, "every time I use Sinatra, I ended up with franken-rails" means that Sinatra was either picked for the wrong reasons or misused. If you want to build something large based on Sinatra, for the love of $deity, please use organization systems people have built for you, be it Padrino, some Sinatra stack or something else. It doesn't mean that Sinatra is bad, but its often misunderstood.

[1]: http://www.asquera.de/opensource/2012/10/22/the-rails-monoth...


So use C and Assembler instead of Linux and create the OS and kernel that works for you. People are way too into Linux...

My point is - some of us are trying to build websites and get work done and were attracted to a full-stack framework so we didn't have to keep reinventing the wheel and so we can benefit from an ecosystem.


Changing predefined wallpaper is not reinventing the wheel. Neither is adding one line to `.gitignore`.


This isn't exactly a useful comment. I use both Rails and Sinatra frameworks (and some others) depending on the task. Under no circumstances would I blindly use one over the other without first considering the problem I'm trying to solve.


I've come to enjoy Rails defaults and "just solve the business problem" attitude, coming from ASP.Net MVC3 it's a breath of fresh air.

It's quite liberating to have things have a default naming convention and location. I can imagine it makes working on teams exceedingly easier other alternatives.


I think this an interesting point. I feel like the ASP.NET Web Forms stack got a bad name because it so closely coupled a web application framework with proprietary, abstracted, controls (which I agree was bad).

But an empty MVC4 application makes no assumptions about frameworks (JS, CSS, ORM, Tests, View engine, etc.), and yet it generates criticism that there isn't enough dependencies built-in. It seems MS can't find the middle ground.

I agree that it fragments open source projects (you won't find any two MVC4 apps that follow the same methodology), but I find the flexibility for an internal team to be more desirable than Rails.


Rails has become extremely popular over the years, but we have to remember that in the end it's a software created by a guy containing his particular beliefs. And this is great! A good web framework need its own set of core beliefs.


This is assuming that those who make rails are master chefs. This is debatable.

Also, the analogy does not hold well because at a sushi bar, the one who orders is the end consumer. Rails is a tool for developers so a more accurate metaphor would be I am the chef, my customer orders omakase and Rails supplies all my tools and ingredients. If those tools and ingredients are what I need to make my customer happy, then great. If not, then I'd prefer to throw them away and do it right instead of dogmatically defending my framework like it's a religion.


Who would you consider 'master chefs'?


Good question. Web development has been around for only about 20 years and changed significantly during that time (CSS, JavaScript, Ajax.) Cooking has existed for thousands of years so I would argue that there has not been nearly enough time for any master chefs to come into being.

That does not mean that many (mostly due to Dunning-Kruger) will claim to be masters and that even more will rush to the charlatans hoping for a magic spell that makes complex, new and continuously emerging technology easy without the need to learn or practice.


Granted, everyone should be able to choose their own tools. But different tools can sometimes (in extreme cases) create inconsistent behavior. And you don't want to see the consequences of that roll into production.

That's the one reason I wouldn't recommend each dev using a different package manager.

However, if we follow that logic, only experienced devs will venture to choose a different package manager. Which implies that he/she would be knowledgeable enough to edit his own .gitignore and whatnot.


I guess that makes Python/Django an international buffet.


Django does not accomodate all. The architecture is a bit more adaptive than rails, given the way the desginers allowed for plug-in "apps" inside the system. Aside from that, its the same stuff basically.


Huh, i'd say Django is LESS flexible than Rails, as it comes with it's own ideas about end-user UI (Rails does not).

Rails doens't have "plug-in apps" in the same way as Django, because Rails doesn't have "apps" at all, apps are what you build with Rails, not part of Rails.

(And Rails does sort of support plug-in apps in the form of 'engine gems' -- but there are no conventions for how different engines interact with each other, because Rails doesn't establish conventions for end-user UI, it consistently does not go to as high a level of abstraction as Django. This has plusses and minuses of course).


> own ideas about end-user UI

Really, like what? I don't consider the admin to be end-user and even if it is, its highly customizable.

Django is really more modular and customizable than people give it credit for. Perhaps, because it works one way "out of the box" and you have to look deeper and learn it to have it work some other way.


> Django is LESS flexible than Rails, as it comes with it's own ideas about end-user UI

what?

Contrary to Rails, Django never forced front-end solutions upon the user, and every suggestion on the dev list to do so is dismissed, which I'm in particular very happy with. The exception is admin, being a full-featured out of the box solution, but even there are some occasional talks about decoupling the orm/forms/admin and provide generic APIs.


"it comes with it's own ideas about end-user UI, (Rails does not)"

I can remember the Rails HTML helpers with Javascript mixed in and the framework relying upon Prototype.

On the other hand I can't find any example of Django forcing UI stuff onto the developer other than maybe the widget/forms rendering methods.


Don't see how Django apps are really any different from Ruby Gems/Plugins.

Furthermore, ActiveRecord is much less tied into Rails core than the Django ORM is to Django.[1]

[1] - Yes, you technically can not use the ORM, but then you don't get the Django Admin, which, frankly, is the only thing Django has over many other Python web frameworks.


Ruby gems are like Python packages. Django apps are very often not installable as Python packages.


Sure, in terms of features either available in core or through third party gems/apps, both Rails and Django are pretty much on parity. You won't find anything worthwhile in the Rails world to tout over Django, since there probably exists an equivalent (or if not a port is soon to appear). Likewise, this works the other way around.

What makes me personally prefer Django is the approach the developers take, which when compared to Rails is more conservative. If something is to change in Django, the old way generally gets marked as deprecated a few version prior, and changes are introduced to have limited impact. I mean, even when Django changed the base directory structure of a new project they made sure that old code with the old directory structure would still work in most cases.

For the new url template syntax in 1.5 (they changed it to fix an inconsistency with other tags, as well as to support a new use case to allow variables as an argument), a from-future fix was introduced early on (in 1.3 even!) so that people with slow moving projects could safely ignore the problem until they could get around to fixing it, while people with fast moving projects can adopt the new "correct" behavior early.

Not to say incremental upgrades are always painless, but the pain is limited and well documented. Things that can be introduced on the users schedule (like the new url template syntax), are.

In some ways, that could end up being a disservice. Django can't move as fast or change as much as Rails can. But really, that's what you signed up for. If you bought into Rails and now you're mad that the floor is moving, you really should've considered that in the first place. Likewise, if you bought into Django and you wonder why it doesn't have ZOMG coffeescript (or whatever) as a default, then you probably should have considered that. Personally, I'm okay with Django core moving slowly, because I can augment it with reusable apps that are able to move a lot more quickly.

You also don't see douchey posts from the Django developers. They generally show respect for competing frameworks, and aren't afraid to be critical of their own. There's a lot to like here.


Come on, this isn't how porn stars work! Now, someone diagram this discussion and put it up on slideshare.


There appears to be a lot of disgruntlement about rails lately. I like Rails but switched to Sinatra about 5 years ago b/c I didn't like Rails 2 and realized that the Rails APIs were a lot less stable than I'd expected.

DHH is right, there is no reason to complain.


Does DHH post regularly? His "Archive" shows 3 posts in the last 4 days, you'd think he'd have more history posting.

http://david.heinemeierhansson.com/archive.html


He used to have a blog called "Loud Thinking": http://david.heinemeierhansson.com/posts/archives


Probably related to Rails 4. Once it's gold, I'm sure he'll have less to say.


Just saw Tenderlove's tweet, which is pretty funny "while we're at it, we should check in the .so files too. Binfiles won't work so well without them."


á la carte. UTF-8. Use it :-)


I think what this guy is trying to say is that Ruby on Rails is . . . on rails.


Is anyone else suddenly craving some unagi?


> "Nobody ever got to have a meaningful impact on the direction of Rails by contributing no code and just showing up in a Github comment thread and yelling about the evils of CoffeeScript"

I think it sums up some kind of state of mind on the internet today. it's not just about software or programming.


eh, its kind of always been a meritocracy...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: