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.
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.
If, heaven forbid, Merb's best doesn't make it to Rails and it falls fallow, I have a hunch Merb takes root again. There are too many SCM clones and forks for it to disappear. Granted, time and energy is lost. Yet along the way, there'll be another Merb. Sometimes a spoon is a better fork.
How can the Ruby community splinter between two competing web frameworks? The entire Ruby-using population does not need to agree on a web framework. There can be smaller communities around various projects and frameworks within the Ruby community. In fact, I would think that it would be vital to Ruby's advancement and evolution.
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.
That's a completely valid problem, but at best it's debatable whether it applies to Ruby web frameworks. There's not exactly a plethora of mature web frameworks available. Rails and Merb seemed to be the most firmly established frameworks with a few others like Sinatra, Camping and Ramaze sprouting up.
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?
Well, Rack is really changing a lot already with Ruby frameworks. Sinatra is becoming more popular for highly specialized apps, and now you can embed Sinatra and Camping apps into other Rack apps, which includes Rails edge apps.
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.
This is informative. I had never heard of Rack before. It seems very similar to Python Paste. Neat.
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".
I agree that competition is good. There is (was) concern that loud, shallow, infantile arguments of Merb versus Rails were damaging, to an extent. If nothing else, they were really, really annoying, and too frequent. This may be the "splintering" of which john_dahl was speaking.
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.)
Impressive! How often do you hear about two open-source projects merging? Forking is much more common. I can't even recollect other instances of merging.
Best of luck to the two teams with making it work!
Compiz and Beryl. Beryl forked from Compiz and, if I remember correctly, relations were very sour between the two projects. Several months later they merged into Compiz Fusion.
This is the best comparison. Struts was great when it came out and inspired a lot of 2nd gen frameworks like Webwork. Webwork was very clever and much improved over struts. However, struts was far more popular. Bringing the two together created a better product that was adopted by the mainstream java web developers. It was a great way to get the developers that were stuck on struts (for whatever reason, most likely to support existing code bases) into a better design.
In about a year I could write the paragraph above substituting rails for struts, merb for webwork, and java for ruby.
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?
Yes, but someone needs to step up and build a community for it to be a viable fork.
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.
Yes, it means Rails will feel more like Merb. From the article:
"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.
I love this. I was just torn about learning Merb and worried about how the Rails community was slowing down. This should inject some much needed energy as well as introduce some of Merb's awesome features into Rails. Great move.
My brain knows it's the middle of December, but I had to check to make sure it wasn't April 1st. This is exactly the type of headline we see every year on April 1st. Crazy that it's real.
I once heard someone suggest that the "Rails" architecture should just be a standard that could be implemented for any language. This seems to be a step in that direction. Sounds pretty good to me.
So, I posted this on one of the threads for other blog posts about this, but that tread doesn't have much going on, and I want to see what people have to say about it:
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.
There are plenty of people in the Ruby community who avoid Rails (whether their reasons are valid or not). I think you'll find plenty of Rubyists who wish to create things outside of Rails. Whether that means they will be throwing weight behind another framework such as Ramaze, or creating a new one, I can't say. I do believe that there are enough anti-mainstream hackers in the mix now that you don't have to worry about that "scene" dying.
You're one of them, to an extent, and there's nothing wrong with that. Have at it.
this is huge. and it turns out that yesterday i was considering learning merb instead of rails. but for the moment i will learn rails. what is the best one to learn at the moment in order to be ready for rails 3?
Both. They're both Ruby. The learning curve for one over the other changes very little ultimately.
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.
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...)
56 comments
[ 4.6 ms ] story [ 125 ms ] threadI'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.
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.
Exciting to see some smart people uniting over respect for a common problem.
http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-in...
http://yehudakatz.com/2008/12/23/rails-and-merb-merge/
http://rubyonrails.org/merb
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...
Merb: Nooooooooooo!
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.
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.
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...)
http://www.benchmark.com/news/sv/2008/10_21_2008.php