Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

Rails and Merb Merge

Today is a fairly momentous day in the history of Ruby web frameworks. You will probably find the news I’m about to share with you fairly shocking, but I will attempt to explain the situation.

Before talking tech, and even going into the details of the announcement, I want to assure everyone that the incredible members of the thriving Merb community are top priority, and that this could not have been possible without every one of them.

Merb is an open, ever-changing project, and some its best ideas have come from not-core regular-Joe community members. It’s gotten where it has because of the community, and the community will get us even further in the future. Your ideas, feedback and even complaints will be 100% welcome in the future, just as they have been in the past. I believe in the tremendous value an open community and just generally open attitude bring to the table, and am counting on those things to continue ushering in the future of Ruby.

On to the news: beginning today, the Merb team will be working with the Rails core team on a joint project. The plan is to merge in the things that made Merb different. This will make it possible to use Rails 3 for the same sorts of use-cases that were compelling for Merb users. Effectively, Merb 2 is Rails 3.

What does that mean exactly?

  • Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. We will focus on reducing coupling across Rails, and making it possible to replace parts of Rails without disturbing other parts. This is exactly what Merb means when it touts “modularity”.
  • We will port all of our performance improvements into Rails. This includes architectural decisions that are big performance wins. This project will also include the creation of one or more benchmarking applications, so we can more clearly see what optimizations have real-world impact.
  • As of Rails 3, Rails will have a defined public API with a test suite for that API. This was one of the major differentiators of Merb. This will allow users and plugin developers to have a clearer, more stable API to build against. It should also significantly reduce plugin breakage from release to release.
  • Rails will be retrofitted to make it easy to start with a “core” version of Rails (like Merb’s current core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. Of course, Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.
  • Rails will be modified to more easily support DataMapper or Sequel as first-class ORMs. While ActiveRecord will ship as the default ORM, the plan is to make it drop-dead easy to drop in other ORMs without feature degradation (to the extent possible, of course).
  • Rails will continue their recent embrace of Rack, which is a really exciting development in the Ruby community that Merb got in on early and which we believe will improve the state of modular, sharable logic between applications.
  • In general, we will take a look at features in Merb that are not in Rails (the most obvious example is the more robust router) and find a way to bring them into Rails.

How will we do this?

The plan is to start working on Rails immediately, and to continue fixing bugs and resolving other major issues in Merb in the interim. We will also release versions of Merb specifically designed to help ease the transition to Rails 3.

In particular, we will do Merb releases with deprecation notices and other transitional mechanisms to assist developers in tracking down the changes that will come between Merb 1.x and Rails 3. Expect a number of interim releases that get incrementally closer to Rails 3, and expect parts of Merb (most notably the helpers) to be ported to run on Rails 3 in order to further reduce friction.

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.

If you’ve already learned Merb, we will be working hard to make sure that you can parlay that knowledge into Rails 3. At Engine Yard, we fully intend to continue using Merb for our internal apps until Rails 3 is out, but we will be using those (non-trivial) applications to be sure the experience is smooth for everyone. There will be no huge jumps and you will not need to rewrite your application from scratch.

Why!?

As you have probably gathered from the above, there aren’t any clear points that the Merb and Rails team disagree on anymore. Merb has been around for roughly two years now, and we’ve proved out our ideas by use in real-world applications (like Yellow Pages, SproutCore, Powerset, Defensio, etc.). Given this philosophical convergence, it just didn’t seem like there was much to gain by continuing to duplicate effort and spend time and energy fighting each other.

I think it’s important to acknowledge the Merb community for building something super-awesome. I really hope that we’ll all stay in this together, help each other in the coming months and in the transition to Rails 3.

Rails will be putting together a new evangelism team, which will include Matt Aimonetti (Merb core team member and evangelist) and a few other people doing Rails evangelism work. This group will be responsible for, among other things, helping the community get where we’re going. Their job will be to listen to you.

This seems crazy! Has this ever happened before?

Interestingly, yes. A very similar situation confronted the Struts developers several years back. They had built a very popular framework in Struts, but a very active group of developers were really advancing the same ideas in interesting ways in a framework called Webwork. The Webwork developers saw their project as “Struts done right”, just as we believe we’ve improved on the implementation of Rails.

Eventually, the Struts guys and the Webwork guys came to the conclusion that they would be stronger together then apart, and merged the projects. What became Struts 2 was effectively also Webwork 2, but the two communities got together to build something better.

I believe that this merger will get the ideas that gave Merb momentum into the hands of many more people, and that really serves us all. I’m looking forward to the future.

Postscript

  • One of the most personally gratifying parts of working on Merb has been working with alternative Ruby implementations to make Merb run well on them. Fairly early, Merb was running faster on JRuby than MRI, and I’m looking forward to bringing a lot of that insight to Rails, and helping to make Rails to be solidly competitive on the performance front with frameworks in “faster” languages.
  • The Merb Training is very much still on! We’ve spoken with the majority of the attendees, as well as with our partners at Integrum Technologies and they’re all really excited about the merger. That makes this training basically the first training focusing on the future features of Rails 3, and a great way to get ahead of the game. There are still a few seats open, so sign up now if you’d like to join us!

Tags: ,

178 Responses to “Rails and Merb Merge”

I too am having mixed feelings about this. I’m worried about having to learn yet another API. The stable Merb API was really great. Any idea what will happen with the following:

* Router — This is by far the biggest syntax difference

* Will Controller methods still render their return values or revert to Rails style Voodoo?

* Model and controller naming conventions?

* Slices — This is one of the best parts about Merb. How will it integrate into the Rails ecosystem? What will be involved in porting Merb 1.x slices to Rails 3?

* What will be the transition path from the Merb name space back to Rails? How soon can we expect to see transitional versions?

* How are resources being handled c.f post by ’til’

* Will there continue to be support for :formats as it exist in Merb? I’ve always found Rails support for this to be crude and tacked on.

This is great news and a very good thing for the Ruby community.

You mention – “The Merb Training is very much still on! That makes this training basically the first training focusing on the future features of Rails 3, and a great way to get ahead of the game.” Golden words that holds good for the “Introduction to Merb” course at RubyLearning too! Thanks to the Merb and Rails teams.

The best make up sex ever !
Congrats guys, glad it’s over, Rails3 Time

This is huge news. I have been eyeing Merb for a while because I really liked many of the ideas it espoused. But for the apps I have been writing, I couldn’t justify jumping ship to an even less common framework. Now I am looking forward to taking advantage of many of the good things from merb (modularity, slices, performance enhancements) without having to leave the Rails fold. Hope the merge goes well.

Hi,

These are great news.Ruby community is going to gain a lot. This is an effective step in my views when Microsoft is joining hands with PHP to make both of them safer in long run, when cloud computing is at its peak.

I think… Rails 3.0 should not kill Merb 2.0. How about adopting a new name for this framework and shaping up with a brand new identity. Adobe has taken over Macromedia but the DreamWeaver name still lives. In the same way…. Merb should not die.

MerbRails 1.0 will be a nice name with Rails 3.0 Merb 2.0 features. This way… one can keep themselves focussed on one framework only, rather than switching otherways. Plus… This will keep Rails and Merb alive for years.

Another important thing… A detailed Blog on what is supposed to change and what remains intact in Rails 3.0 and Merb 2.0 should be the main goal.

Thanks

I am not convinced. I do not think there was much of a reason to merge into one framework (Rails). It all comes down to $$$. Here are 2 entities (37S, EY) that make their business out of Rails, and Merb was coming in just too fast and too strong.

This is a business decision, which is fine.
I’ve been around way too long in the software business, longer probably than some of the people here have been alive. I have made decisions like this many times.

I chose Merb because my brain just does not work the Rails way. This post seems to imply Rails 3 will still do things the Rails way. I’d rather see Rails move towards Merb than the other way around. But it is OK if it doesn’t. The merge will definitely make Rails stronger.

I will have to wait it out. Just as this group of very smart and talented people created Merb, another group of equally talented and smart or smarter people might emerge with new alternatives.

TODAY:

Some guy – I think rails should do X.
DHH – No.
Some guy – The Merb guys did it, and X is better.
DHH – No.
Some guy – Why not?
DHH – I don’t want.
Some guy – I understand that, but why?
DHH – FUCK YOU!

DHH peaks into merb, and rails implements X with a stupid name.

TOMORROW:

Yehuda – I think rails should do X.
DHH – No.
Yehuda – But X is better.
DHH – No.
Yehuda – Why not?
DHH – I don’t want.
Yehuda – I understand that, but why?
DHH – FUCK YOU!

And we’re screwed. Until Merb reborn again.

@jc what in any of the posts led you to believe that Rails 3 will work “the Rails way”. The entire point of this exercise is to make it possible to use Rails in the way people like you like to use Merb.

Some specifics we provided include having a clear public API, making the core significantly more modular and decoupled (which will also make the core more readable), reduce the amount of code required to start up Rails, and focus heavily on perf.

Unless the Rails team is straight-up lying to me in dozens of hours of conversations, Rails 3 is going to conceptually please your way of thinking quite a bit.

@antares_trader:

> I too am having mixed feelings about this. I’m worried
> about having to learn yet another API. The stable Merb
> API was really great. Any idea what will happen with the
> following:

> * Router — This is by far the biggest syntax difference

Plans are already underway to port the Merb router over to Rails. At the very least, you will have the option to use the Merb DSL syntax instead of the Rails hash-based syntax. We’ll see which one becomes the default.

> * Will Controller methods still render their return values
> or revert to Rails style Voodoo?

Controller methods will be *able* to return values, like in Merb. So if you like explicit return, it will work exactly the same as it does now. No voodoo. render will return a string, and returning that string will do what happens in Merb.

If you want to return a raw string (“Hello world”), you will do something like respond(“Hello world”).

If you do not render or respond, Rails will fall back to implicit render. But this will not affect anyone who wants explicit return. If there’s enough demand, we can even allow you to turn off implicit return (to catch errors, for instance).

> * Model and controller naming conventions?

I don’t see any reason why we couldn’t support Merb’s naming conventions. Part of the plan is to make the Rails codebase less coupled, so there’s no reason the specific controller name (Foos vs. FoosController for instance) would need to be hardcoded. We’ll obviously be working out the specifics.

> * Slices — This is one of the best parts about Merb. How will it integrate into the Rails ecosystem? What will be involved in porting Merb 1.x slices to Rails 3?

Merb had already decided to replace slices with fully mountable apps. This would mean that any app could become a slice. The Rails team loves this idea and we’ll likely get it into Rails3.

> * What will be the transition path from the Merb name space back to Rails? How soon can we expect to see transitional versions?

There will be Merb 1.x versions that will explicitly help with namespace transitions. We will also port over things like merb-helpers so that they can be run in Rails3 without having to rewrite all your views.

We will likely start releasing transition versions as soon as the Rails3 API is more clear.

> * How are resources being handled c.f post by ’til’

I don’t understand this question.

> * Will there continue to be support for :formats as it exist in Merb? I’ve always found Rails support for this to be crude and tacked on.

I’m not sure what specifically you’re asking, but respond_to will get display-like powers. For instance:

respond_to(@obj)
respond_to(:html, :xml, @obj)

Congrats on the merge!

You’ve made me a believer of everything you support, starting with jQuery. I hope you’re right about this.

did you convince them to eradicate alias_method_chain? ;P

The day merb lost it’s independence…

Seems like an interesting and promising move, why not give it a go eh?

This is the beginning of the end. It is like Muslims joining the Christians and calling it Christianity 2.0 with Jesus as the default prophet and Mohammed as another first-class pluggable one.

What will become of Merb in Action? Will it become Rails 3 in Action?

Questions:

1. If Merb is so good, why not continue with it?

2. Why didn’t the Rails team join the Merb team instead and say Rails is the new Merb instead of the other way around? If this just a branding exercise and a way to cover DHH’s ass?

Wasn’t “because a monoculture is bad” a tagline for Merb back in the day?

Other than the expanded community, what is the benefit for Merb in this merger? What does Rails have to offer Merb? Just plugins and helpers as far as I can tell, and those are easily ported.

How much can be merged? And how much must be rewritten in Rails? Wouldn’t it be more efficient to scrap Rails and just rename Merb? I guess “Rails abandoned; team joins Merb” is a bit more jarring.

How many planned advancements are being put on hold while Rails catches up?

How soon until ActiveRecord and DataMapper are merged?

Will Rails adopt Thor usage as well?

Can we keep the green color? Red is overdone in the Ruby community ;-) And what about the mascot? His face already looks like an ill-fated merger gone wrong…

> Wasn’t “because a monoculture is bad” a tagline for Merb back in the day?

Yep. But that’s not a very good reason to have two teams working towards very similar goals, and consistently replicating each other’s work. Before the Rails team effectively came to agreement on the things that differentiated us, it was a very good reason.

> Other than the expanded community, what is the benefit for Merb in this merger? What does Rails have to offer Merb? Just plugins and helpers as far as I can tell, and those are easily ported.

The benefit is getting to work with other smart people on hard problems. Merb was awesome, but Rails has already solved some hard problems that we have yet to solve (i18n, timezones), and it seems like a good time to get everyone together and hash out what the future of Ruby looks like.

Instead of fighting while the future of Ruby plays out, why not get everyone in a room and plan it together. Sounds like a win-win to me.

> How much can be merged? And how much must be rewritten in Rails? Wouldn’t it be more efficient to scrap Rails and just rename Merb? I guess “Rails abandoned; team joins Merb” is a bit more jarring.

It’s just complicated. Full-on rewrites are rarely successful, and in this case I think it’ll be easy enough to make the substantial changes in place, which will ensure we don’t paint ourselves into a corner while working on Rails3.

I honestly believe that trying to port all of Rails’ features to merb-core would be more work than going back in and modifying Rails’ core to behave more like Merb. Of course, I could be wrong, but it’s hardly the black-and-white issue some are painting it as.

> How many planned advancements are being put on hold while Rails catches up?

None that I know of. The biggest one, mountable applications, should make it into Rails3. We already have some great ideas for how to implement it (which were hashed out with members of the Rails core team, the first big win).

Getting access to the bigger Rails community should make things like building the admin-panel easier, because there will be plenty of people interested in jumping onboard and helping instead of the core team having to shoulder the burden ourselves.

> How soon until ActiveRecord and DataMapper are merged?

There are no plans for that right now. Let’s first see how well the Rails/Merb merge works, but who knows!

Will Rails adopt Thor usage as well?

> I’m going to port the Merb bundler, which uses thor, to work with Rails’ config.gem syntax. This will allow transparent gem bundling in Rails. Merb currently uses rake for everything else, but if people are interested in using thor for more things in Rails, I’m certainly up for it.

> Can we keep the green color? Red is overdone in the Ruby community ;-) And what about the mascot? His face already looks like an ill-fated merger gone wrong…

Meh :P

Hi,

Can you focus more on the structure of New Merb 2.0 ( Rails 3.0 ) as soon as possible, giving us a sense of relief to avoid sleepless nights during great vacation.

Lets keep the fingers crossed that Rails does not kill the charm of Merb, just to meet old compatibility. Old versions like Rails 1.2, 2.2 can always be freezed and made to work.

Please don’t let new generations be the victims, just to support backward compatibility in Rails.
We are all born to move ahead and existing in the past will kill us.

Give something different and unique to the Ruby Community that has all the powers of Merb 2.0, and good points of Rails as well.

Ask for opinions on Forums and Blogs before killing something good in Rails and Merb.

Make a fast move with Netbeans community before they close their code for Netbeans 7.0, or else Merb community will miss the bus once again for another year

Time will decide, whether I am happy or a victim with this Merger decision.

Thanks

@solnic: This won’t slow down DataMapper development at all. We’re still working hard on the dkubb/dm-core branch and it should become the stable branch within the next month or so. Then we’ll begin to outline a solid roadmap for DM 1.0 and work will proceed as planned.

@Aaron: AR is obviously more mature than DM due to it’s age and real-world usage, and I think there’s stuff DM could learn from AR (which in fact we have been doing all along) but there’s no plans for an ActiveRecord and DataMapper merge.

However in the immediate future I could see some collaboration on the DataObjects side, but I still need to discuss that with someone on the Rails core team. Still, it would be sweet to have a nice, consistent foundation for AR and DM, and the sheer size of the AR community would bring alot more assistance to adding new DO drivers.

In the end, I think this will increase DataMapper’s community significantly, and help it mature even more quickly.

A very interesting development. I look forward to the results of such venture but I can’t help but wonder if DHH’ll continue to keep and reap the rewards of owning the Ruby on Rails trademark.

It certainly seems like a better deal from his perspective and not yours. I thought that Merb would eventually become the ‘next Rails’, and now certainly, it’ll become the next Rails.

The question is, what will Rails have, except for the branding and mindshare and perhaps ActiveRecord that Merb doesn’t have?

It’s an interesting decision, I just hope you reap the benefits, as you were already doing really well in my opinion, and were well on your way to being a very viable alternative.

Great, I’m really excited !

respect to the merb team for being so humble.
first develop this beautiful project –that i (together with datamapper) happily use for all my website projects now– by listening to the users constantly and improving upon common frameworks/libs in order to deliver the BEST out there (the thor/gem/install thing is god-sent).
secondly to be so humble to allow merging back into rails!

i think the rails community will benefit big time, it will be opened up by a fresh wind of merb.

rails people say: merb merges into rails.
i like to say: merb 2 will be the rails 3.

(i sold merb twice by saying it is the next-gen rails)

my fear is with the API.
rails 2 -> 3 will likely be a big step, but how big? probably not as big as rails -> merb.
i really hope the API will look more like merb than like rails.. i really prefer the merb API over the rails one.

butttttt… i shouldn’t get all passionate about this, and instead i should follow staint yahuda’s zen practice of humbleness. pick what is best for everyone (even those in ‘the other’ community).

these communities merged will result in one amazing community (culture) using the best framework out there, using the best programming language (ruby1.9). together with easy deployment by passenger, and the discussed super-slices, this is will soon be the worlds preferred website development platform.

thank you guys!
_cies.

Great news and bad news at the same time!
Great that we get a better, more modular and more lightweight Rails, which essentially is Merb, fully compatible with Rails.
The bad news is that the main competition is now gone. So what will be the the next competitor?
I do agree through that it’s mostly good news :)

Merage? Rails eats Merb, it is more properly

> > * How are resources being handled c.f post by ’til’
> I don’t understand this question.

My question, or rather note, was about a small detail of URL generation for resources: in merb when I want to create a URL to the resource of e.g. an instantiated user object, I’d do resource(@user) and it returns ‘/users/123′. Perfectly simple, does what expected – a single method where I can easily look up the docs or even the source. In rails I have to deal with magically created generator methods, in that example it would be user_path(@user), which was, at least for me, much harder to understand in the beginning. Not a big deal in itself, but symptomatic for ‘down-to-earth’ vs. ‘magic’ attitude which made me like merb much more than rails recently.

Another good example for this was talked about here earlier – returning a string from a controller action or calling render. I liked the way merb did this a lot and it doesn’t thrill me to hear that this behavior may become a not-default option in the future.

congratulations :)

Long as this endeavor doesn’t turn into a Perl 6 over-engineered-10-year-development-cycle that kills the framework, I’m all for it!

Stil, Yehuda wrote that controller methods will be able to return and work like it does in Merb. And I don’t see how it will become a problem if it’s not the default. The same way it’s not a problem to use HAML, ActiveRecord, or anything else non-default in Merb. Since the goal is for rails3 to be more modular I can’t see how this will affect anything.

Regarding the URL generation and documentation, I completely agree with you. The _path and _url magic in rails is a messy solution.

To me it feels like rails3 is gonna be a mammoth of a framework. To satisfy both rails and merb users there will have to be two solutions for a lot of things.

Is it effing APRIL FIRST?!

This is awesome news!

Congratulations!

Instead of Rails 3, can we call it.. mmmRails ???

Just a thought…

Somehow this reminds me of how big corporations work – if you are scared of a small competitor, buy it and “merge” it to death.

Diversity doesn’t seem to sound too good to the RoR team.

Back to JSF for me. Gets paid better anyhoo.

awesome news this is!!

I have the same question as Gary Blomquist:

What will become of the Merb in Action book that I just bought? Should I even bother reading the MEAP chapters?

Congrats, though. Hopefully this will work out to for the best.

@Gary Blomquist, @Eric: I definitely still think it’s worth a read, and may now even be *more* important to read, since the concepts and components it talks about will be part of Rails 3.

More pragmatically, I’m in talks with the publisher to determine what our next step is, and will post about it when it’s resolved. It’s the holidays, and lots of people are off work, but I hope to have something here within the next week or two.

Look, this is sorta bullshit. Unless the Rails team is really dedicated to removing poorly scalable “features” such as message chaining and a whole host of other monolithic performance killers too numerous to list here, this is a bad idea. From what I’ve read so far, this is not the case.

Look, I like both projects. But the it seems clear to me that a lot of dedicated merb developers are getting the shaft by some very self-serving interests (Engine Yard VC’s, book marketing, etc)… At the end of the day, this may very well be about the ego’s on top trying to grab a piece of the “I built it, it’s mine” spotlight at the expense of the hundreds of dedicated unnamed developers that contributed thousands of hours to make things better. So much for open source…

The big problem, as always with Rails, is DHH: a vainglorious, two-faced prima donna with a massive and fragile ego. He’s good, but not nearly as unique and amazing as he thinks he is.

I went to Merb to get away from DHH. Ugh.

I’m nervous about this for a number of reasons, as a lot of people tend to. Bigger teams and communities always mean more compromises. However, if the Rails guys approached y’all, and they want to make this work, what can I say?

I like Merb so I trust Yehunda and da boyz wouldn’t have jumped into this if it didn’t seem like a good idea. I’m cautiously optimistic.

I don’t understand all the real fuss though. Merb is open source. I think what bothers me is that the people who are quite negative toward this are upset that their free ride is gonna be gone. “Who’s gonna fix my bugs!?” It’s open source. If Rails 3 doesn’t do what we want… we’ve got Merb. It can be forked, expanded, modified so long as there’s a sufficient number of people willing to do so.

My main worry is that I’ve REALLY liked what I’ve seen and read from the core team and the philosophy and direction of Merb. I’m just afraid that a bigger committee my inhibit that. But, like I said, I trust the core team and I think if this is all done right the final product will be quite nice.

So, more than anything, good luck Yehunda! I’m pretty new to this whole Merb and Ruby game, but I’m gonna try and be a help, even if it’s limited!

I don’t know if it’s a good or a bad thing at the end. But at the moment I think it’s great news. I really look forward to Merb 2.0 / Rails 3.0.

It really came as lignthing from a clear sky. I checked twice to see if it’s some kind of prangster-day.

The people who know most about the two frameworks made this decision. And I’m confident they thought it through `till it hurted and made a right decision in the end.

Any chance the merb devs will take the “opinion” out of rails?

Personally, I feel that I wasted much effort and resources developing merb-slices and convincing others to do the same.

I, for one, love developing with Merb. Can’t say the same for Rails. From the terribly out of date “documentation” scattered across various blogs to my apps breaking with each new release, my experience learning Rails left me wanting for something better. I found exactly what I was looking for in Merb and began learning to code Ruby the right way by example.

I still believe that monoculture is bad and that everyone wins when there is competition. Hanging the Merb flag on the Rails ship flies in the face of this basic principal.

My suspicion turns to the fact that almost every Merb core team member is owned by Engine Yard. Something doesn’t smell right.

It’s too bad that we’ll never know what developing with Merb 2.0 would be like. Merb 1.0 is solid and had a promising future.

i hope the gooder parts of merb show through in the ‘other’ parts of rails. at least you both appear to be in the holiday spirit. and for that, to both of you — http://web-poet.com/2008/12/24/fun-and-frolic/ — i hope you like it

@uipoet the Merb slices effort brought back engines (done right) in Rails, and our plans for mountable apps (any app can be a slice) are planned for Rails3. Seems like a win to me!

> Look, this is sorta bullshit. Unless the Rails team is really
> dedicated to removing poorly scalable “features” such as
> message chaining and a whole host of other monolithic
> performance killers too numerous to list here, this is a bad
> idea. From what I’ve read so far, this is not the case.

Where have you read that? I’ve specifically addressed your concerns in posts above. DHH addressed the concerns on his blog and on the RoR blog. The Merbist addressed them. Yes! we are doing major architecture work on Rails. I don’t see where you’re seeing anything to the contrary.

> Where have you read that?

DHH Specifically said this wasn’t going to be a huge re-write (saying: “It’s important to understand, however, that this is not a “big bang” rewrite of Rails.”). To us looking in that doesn’t look like huge changes are coming to rails. It looks like Merb is being changed.

I think DHH saying that means we aren’t going to throw Rails away and rewrite from scratch. It doesn’t mean that there are not going to be a lot of changes. You are getting too emotional and reading way to much into words.

Amos: precisely.

“This is not a big bang rewrite
It’s important to understand, however, that this is not a “big bang” rewrite of Rails. We’re far beyond the time when we could just throw out everything and start over. This is going to be a progressive improvement of Rails that’ll carefully judge new initiatives on their impact on backwards compatibility as well as their general utility.” – DHH

I think Yehuda has called merb a framework for building web application frameworks with a pretty good default implementation. I think it would be beneficial if architectural lines were drawn in the sand in advance so that no one’s ego is bruised along the way. If the merb guys could focus on what they have always focused on, building a kick-ass framework and staying close to the metal, the rails guys could work on what they have always worked on (making it efficient for rapid development). I would have thought rails 3 would have been merb 2 rails compatibility when i first read the announcement. After reading DHH’s post I was not so sure.

Based on some of the Comments Ezra has made, I was under the impression that merb was created because a complete rewrite was easier than trying to fix the squirrel code he set out to fix in rails in the first place. I guess Rails has come a long way since then, but the bottom line is that Yehuda and the merb core team are closer to understanding what this merger means than anyone else. I am happy to take it on faith that they are on a beneficial path for everyone concerned, and hopefully the big picture will become clearer for the rest of us soon.

Tim

i have a bad feeling about this.

what about alias_method_chain? yehuda’s strict interpretation of modularity and truth in monkeypatching is extremely comforting. no, it’s more than comforting, it’s something people can believe in. it’s clear to me that rails will benefit from this, but i don’t see the reciprocity. what do we (merb) gain? more document writers? bad trade.

i feel like there’s a huge piece of information missing here. merbists actually disdain most of the fail inherent in rails. why are you guys so gleeful about this?

Leave a Reply

Archives

Categories

Meta