As an early Rails adopter who rarely gets to code directly on projects anymore (I'm a victim of my own success) I find it really curious when developers feel the need to post expository essays about framework switches. Things move fast and it would be bad for tech evolution to stop, so there's nothing to be loyal to unless you've placed awkward bets on the future of any given tool.<p>DHH said at the first RailsConf that he was tired of people asking if Rails would "hit critical mass" or become "ready for the enterprise" because Rails as a tool hit critical mass the moment it was useful to him and the core team that built Basecamp and Shopify. If anyone else found it useful then awesome, but everyone else can pretty much go fuck themselves.<p>Cocky? Sure. A lot of fun to be part of? Hell yeah.<p>I've never been on core but I can arrogantly speak for the early Rails community when I say that we excitedly encourage all Rails fans to try out Node, Django, SC and Backbone. Anything which captures your imagination and makes you see coding in a more whimsical, _why?-like way.<p>I recommend anyone that hasn't seen it check out Foy Savas' amazing talk from FutureRuby in 2009, Polyglots, Unite!<p><a href="http://www.infoq.com/presentations/savas-polyglots" rel="nofollow">http://www.infoq.com/presentations/savas-polyglots</a>
The author seems to consistently confuse architecture, languages and frameworks. None of his arguments have anything to do with Rails, Ruby, PHP or whatever else he mentions, except partly Javascript.<p>This seems to be a recurring pattern with developers who have "discovered" design and architecture through frameworks and can not seem to separate that from the tools used.
I think the whole point here is: build APIs first, wrap all the client code around them. If I have an API written in Ruby/PHP/node.js/Java/whatever, and a standard format (or protocol) to exchange data, I can then build the clients in Ruby/PHP/node.js/Java/whatever, clearly separating the backend and the frontend which can now be built in completely different ways using different technologies.<p>This is not new. There are lots of system out there built on top of private/public RESTful (XML/JSON/whatever)/SOAP APIs. There are both huge and small applications on top of distributed, stateless, components that clients can easily consume and that makes the whole architecture highly scalable (again: stateless). People can do this on HTTP, TCP, UDP or on TheirCoolProtocol.
"I was coming from PHP. PHP was shit then and is still shit now."<p>I find it embarrassing that the community would vote up a story with comments like this. There is simply no need for it, and it shows nothing but a lack of articulation and outright immaturity.<p>If you don't like PHP, fine, but slamming it with one word insults does nothing but insult the tens of thousands of developers out there that use PHP to solve real world problems for a living.
This is less about moving on from Rails and more about moving on from building static pages from a database. Lots of web folks have been predicting this. I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. With things like Backbone, I can bring up a Rails app without views and do something pretty awesome. And then it becomes a question as to what Rails offers.<p>I love Rails. It got me back into web app development in 2005 after nearly burning out. But Rails isn't exactly keeping up and people who need to move on are going to do that.
I did a single-page app before with GWT. I guess the GWT crowds beat y'all by miles since 2007.<p>The problem with this kind of web-app is that it's so much harder, so much more difficult, so much effort is required. And you need to be very very discipline and build automation testing from ground up (and I know many developers are just lazy to write automation testing, don't give me the start-up/iterate faster excuse, lazy is lazy).<p>At least with GWT, there are patterns and good practices to support unit-testing and modularizing your app properly.<p>In JavaScript? the fight just goes uphill straight away. In 2011, we still don't have automation test framework that is headless (console based) without requiring investment to infrastructure. And this is largely because the mentality of JS developers is to test in real-browser. Which is fine. Except the extra effort required to setup automation-test will cause a lot of people to find more excuse not to write automation test.<p>I get that developers are optimist people. But time through time, developers get burned so bad. Most people don't even know how to write JavaScript code properly but they're so ambitious. These people bite more than what they can chew.<p>So... good luck doing that while some of us will stick with Rails/Django/PHP/JEE6. Get ready, you're in for a lot of pain.
I don't understand why this article is remarkable.<p>It shouldn't be a grand revelation that there is more to web development than what runs on the server.
TL;DR When web applications is written mainly in javascript and communicates with the server over json, what language is beeing used on the server becomes less important. As long as it's not php. ;-)
great summary of architecture trends. i think there's a room out there for someone to build a framework with the server-side simpleness of Rails and the client-side elegance of Backbone/SproutCore
It seems like the title is a bit poorly chosen.<p>The author talks about the importance of having a platform to cater to the multitude of devices and other apps out there, and that this means rails isn't the center of the universe anymore.<p>To me, this does not necessarily mean moving on from rails.<p>It does mean moving on from writing all code in rails.<p>There could be a fullfledged backbone.js app powering a responsive ui, and a distributed clojure jobqueue making sure messages are fanned out to their destined networks in the backend. However, there is still room in this picture for Rails as a router of sorts.<p>Rails still makes it easy to quickly build a solid REST api, and easy to delegate long-running jobs to a separate system, in this type of architecture, Rails would have roughly a third of the responsibility / code that it has in a Rails only architecture, but it's still a vital component.
tl;dr - web development is changing, the frontend side of things is gaining significance, while the backend is moving to, well, the background.<p>No reason to be surprised there, right?
"From my experience, generating a good UI (V) takes orders of magnitude more than implementing M and C."<p>yeah, because picking the right font has always been way more of a task than domain modeling..
(yes, i know that ui / ux isn't a breeze, but this depiction is just insane.)
"Think back to when Rails first came out. There was no iPhone. There was no Android. People still owned Nokias and actually bought stock in the damn company. Windows XP was still massively popular and we were fighting to get a decent version of IE (but that will never end). There was no such thing as a mobile web. No one was thinking about tablets. How old is the iPad? Not very old".<p>OK, no iPhone and the iPad is not very old. Wikipedia should change their contents, especially on the dates when the iPhone and iPad were launched.