grantmichaels'blog

Lacking filter between brain and mouth, I decided to sleep on the Rails/Merb merger before blogging about it. I haven’t been silent, but I haven’t really said all that much either. While I can’t say that every single cell in my body is in favor of this change, I’m more relieved than not. Why? Because the in-fighting within the Ruby framework community was growing tiresome quickly. I’ve been participant to a number of online communities, spanning nearly two decades, and the story is retold with only the subtlest of variation. Nothing will ever please all people – it’s pointless for anyone to try to achieve this end. My only concerns are with regard to the resulting framework’s performance, where I have trouble imagining Rails 3 measuring alongside Merb 1.x, let alone winning out. Now, the Merb core were undoubtedly going to add overhead for their 2.0 release, so we have to make some concessions for that reality.

Separately, I really do not have a problem with DHH or his involvement in whatever framework I’m using, and I remember that my opinion distinctly evolved following his Startup School presentation. Rails has a target audience, one it’s well-suited for, and it’ll be better for everything it does from whatever it gleams from Merb. I have watched the entire Merbcamp series and everything Merb-related that I could find from the past 18 months or so – all within the past couple of months. I was damn near positive that I was going to give Merb the nod, with Erlang remaining frustrating for me (granted, I was trying to do things it wasn’t designed for). Thinkerlang held some promise for a week or so, but quickly became focused on more skilled coders. Based on more recent Tweet, I think Joel probably now realizes that the professional audience is tight-fisted, because I have noticed he’s already looking for a new project to monetize. Anyways, getting back to the merger, there is inherent two-facedness that comes with the territory, I mean – now all of a sudden everything that was terrible about the other side isn’t as bad, and everything unique that you’d been boasting about, can magically become less important in moving on. You don’t blame individuals for this, you accept that it is the nature of competition and business. Just because you don’t have to pay to use open source software, doesn’t mean that there aren’t millions of dollars riding on top of it – think about it.

Yesterday, someone was complaining on Twitter about a ‘lack of transparency’ regarding having arrived at this merger – that the two core teams had done so without consulting the community – which I think is an unrealistic expectation for that person to have had. While there were numerous unaffiliated contributions I’m sure, Merb was made possible by Engine Yard resources. Engine Yard vendors Ruby web-framework hosting, of which Rails is the undisputed leader, particularly in the for-profit sector – so I ask – who would have funded Merb development when beating out Rails perhaps put Engine Yard under? Merb had recently drawn likenesses to Django too, recognizing things in the Pythonic competition that were superior to both Merb and Rails. Django Apps (the inspiration for Merb Slices) and the administrative tool come to mind in this regard, and it was planned to have an admin added to Merb 2. Anyways, this had gone so far as to having a Django coder as a presenter at Merbcamp – at least that was the way I understood it. In a sense, we can rejoice that Merb adopted things from Django while it was distinct from Rails – things that hadn’t managed to cross the language divide previously. I don’t think the Rails/Django competition had been fruitful from the Ruby perspective – at least, not that I can think of, anyways. Gaining the admin system from Django that was planned for Merb 2, in Rails 3, will be a win. The ex-Merb team keep insisting that people keep them honest, this is definitely a point to watch.

So, even though I almost never use IRC, I popped in #merb following the flood of merger Tweet and asked a few questions, but mostly I just listened to Yehuda and Ezra answer to the community of actual Merb users. It was pretty obvious that people were upset about the news, but this is to be expected, really. These people probably came for varied reasons, but all of them felt that the end result of learning Merb was going to give them tangible benefits in a few key areas – speed, modularity, JS framework and ORM agnosticism, better routing (and Rack), and a public API to decrease the pain in upgrading apps to new framework revisions. We are being told by everyone in the new Rails 3 team that these are to be adopted by Rails, so honestly all should be well. I threw the question out on Twitter as to whether Yehuda would still be employed by Engine Yard to work on this integration, and the answer was an unmitigated yes from Ezra and later from Yehuda himself. This is a definite win for everyone and it’s impossible to disregard his constant evangelism of using Ruby for web development. As a non-professional web developer, my perspective is different from most people that I talk to about coding, but this is a no-brainer for me. I knew enough to know that I wanted the performance benefits from Merb, but the lack of documentation made it a real time suck to follow the mailing list and blogs (and Twitter) to figure out how to navigate the breakages and gem dependencies through the 1.0.x releases – only further compounded by trying to run with DataMapper on JRuby, which is just barely – if working. To have finally decided upon using both JRuby and Merb, I was admittedly disappointed to have had hoops to jump through to use them together. Merb without DataMapper had me considering Rails anyways, so this merger is a total solution from my limited perspective.

Lastly, I was curious to see the opinions of some of the people who have been down on Ruby as of late. Most seem to feel that this will be beneficial, and most of them don’t have anything at stake any longer, so their opinions are perhaps more objective than my own, or that of anyone who is still coding in Ruby. The only thing I outright disagree with from the Merb crew is the proposed path to Rails 3. They seem to suggest going with Merb 1.x as opposed to Rails 2.3, but I don’t think I’m going to follow that route. I have more Rails experience than Merb at present, and there will certainly be a ton of documentation to get people from Rails 2.3 -> 3.0 (books, posts, ‘casts, conversation, etc). I just can’t have the same confidence that there will be an abundance of documentation from the Merb side, since there really wasn’t a concerted effort to document their project in the first place. While I’m sure there will be working code to do so, I don’t think it’ll be as readily available. I never really got to know Merb, as I was just getting the stack sorted in preparation for this very weekend, but all of the time spent watching the Merbcamp and RubyConf presentations has taught me what kinds of optimizations and improvements I should expect in Rails 3, and that has plenty of value.

I have found Webby, Scanty, Marley, Jekyll and a couple of other interesting projects built on Sinatra that I think will improve my productivity in the short term, and now I have to ask myself whether to go forth with getting to know Sinatra, or to just look at Metal and drink the Rails kool-aid through and through. For the first time ever, I can see how it might be possible to do everything well enough with only Rails – and to be honest, that is cause for celebration. As I draw to a close here, I’m left wondering what will become of SproutCore going forward, and whether there will be YAMerb sooner than later – if for no other reason than just to scratch the itch of those who crave minimalism and speed. Truth be told, while Rails 3 may very well be a beast of a framework, it most certainly won’t be the “Hacker’s Framework” that some set out to use, let alone a “Pocket Rocket” …

grantmichaels