I'm in the preliminary stages of designing a new web application, and have yet to begin any sort of implementation. The application models a fairly complex domain, and I'd feel more comfortable using tools such as the ruby DataMapper ORM (having using NHibernate in the .net world) than Rails Active Record. I also prefer jquery over prototype. All of these considerations of course point to using Merb, yet I'm aware that Merb is being merged into Rails for version 3 and will no longer exist as a distinct framework.
Is there any sense in starting work on the implementation of the application now given the fairly profound changes coming to rails? I'd really like to know if it would be worth starting development in Merb now and then porting it to Rails, but I've yet to find anything suggesting how difficult this may be. Another approach would be to start work on the domain now in Rails, and only give consideration to the ORM and frontend once v3 is released.
In essence, I'd like to know how portable a Merb app is going to be to Rails 3, but am aware that it may be too early for anyone other than the core developers to know this.
Any thoughts would be greatly appreciated. Thanks :)
-------------- Edit ---------------
Yehuda Katz, lead developer of the Merb project has this to say on his blog:
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.
It's never a good time to start a complex application on a framework, really. It seems like there's always a major upgrade coming up or some other competing framework that may be a better bet. If you're having more success with Merb, stick with that right now and develop your project without fear! Both the Rails and Merb communities are going to have to cope with the merging of the projects with the release of Rails 3, but that's going to be awhile.
The project merge doesn't mean that Merb will be going away, however. Yehuda Katz will stop being the lead developer, but someone will take over the project. At the minimum, you can expect security patches and bug fixes for a few years, as long as you follow the official Merb developers' repository. Likely, after the Rails 3 release, you'll find great walk-throughs on upgrading your Rails 2.x/Merb 1.x application to Rails 3.
Related
Yes, several similar threads exist, but we're now in 2011, and much has changed.
Grails 1.3.6 has improved hugely compared to v1.3 when I initially tried to learn the framework (and gave up to slow compile times and other groan inducing events).
Having spent a couple months with the latest release, I am impressed, protyping an app is an absolute breeze (GORM is great!). In development mode one no longer needs to restart, barring changes to domain classes. Groovy.lang is fantastic (bare in mind, this is compared to my day job life in PHP).
Now, on the flip side there is Ruby/Rails, which I have little experience with beyond perusing Ruby docs and exploring Active Record (to compare to GORM). Coming from PHP/Jquery, groovy syntax is cake, ruby not so much, although accessible.
Ruby/Rails is all the rage, while Groovy/Grails seems to be picking up speed in its own right.
I'd like to hear what both camps have to say (flame inducing lang war welcome) re: pros/cons of both langs/frameworks now in 2011. When choosing a framework it's important to know what you're getting into, so have at it, newbies will benefit, and experts can vent ;--)
Rails and Grails are both excellent frameworks with their current releases. You really can't go wrong with either. Here are some things I find interesting about them though:
Rails
Rails (Ruby) does not scale as well as Grails (Groovy). You will need more horsepower to run your application. This isn't a big deal at all with PaaS options like EngineYard (and hopefully a AWS BeanStalk Rails option in the future), but it might just cost a little more to run a Rails app vs a Grails app (obviously JRuby is also an option to though).
Rails is slightly better with NoSQL alternatives currently, but Grails is catching up quickly
Rails has many more plugins, but this can lead to trouble if you use some that aren't maintained (a lot of them don't currently work with Rails 3 yet either).
Rails is more mature and has more features at this point in time because it's been around longer
Rails REST support is amazing
There are many more "big" Rails websites than Grails
Ruby is much more popular than Groovy - TIOBE
No dependence on Oracle, ha! (Grails obviously needs the JVM)
Grails
Grails integrates with the JVM better than JRuby
Grails GORM is better than ActiveRecord (IMHO), although Rails 3 opened the door a little bit for other persistence options, but all the books, tutorials, etc all use ActiveRecord
Grails View taglibs are better than <=%...%> in view
Grails plugins are well documented and clearly state whether they are supported by SpringSource or not
SpringSource is investing heavily in Grails
There will be many more corporate jobs for Grails than Rails in the future, but more startups use Rails (where do you want to work?)
My perspective
I used Rails a couple years ago, I'm working on a Grails project now
I like them both better than Django (Python) or Zend Framework (PHP)
I plan to learn Lift (Scala) next
My Recommendation
If you have never done Java development and are working on a side project for a small to medium website, go with Rails
If you are working at a big company that uses Java, try pitching Grails to your management as the "next Java framework" they should invest in
If you are working on "the next twitter or foursquare," well then you are smart enough to answer this question yourself! :)
First time I begun a project with Rails I was really surprised:
How can I separate "repository" from "Service"? Oh my God: I have to put business logic on controllers... I can't imagine a real big project with Ruby on Rails: Is there Someone on 37signals remembering the basics of separating Business and Domain/Repository. The Rails folders/classes structure doesn't take care about this.
Second sock: "Active Record". Try to design a real complex Object Oriented Business layer and map it using the Rails Models (Active Record)... really: don't.
6 months later, with our project running: R&R is consuming 80% CPU (and memory...) using apache + passanger on a quad core server... and the Postgresql Database is in holidays (3-4% of CPU)... Oh my god (newly)
My old ASP/VB6 applications where capable of serve pages to 300 concurrent users in a real backoffice context with real complex databases and complex business installed on a standalone machine (a year 2001 1 CPU core server).
Of course, conventions and Ruby syntax are lovely... and no one needs a compiler (well... unit tests are used for this porpouses 90% of the time... just for solving the dissapeared typing each time I change some code... "Please, programming god, take care about my fingers mistakes" )
First impession with Grails:
A "Cool" stack inspired on Rails with professional power based on Spring framework (IoC, Hibernate, ...)
And YES!!!
There is a clean Domain/Service separation. NICE!!!
You can, eventually, forget Java.
Rails is fairly mature, has a HUGE ecosystem to go with it. I'm not familiar with Grails or it's support online, but the red flag I see in your post is that you've admitted Grails is playing catch up to Rails.
Ruby is an absolute joy to work with (and this coming from an old C++ hack... why, back in the day I used to program with just a hex keypad, young whippersnapper... now GET OFF MY LAWN!).
There are things about ruby that make it hard to follow at times (method_missing I'm looking at YOU) but I'm sure that can be said about any language.
Me? I'd go with ruby and rails.
Well for grails, i still think that even catching up, it has 2 main things that rails won't have in a easy way:
scaling up
tons of mature java libraries at your fingertips (personally geotools among others)
Ruby on Rails is outstanding - like the Pink Floyd of web dev.
Groovy on Grails is a decent copy of it - kind of like the Australian Pink Floyd show...
BTW - We have both at work - and I have seen many Grails developers eventually learn Rails and stick with it.
I have also seen Rails developers learn Grails, but NONE of them have preferred it.
About half of the time, our Java developers learn Grails and simply stay away from Ruby.
IMHO - If you truly know both fairly well, you will almost always prefer Ruby and Rails.
You also have to consider your IDE. When I started out with rails, it was quite painful. Rubymine was super slow and crashing, everyone I know were using textmate. Grails has STS (eclipse based) and gives you all the features you need.
I moved my application off of Rails early in 2009 because I didn't need or want all of the features in that framework (ORM, MVC etc) and didn't like the large footprint we were generating (200Mb). Merb-core has been a great home for our application but I'm now wondering if we should move elsewhere now that Merb & Rails have merged.
Does anyone have advice on the following questions?
Should we stay on Merb?
Given the desire for a minimal
footprint, is there any point trying
to reimplement the app on Rails 3.x?
I have some experience with thin and
Rack but use enough Merb features
that the port wouldn't be painless -
is it worth going 'down' to bare
Rack?
Thanks, I appreciate that some of these are subjective but I hope that there are enough people who have used Merb and who have faced the same questions.
Just as an aside, the last question here about Merb was almost four months ago.
I have a couple of production apps running with Sinatra. It's light-weight and generally a pleasure to work with.
Since Rails 3.x is more modular than before, you might want to have a look at it too. You can slim it down quite far. If you're going for a really minimal footprint, Sinatra is an excellent choice.
Does Merb not meet your needs anymore? I'm still using it. I've tried Rails 3 and it doesn't feel at all like the "Merb 2" I was promised; kind of just feels like Rails. As such I continue to use Merb for new projects. I have one I deployed this past summer and a larger project for an existing website that I am currently developing. Perhaps it's not a very popular framework, but it meets most of my goals and so far I've seen no reason to leave it behind.
I heard Rails 3 is almost ready to be released from beta, meaning its a stable version. But of course the real date still unknown.
So I'm looking for advice from a good RoR developer. Do you think I should learn and use Rails 3 RC version or use Rails 2.3.8? If I use the RC version now will it be hard to upgrade to the stable Rails 3 version?
Is there a decent RoR developer out there than can offer some guidance?
Thanks.
I don't know what a rock developer (!) is, but I'd recommend going with Rails 3 rather than Rails 2.x. Rails 3 represents the future direction of Ruby on Rails, so it's worth getting up to speed with it as soon as you can. To be frank, Rails 2.x is now an evolutionary dead-end. There shouldn't be any significant changes between the Rails 3 Release Candidate and the final version.
The barriers to adopting Rails 3 you might encounter are:
its availability on your production stack
plugin/gem compatibility
For the first issue, I know that the popular Heroku for example are tracking the Rails 3 beta releases pretty closely. Regarding the second issue, not all plugins or gems are compatible at the moment, but a lot of the most popular ones are. If there are specific plugins or gems that you need to use then check here.
If you need to get a project off the ground now, then by all means go with Rails 2.3.8. It's the safe choice.
There are some significant changes in Rails 3. Some tools will be available to help you upgrade. But no automated tool will ever completely convert your 2.3.8 application to Rails 3. It's hard to tell how much effort is involved, that really depends on your application.
That said, if you are new, learning, and not expecting to release anything for several months, Rails 3 is the right choice. By the time your grok Rails and have something in production, Rails 3 will likely have stabilized, and nobody will be looking back.
Use rails 3!! The RC is still in the pipeline, but it's more or less good to go and you won't need to make any code changes when the final release is made
Here are some reasonable resources to get you started with it
http://railscasts.com
http://www.railsdispatch.com/
http://www.teachmetocode.com/
http://rubyonrails.org/screencasts/rails3/
I am trying to help some people getting started programming on rails identify which version that advice found on web pages corresponds to, and am seeking advice and/or guides on how to do it so they don't have to rely on me and/or waste time trying outdated advice.
Narrative: I am helping some people get up to speed on rails development, and their stock response to running into problems is searching google for advice. They're using 2.3.5 and thinking of moving to 3. The problem they're running into is that there's a lot of advice out there specific to older rails versions (2.2 for example being popular) that isn't identified.
I can usually figure out when the pages are old pretty easily, but they can't (yet.) It seems like random web page authors don't identify which version they're using when they're using the current version, and not all pages are dated.
This seems to be a general problem that will get worse -- current unadorned advice is usually 2.3.5 and older unadorned advice is 2.2.x at this point, but people are moving / will be moving to version 3 over the next while and newbies will be stuck looking at a bunch of deprecated/incompatible 2.3.x advice without realizing which version it is.
Any advice / pointers / telltales?
Check out API Dock. It has an excellent, annotated, and more importantly, versioned documentation of the rails API.
When I started with Rails 2.x last year, I got some books that were talking on Rails 1.x
There were things that changed from 1.x to 2.x, such as the way scaffolding works or that a framework like streamlined stopped from existence. On the other hand, there were some concepts and points that stayed valid from Rails 1.x to 2.x For example, most tutorials and documents start on talking about the model layer, how easy it is to use ActiveRecord and how you have REST for dealing with basic CRUD operations.
In general, I think with such an active community, it's actually one of the strong point of rails that you get so many shifts in innovation so fast. Actually, it is one of the strong points of the open-source community.
So Rails and Merb are sort of merging in Rails 3.0? Thats how its been described to me anyway. This means that a lot of what made Rails, Rails will now be moved to plug-ins so that it can be more lightweight. HOwever, what are those plug-ins going to be and as a new Rails developer, what are THE must have - and also more mature - plug-ins that a Rails developer should install? Some good examples I can think of might be will_paginate, ruby_prof or sqlite3-ruby.
My understanding is that Rails (3) will still essentially be composed of the framework components that make it up now i.e. ActiveRecord, ActiveSupport, ActionPack, even prototype.js etc. It's just that the internals have been significantly refactored and cleaned up and it will be much easier to swap out components for alternatives. For example, perhaps replacing ActiveRecord with Data Mapper.
The tag line for Rails 3 is the same as Burger King i.e. Have It Your Way (I'm not joking!)
Many releases have taken out significant components and put them in plugins, you probably haven't even noticed most of the time. The best thing to do would be to just stay upgraded and pay attention to deprecation messages in your logs and you'll be fine.
This is all thanks to posts like this which highlighted the problems to the community earlier on. Now it should be much, much smoother.