I have a couple of criticisms of your article. Firstly, you give a list of successful companies who made the "safe choice" you're advocating, but you fail to mention that at the time the companies adopted those projects they were actually the cool, risky new upstarts. Your first example, Twitter, started in 2006 - a mere 18 or so months after Rails 0.8. If Twitter had followed your advice of using a 13 year old web framework when they started, what would they have been using? ColdFusion? They succeeded by using the productive new technology - which at the time (absolutely not now) was Rails.
And secondly, some of the features you list the frameworks as having are questionable at best. Rails has built-in user accounts, permissions and admin interface? Since when? And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
I think you confused the two messages of "don't build your own web framework" (I heartily agree) with your assertion that a startup in 2017 would be somehow remiss to not be using frameworks developed in the time of Windows XP, with which I do not agree.
For me the current "Rails in 2006" framework is elixir/phoenix, and for the slightly less adventurous, something in nodejs - maybe meteor or plain express. Of course Rails still works, and is not an absolutely horrible choice, but it's for last decade's web, and has profound disadvantages compared to today's technology.
I agree with you completely that these frameworks are old. They don't get features like websockets immediately. From a performance standpoint, they are lacking with respect to compiled languages. Statically-typed choices have come a long way.
However, for new business owners who don't care so much about getting an A+ for technical excellence, I would still stand by this advice. The benefits of technology maturity and ecosystem are extremely compelling.
Today, for someone who just wants to let their users log in with Facebook, Elixir has far fewer user-friendly resources and will require more technical expertise to produce the same result. How many StackOverflow questions address common woes in these popular frameworks as opposed to the up-and-comers? How easy is it to hire someone to build + maintain? What about for hiring on the cheap? What existing libraries and integrations exist?
Of course, these things get better for new technologies over time. Until then, I can't tell people to use them if it incurs a disproportionate cost to achieve the same return.
Lastly, that "it's old" is not a compelling reason to me to recommend something else. GNU/Linux was created in the 90s, and it's still everywhere and growing. There's a job for an operating system to do, and GNU/Linux solves it well enough for the amount of effort required to use it. I believe the same to be true for Django or Rails in building a fast business prototype for most enterprise or consumer use cases. I think measures of suitability for the task are more relevant than age.
Well, I agree with you of course. Re-reading my comment, I overstated my case somewhat. The truth, as always, is somewhere in the middle. I suppose I was reacting to the previous comments as well, asserting that anyone choosing anything other than the boring, tried-and-true mature stacks for any new project whatsoever was being "seduced by technology" and otherwise an irresponsible and non-pragmatic neophilic dilettante who is not a Serious Businessman Like Me.
For the use case you're describing, I agree completely with your comments. Perhaps a useful razor is - if you can't state specifically why you can't use rails (and don't say "it doesn't scale"!) - then use rails. I concede that 90% of the time, this is probably the case.
And yes, harping on about its age was silly of me. Age does not inherently mean anything. I'd use postgres (1984!) over mongodb anyday. And erlang is older than ruby. Right tool for the job is far more important, thanks for pulling me up on that.
All that said - I still think that categorically stating "use boring technology" or "just use rails" for absolutely any new project is harmful. New technologies are not always just about the new shiny, they can provide capabilities and functionality simply unachievable with the old. Look at what you can do with concurrency with phoenix. Look at what you can do with react native. Roundly writing off the whole idea of using this new tech as "magpie development" is just lazy.
> And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
And secondly, some of the features you list the frameworks as having are questionable at best. Rails has built-in user accounts, permissions and admin interface? Since when? And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
I think you confused the two messages of "don't build your own web framework" (I heartily agree) with your assertion that a startup in 2017 would be somehow remiss to not be using frameworks developed in the time of Windows XP, with which I do not agree.
For me the current "Rails in 2006" framework is elixir/phoenix, and for the slightly less adventurous, something in nodejs - maybe meteor or plain express. Of course Rails still works, and is not an absolutely horrible choice, but it's for last decade's web, and has profound disadvantages compared to today's technology.