Ruby on Rails application in 10 minutes is a myth
Lately netbeans remainded me about something that makes great marketing for Ruby on Rails – ability to create application in 10 minutes.
By example you can have a look on the netbeans tutorial. Everything looks great, sometimes You can even create the application in 10 minutes …
Lets think what You will get in this 10 minutes:
- Scaffold of application … without head or legs
Thats all, the application generated in 10 minutes does not have authentication, it does not have administrative part. Of course there is a lot of plugins, that helps to add functionality to Yours application. But wait a minute, authors of this plugins cant catch up stable rails.
Each few months we have new rails version, and each version is requiring application changes, this is endless. After You finish migration to newest rails, after You find new plugins there is new rails version – and the wheel spins again.
Comparing to other applications rails is getting new releases at least twice offten, that would be good if it would have one stable base, but not, the base is changing each few months.
And what is the plan, four months after rails 2.3 we will have rails 3.0, it will be more like rails or maybe more like merb? Hopefully it will start slowing down a bit, as it requires now very big efforts to maintain application and keep it up todate.
Somebody would say “You can freeze rails, gems and plugins” – yes I can, but I can not freeze my developers, they will learn new rails version, and after one year I will have a team of experienced developers in rails 4.0 or even rails 5.0 and application with frozen reail 2.3 … and try to migrate when the core was rewritten three times during last year.
Assuming having steady framewoirk with “broken tables” like Java or less broken DJango makes a lot more work on begining, but development stacks are available, the documentation is more complete, and the major version changes once for few years, this allows developer to understand and modify application code even after ten years.
Did You liked this post or maybe not, vote on it at dzone.
I think Rails is going to a similar Django stack way. With Rails 3.0 you will be able to select any particular “slice” you want to use, Prototype or JQuery, ActiveRecord or Datamapper, and so on. This will be a great improvement IMHO.
Aron, thanks for the criticism, You are right that I’m not real rails developer, I’m more involved in deployment process and keeping integration of the whole system (rails, flex, media conversion tools), but I already learned Ruby to very good level.
You are right that it is possibly going in the right direction (merbify) but this is what will be not what we have … and are You sure that they really will freeze the plugin API.
When You are saying about new features I very like engines, they could allow to build application from bricks, I already have seen whole CMS build this way.
When comparing to django, they have stack, you are not forced to use it, it’s meter of choice which middleware You use (this also new feature in rails). So if You do not like the build in admin You do not have to use it, use You own solution.
With this stack You have provided authentication solution (again You do not have to use it), it makes me more sure that it will give me the guided security, not whatever the lazy/busy plugin developer has done and stopped maintenance.
I wonder how much time you have actually spent developing on Rails. I think your points are seriously misguided.
Rails is being futzed with fairly significantly release to release, but you make it sound like each incremental release completely breaks every prior release, which is not true. We have had been running production applications since Rails 1.2.6, and are not seamlessly moving to 2.3. Some apps we’ve migrated; some we have frozen and left. But the point is, Rails 1.2.6 and 2.3 share far more than PHP4 and PHP5.
And if you say you can still develop in PHP4, then why can’t I make the same statement with prior versions of Rails? Like I said, we have plenty running now on prior versions without issue.
In terms of the admin/authentication argument… this makes me crazy: Why should a framework provide all that? Rails core developers have always maintained that Django’s built in admin is out of scope for the framework. And I agree. What if I don’t like Django’s admin, or can’t for some reason use their authentication scheme out of the box? You’re kind of stuck, aren’t you?
What rails does exceptionally well is allow the community to fill in those gaps. There are umpteen plugins that provide exactly the same functionality out of the box (admin, authentication, etc). With templates in Rails 2.3, you could easily create a base application that will provide everything you want, and more.
With the move to merbify Rails the news just gets better. The framework will provide what a framework should — and nothing more. You should be able to plug in functionality as needed. You should not be forced to use whatever ORM Rails core seems to like. You should be able to easily extend functionality through plugins/engines. And you should be able to run bare-bones apps in a bare-bones environment, without all the bells of whistles of the full rails stack.
Choice is bad? Is that really your argument?
You are right we have to work on the old versions as this is Enterprise IT requirement. But here is the difference, I can still work on Java 1.3 or PHP4 as there they are backwards compatible, switching to old code is just stop using few features, it is not totally different framework like with rails in one Year having Major version switch … The speed up of rails development is a bit to big. Framework should be rather stable base to build stack on it, or even better framework should provide development stack like django does (authorization, authentication, admin-panel).
I agree with you and I don’t.
Yes, all these build a XYZ App in 10 minutes are crap.
IMHO these are the greatest disservice one can apply to a serious framework.
(Same for Grails, Django, Pylons, YouNameIt)
Developing a larger app ALWAYS requires that you take a look under the hood.
So the training blog posts, screencasts and books should take into consideration to give these topics enough time and place.
For example I bet that only 1 of 10 Rails Developers can describe the startup process.
Yes this is far more boring than ‘pluggin in’ a new Web 2.x feature – but once you dig deeper it’s worth a lot to know.
Conderning the rails versions. Yes, sometimes it’s a bit annoying but most of the changes are community driven requests. Let’s say there would be a only one minor upgrade a year. What would we win ? It’s in the responsibility of the plugin author to keep track with the versions. Some are lazy, some are busy with other things, i.e. earning money, so it also could take several weeks before they adjust their code to the new rails version if there would be fewer versions.
Let’s say, just as example, each new minor rails version has 5 significant and 25 small changes. What is better – dealing with 5 changes each quarter or with 20 after a year ? I prefer the smaller bits.
By the way these ‘problems’ are not reduced to rails. Many project out in the wild still run with php4 and on jdk 1.3. Developers, me too, never like to deal with the old versions but that is a big part of (Enterprise) IT and it always will.