Rails 3 and Merb
11 comments Latest by Jermy Nicoll Wed, 24 Dec 2008 17:25:01 GMT
So… Rails and Merb are going to be merged into Rails 3. (link)
Has hell frozen over?
(it has in Portland the last week)
I’m curious about how the revised core team will incorporate the library-agnostic view points into Rails without increasing the complexity for configuration. For example, being able to use a different ORM is great, but at the same time, one of the things that I have really liked about Ruby on Rails was that it did make decisions ahead of time for you. Conventions over Configuration and all that jazz. While they intend to keep these defaults, I really wonder how much more configuration will be involved. Be that as it may, Rails and Merb are run by some of the best developers I’ve ever known… so I am sure these decisions will not be made without some deep consideration.
Rails application don’t all look and smell the same, but it’s nice to know that there is consistency across all of our client applications. What I’m concerned about (from an efficiency standpoint) is that this could lead to project-diversity at the cost of experimenting. Pre-Rails, the development teams that I was a part of was constantly trying out new libraries from client project to project, but this came at a huge cost. We weren’t able to leverage our experience with previous projects like our team does with Ruby on Rails currently. (hell, I even helped write two different ORMs in the two years before Rails for PHP… and still wasn’t satisfied)
But, this isn’t so much a technical problem as much as a people problem. The thing is… is that Rails helped solve a people problem with a technical answer. Having testing, consistency, and other best practices built-in did the world a huge favor. ...and all it took was someone like DHH to throw his opinion out there and stick to it. It took me nearly a full year to really embrace a lot of these conventions, but in the end.. it paid off.
While I do feel that it’s in developers best interests to try out new approaches, I just don’t think it should be on your clients dime. This was part of the reason why I quit my last job to start Planet Argon full-time. I really wanted to get away from that cycle.
Since we (Planet Argon) adopted Ruby on Rails four years ago, we’ve been able to build off of every project we had worked on before. We since adopted things like RSpec and JQuery, but our team decided on these changes after someone took the initiative to experiment with these on internal and personal projects. Having this foundation has freed up a lot of our time to focus on other issues as a team, like Interaction Design, Usability, and client collaboration.
As far as Merb itself, I honestly haven’t tried to do anything with it since about 0.2/0.3. I gave up quickly though because the documentation didn’t help me get anywhere and my time is valuable. I’ve since seen that documentation has improved drastically, but I haven’t been able to prioritize the time needed to really play with it. With Merb being merged into Rails 3, it means that I really should spend more time exploring it as we might be able to leverage some of it’s benefits without as much of an investment.
Much of the lack of great interest in Merb was because I felt Rails had consistently provided our team with a solid foundation for a majority of our internal and client applications. The old saying, “if it ain’t broke, don’t fix it.” Not to say that others haven’t expressed a lot of excitement about Merb and it’s benefits, I just didn’t see there being enough of a productivity gain to warrant the time investment required to really learn and use a new framework… and the one thing that I have had trouble with was that it didn’t sound like Merb encouraged a default set of libraries. I could be totally wrong, but that’s been the perception I’ve had based on how it was branded.
But… the best part about this for you, me, and the Rails community? Is that I don’t need to register robbyonmerb.com anytime soon. ;-)
I hope that you’re all having a great end to 2008 and am excited to see all the energy in the Ruby/Rails/Merb community. I suspect that between these two (now-merged) teams, we’ll have an even better platform to develop web applications on. I believe this is great news and I’m all in favor of seeing the Ruby community conquer these challenges that lay ahead.
Anyhow, I’m just thinking out loud. What are your thoughts?
Enjoying the content? Be sure to subscribe to my RSS feed.
You’ve pretty much articulated my thoughts on the subject. My tweet from earlier:
“if merging with merb means more choices, i’m not sure what to think—rails has low barriers to entry, but more choices means more barrier.”
I think it’s exciting news, but I’m cautious about what it means, particularly to the job of getting new people started in Rails. If we take on a new starter, or someone with limited Rails experience, how quickly can we get them going? I’m envisaging that Obie’s next “The Rails Way” revision could be twice as large ;) and no-one wants to carry something that size around in their bag.
But this is an age old problem—convenience versus power. I just thought Rails had chosen convenience for good.
I agree with “Lightning David Bolton” here. This sounds good on the surface but I’m concerned about how complex the configuration will end up. However, if what they say is true (about default solutions), I hope that people will avoid straying too far away from conventions.
As a Rails consultant, it’s great that I can jump from project to project without a lot of variation between the libraries, but it sounds like we (consultants) are going to have to spend more time learning about alternative libraries should someone call us to ask for support. A Ruby on Rails application could be anything in two years time.
I imagine a sales call going like
Awesome.
I really hope that the Ruby on Rails community does a good job to advocate not straying from the pack because I’m sick of trying to clean up after developers that think they’re clever and have their own solutions. Rails has strongly discouraged this as a whole and now it seems to be opening a door to that sort of behavior.
Robby is echoes my thoughts well. It is and will always be a people problem and Rails provided a technical solution (some might call it a hurdle) to this. As someone who wants to just Get Things Done, Rails has given me an opportunity to earn more personal time through conventions.
I am just worried about hitting a point when the inmates are running the asylum. However, I am excited about the possibilities but will remain a skeptic.
I find it most humorous that your concerns are quite the opposite of mine. I switched to Merb a while back as I hated Rails telling me what I could and could not do. I’m hoping that I am still going to get the control I need in Rails 3.0. If anyone can satisfy the two (or more) mindsets, I’m sure the guys behind Rails/Merb can do it. Btw, Merb 1.0 is much different than version 0.3. It was kinda painful at version 0.3, and the only reason I showed interest throughout subsequent versions is because I hated how much time I was spending hacking on Rail’s code to do what I wanted to do. I feel that it paid off, as I have a a few projects that I’m doing in Merb and loving it now. Both of us don’t want things to change too much, but for completely different reasons.
Merb’s got some default libraries. When you generate a Merb app, by default it’ll use DataMapper for its ORM, RSpec for testing, jQuery for its Javascript library and it even generates a .gitignore for you, encouraging Git. There are leaner ways to generate an app without these though.
DataMapper may be new to Rails devs, but the others (RSpec, jQuery and Git) are not, and I think they’re actually better defaults. And ActiveRecord is gonna be the default anyway, so I don’t really see this as a problem for Rails devs. But yeah, I can see that support people are gonna have to study that too.
Jermy,
Heh, I suspect that there are a lot of people that feel one way or another about it. I also suspect that we approach development differently, but it’s possible that I’m wrong there. :-)
See, this is what strikes me as weird. It sounds like Rails was abusing some trust or something and forcing you to comply. While marginally true, it never hid any of this. I suspect the question that I’d have here is, “what is the control that you feel you need?”... and more importantly, “why do you need this control?”
Perhaps the problems that your web applications require more options, I just haven’t hit many walls using what Ruby on Rails provides as the default set of tools.
I have always thought of Ruby on Rails as a toolbox that you could pick up at the store and quickly buy (into). As a result, you could tackle a large majority of the problems you encounter maintaining your house. The Merb approach (as I’ve perceived it…) has been… “here is a partially filled toolbox, pick your hammer and screw driver before you proceed to pay at the counter”
Mileage of course… may vary.
Again, I’m feeling positive about this, but just curious how these two approaches are going to compliment each other. (for the greater good)
You’ve basically summed up my thoughts on the matter – excited that two fantastic teams have decided to work together, but concerned about how these diametrically opposed projects (in my opinion) are going to come together without getting in the way of why I use Rails (opinionated software with intelligent mindshare).
Like yourself, I’ve embraced some of the aspects of Rails I originally saw as constraints…and while I do find myself wishing every so often that Rails was custom made just for me, it’s not long before I realise that Rails was never going to solve 100% of my problems.
Another aspect I’m concerned about is stifling innovation. Merb has done a fantastic job of keeping the Rails team on their toes, and vice-versa. Merging the projects risks removing the competition, which has yielded great results for both projects thus far.
That being said, I really don’t want to pre-empt the problems that I’m sure both teams are already thinking about. I look forward to seeing what comes out of the Rails & Merb teams in the lead up to Rails 3.
@mikong
Thanks for the quick overview. I’ll be the first to admit my ignorance on the Merb-side of things. This has just been my perception as it’s always been marketed as framework that you could easily switch the libraries in. Not going to say if that’s better of worse for the community as a whole, I can only comment on what I see is better for my team and clients (based on my experience).
Regardless, I have some homework to do. I’ve only looked at DataMapper a few times and never really tried it out. Using it to connect to external web services sounds great (especially since our team often has to interact with XML/SOAP services for client projects).
@Nathan
It’s funny, I was just thinking about my first six months or so on Rails. I really had trouble distancing myself from database constraints and relying on ActiveRecord to be a guardian to our client’s business logic and data.
Fast-forward 3 1/2 years and I approach software development completely differently.
Perhaps I’ve been poisoned and/or brainwashed by Ruby on Rails conventions. It’s comforting to know that I’m not alone in this though… ;-)
Hey Robby, let me try to allay your fears. An absolutely key element of Rails is that there be a default choice for everything. When you’re first starting out, you don’t know what ORM is better. Or which testing solution is right. Or why you might pick jQuery over Prototype. And frankly, you don’t give a damn. All you want is get started. Rails is going to give you exactly that.
Rails 3 will continue with the strong defaults of AR, ERb/Builder, Prototype, test/unit, etc. But at the same time, there’s just no benefit in denying or trying to suppress other frameworks that could drop in. Some people were already using Sequel/Data Mapper, jQuery, rspec, and whatever instead of the Rails defaults. Rails just weren’t making that particularly easy.
I really like the idea that Rails will have strong defaults but be respectful of other options.
Another thing that’s not going to happen is for the default stack to require any additional configuration. We’re not going to allow the default ride to be any more bumpy. Instead, we’re just going to say, hey, if you want to go off-piste, here’s a map so you don’t get hurt.
Robby, IMHO as a Postgres guy in 1 year you will be loving DataMapper. BTW we are already choosing alternatives, I don’t think many people is using test/unit, we all switched to RSpec. And having a public API is just plain awesome. I suggest you take a look to the Merb book, especially slices, contextual validations (that’s DataMapper) and routing.
Robby, The thing that I remember the most was the router, it was quite inflexible for a couple of projects that I was working on. There were some other things, but I do not recall what they were off-hand. Of course, many things may have changed since I jumped ship, as has been indicated in both the Merb and Rails blogs that the projects have grown closer together. We probably do have different mindsets on how to do projects – I’ve always been one to take my time to think things through, while others like to just “get things done.” I’m not saying that either is a good/bad approach, I just think and prefer to do things differently than what I remember Rails allowing me to. I love having choices, the cost of speed is worth it to me. It’s going to be interesting to watch how they are going to blend the two approaches.