I think the problem with MVC web frameworks in general is that it makes it makes the easy/boilerplate stuff really easy, but the hard stuff harder. Sure, if you doing a simple CRUD app that is only updating a single table it is fine. Beyond that, you waste so much time trying to figure out how the frameworks wants you to represent composite objects, and debugging the default model binders, then thinking you might have to write your own binder, then just saying screw it and reverting to Request.Form[] and parsing your own requests.
I absolutely agree that a complex, n-table, n-page site does not scale with MVC in general. Simplistically, [n-tables] X [n-pages] = n^2 controller methods for n controllers. So trying to make the controllers nice and OO just means each controllers complexity expands excessively.
I would be really curious. What pattern do people think scales in this general situation?
In the simple case, Rails likes you to have seven controller methods and one controller per table. Realistically I usually end up throwing a few more methods on each controller.
This is actually part of the reason I like Rails: it guides the developer towards what I consider to be better application design. I understand that a lot of folks don't agree, and that's cool for them, but I still like hearing why.
I can see that working if each of the 7 tables was their own individual entity, but I am talking about a composite object here. Normalized data.
How do you manage a transaction across 7 different controller methods?
I am not saying their isn't a nice way to do this, merely using this as an example of why people may not like Rails. It forces you to figure out the Rails way of doing things. And that may not always be the best way for you, especially if you are an experienced developer.
when you have to spread your updates across 7 different controller actions (methods) to make it work the Rails way, it most certainly is a rails problem.
You're assuming that there is a hard coupling between Controllers and Models. There isn't.
Rails suggests a CRUD pattern, but doesn't enforce it. You can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method.
You can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method.
You can very transparently do it with ActiveRecord associations, so that you're operating on only one instance of a model, or you can do it very opaquely, where you instantiate and update several models. Or you can just run an UPDATE statement; those haven't gone away.
I agree Rails work pretty well when you've an "average" app that doesn't spread across a lot of tables.
The problems only when things go past averageness in one way or another. I actually have had more problems with Rails in personal apps I wanted to develop than in apps for clients.
Rails is a paradox - the bleeding edge framework that works for only non-bleeding-edge sites...
When I first used Rails, I was frustrated by two main things:
* Files everywhere! I like starting simple, and you generate all these folders with things I just don't want to deal with yet.
* Lots of things were implicit, making it difficult for a newbie to the framework to understand the flow (How do we get from the controller to the template? was one, I think).
Now, that was several years ago (a little over 3, now), and both Rails and I have changed. I've been waiting for Rails3 to give it another chance, but haven't found the right project yet.
My current gripes with Rails are this:
* DHH is a prick.
* It's damned difficult to find a good Ruby feed that doesn't get polluted with Rails stuff.
My first issue is, of course, not very valid, but I have to admit that it exists.
For the second one, yes, I program in Ruby (and love it!), but I'm not using Rails. Even when I do web development in Ruby, it's with Sinatra. So, I don't want to see your frackin' "Ruby tips" that are actually Rails tips!
I think Rails is great, and it hasn't ruined any of my projects.
Once in a while, however, the magic can be a bit tiresome - you have to know a lot of things. For instance that if you change the routes file, it may make a series of functions named in a certain way to appear in your views. Or just how to name everything in the right way to make Rails happy.
Often times it's a time saver, but once in a while you kind of wonder if it has to be quite so magic.
Also, sometimes those things are dynamically put together, so you can't grep for them in the source code.
I really like Rails - for all the CRUDish apps of the world there's nothing better: you'll avoid reinventing a lot of boring wheels.
Perhaps the reason some HNers are Rails-phobic is that Rails is rightly designed to be precisely the opposite of tool you want for hacks: convention over configuration, config opaquely doing as much as possible for you, and development being as far as possible snapping together canonical bricks (Devise, WillPaginate et al).
If it didn't get in your way for hacks with very different requirements to the apps Rails was designed for, it wouldn't be doing its job. Right tool for the job, as ever!
The above bug report (while incredibly funny) was a symptom of what turned me off while learning rails. Why would tables be pluralized automatically? A model might change to a word I didn't even know is the correct plural. ( I didn't go any deeper than tutorials. )
Overall I prefer Django as nothing comes as a surprise, and the shortcomings aren't a huge bother for what I do.
It's beneficial to point out that ActiveRecord is no longer tied to the hip of Rails. In fact, in Rails 3, you now have ActiveModel which gives you all the "Active" goodness of model objects without connecting to a specific database at all. In other words, issues like this are no longer a problem in Rails, maybe just in certain modules you can install and use optionally in Rails.
Some issues I think come from the early hype that it was the 'one framework to rule them all'. I personally love Rails but it is a bit heavy and shouldn't be used for smaller projects. But that's not Rails fault it was more a misunderstanding of Rails' sweet spot. For those smaller projects I now use Sinatra.
That said when I first started using Rails, four years ago, it should have come with a warning sticker about deployment issues. A smaller VPS that could handle dozens of PHP apps could be only really handle one maybe two Rails apps. Litespeed, Passenger, JRuby, etc. have made these issues go away, but I can see how it might have left a bad impression of the framework.
P.S. You think people hate Rails try being a Flash developer on here.
Some people don't like Rails. This isn't a problem. It's not a personal insult to you or to your skills or to anyone else who likes or uses Rails. It's sometimes useful to discuss the limitations (in some subset of people's views) of software.
I say this as someone who quite likes Rails but doesn't use it at the moment. It just so happens that the bit of web work I do at the moment tends to fit Django better. But don't worry, we don't need to hate each other :)
I've flagged this article because I really can't see anything of worth coming out of it. Holy wars are very rarely that interesting.
I've used Rails for over a year. I keep hearing people say that it's slow, or it doesn't scale well, or that after the first 80% of the application is finished it gets in your way.
I haven't found that to be the case, but my experience is limited. So I'm looking for any cases where any of these things have actually happened. I want to know if these claims have any substance.
Of course there are cases where Rails isn't the right solution, that's true of absolutely everything. It's probably fine for all your uses (and for mine too) though. You are not going to get a useful discussion of them with that blog post though. You use an antagonistic tone and target a group of people who largely only exist as a group in your head, that's not going to produce good stuff!
I'm pretty sure the general direction of the comments weren't bashing on Rails specifically, just the idea that they thought the honeymoon wouldn't end (it always does).
They went from a very heavy django background, where they saw the shortcomings of the framework (or every framework, really), dabbled in Rails for a day, loved its magic for trivial tasks (protip: most frameworks make trivial tasks easy and magical), and somehow concluded it was superior to django and that they had stumbled on a hidden gem (pun intended).
Frameworks have limitations. You will always reach a point in your career working with them that you disagree with one or more design choices, and you will have to deal with a problem the developers never accounted for. Sometimes that problem is easy to solve using your existing framework, and sometimes the framework (in solving 95% of other use cases) makes handling and solving that problem a pain in the ass. It isn't unique to django, Rails, Zend, or whatever else you happen to be using. But pretending that the framework you just discovered is perfect is just silly. Take the language you enjoy working in, find a framework that suits your style and doesn't get in your way too often, and run with it.
My apologies for still giving vague, sweeping statements, but I haven't worked deep enough with Rails for it to get in my way yet (I've only done a few simple proof-of-concept sites with it).
I preferred Nitro over Rails when they both arrived in 2004. Nitro made it far easier to evolve an application from a single static HTML file to any degree of complexity (plus it was faster, thread safe, and more modular). Rails seemed better suited to a very specific genre of application. Great when you're building that app; less so when you needed to color outside the lines.
Ramaze picked up where Nitro left. All software is opinionated; I prefer the opinions built into Ramaze. Whatever tool you pick, whatever language you use, make sure the opinions it embodies align with yours, or you'll find yourself frustrated way too often.
But I really think the alleged hating on Rails has more to do with how some people perceive its more vocal proponents. Sadly, it all feels like being back in high school again. It's the "rock star" and "hero" nonsense that grates.
People would do better to scope out the various languages and tools, learn to appreciate the good stuff, steal the better ideas for their own preferences, and ignore the personalities and drama.
Well, the main problem is that the user data we store is multi-valued. So each attribute can have multiple values in the same 'record'. As you can imagine, Rails doesn't help much in this situation, as it assumes that each column in the databas table has just one value.
Oh, and each application on a multi-tenant app server can have a completely different schema. Again, there's not much that Rails can do to help.
Rails was good to get going, and it helped for the relational stuff in the app. But unsurprisingly, if you try and use it for something it's not designed to do, it's not going to work terribly well. This principle applies to everything.
I first experimented with Rails in the 0.7 days, and stuck with it until sometime in the early 2.x series. The general complaint you mention about "it got in my way and I had to abandon it" is basically at the top of my list.
As Rails evolved, it picked up a _lot_ of cruft, and when things went subtlely wrong (or I was trying to track down a "magic" method) it was just a big pit of morass to dig through. About that time (nearly 3 years ago) I switched to Merb, the new kid on the block. That's had its own share of pain to deal with, and at work we're now figuring it'll be worth it to migrate back to Rails 3. The Rails/Merb "merger" has resulted in a lot of good architectural cleanup, and being able to live within the regular plugin ecosystem has a lot to say for it (namely, we won't need to maintain the dozen-odd forks for merb support anymore).
>it's completely won me over, replacing almost every single place I'd use PHP
which it should, php is terrible. It's OK for many purposes, but there aren't that many spectacular libraries for difficult things, lack of sophisticated IDE support, etc.
Some HN'ers seem to hate PHP, I want to know why :)
I couldn't care less about a platform someone else uses that I don't use.
Familiarity breeds contempt. So I think I'm qualified to rant on PHP because I wrote an awful lot of it over the years and am still maintaining one large PHP project that was written in the PHP2 days, so you can imagine what that's like (we're re-writing that at the moment).
If you're happy with rails, more power to you. If you're happy with python, great!
Whatever you use, if you're happy with, I'm happy for you. Meanwhile, live and let live.
So, PHP may be 'terrible' for you, but it has made me more money than all the other programming languages that I know combined, in spite of all its shortcomings.
Spectacular libraries for difficult things? Not on my wishlist. Lack of an IDE? I use vi(m).
It's all just work, and work needs to be done. Use the tool that's best for you and move on, don't look back too much and kick at where you came from.
And if you didn't 'come from there' you shouldn't be having an opinion on the subject anyway, then you're just parroting.
I've evaluated as a tool that doesn't give me any benefits I can see over stuff I already have a lot of experience in. I haven't heard any compelling arguments for starting any new project in php.
PHP has a long documented list of shortcomings, but y'know what? Just like shell scripts, it is absolutely fantastic at small one-off but long-lived programs.
Frameworks have limits, the same guys who loved rails had a previous experience with Django where they loved it then they hit a wall and started replacing all of its components.
Of course Rails is 100x better than php.
I suspect it exhibits the same characteristics of frameworks that make a lot of people turn against Django after some time. It is, after all, an opinionated framework.
If people never hit a wall with it, I'd be a bit concerned; perhaps they're probably not trying hard to push their apps beyond limits of the framework.
If I'm a good C programmer, if I grok Lisp, if I'm fluent in Python, if I can accomplish damn near any file munging task from a bash prompt, and if I have an understanding of component-based development, then I should be suitable for the vast majority of programming jobs. Yet something like 90% of job postings require X years of experience in Ruby, PHP, Java, or some Microsoft-specific language. Many of the interesting programming jobs have chosen to select for a language that I could learn in a couple hours, work with in a couple days, and use well in a couple weeks, but because I don't know it right now, I'm not hire-able.
Background, intelligence, and work ethic be damned, you need Ruby and Rails experience to work here, because after all we have many applicants and someone is bound to fit all our criteria. And while we're on our soapbox, why-oh-why are good programmers so hard to find? Because you're not even trying. You have too much other crap to do, and you're just looking for a quick, safe reason to reject everyone else and have a couple people conveniently left over to choose from. And no, I don't know the ins and outs of b-trees anymore, but give me some time with Google and vim and I'll have a C solution ready to be tested. You know, the way real work is done.
So yeah, I suppose I do find myself bitter that I'm expected to pick up a trendy language and platform (and recall every data structure I learned 4 years ago) to even have a chance on the job market. From the outside it just looks like a giant Ruby/Rails clique (or PHP/Cake, or Java/Spring, or whatever technology your company has happened to fall into). We're all forced to learn something that we don't actually need -- we can already get it done with similar effort in another way -- just for you to consider hiring us. And everyone has a slightly different stack that I have to go teach myself just to avoid looking like an idiot in the application process.
And it's not just Rails and the languages I don't know (yet!). Even the Python job postings I find almost without fail require experience with Django or some other framework du jour. I mean geez, how long does it take to learn a freaking framework, especially with a bit of early guidance? Stop selecting for the wrong criteria!
I'm not one of the ones typically "bashing" Rails, but I understand the frustration of being forced to learn a bunch of crap as part of an elaborate mating game of inefficient, badly-designed hiring practices. Just throw some work my way, give me the email of a knowledgeable employee who can answer occasional questions, start me out at a below-market rate, and evaluate my role and contributions in a month or two when I've had a chance to get acclimated. The filters that employers use are such bullshit, and then to make it worse they slap us in the face by claiming that it's impossible to find good programmers.
I'm not saying I disagree with the principle (I very much agree that it shouldn't be this way), but this seems like a rather impractical argument.
a language that I could learn in a couple hours, work with in a couple days, and use well in a couple weeks
...
I do find myself bitter that I'm expected to pick up a trendy language and platform (and have arbitrary recall of every data structure I learned 4 years ago) to even have a chance on the job market.
Are you saying you feel you don't have a chance on the job market, and that you'd really like to have a shot at all the Ruby jobs out there? Why not spend a couple days becoming proficient hacking together a couple OS projects (or contributions) to show your proficiency (hint: the majority of Rails devs I know don't have any OS work to show)? I guarantee this will trump all the "X years experience" requirements and give you a legit shot at all these jobs.
> Why not spend a couple days becoming proficient hacking together a couple OS projects (or contributions) to show your proficiency (hint: the majority of Rails devs I know don't have any OS work to show)? I guarantee this will trump all the "X years experience" requirements and give you a legit shot at all these jobs.
That's a great suggestion. But why does no one put that in the requirements? "Fill this arbitrary criteria -OR- show us that you're a good programmer."
There's even a problem there in that if you've been working with a security firm or just in internal software for long enough, it can be impossible to show all the amazing shit you've done. Everything is "For an extra-good chance at getting hired, show us your GitHub and StackOverflow presence." If we want to get paid, it seems we first have to be willing to work for free. For those of us who have been out of college for a few years, are paying back $60K in debts, and have settled into a soul-sucking tech job that leaves you wanting to nap in the sun by the time you get home, it can be hard to break out of the cycle.
What I'm really saying is that "the Ruby jobs out there" should in actuality be "the programming jobs out there. Oh, and we happen to use Ruby, but since you clearly understand analogous languages, that shouldn't be an issue."
It's worth noting that when you submit your resume/cover-letter/application for a job, it goes to 1 of 2 people. It either goes to some administrative assistant whose sole job is to filter through all the resumes that don't meet some arbitrary requirement (simply a function to arbitrarily cut down the number of resumes they actually have to read). Or it goes directly to the executive hiring for the position. If your resume makes it to this person, pretty much nothing is set in stone (including their own requirements).
Case in point, when I first graduated from college, I landed an engineering job that had "10 years industry experience" as a hard requirement.
Thanks a lot for the data point. I guess the real lesson is to show an interest in and affinity for a position and just apply for it, requirements be damned.
I got my first job in programming by simply applying to every IT job at a company where I worked in the mailroom.
Because it was an internal interview they had to do it (some kind of rule they had to follow) and finally they gave up and gave me a chance with the testy remark that if I failed they never ever wanted to see my face again.
I think that if you are able to learn those languages and frameworks in a couple of hours and you can be productive 'well' in a few weeks that you should maybe invest those few weeks times the number of framework/language combinations that you come across in those job postings, just so next time around (in a few weeks that is) you will be hired.
For me it's different. It takes me a long time to really know a framework (and a language too), the up-front cost is for me ridiculously high and so is the cost of switching.
I take a huge hit in productivity as soon as I hit another language and it takes me quite a while before I'm back up to speed.
I'm 'old school', as in I don't use an IDE, I pretty much memorize the documentation and by the time that I think I'm fluent on a platform, I usually really am.
For you that's obviously different, so don't rant, go and spend that time and you'll be fine.
> I think that if you are able to learn those languages and frameworks... you should maybe invest those few weeks times the number of framework/language combinations that you come across in those job postings, just so next time around (in a few weeks that is) you will MAYBE be hired.
The point is that many companies have sightly different stacks. Your company wants a programmer fitting X criteria... I go fulfill that on my own time while I'm working another full time job, applying to other jobs, and trying to develop personal projects because everyone wants those now too and you then decide that I'm not a good fit, and I get to go do it all over again. Of course it eventually converges as I learn how to build a blog 20 different ways, but why not treat programming jobs more like apprenticeships? The way it is now only makes sense for people who are happy to spend 12-16 hours a day in front of a computer contemplating technology.
> For me it's different. It takes me a long time to really know a framework (and a language too), the up-front cost is for me ridiculously high and so is the cost of switching.
It's like that for everyone because we're forced to wrap our head around a bunch of seemingly-arbitrary design decisions in a solo quest of technology dominance, with haphazard how-to posts and incomplete documentation as our guide. How much easier would it be to learn a company's technology stack in the context of the work you'll be doing, with the guidance of someone who's already working with it?
> For you that's obviously different
Not exactly. I just think the entire setup right now is grossly inefficient and requires a bunch of otherwise valuable employees to bang their head against a wall for a while before anyone will give them a real shot.
I agree absolutely with this. A bad hiring process is responsible for so many problems that companies have. Lots of places which 'require' <insert trendy language / framework> experience hire someone who ends up being in way over their head because they have no real programming ability, just 'knowledge'. Tons of people 'know' how to play a guitar, right? It doesn't mean they're any bloody good at it. Someone who can play a guitar WELL, can probably also play a bunch of instruments, and I'm willing to bet that they'll be able to pick them up fairly quickly too. So they can't play a keyboard right now - I'd put money on it that they'll pick it up pretty quickly if they have to.
The problem companies face is that the real traits of good developers are difficult to evaluate in the interview process. This is why tests (both generic programming tasks and a few 'real-world' problems) during the interview are important. Yes, I hate having to do them, but I recognise their importance. I'm very wary of an interview for a development position that doesn't involve a test at some point.
People hiring for development positions: languages (particularly the new trendy ones) aren't particularly important - a good developer will be able to learn enough in a short time to essentially hit the ground running. Hiring a bad developer who knows (or at least manages to convince you that they know) your favourite language / framework is going to cause you endless headaches.
I completely agree that the whole standard job process is broken.
We've been doing a ton of interviewing recently, and when it comes down to it I don't care one bit what you know or how long you've been doing it. All I care about is: 1) how well can you code, 2) how willing are you to learn new things, and 3) what's your style/personality like.
Maybe you need to ignore those job postings and find the ones that get it. They're out there.
Also, while I haven't done much OSS work, many of my friends are quite active and they have job offers pouring in from everywhere. Consider building something useful, and then throwing the code up on github (w/docs please!).
Consider it a reverse screening function. The worthwhile employers won't give much weight to what you know[1], they'll be more concerned about your ability to think and learn. I've gotten several jobs at places using a language/platform I didn't know because I proved I could think and learn what was necessary. I don't think you'd be happy at places that are busy drinking the kool-aid of one framework or language.
I think this is a great question to ask. I feel the same way, and unless I missed it in the comments so far, I don't see any specific examples that would give me pause.
I'm loving Rails so far, especially after being able to start from scratch and build a viable, working, commercial, revenue earning app in just a week. I'm sold, but scanning the horizon cautiously.
perhaps the theory is one day your site will blow up and you'll need to scale... or hire additional programmers. at which point these things are probably easier with a php app...
there's a certain safety in choosing the more popular language.
- more job opportunity at higher billing rates for Rails
- it's easy to hate on smug people, unless you're on their team
I'm perfectly happy with Rails, because we've now invoiced several million dollars on cool projects that we never would have worked on had we stuck to [in our case, .NET].
Every system I've seen that has some "magic" also has the potential for that magic to reverse itself and become something that seems to work against you. And when that happens, it's easy for the magic to become something you "hate".
Rail and Ruby each a lot of this magic.
No matter what you say, Twitter is relevant. No matter what Twitter says, Twitter is a Rails success story because Rails got a major, major site up and running fast. And naturally when the magic stopped working, everything about Rails just seemed to work them. It was what they needed until they grew into a site that wasn't well served by Rails.
Imagine if I said, "San Francisco is a terrible place to start a business and what proves it is that we experienced wild success and then couldn't rent any more office space, had to split our headquarters and eventually moved to Omaha". How convincing is that?
