Posts Tagged merb
- Foy Savas, author or the “merb way” wrote a very well written post on “Rails monoculture”
- Pat Eyler, wrote an article asking if Rails and Merb would be better together.
- Ben Aldred, tell people to stop worrying and start loving Rails 3.
- fotonauts.com a Rails and Merb Photo website developed by an ex-apple team, was featured in TechCrunch. Fotonauts is the perfect example of an app that will bain a lot from the merge.
- Yehuda has been blogging a lot about every single step and even though most people are enjoying a well deserved break, you can read the details of the work started on the merge.
Basically, the work started, we are getting familiar with the rails code base and are optimizing things slowly but surely with a focus on testing JRuby. The Merb router is being optimized and ported over to Rails 3.0. Rails and Merb developers will be able to stick to their DSL (so we stay backward compatible). Merb bootloader is also being ported over without breaking the backward compatibility. Finally, ActiveSupport is being broken down in more manageable/independant chunks so people will be able to pick only what they want to use. A “mini” version is also on the work.
- Merb 1.0.7 got released yesterday with a bunch of bug fixes.
- merb_sequel 1.0 should be released sometime this week and i’m planning on adding rails i18n syntax support to merb_babel.
December 23, 2008, was an important day for the Ruby community. People who used to argue and not get along, have decided to sit down, talk and evaluate their differences. The end result is a strong collaboration of two teams who share the exact same goal.
Interestingly enough, the Rails community really embraced this decision and just got totally excited about the perspective of merging merb’s philosophy and expertise into Rails. If you re-read David’s blog post you can see that it’s a real homage to Merb.
The rest of the internet sounds pretty happy about the news, here are few posts:
Even Zed the entertainer thought it was a good thing:
I think a pattern emerged from the negative reactions:
- Why merge when we are about to win?!
- What does Merb win by being merged into Rails?
- Why not merge Rails into Merb?
- You are killing innovation by killing the competition
- You screwed us over and now I have to go “back” to Rails
- Rails 3.0 won’t even be as good as Merb 1.x
- The Rails team won’t let you do what you have to do to merge Merb into Rails
- DHH is a jerk
Let me quote Yehuda:Â “Calm yourselves ”.
Why merge when we are about to win?!
This is probably the most rational argument. This is also something the Merb core team considered for a little bit.
Merb is gaining huge momentum and the target audience was very reactive to what we did.
People such as Yellow Pages, Wikipedia and even Adobe started using or looking seriously at Merb because of its focus on modularity and performance.
We started building an elite community and we were pretty proud of that.
But take a moment to think about it. Our goal has never been to hurt or compete with Rails. Our goals were to get modularity, performance and a strong API. If the Rails team really wants that, and will work on it, why should we work against each other?
It’s not about winning or losing. It’s all about the long term plan of your framework, about the people involved and the community behind it. We had to take ourselves out of the equation and consider what would be good for the Ruby community.
What does Merb win by being merged into Rails?
People seem to easily find things we might lose but have a hard time finding things we are gaining.
Looking at it on the very short term, this is probably correct. The merb team will have to learn how to work with the Rails team.
We need to understand the reasons behind every single aspect of the code and find ways of merging things nicely.
On top of that, we still need to work on merb as promised. (see Wycats’ post)
However, in the long term we get all the benefits of Rails:
- don’t have to always justify why use Merb instead of Rails
But more importantly, we extend our team.
Most people using a framework might not realize what it is to work on a big Open Source project.
When you work on an OSS project, people come and go, and that’s why you usually have a core team of people you can rely on.
Merb has a lot of contributors but a small core team of 5 people (Yehuda, Carl, Daniel, Michael and myself).
Managing a project, such as merb, requires a tremendous amount of time and patience. Rails has the same problem with its core team of 6 people. People have lives, business, projects etc…
Joining two teams of experts in developing web frameworks in Ruby is like if in the next Soccer World Cup, the French and Italian teams would go on the fields at the same time to beat other teams. 22 players on 1 side, training and learning together. American readers, please imagine the Giants and the Colts facing the Green Bay Packers (I was told I don’t like the Packers).
Long term, you will get better quality and more frequent releases. We also have different world views and backgrounds which means we will learn a lot from each other, again that means better code for you guys
Why not merge Rails into Merb?
That’s actually a good question. We discussed maybe using merb-core as a base for Rails 3.0
The truth is that Merb 2.0 would probably be as big as Rails but more modular.
So we have the choice to keep on building on top of Merb 2.0 or deconstruct Rails.
As the Russians say: ‘Ð»Ð¾Ð¼Ð°Ñ‚ÑŒ â€” Ð½Ðµ ÑÑ‚Ñ€Ð¾Ð¸Ñ‚ÑŒ’, it’s always easier to take things apart
Rails already has a test suite, it has already been tested on the wild for a while and its internals are known to many developers. Taking apart the code to make it faster, cleaner and more modular is arguably easier than reinventing the wheel. At the end of the day it doesn’t really matter from which end you start as long as you end up with the same result.
Some people even asked to come up with a new name for the merged project. Meails, Mr Ails, Reverb, Reab were suggested. While I thought it was a joke, some people were really serious. Can you imagine if during the recent bailout, banks changed names every time they were purchased by another bank? People would be super confused and would not even know where to send their mortgage payments.
On top of that, Rails has a huge user base compared to Merb and has an immense brand recognition in the world at large, it would be foolish to throw that away.
Let’s not be chauvinistic and see what’s best for all.
You are killing innovation by killing the competition
Again, a good point but my question to you is: Should we stay in the competition just for the sake of it?
Rails clearly told us: we want what you have and we would love you to work with us. So the options were:
- tell them to go to hell and let them try to redo what we already did and know how to do.
- accept to work with them and make Rails a better framework.
Option 1 would keep the competition alive, but now you have 2 groups of people trying to do the same thing and being better at different aspects. The community gets confused and communication breaks.
Option 2: we lose the Merb vs Rails competition, but we double the amount of people working on Rails and therefore increase the change to make it better faster.
We went for option 2 and we know there is already some competition out there and there will be more coming up soon. I don’t think it’s realistic to expect us not to merge because we want to keep the competition going.
You screwed us over and now I have to go “back” to Rails
Yehuda will blog about some more detailed examples as we are making progress, but you need to stop thinking that Merb will just be absorbed into Rails.
If Rails just wanted to add some “Merb flavor” to Rails, they would have just taken whatever they needed and would not be interested in a merge.
See Rails 3.0 as a new generation of Rails, whatever we promised you for merb 2.0 plus all the goodies from Rails. Rails users will still have their default stack and all choices will be made for them (like in the current Merb stack). The difference for standard Rails user will be better performance, a static API and an option to go off the “golden path”.
Merbists won’t lose the stuff they like in Merb, stacks, full support for DataMapper, Sequel and other ORMS, jQuery or other JS library, opt-in solution using just rails-core, better core isolation, built-in RSpec and webrat support, slices, merb-cache, merb-auth and all the other key plugins that will be ported over.
To be able to achieve all of that, we will have to make some infrastructure and code modifications.
Rails internals should end up:
* way less magical (even Merb uses some magic, but we’ll make sure to keep it to a minimum)
* returning shorter and cleaner stack traces
* cleaner (required for the new API)
* better isolated (required to increase the modularity)
* alias_method_chain won’t be available at the public API level (we probably still will need some chaining mechanism internally, but that’s a different story)
So, no, you don’t have to go “back” to Rails. In fact, imagine you could do exactly what Rails does but with the performance and modular architecture of Merb. That’s what you will get with Rails 3.0.
Rails 3.0 won’t even be as good as Merb 1.x
I think I mainly replied to this question in my previous answer.
There is no reason why Rails 3.0 won’t be better than Merb 1.x.Â Actually, I believe our API will actually be even better. With the help of David, the existing Rails core team, and the Rails community, we will be able to define an awesome API that will change the way ruby web development will be done.
The merb API is great but we already know some of its limitations and we don’t have as many plugin developers to work with. Working with plugin developers is something I’m personally excited about. As a Rails developer I have been really frustrated when using 3rd party plugins and trying to develop my own.
Having a well tested, developed against, public API will make all the Rails 3.0 plugins so much better. And because Merb plugins already use an API, we will be able to port all the plugins over, so it will be at least as good as 1.x
Also, we are going to work on real app benchmark tests to make sure the performance gain is at least as good as what we have with Merb.
Migration will be easy and well documented. We are not giving up on the Merb book and it will be very useful to explain the Merb way to new comers wanting an idea of the new stuff in Rails 3.0. It will also be the best source of information to migrate your app to Rails 3.0.
Talking about migration, we promised to give you a sane migration path when it will be time to migrate.
Again, don’t freak out because we are changing the name, the spirit of Merb will keep on living.
The Rails team won’t let you do what you have to do to merge Merb into Rails
In all honestly, I was worried about that. I was wondering if all of that was not an evil scam planned by DHH to kill Merb as it was getting a good momentum. I like conspiracy theories and it sounded pretty good.
To my surprised, after a few private conversations with David, I realized that he was genuinely interested in making Rails better for people and fulfill the needs of people who need more flexibility.
Just re-read his blog post http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3. After what he said, how can he back up and just keep Rails the way it is? And why in the world would he want that to happen?
It’s a team effort and we have already spent hours and hours discussing some details. I can promise you that the Rails team is very excited about the new stuff that’s coming up. But don’t forget that it’s a merge and we are reconsidering some of the stuff we did in Merb to better re-implement them in Rails 3.0.
So far, I haven’t seen any of the Rails core team member tell us, no you can’t do that because that’s not the way it’s done in Rails or because we just don’t like it.
DHH is a jerk
Recently, in an interview I gave to rubylearning.com http://rubylearning.com/blog/2008/12/18/matt-aimonetti-why-on-earth-would-you-ignore-merb/ I mentioned that a big difference between Merb and Rails was the way we were dealing with the user base.
I quoted David from an Interview he gave to InfoQ http://www.infoq.com/interviews/David-Hansson back in 2006.
As part of the merging evaluation process we literally spent hours talking back and forth. I had a seriously hard time believing that Rails and David honestly wanted to change their world views. How can you go from saying what you said in 2006 to adopting what Merb is pushing for: letting the framework bend to make what each developer wants if he doesn’t want to follow the “golden path”?
Interestingly enough, David recently addressed this point on his blog. http://www.loudthinking.com/posts/36-work-on-what-you-use-and-share-the-rest
“I wanted to take a few minutes to address some concerns of the last 4%. The people who feel like this might not be such a good idea. And in particular, the people who feel like it might not be such a good idea because of various things that I’ve said or done over the years.”
First thing first, David addresses the minority of people worried about his image and what it means for them.
So, David actually cares about hard core merbists and he wants them to join the fun. I personally see this as something very encouraging!
A recurring theme we hear a lot is that Rails becomes whatever DHH/37signals needs/wants. If DHH needs something new, it will make it to Rails, if he doesn’t need it, it won’t.
David has a very simple and almost shocking response: DHH != Rails
David is really happy with Rails. Rails satisfies his needs but he knows that some people out there need/want something more/different.
“I personally use all of those default choices, so do many other Rails programmers. The vanilla ride is a great one and it’ll remain a great one. But that doesn’t mean it has to be the only one. There are lots of reasons why someone might want to use Data Mapper or Sequel instead of Active Record. I won’t think of them any less because they do. In fact, I believe Rails should have open arms to such alternatives.”
So, you can still think whatever you want about David. What’s important is that Rails is more than David. It’s an entire team of people with different needs and different views.
DHH isn’t a dictator and based on concrete examples such as the “respond_to vs provides” discussion, I can reassure you that David has been very receptive to arguments and never tried to force any decision because he thought it was better.
This is huge!
While people still try to find some drama in a hypothetical war between Rails and merb …
The Rails team and the Merb team announced today that they will work together on a joined version of the 2 frameworks. This is so exciting! Nobody believed it could ever happen (I personally, seriously had my doubt).
I have to say that I have been impressed by the Rails core team and especially David (DHH).
I’ve known David for few years now and we had long (sometimes heated) discussions on topics like i18n/l10n for Rails. David is known to be a very opinionated person. But if you come up with the right arguments, he can be convinced and when that happens, he is willing to move forward and shake things up.
This merge is a concrete example that David and the rest of the Rails team care about Rails and the Ruby community more than we usually give them credit for. As a unified team, we are going to change the way web development in Ruby is done!
But what does it mean for you?
I put together a FAQ video which, I hope will answer your questions.
Hi, I’m Matt Aimonetti from the merb core team and as you might have heard, a big announcement was made earlier today.
I did this video to hopefully answer the questions you might have.
Q: So what’s the big news?
- merb and Rails team will work together on the next version of their frameworks
- merb 2.0 and Rails 3.0 share the same common endpoint
- we realized we now have the same objectives and agreed on all the key principles.
- merb will provide Rails with agnosticism, modularity, improved performance and a public API.
- The end product will be called Rails 3.0 but what real matters is that it’s a huge gain for the entire community.
Q: What??? I thought there was a war going on between Rails and merb, what happened?
- There was no war between Rails and merb
- We created merb because Rails was not fitting us
- We wanted better performance, more choices/ more modularity and a Public API.
- The Rails team now embraces these concepts and want Rails to follow them, so why not work together?
Q: Wait, does that mean that merb is dead?
- Absolutely not!
- merb development won’t stop, we are going to keep on releasing updates until Rails 3.0
- clear migration path, and upgrading to Rails 3.0 will be as trivial as upgrading from Rails 2.x to Rails 3.0
Q: What does the timeline look like?
We just started getting together to discuss the technical details. We are shooting for a release at RailsConf 2009. However it’s hard to estimate this kind of thing so, again, that’s just an estimate
Q: I just started a merb project, so what now?
I’m sure you had valid reasons to use merb, you needed modularity, performance and a solid API.
Keep on using Merb, we won’t let you down. The good news is that the next version of merb (Rails 3.0) will be even awesomer!
Q: What about my client who was looking at using merb for his new project?
If your client is going to be using merb for valid reasons (and not just because it’s not Rails) they should still use merb, but with the full understanding that they will end up using Rails in 6 months or so. Again, Rails 3.0 will have what pushed you to use merb.
Q: I’ve been involved with the merb-book, what will happen with this project?
- Rails 3.0 won’t get released right away
- still need awesome documentation
- if we look at Rails 3.0 as merb 2.0, we can easily imagine how the current work can be extended to the new version
- Rails team will also include an evangelism team which I will be part of, so will be able to focus more on projects like the book
Q: I’ve been working on a merb plugin, what should I do?
Keep working on it! We’ll assist you with the migration process and the new solid API.
Q: What if I still have questions?
Come talk with me, or any member of the new team. We’ll be open to hear your questions, worries, frustrations.
merb always valued its developers and we will continue to do so but on a bigger scale.
Concretely, nothing changes for merb users. People loving merb should not worry. The way you build merb apps won’t change until merb2.0/Rails3.0. We will still work on your favorite framework and improve it.
Lori Holden worked on merb_sequel and we should release a 1.0 release of the plugin in a few days.
I’m sure this news comes as a shock for many of you, but try to not see Rails 3.0 as the way Rails is right now. Imagine a version of Rails with true modularity and agnosticism (sequel, DM and AR will still be supported) and the same type of performance as what you get with merb. In other words, the Rails world is about to discover the power of merb!
Here is what Yehuda explicitly says in his blog post:
- Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. [...]
- We will port all of our performance improvements into Rails. This includes architectural decisions that are big performance wins.[..]
- As of Rails 3, Rails will have a defined public API with a test suite for that API. [..]
- 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. [..]
- Rails will continue their recent embrace of Rack, which [..] 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.
I’m personally really excited about this opportunity. I had a hard time believing that we could work together but I was proved wrong. We have many challenges in front of us, but watching the two teams working together is very reassuring.
I’m also glad to see that we will have a Rails Evangelism team that I will be part of. I strongly believe that one of the many reasons why merb has been so successful is because we work and listen to our community. We have put a tremendous amount of energy into trying to understand what you guys need and what you like and dislike. In return, we have seen many people working hard on the wiki and the merb-book.
Can you imagine doing that with almost 4 Million Rails developers?
I’m also looking forward to working with a team and reaching to even more people.
Other news related to the merge:
- The RubyOnRails website will keep a trace of this historical moment: http://rubyonrails.org/merb
- The merb training scheduled for Jan 19-21, in partnership with Integrum, will still take place, and if you want to get a head start and learn about the things that will make Rails 3.0 totally kick ass, I’d suggest you join us.
If you have any questions, or if you want me to publicly answer questions on your blog please contact me. I’ll do my best to get back to everyone.
My favorite aspect of merb, though, is the stable api. It’s very comforting to know that by upgrading to the next stable point release of the framework that I’m not going to have things that break. This of course doesn’t mean that a stable and comprehensive test suite isn’t important but it is one less worry.
I would encourage people to try merb if they’ve been holding out at all. It’s a great time to get involved and the community is great, too. Also, I’ll be starting a merb podcast soon so stay tuned for that. Thanks very much for talking with me.
Today, Andy Delcambre is our featured merbist.
(http://engineyard.com) as a Software Engineer. I work primarily on
internal and customer facing projects. These projects are almost
exclusively written in Merb. At Engine Yard we take advantage of many
of the modular aspects of Merb. For example, we use Salesforce for
customer tracking and have a Merb slice which includes the DataMapper
adapters for Salesforce. This gives us the ability to interact with
salesforce from any application for free.
Ruby and Ruby on Rails for a while before I finally dove in. I worked
for the College of Engineering as a Linux Administrator and took the
opportunity to build my first rails application: a tool for managing
our automated deployments. This was a huge learning experience, I had
done web development in raw php before, but this was my first time
using a framework. It was both a bit overwhelming and a breath of
fresh air. When I graduated from University, I decided to pursue Ruby
and Rails as a career path and have yet to look back.
on Rails development company and was looking to do some open source
contributions. I had been hearing quite a lot about Merb in the rails
community, especially that it was smaller, lighter and faster. I
decided to look in the bug tracker and see if there was something
small I could tackle and found a bug with the way nil and false
default arguments were handled in merb_action_args. When my patch was
accepted I was fairly hooked. I have been submitting small patches
ever since. I also led the inline documentation team at the Merb
sprint in San Diego during the run up to 1.0
wrote a simple Merb app to manage the content on the Engine Yard
homepage and the blog is based on the Feather blogging engine, written
in Merb. My current projects are not yet publicly available but
should be very cool when they come out.
someone who works with merb.
Ever since that first patch to action_args, I have loved the ease with
which I can jump in and dig under the hood. I have dug down into the
router, the dispatcher, the form helpers, and the mailer, all without
much problem understanding the code.
Second, as a developer of merb applications I think the direction merb
is going with the heavy emphasis on modularity is fantastic. In the
app I am currently working on, we are using four different slices
right now. One of which is an entirely different merb app modified
slightly and mounted within the application. One is a custom
merb-auth strategy that we use internally that makes it much much
easier to maintain consistency for our internal applications. These
would be much much harder to integrate for most other frameworks. It
is so useful to be able to just plug in these small, specific pieces
merb. I am really ready for the day that you can mount entire merb
apps inside one another. Then, once everything uses merb-auth, I can
imagine mounting a blog and a cms inside the same “app” and have the
users shared across, automatically. How awesome would that be.
project just keeps getting better and kicking more butt. Thanks a lot
for including me in this series.
Merb is fresh. I find it carries a lot less baggage with it than Rails. Even better, the project is still small and I seem to get along quite well with the the other developers on the project.
I really enjoy helping projects push through to release and I was glad to be a part of that for Merb.
Sequel is a really wonderful tool, and I was finding that just not that many people in the Merb community were using it. I had a lot of experience with getting Merb and Sequel to work with each other, and figured I should share my experience with everyone else.
The good news is that the core team is working hard on improving the state of documentation.
You have the Merb Book on which I am actively work on with a team of 20 people (writers, editors and translators).
You also have the documentation browsing application we are developing to let you browse documentation based on where you are in your app.
Finally, you also have other resources like the Merb peepcode.
The point being that we are actively working on improving the overall state of documentation. However, if you wish to learn more about the internals, how to some more advanced stuff like writing plugins, building your own stack, knowing when to use what component, I would suggest you attend the training class that Yehuda Katz (Merb lead developer) and myself are giving in Phoenix, AZ, January 19-21.
This would give you a rare opportunity to spend time with some of people directly involved with the day to day development of the framework as well as other like minded developers.