On Sat, Jan 07, 2006 at 01:56:44PM -0800, Jeremy E. wrote:
In the interests of starting a more serious discussion of problems with Rails:
As a core member I’ll respond to some of the issues you bring up.
- The internals are undocumented and sparsely commented, making it
difficult to patch when you discover yet another bug.
When you run up against internal code that is poorly documented or not
documented at all and struggle to figure out how it works, documentation
patches would be appreciated. We work hard to make the outward facing
API
always backwards compatible. Documentation is like code. The more you
write
the more you have to maintain, so we privilege the public API over the
private API in this regard, as the internals tend to be refactored more
frequently (which requires the overhead of documentation updates). Also,
those delving into the internals are likely more able to determine how
they
work. Point taken though. Rails would likely benefit from some more
documentation of the internals. Again, patches welcome. Documentation
patches
don’t require tests 
- Non-trivial patches only get applied if they affect the core team.
If a patch is non-trivial it needs to be well tested. If it doesn’t
apply
cleanly the core team doesn’t have the time to make it unless it is
really
important. If it is well tested then it still takes time to evaluate.
That’s
how open source works. There are two sides to everything.
I take issue with the “only get applied if they affect the core team”
part.
As a member of the core team who has taken the time to apply, test and
commit
plenty of code that has nothing to do with me I can’t accept such a
broad claim.
We try to make an effort to express in ticket comments when a patch is
not
complete or needs more work. If a patch is of high quality, well tested
and
appropriate for inclusion in Rails then it is often applied relatively
expediently. In the cases where this does not happen I apologize. Gentle
pestering on the rails-core list is encouraged. Gentle…
You may take issue with what “appropriate for inclusion in Rails” means.
Rails came out of David and 37signals’ needs for Basecamp so it has its
original motivations springing out of necessity. The core team does have
needs in the applications they build. David, for example, had a need for
tagging in Sunrise. But he did not add a tagging framework to Rails.
Instead,
after implementing a tagging system he was happy with, he extracted the
higher level database relationship model (the new polymorphic
associations)
into ActiveRecord. In other words, there is a distinction to be made
between
people’s needs and thing that are appropriate to the framework. We
ultimately
are the judge of what the appropriate level is. If it’s at the framework
level and is a good fit for Rails, it goes in. Scott B., a core team
member with the keys to the svn repository, is using the plugin system
in
Rails for several of his projects. He has needs for his apps but
recognizes
they don’t fit in on the framework level.
The relatively high barrier of entry to patch submissions is also
largely the
reason why you like Rails so much. We say no before we say yes.
- Implementing new features takes priority over fixing bugs.
Rails has been in growth mode for a while. With the release of 1.0 we
have
said, “This has enough features.” The 1.0 branch will only receive bug
fixes
now. Rails hasn’t stopped its development but non of the core team has
an
interest in making it huge and bloated so a lot of the work post 1.0 is
going
into the tools used in conjunction with Rails and not as much on Rails
itself. Either way, new features will be implemented and bugs will be
fixed.
We could all spend more time fixing bugs but as the considerable test
coverage of Rails indicates, its code health is good.
- There are a lot of bugs.
Undeniably, there are many pending bug reports. There is a distinction,
though, between there being many tickets and many egregious bugs. Rails
is
always going to have bugs. A lot of bugs, though, are edge cases or
otherwise
not a priority so simply going off the number of pending bug reports is
not
the whole picture. Regardless, if you are so inclined go through and
identify, say, the 10 most critical bugs as you see it and post their
ticket
numbers to the core mailing list making a case. Help prioritizing bug
reports
would be appreciated.
- It’s slower than other frameworks (if you can’t use caching).
Rails privileges programmer productivity over execution speed. Always
has
and will. As does Ruby itself. That aside, the core team is mindful of
performance and we are working closely with Stefan K. who has taken it
upon
himself to work exclusively on Rails performance. I personally spent
over 20
hours for the 0.13.x release integrating his performance work into
Rails. So,
Rails is slower than other frameworks. There are other criteria by which
it
can be compared to those same frameworks as well. Ruby 2, out there in
the
distance, will likely make that a non issue. Rails is most of the time
fast
enough. There are real world apps with lots of traffic backing that
claim.
- def many_method_names_are_really_long_like_this_one; end
What is the problem with this? You want intension revealing method
names.
Your text editor should alleviate the hassle of typing the whole thing
out.
I like Rails and I think it is the best web framework for my needs,
but there are still a lot of problems with it.
Thanks for the list. It’s very useful to have people who like Rails
pointing
out what they don’t like rather than people who’ve already made up their
mind
to hate it looker for things to throw rocks at. So I do really
appreciate
your candor. I’m all for people willing to help.
marcel
