That said, I believe he is a bit right in that Rails is no longer the new kid on the block, but you should read Jeff Atwood's post on Ruby (and maybe steal some arguments from him!):
http://www.codinghorror.com/blog/2013/03/why-ruby.html
"Ruby isn't cool any more. Yeah, you heard me. It's not cool to write Ruby code any more. All the cool people moved on to slinging Scala and Node.js years ago. Our project isn't cool, it's just a bunch of boring old Ruby code. Personally, I'm thrilled that Ruby is now mature enough that the community no longer needs to bother with the pretense of being the coolest kid on the block. That means the rest of us who just like to Get Shit Done can roll up our sleeves and focus on the mission of building stuff with our peers rather than frantically running around trying to suss out the next shiny thing."
> My manager called Rails passé this morning [...]
> our team to start using a single page architecture
What server-side framework does your manager think should be used with the client-side framework? > a trend just like rails was a year ago.
Rails was a trend a year ago (2012)? Out of curiosity, what was Rails between 2005 and 2011?Your second comment is a good one. What I think he meant by "trend" was that last year Rails was what all the architects and leaders at the company were pushing for. His argument was that this year it's the same thing except with single page architecture (Backbonejs in this case).
For a company where development is not core, I wouldn't recommend it, but if the company is a tech company, I would evaluate devoting resources to learning single page applications and doing some pilot projects, then leveraging the experience and pushing it into the main projects if applicable :) .
Using Rails will save us '$x' over time and use 'y' less engineers.
On the flip side, you do have to calculate the ramp up time of learning the technology.
To make a convincing argument, try to understand the other person's value system.
It's (intendedly) a simplification, but one that aptly describes how to respond to a situation like yours.
There is value in both style and principle, but there's a distinction between the type of value each provides. As a member of Society, Style has obvious social value.
Programming is a society as any other. The social value of following trends (swimming with the current) is that often many of the most creative & adventurous of us are early adopters of trend. Being the best people is so important, that it's often worth taking a leap based on that.
Usually genuine programming trends starts with a small group of bright hackers imagining a different future. They've probably got at least a couple inspiring ideas and it's worth taking a risk that these are the right ideas.
Every good hacker (or scientist, engineer, founder, writer, artist, thinker) has first principles. Whether they've explored their own intellect as much as say Paul Graham, unlikely, but if your moorless at sea, your simply at the mercy of every current that comes along. You simply wouldn't get anywhere.
To wrap up this wordy spiel, here's an summary:
> Use the current (Style) to arrive at your rock (Principle)
Rails was part of the old paradigm where a webapp runs on the server and sends HTML pages to the client.
The new paradigm, which I would not call single page architecture for historical reasons, sends the app to the client in when they open a page, and then runs on the client and only calls back to the server to get/post data. And maybe load some additional code blocks. These apps are built in Javascript with underscore, backbone, angular, ember and related tools. They are also typically MVVM or MV(something other than C).
> Rails was part of the old paradigm
> where a webapp runs on the server
Web apps no longer run on servers? They insert data directly into databases from the client? Isn't that insecure?The developers of Rails::API should be informed about the new paradigm so that they stop wasting their time.
> then runs on the client and only calls back to the server to get/post data.
And what's running on the server to handle those GET's/POST's?Realistic options are
a) Deal with what the manager wants you to code in
b) Find a new job