[I’m not sure what google-groups’ problem is, but I posted this topic
hours ago and it still doesn’t appear on the list, here it goes again…]
Tom M. wrote:
…
I’m curious where the distrust comes from?
The community as a whole is working hard to avoid these sorts of
feelings,
and I’m sure it would be an interesting discussion in and of itself.
In short: In my opinion Rails is perfectly ok for small scale projects:
One developer projects that don’t really need active maintenance.
Why wouldn’t I dare to risk a large project on Rails. I read the Lisp
discussion, I agree with the issues elaborated on, but my conclusion is
the opposite. As mentioned earlier web-apps really aren’t rocket
science. And I firmly believe that anything can be done in any
language. (Maybe not in any framework, and certain things will
definitely be easier/harder depending on the framework) Thus to me
choosing a well established framework means that you assure yourself of
the ability to get 1) enough expertise and continuity (new developers
are easy to find) 2) stable third party libraries and 3) a future proof
web-app. Fun-to-code really doesn’t seem that important to me.
As for specific problems with Ruby/Rails. Third-party libraries is the
first issue. While the libraries that are at hand might be sufficient
for what you want to accomplish there’s a definite change it might not
be sufficient in the future. More over you cannot be sure that the
current libraries are of stable quality (the mysql-lib finds it
necessary to hg memory and performance by copying table headers for
every new row, ferret and rmagic kill make/made rhtml templates with
tabs unusable) and will continue to work after an upgrade of either
rails or ruby. And the same issues can be found in Rails itself,
Active-Record could be optimized a lot (rebuilding the same queries ever
again… I’d cache them)
Talking about upgrading, this is my second issue. The nature of both
Ruby and Rails make upgrading to a new version a bit like Russian
roulette, you never know whether something’s going to break and whether
it will be fixable. “Breaking open†ruby classes and injecting your own
code only works if the entire (not only public part) of the api never
changes. (For example, rails 1.16 killed forced scoping in the old way
(only showing models where valid was true) as it introduced new nested
scopes, rails 1.2 will kill my urlrewrite pluging that adds .html) Of
course these are small issues easy to resolve (especially because I
wrote these plugins myself). But what about all the other plugins out
here. Most of them are not actively maintained so who knows what’s going
to break with a new version of rails or ruby. The common counterargument
is that hacking into other classes is “bad design†but it is a design
inherent to rails and ruby and even advocated in various books /
tutorials.
Thirdly I don’t know what to expect from Rails in the future. Take for
example Django (mind you Django has other issues), it has spend near a
year to “remove the magic†so the api would be stable once 1.0 is
released. With rails it seems every now and then a major part gets
refactored (1.2 meanse new url resolver). But when will other parts of
the framework/api be altered? God only knows.
I guess the previous issues boils down to that at some period in time it
might extremely difficult to update or add features to your app, making
it almost necessary to build a new one from near scratch. I fully
realize that large web-apps in general won’t be updated that often, but
what if there’s a security issue in your versions of rails (or ruby) or
you simply need part of the new framework that isn’t part of the old.
Rails says it’ll always encourage/need the latest ruby and libraries…
ouch… And to me it seems inherent to rails that you’d need to update
more often then you’d like, rails is still young, as is ruby (not really
young, but rails certainly kicked off development of much needed
(third-party) libs), to keep a workable (read: supported) setup you’ll
need the latest and greatest.
Apart from this we have the famous mantras “make programming
fun/productive†, “DRYâ€, “time is expensive, servers cheapâ€. I don’t buy
them, nearly all frameworks now give you the possibility to not repeat
yourself, but it’s up to the programmer to smartly implement his part of
the app to actually use it.
As I mentioned before there’s nothing I could do in rails that I
couldn’t accomplish in .net or java? (or php, python for that matter).
It might be more tedious true, but it would get done. But the other
language has a major benefit, if I ceased to exist, it’d be easy to find
someone else to take over the app. When building a large scale webapp
that needs a team of programmers this is even more important (you’d be
hard pressed to find a team of good ruby programmers). Moreover it would
be a huge benefit that once time start ticking you could simply open a
can of programmers (hire) to finish those famous last lines of code.
(True for a small company this scenario wouldn’t happen).
As for increased productivity… true, it increases a bit. But actual
implementation is only a part of building a webapp. Building an
interface/design, defining a db-model, defining needed functionality etc
are equally important and time consuming. And, like I mentioned before,
increased productivity now might mean decreased in the future, when
adding functionality means a lot of hacking in rails core. More over
ruby/rails have the odd practice of scattering functionality over a
number of incoherent files, got to love this mixing-in of
functionality… (but I guess you’d get used to it. But again, this is
something you only get confronted with later on, when you need to keep
using rails/ruby because you already did and you now have to dig a bit
deeper to get that problem fixed of this functionality added)
Finally the idea that hardware and servers are cheap. This totally
depends on what you need. The more servers you need to keep running the
more server-maintenance is needed and the harder it is to keep them all
running in sync, and from what I picked up on most lists, it isn’t that
simple to keep rails running. More important, a slowish web-app will
always be a slowish webapp. I mean if actually building of a view takes
half a second you could place as many servers as you want, it will still
take that time to deliver the html to your user. In the mean time your
competitor is working towards a more responsive app which once it is
live your clients will say “wow… this is fast… why can’t you be that
fastâ€. You could place more servers, and more servers(and notice a
single server has a maxed cpu speed and amount of memory)… but no
matter what you do your competitor will now benefit from its slower
startup time, having an easier time expanding it amount of users on its
fewer servers.
