Rails and Merb Merge
yehudakatz.com
yehudakatz.com
For someone who loves Merb and had decided to leave Rails behind (as much as possible), I have very mixed feelings about this. If this means Rails will start to feel more like Merb, fantastic! Otherwise?
I have a feeling it'll be a long while before I really know how to feel about this...
It'll be interesting to see how well this merger actually works in practice. It seems like when large companies merge the results are often underwhelming. Can a merger of large open source projects work? Will the different cultures clash?
There's a difference between someone forking Rails on GitHub so they can say "look at me, I maintain my own fork of Rails" (like 99% of those Rails "forks") and a legitimate open source project.
"To be perfectly clear: we are not abandoning the Merb project. There are many production applications running on Merb that are relying on both timely bug fixes and a clear path to the future. If you’re using Merb today, continue using Merb. If you’re considering using Merb for a project because it works better for your needs, use Merb. You will not be left in the cold and we’re going to do everything to make sure that your applications don’t get stuck in the past."
What this really means is that Merb will do what they should as an open-source project: Integrating with another. But for Merb's changes to Rails to be effective, they will have to continually improve Merb in isolation. Merb's going nowhere.
"As you have probably gathered from the above, there aren’t any clear points that the Merb and Rails team disagree on anymore."
Basically, Rails is being reworked to be more modular, to have less tight coupling among components, to have a defined API and test suite, to support other ORMs, etc. These are the reasons Merb came to be, and the merge back into Rails vindicates the Merb team's design decisions.
http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-in...
http://yehudakatz.com/2008/12/23/rails-and-merb-merge/
http://merbist.com/2008/12/23/rails-and-merb-merge/
http://brainspl.at/articles/2008/12/23/merb-is-rails
http://loriholden.com/archives/2008/12/23/16-merb-is-rails-3...
http://mornini.wordpress.com/2008/12/23/rails-2x-merb-1x-rai...
http://splendificent.com/2008/12/the-merb-rails-merger-annou...
I'm mixed on this. One of the strengths of Rails was that it was the dominant Ruby web programming framework. This meant that virtually the entire community was behind Rails when it came to web app development - unlike some other languages, which have several frameworks competing for the crown. But Merb has recently started to give Rails a run for its money. Fortunately, the learning curve between Merb and Rails is relatively small.
So on the one hand, it's great that the Ruby community won't splinter between two competing frameworks.
But on the other hand, Merb was really creative and innovative, and I'd hate to see that innovation slow down as it becomes the Establishment.
All innovations either become Establishment or remain obscure. I'm perfectly happy to see Merb go Establishment. If it doesn't work out... it's not as if the project won't be forked again.
Innovation won't stop. It will just have a different name and perhaps some different principals.
That's exactly my hope.
You mention that Rails being the dominant web framework is a strength and in the same sentence remark about how with other languages there are multiple competing frameworks. How, exactly, does this negatively impact developers? On the flip side, how does a merger between Rails and Merb positively impact developers? Developers who don't like Rails had an alternative in Merb and vice versa. How is the elimination of a choice a good thing?
The way I see it, competition here is only a good thing. Why would anyone want Rails to be the only option-- or even the de facto standard-- when it's been shown to be exactly the wrong tool for the job in several high profile scenarios? Don't get me wrong-- I'm not bashing Rails. I'm just saying it's a good thing to have a few more tools in the toolbox. When your only tool is a hammer everything starts looking like nails.
I think the too much choice problem applies much more when you're installing a Linux distribution and you have to choose from 40 different text editors or IM clients. Who has the time or the inclination to evaluate each one?
Basically what's happening is that everything in Ruby is already becoming more modular, shifting toward organized APIs, so this helps move in a direction where you can basically build a customized framework like legos out of a bunch of gems and specialized apps without spending an inordinate amount of time trying to patch things to work together.
However, I don't see what this has to do with my original comment. It doesn't address any of the concerns I raised about the john_dahl's comment. Specifically, I'm wondering how several competing web frameworks results in splintering of the Ruby community. Isn't competition good? Don't we want a variety of tools that meet different needs?
I frequently see Merb mentioned as an alternative to Rails in response to some gripe about Rails. Developers obviously have needs that aren't met by Rails. So my question is how is this merger a positive thing for developers? What's wrong with having several tools that are used for different scenarios? Of course, 100 competing web frameworks that are essentially all the same doesn't do anyone any good, but surely there's nothing wrong with several if they specialize in different areas.
john_dahl's comment essentially applauds the merger as a unification of the Ruby community and implies that it's a disadvantage to have competition. Is that really a good thing? Developers don't benefit one iota from having a "winner".
There are other frameworks, although they get little "press", as they lack an Engine Yard or 37signals hype-machine. In fact, if you visit ramaze.net (one of the more mature frameworks) and scroll down, you can find a listing of all the frameworks of which the ramaze people are aware. Twenty-one, including Merb AND Rails, at last count. (It is likely that not all of them are wholly distinguishable from one another. I can't say, as I haven't tried them.)
Best of luck to the two teams with making it work!
In about a year I could write the paragraph above substituting rails for struts, merb for webwork, and java for ruby.
Merb: Nooooooooooo!
Exciting to see some smart people uniting over respect for a common problem.
I'm a merbist and think this will be good for both the Merb and Rails communities.
That said, I'm a little afraid it will shaft the other Ruby frameworks (Sinatra, Camping) and possibly straight ruby too. People might make interesting things only compatible with Rails.
When Merb was a pretty big, active minority, it was more compelling to go out of one's way to make interesting libraries (ORMs, gems, etc.) easily compatible with anything ruby.
Now, people might at the least write things specifically setup for use w/ rails in such a way that it's inconvenient to nonrails ruby, and at worst make Rails plugins for things that could be useful libraries for all of Ruby.
Rails is gaining modularity, but I fear Ruby overall might lose it. Even after Rails and Merb merge, rails!=ruby.
You're one of them, to an extent, and there's nothing wrong with that. Have at it.
Edit: I wrote the orginal comment in a hurry - but what I was getting at was that Engine Yard took quite a bit of cash from Benchmark. I somehow doubt that a move like this could have happened without their approval, and I have to wonder if they instigated it (and why...)
Merb has become the 'go to' framework for Rails developers like myself who are unsatisfied with several Rails design choices.
However, the technical differences between the two are actually not that big. A merge of Merb and Rails concepts sounds like a good thing, all 'round.
Three cheers for open-source development and civil relationships between developers.
In practice, however, Merb docs, tutorials, articles, howtos, et cetera, are lacking. That is reality. If you're starting from scratch w/ Ruby and her frameworks, you'll probably find Rails more newbie-friendly from a learning-materials standpoint.