Let's say you have a website and let's say that website serves a lot of traffic. Now let's say you relegate Rails to act as just your API because clients are fast now and you want to do some new cool stuff with Javascript also, you're convinced your site is more like an "application". So you build this system and it works really well, except for one thing. The first time you load the page it takes a second or two minimum to get the page loaded. That's ok at first, but really soon it becomes annoying. So you do everything you can with your client, caching whatever possible. You get the load time down to something like 1s. That's better but still not great. Some static sites can spit back pages in like 200ms (across the network!!) and that 800ms difference is crucial to the overall feel and snappiness of your "application". Eventually you give up, you keep the parts of the site that work well as a client-side app, push the rendering back to the server because even though the server is a long ways away from the client and even though clients are fast, you can directly control how quickly the server builds a page and you can optimize that to your heart's content. Now you've gotten your page loads way way down to like 400ms. You're doing great, people love you and you've saved the day. I've fabricated the numbers, but this story is based on truth, because you know who you are? Twitter, Alex's employer.<p>That's not to say that Rails doesn't make a great API and that Alex doesn't have a point. There certainly is a place for frontend applications out there built on frameworks like Spine, Backbone or Ember (all great projects). Those types of applications have their advantages in some cases. But, it's prudent to be pragmatic and to recognize that the times where you truly need to build a client driven application are few and for the other times Rails is still great at serving up HTML.
Not so fast.<p>The backend (i.e. Rails) still does almost everything it used to do: validations, access control, session management, data crunching, and everything else that you can't blindly trust a client to do. The real difference with client-side applications is that instead of stitching together view templates and sending back HTML documents, JSON objects are sent back for the client to represent.<p>More (sometimes duplicate) stuff is added to the client - things like client-side validations, and all the business logic and template code for the purposes of presentation. But no one in their right mind would let their backend blindly consume whatever it gets and persist it without question.<p>There's still plenty of responsibility for the backend.
<i>The caveats in moving state to the client is that it's a huge perceptual shift for developers, with a steep learning curve.</i><p>From my perspective we're coming full circle back to client/server desktop apps... only instead of C++, we're doing it with js inside a browser container... I've done ActiveX controls and Flash components... It's not that much of a stretch.
Strange that there's no mention of Rails new/potential "API only" mode: <a href="https://github.com/rails/rails/blob/efd557a60cd976ac17be9e238111a551599caeb5/railties/guides/source/api_app.textile" rel="nofollow">https://github.com/rails/rails/blob/efd557a60cd976ac17be9e23...</a><p>This will make it much easier to only use Rails as an API and get rid of a lot of the bloat/complexity people seem to complain about.<p>This was posted on edgeguides but it's since been removed some reason (<a href="http://edgeguides.rubyonrails.org/api_app.html" rel="nofollow">http://edgeguides.rubyonrails.org/api_app.html</a>).
This feels very conciliatory towards Rails, like that of a boss praising the employee he just demoted.<p>I'm bearish on Rails because its maintainers <i>don't want it to just be an API</i>. The fight to become the best backend API is much different than the fight to become the best html server. Rails isn't even participating in the fight. Rails has a lot of cruft not needed in an API, Sinatra or Express feel much better for that.
One thing I find interesting is the balance of the Rails model and the Backbone model. On a new project, I generally have fat Rails models and skinny Backbone models. On legacy projects, I put most of the logic into Backbone (since I'd rather not tamper with a legacy backend) making liberal use of parse() and toJSON() in order to get the model the way I want to use it.<p>Rails/Backbone will work well for the time being but I wonder which way the balance will swing? Will we have fat Rails models or fat Backbone models? If it is a fat Backbone model, then maybe direct database queries is the solution, cutting out Rails entirely. CouchDB and others already support this and could make it even simpler in the future.
This is how I feel about Flask.
I've been using it with Backbone.js and they make a great combo: Flask API serving JSON, and the rest of the logic on the client.
I tried this approach and it's clearly attractive, but it also has some disadvantages. I decided to switch back to rendering static HTML in Django (not a Rails guy), with just a little JS on top for now. These are my main reasons:<p>- Debugging on every browser was quite painful. I tried to support IE7+ as well. If a server-side code works, it works for everyone.<p>- Frameworks on the client-side are not as developed as the server-side ones. Also I am reluctant to introduce more client-side libraries than necessarily, so I will end up coding a lot of stuff, that I can get for free in Django otherwise.<p>- The user will need to wait for the JS to load and execute until they see something on the first pageload (at least in my implementation).<p>- If there is a bug in the JS it's harder to get it logged.
Nice article... very timely and fits in with my perception of where I'm headed with my own Rails development.<p>I usually just go with wherever the Rails team is taking the framework. For some legacy sites, I may stick with wherever they're headed.<p>For new projects, I really view Rails as just the web api that feeds my Backbone framework.
The cherry on top is just coffescript and the new sourcemaps functionality coming from browsers.<p>Even if you prefer vanilla javascript, still is an awesome combo.
I'd love to know what people think the current "state of the art" stack is for rich and highly scalable web applications, something that has been proven to work great in production by big projects. Is it nginx + Rails + Backbone? When I think of fast rich web apps, Facebook and StackOverflow come to mind, and as far as I remember, neither use the above-mentioned tools (not that it means they're bad in any way).<p>Just a couple of years ago Rails-generated HTML pages were super hot, and now people are almost insulted if you don't have a fairly complex Javascript framework running the show.
<i>So what's the future for Rails? If you talk to the likes of 37Signals and GitHub, it's pjax and server side rendering. This involves fetching a partial of HTML from the server with Ajax, updating the page and changing the URL with HTML5 pushState.</i><p>I really hope not. Rails is awesome and I love it to bits, but I will hate to have to use a framework that is massively invested in Ajax/Pjax. The reason for this is simple: UX. Companies don't seem to understand that there's more to the world than just America and America's top-notch Internet [1]. A lot of web traffic comes from places where the connectivity is simply shit and interfaces like Quora, GMail, Twitter et al that have so much functionality with server-side JavaScript as a prerequisite make it seriously difficult to have an enjoyable experience more often than not. If you've ever tried to access Google Analytics on a 1mbps shared connection in a relatively populated office, you'll know what I mean.<p>Yes of course Ajax and the interactivity and convenience it offers are awesome, but they come at a massive expense, and this is something that will be very saddening if Rails starts considering it as a major part of its core sooner rather than later.<p>[1] Alright so it's not just America, but my point stands.
Rails is overkill for an api, I think grape <a href="https://github.com/intridea/grape" rel="nofollow">https://github.com/intridea/grape</a> has a lot of potential here.<p>Put node.js in front of something like grape and you have the best of both worlds.
Let's talk about context switches here: OMG! it's going to be sooo hard for developers to switch from a model where all the logic happens on the server and where the client is just a dumb display to a model where the all the logic happens on the client and the server just serves as a coordinator.<p>Oh wait. That already happened, and it was called the switch from mainframes to PCs (or whatever the fuck you want to call it). The point is: developers adapted, and got over it, and you will too.<p>The question I (and everyone in this community) have (or should have) is - are there strong technical foundations for this switch? Is Javascript the right client-side interpreted language to support every conceivable application over the next 10 years? Is HTML the right display/templating language?<p>My answer: no, not at all. But it's hard as hell to fight the momentum of an unstoppable force. Even with an immovable object.
My only gripe with the shift to client side MVC frameworks and such (which although I like!), is that it often makes handling security (from authorization perspective) a bit difficult, at the end of the day I cannot have my authorization based presentation logic in the front end since it can be easily manipulated.
The major reason I'm excited about this shift is the potential for higher scalability out of the box. Instead of rendering pages, the server is just for static pages and data. Instead of using a central server to render for each user, it's distributed out to the computing power of all clients.