4 ms·

There's a deeper problem that Yehuda isn't hitting and that is that there is an inverse correlation between being cool and cutting edge and being consumer frien

by Jd 15y ago

There's a deeper problem that Yehuda isn't hitting and that is that there is an inverse correlation between being cool and cutting edge and being consumer friendly. Rails is, and really has always been, a framework which changes very quickly. Although virtually all of these changes are for the better either in some abstract feels-better sense or in a tangible practical sense, each of these changes imposes a cost on other people. This isn't really a problem with the decisions of the rails core team, it is the entire ethos accompanying rails. Authentication plugins I remember from 4 years ago are barely maintained today, and there are a whole bunch of new ones. I'm guessing my knowledge re: authentication has a half-life of approximately 1.5 years. The implications are as follows: (1) If you are a Rails developer you need to be a full-time Rails developer and not do too much else. You can't do Rails and a bunch of other things because Rails will take up a lot of your time. (2) Think you can code, release, and forget about it? Think again. If you have projects, you (and the people who commissioned the projects) need to know that these projects need to have at least 5 hrs / week budgeted for the indefinite future (perhaps less, but the point is that they need a developer on staff -- they can't simply be released and forgotten about). (3) Extra caution, since not all change is good change. You may end up to subject whatever is cool at the time. That's not to say that this really affects the core team, but there are a gazillion Rubyists out there attempting to change everything over to MongoDB that works just fine in whatever flavor of SQL they were running before. A lot of people have been burned here. All of these take away from the promise and excitement of Rails for many people -- which was not simply "oh we can be on the cutting edge of technology," but "oh, we can have a sexy app with decent functionality up in a matter of a couple weeks with half the budget of what we thought." That second impression, which is what a lot of the Rails ecosystem is built off of, is largely false (esp. now that there are a bunch of other quickstart web frameworks).

chollida1 15y ago
> (1) If you are a Rails developer you need to be a full-time Rails developer and not do too much else. You can't do Rails and a bunch of other things because Rails will take up a lot of your time. I'm glad to see someone else say this. I don't use rails often, nor am I a "front end" developer by trade. I have put together some simple web apps using rails, but it seems that each time I go back to rails and try to use the newest released version I'm starting back close to square 1 due to how things always seem to change. I always just assumed that I didn't grok web frameworks, though this is still a possibility.
- Jd 15y ago
  There is a huge learning curve with Rails, insofar as it is its own "opinionated" framework with numerous conventions, if well-chosen, that are unique to Rails. You can deploy web apps in Rails without adopting all of these things, but you will never be respected by Rails developers (I've heard devs say "that's not the Rails way" countless times). Usually these conventions are chosen for good reasons (even though they frequently change), but impose a significant cost since you have to learn: (1) Ruby the language (2) Idiomatic Ruby as perceived by Rails Devs (3) Rails conventions (4) Appropriate plugins/addons All of them take a decent amount of time to learn (well). 3 & 4 also change pretty frequently. So, it is possible you "grok" everything quite well (I'd guess that you do), but haven't learned all the specifics that make things tick the "Rails way."
- cies 15y ago
  i feel often enough that things could be simpler in rails, but still i think that rails is currently still the fastest fw to get most webapps done. by most webapps i mean: (r)dbms-backed, uses a fair bit of html/css (not pure js), that needs to do 'common webapp things' (authentication though fb/google/etc.; audit trails; some REST api; memcache; pagination; ...) going back -- to php, jsp or even (albeit less so) django -- would complicate things for me. i feel at time rails might seem to take up a lot of time; but actually it is web development just being quite laborious, and rails one of the best fw to "take the pain out of it" and "providing sane defaults that can be changed where you see fit".
- chrstphrwrght 15y ago
  I've tinkered with Rails projects on and off since 2005, but it's never been my main gig. I'm sure if I was using it full-time I'd be okay keeping up to date with the latest trends and conventions, but as it stands I wind up Googling before almost every decision to ask "Okay, so how are we doing this now?" I figure that infrequent users like us aren't who the Rails core is catering for, and that's fine. It does feel like a slow reboot coming back to Rails every 6-12 months for small projects, but I still recognise that it's a great framework that solves a lot of problems. When making a decision on what technology to use, I often consider Sinatra for its simplicity. Rails feels like a black box to me at times - again, likely not a problem if it's your bread and butter.
sebilasse 15y ago
You can have your sexy app up in a couple of weeks. But maintaining it still takes time, no matter what language/framework you're using. Upgrading to a new version is in the end maintenance (security fixes, underlying framework improvements, and the refactorings that go hand in hand with upgrading). If you go with rails you still can get to a point very quick, with the downside that you have to spend time for upgrading. But both the elegance and maturity of rails 3, in regard of it's age is quite unique. The older it gets the prettier. [2]. Agreed. I've been working both on client projects and in startups. If you have 10 Rails projects from clients to support, this is a nightmare, (rails 1.2 - 3.0, from mongrels to passengers). It's hard to charge clients for a rails upgrade. [3] I developed rails since 0.14 full-time. I think rails was/is very conservative regarding trendy things (except coffeescript).
- freshfunk 15y ago
  >But maintaining it still takes time, no matter what language/framework you're using. Upgrading to a new version is in the end maintenance (security fixes, underlying framework improvements, and the refactorings that go hand in hand with upgrading). Pointing out the obvious here but using matured languages/frameworks tends to have less of this problem. It's like dating: stable -> boring and reliable while dynamically changing -> exciting but scary.
- sams99 15y ago
  The rails 2 -> rails 3 upgrade path is one of the most complex upgrade paths I have seen for a web framework
  - jarin 15y ago
    I'm not so sure about that, for me it was mostly just moving gems from environment.rb to a Gemfile and updating gems/plugins. After that, I fixed deprecation warnings and moved everything to AREL/scopes at a fairly leisurely pace.
    - speleding 15y ago
      Did you forget about the always-on XSS escaping? Fixing just that took me more than a week on a large project. (I still think there should have been an option to switch it off for old projects.)
freshfunk 15y ago
Glad to hear your opinion on this. What frameworks, in your opinion, are stable, relevant today, easy to use, and has a good community? I've been doing some client-side scripting with Ruby lately just for fun and I've also played with Python in the past. I haven't used Rails or Django. After reading all of this, I'm leaning towards Python/Django but haven't used neither web framework I'm curious as to people's opinions.
- jasonkester 15y ago
  I have a whole pile of ASP.NET sites that went into production between 2004 and 2010 and get roughly zero hours per month of development attention. Once every few years I spend a few minutes on each one migrating to the latest version of the CLR. I can pull any one of those sites up today and make changes using the latest and greatest features of C#, and they won't complain. Or I can pull out the cruftiest bad practice from .NET 1.1 and have that work too.
- elithrar 15y ago
  > After reading all of this, I'm leaning towards Python/Django but haven't used neither web framework I'm curious as to people's opinions. Django has a good reputation for API stability, and has fantastic documentation (Rails has caught up, but for a long time Django was a standout). My 1.1 books still work for 90% of 1.3, and the 1.1>1.2>1.3 release notes explain and offer solutions for any changes they make (such as class-based views). I dabbled in Rails & Django over the last 2-3 years, and took a big detour into Rails a few months ago. I like the conventions, but it's easy to get distracted when looking for plug-ins/gems to solve your problems. Every time I look back at Django, it takes me half a day to get back into the flow. Rails, not so much.
hitonagashi 15y ago
1) Agreed. Fully. Of my outside work time messing around on projects and such, 50% is reading HN, 50% is experimenting with new Rails plugins, or Ruby gems, or databases. I find on average, I end up finding something I prefer every 1.5 years as well. 2) Disagree here. Sure, you can't forget about it, but Rails 2 is perfectly useable. I'm currently managing a fairly substantial mix of Rails 2 and Rails 3 apps for various clients. If 2.3 works fine for them, and they want a minor feature every few months, it's just not worth the cost to them to upgrade. Sure, if major security holes emerge, patch and upgrade. 3) Agreed. I have a big gap between "things I play with on personal projects", and "things I'd use when I'm being paid at work". When I'm writing things for a client, I want battle tested code that I can predict against. I want to be able to say "That will take me a week", so I can bill, without the risk of going overbudget. If I take a new and shiny framework, and as a result of bugs in their code, or lack of documentation/6 month old blog posts being totally redundant and wrong, I end up slipping on the deadlines, that's not a situation I want to be in. The thing that I really like is that Rails 2.x worked. I've got github, which stores old versions of gems and plugins for me to grab. I love Rails 3, and I teach new developers on it all the time, as I think it's far easier to learn and far more intuitive than Rails 2, but with Rails, I can take advantage of a fast moving easy to write system on new projects, while not getting screwed over on the old ones.
rapind 15y ago
1) You don't have to stay up to date with the latest. Pick a version and hunker down. I.e. 2.3.11. Forget about Rails3 for a year or 2 if you like (not me, I happen to really like rails 3). This is what I'd do if I was a part-time rails dev. 2) This couldn't be more incorrect. I'm not sure where you got this impression, but I have several apps in production I haven't touch in over a year. I don't even think I've bounced any services like apache or passenger on that box in over a year. I didn't do anything fancy to make this possible. Are you constantly upgrading your apps when new versions come out? Would you do that with a production EJB app? 3) This is true, but isn't specific to Rails or Ruby developers. One thing I'll say is that Rails 3 definitely has a higher learning curve than 1 or 2 did. I think that's just the framework growing up though. It's a pretty complicated area of development if you want to build a decent sized app. If you're building something really simple and small, rails 3 might be overkill, at least for the time being until it settles down a bit.

by Jd 15y ago

chollida1 15y ago

> (1) If you are a Rails developer you need to be a full-time Rails developer and not do too much else. You can't do Rails and a bunch of other things because Rails will take up a lot of your time. I'm glad to see someone else say this. I don't use rails often, nor am I a "front end" developer by trade. I have put together some simple web apps using rails, but it seems that each time I go back to rails and try to use the newest released version I'm starting back close to square 1 due to how things always seem to change. I always just assumed that I didn't grok web frameworks, though this is still a possibility.

Jd 15y ago
There is a huge learning curve with Rails, insofar as it is its own "opinionated" framework with numerous conventions, if well-chosen, that are unique to Rails. You can deploy web apps in Rails without adopting all of these things, but you will never be respected by Rails developers (I've heard devs say "that's not the Rails way" countless times). Usually these conventions are chosen for good reasons (even though they frequently change), but impose a significant cost since you have to learn: (1) Ruby the language (2) Idiomatic Ruby as perceived by Rails Devs (3) Rails conventions (4) Appropriate plugins/addons All of them take a decent amount of time to learn (well). 3 & 4 also change pretty frequently. So, it is possible you "grok" everything quite well (I'd guess that you do), but haven't learned all the specifics that make things tick the "Rails way."
cies 15y ago
i feel often enough that things could be simpler in rails, but still i think that rails is currently still the fastest fw to get most webapps done. by most webapps i mean: (r)dbms-backed, uses a fair bit of html/css (not pure js), that needs to do 'common webapp things' (authentication though fb/google/etc.; audit trails; some REST api; memcache; pagination; ...) going back -- to php, jsp or even (albeit less so) django -- would complicate things for me. i feel at time rails might seem to take up a lot of time; but actually it is web development just being quite laborious, and rails one of the best fw to "take the pain out of it" and "providing sane defaults that can be changed where you see fit".
chrstphrwrght 15y ago
I've tinkered with Rails projects on and off since 2005, but it's never been my main gig. I'm sure if I was using it full-time I'd be okay keeping up to date with the latest trends and conventions, but as it stands I wind up Googling before almost every decision to ask "Okay, so how are we doing this now?" I figure that infrequent users like us aren't who the Rails core is catering for, and that's fine. It does feel like a slow reboot coming back to Rails every 6-12 months for small projects, but I still recognise that it's a great framework that solves a lot of problems. When making a decision on what technology to use, I often consider Sinatra for its simplicity. Rails feels like a black box to me at times - again, likely not a problem if it's your bread and butter.

sebilasse 15y ago

You can have your sexy app up in a couple of weeks. But maintaining it still takes time, no matter what language/framework you're using. Upgrading to a new version is in the end maintenance (security fixes, underlying framework improvements, and the refactorings that go hand in hand with upgrading). If you go with rails you still can get to a point very quick, with the downside that you have to spend time for upgrading. But both the elegance and maturity of rails 3, in regard of it's age is quite unique. The older it gets the prettier. [2]. Agreed. I've been working both on client projects and in startups. If you have 10 Rails projects from clients to support, this is a nightmare, (rails 1.2 - 3.0, from mongrels to passengers). It's hard to charge clients for a rails upgrade. [3] I developed rails since 0.14 full-time. I think rails was/is very conservative regarding trendy things (except coffeescript).

freshfunk 15y ago
>But maintaining it still takes time, no matter what language/framework you're using. Upgrading to a new version is in the end maintenance (security fixes, underlying framework improvements, and the refactorings that go hand in hand with upgrading). Pointing out the obvious here but using matured languages/frameworks tends to have less of this problem. It's like dating: stable -> boring and reliable while dynamically changing -> exciting but scary.
sams99 15y ago
The rails 2 -> rails 3 upgrade path is one of the most complex upgrade paths I have seen for a web framework
- jarin 15y ago
  I'm not so sure about that, for me it was mostly just moving gems from environment.rb to a Gemfile and updating gems/plugins. After that, I fixed deprecation warnings and moved everything to AREL/scopes at a fairly leisurely pace.
  - speleding 15y ago
    Did you forget about the always-on XSS escaping? Fixing just that took me more than a week on a large project. (I still think there should have been an option to switch it off for old projects.)

freshfunk 15y ago

Glad to hear your opinion on this. What frameworks, in your opinion, are stable, relevant today, easy to use, and has a good community? I've been doing some client-side scripting with Ruby lately just for fun and I've also played with Python in the past. I haven't used Rails or Django. After reading all of this, I'm leaning towards Python/Django but haven't used neither web framework I'm curious as to people's opinions.

jasonkester 15y ago
I have a whole pile of ASP.NET sites that went into production between 2004 and 2010 and get roughly zero hours per month of development attention. Once every few years I spend a few minutes on each one migrating to the latest version of the CLR. I can pull any one of those sites up today and make changes using the latest and greatest features of C#, and they won't complain. Or I can pull out the cruftiest bad practice from .NET 1.1 and have that work too.
elithrar 15y ago
> After reading all of this, I'm leaning towards Python/Django but haven't used neither web framework I'm curious as to people's opinions. Django has a good reputation for API stability, and has fantastic documentation (Rails has caught up, but for a long time Django was a standout). My 1.1 books still work for 90% of 1.3, and the 1.1>1.2>1.3 release notes explain and offer solutions for any changes they make (such as class-based views). I dabbled in Rails & Django over the last 2-3 years, and took a big detour into Rails a few months ago. I like the conventions, but it's easy to get distracted when looking for plug-ins/gems to solve your problems. Every time I look back at Django, it takes me half a day to get back into the flow. Rails, not so much.

hitonagashi 15y ago

1) Agreed. Fully. Of my outside work time messing around on projects and such, 50% is reading HN, 50% is experimenting with new Rails plugins, or Ruby gems, or databases. I find on average, I end up finding something I prefer every 1.5 years as well. 2) Disagree here. Sure, you can't forget about it, but Rails 2 is perfectly useable. I'm currently managing a fairly substantial mix of Rails 2 and Rails 3 apps for various clients. If 2.3 works fine for them, and they want a minor feature every few months, it's just not worth the cost to them to upgrade. Sure, if major security holes emerge, patch and upgrade. 3) Agreed. I have a big gap between "things I play with on personal projects", and "things I'd use when I'm being paid at work". When I'm writing things for a client, I want battle tested code that I can predict against. I want to be able to say "That will take me a week", so I can bill, without the risk of going overbudget. If I take a new and shiny framework, and as a result of bugs in their code, or lack of documentation/6 month old blog posts being totally redundant and wrong, I end up slipping on the deadlines, that's not a situation I want to be in. The thing that I really like is that Rails 2.x worked. I've got github, which stores old versions of gems and plugins for me to grab. I love Rails 3, and I teach new developers on it all the time, as I think it's far easier to learn and far more intuitive than Rails 2, but with Rails, I can take advantage of a fast moving easy to write system on new projects, while not getting screwed over on the old ones.

rapind 15y ago

1) You don't have to stay up to date with the latest. Pick a version and hunker down. I.e. 2.3.11. Forget about Rails3 for a year or 2 if you like (not me, I happen to really like rails 3). This is what I'd do if I was a part-time rails dev. 2) This couldn't be more incorrect. I'm not sure where you got this impression, but I have several apps in production I haven't touch in over a year. I don't even think I've bounced any services like apache or passenger on that box in over a year. I didn't do anything fancy to make this possible. Are you constantly upgrading your apps when new versions come out? Would you do that with a production EJB app? 3) This is true, but isn't specific to Rails or Ruby developers. One thing I'll say is that Rails 3 definitely has a higher learning curve than 1 or 2 did. I think that's just the framework growing up though. It's a pretty complicated area of development if you want to build a decent sized app. If you're building something really simple and small, rails 3 might be overkill, at least for the time being until it settles down a bit.