We’re going Camping! FiveRuns is proud to be a Kick-Ass Sponsor for MerbCamp, to be held October 11-12 in sunny San Diego. Before we head out, we thought it would be fun to celebrate the framework by looking back at what some of the insightful (and enthusiastic) things that our Rails TakeFive interviewees have said about Merb along the way.
And, stay tuned, because we’re also making an exciting Merb-related announcement on Friday!
Karel Minařík, independent web designer, developer, instructor, and organizer of the Czechoslovakian Ruby Users Group:
“Merb to me is above everything a much needed competitor to Rails. Because without competition you risk inertia — the only motivation factors remaining are pride of your work, commitment to users, such things. You obviously still can deliver amazing “product”, but it’s more and more fragile as time goes. So “Go, Merb!” (particularly the slices and parts ideas), as far as I am concerned :).”
Mike Subelsky, OtherInbox:
“I love Merb and think there are many applications where people are using Rails but should be using Merb, because they don’t need the entire Rails stack, or because they are doing something too custom and unconventional and end up having to fight with Rails. The agnosticism simply means that Merb leaves more decisions up to you, though there are still plenty of conventions available if you want them in Merb—more and other gems.”
Jamie van Dyke, Parfait (and ex-Engine Yard):
“Rails is a very opinionated framework. Opinionated in the sense that it chooses tools for you and expects you to use them. That’s all well and good if you like them, but if you prefer a different method of doing something then it’s a matter of overriding the internals of Rails and creating a fragile work environment. Nobody likes to update Rails and find the plugin they’ve been using and rely on, doesn’t work. Personally I prefer testing using Behavioural Driven Development, specifically with RSpec. For this I have to use plugins in Rails to override the default Test Unit that it assumes I should use. This is exactly what Merb solves. Merb doesn’t assume you want any particular testing framework, it allows me to choose. The same goes for the templating language and javascript etc. It’s nice to have the flexibility to choose what suits me best, rather than the framework developer.”
“At Engine Yard we had many customers who used Merb alongside their Rails application. Most of the time it was to solve the problem of file uploads, which in Rails lock the entire thread. This means that when you have 3 mongrels running Rails and 3 users decide to upload large files at the same time, everyone else visiting the site is put in a queue waiting for the file upload to complete. Merb solves this by doing file uploads in a separate thread, allowing other requests to continue. There are many other uses for thread safety, like long running processes that need to be spawned off by the web interface on demand. I think there will always be room for Merb alongside Rails, not just for the reasons I’ve mentioned but because of the smaller memory footprint, speed at which it handles requests and more.”
Reuven Lerner, GigaOm/Ostatic:
“While I like Prototype and script.aculo.us quite a bit, I have sometimes wanted to work with YUI or Dojo, either because they had some useful widgets or just on a lark. Using a non-Prototype JavaScript framework with Rails is theoretically possible, but I don’t think that it’s really practical. Merb, by contrast, seems to really encourage such experimentation.”
“I’m also a bit fascinated by the idea of using a different relational-object mappers. I happen to like ActiveRecord, but I recognize very well that it’s slow, and that another mapper might work better for my purposes. I’ve been using SQL for a long time, and it’s still sometimes easier for me to express my ideas in raw SQL. And yes, ActiveRecord lets me do that with find_by_sql, but it’s just not the same. I thus see Merb as a “what if?” sort of framework—a kind of edge-edge Rails, allowing us to explore alternatives without being constrained by the decisions that were already made by the Rails core team. I think that the people who are developing Rails, and thinking about what should be included in version 2.5, and even version 3.0, should be playing with Merb a great deal, using it to find the best ideas and practices so that the mainstream Rails community can take advantage of what they find.”
Fabio Akita, author, programmer:
“There are several places that Rails is lagging behind Merb. For example, its support for Rack. But given the current state of the MRI, I don’t think thread-safety is that important right now. I mean, both MRI 1.8 and YARV 1.9 have contention problems. For instance, YARV uses native threads but it has that big GIL that prevents it from running threads in parallel for real. This makes thread-safe less important in the Ruby world. So, thread-safe frameworks, by themselves, don’t leverage too much performance just because of that. Right now Merb is faster than Rails. But that’s because it loads much less libraries than Rails. You can customize it in a way that only the exact pieces that you need will be in memory at runtime. Rails projects assume loading everything.”
“I do believe in using Merb and Rails alongside one another. Github, along with many other Web sites, do the same. If both use ActiveRecord for ORM, they can even share the same models at some level. And there are other promising frameworks as Sinatra, Ramaze, Nitro and others that are also very good, each with their own strengths and weaknesses. Competition is a good thing to have.”
Cliff Moon, Powerset:
“Merb is pretty great. We’ll be launching our product front end in Merb. The component agnosticism of Merb simply means that it doesn’t tightly couple with any one framework for ORM, JS, etc. In exchange for some pain getting set up, it buys you more flexibility and a smaller runtime footprint since it doesn’t throw the kitchen sink into your app.”
“One of the reasons we chose Merb for our front end was its ability to safely handle concurrent requests in a single mongrel. The front end is IO bound waiting for a backend service with a highly variable latency. It’s pretty much unacceptable for an entire mongrel to be out of commission waiting for a backend service. The traditional response for a Rails app is to simply increase the number of mongrels running on a host to the number of concurrent requests one expects see at peak traffic. The problem there, from a scalability perspective, is that each mongrel will have a pretty hefty memory footprint. So it means that you would have to commit more memory capacity per page served. For our app, we can serve about 5 concurrent requests from a single mongrel with Merb. The best part is that we really haven’t given up any productivity for these performance gains, at least beyond the initial hump of learning the framework.”
Henry Work, Mark McGranahan, and Rob Olson, CrunchBase:
“We love Merb! McGranaghan closely follows the mailing list and is apt to say things like “that would be a perfect project for Merb… Ezra Zygmuntowicz [is a] great hacker with great taste, entrepreneurial, supportive of the community that grows around his projects, and fearless.”
Jacques Crocker, Rails Jedi:
“I was extremely happy to see that Merb decided to implement “slices”, which is similar to Rails Engines, a hugely mistreated Rails plugin. Engines could have been revolutionary had it been encouraged and integrated by the Rails Core. I’m hoping that merb-slices will demonstrate to the Rails Core team that pluggable, self-contained apps are really the only way we’ll be able to manage our applications’ rapidly growing complexity.”
Thanks again to all of our TakeFive participants over the last year.
Hope to see you in San Diego!
