Moving on from Rails
broadcastingadam.com
Moving on from Rails
1–10 of 54 posts
Re: Moving on from Rails
#2I don't understand why this article is remarkable.
It shouldn't be a grand revelation that there is more to web development than what runs on the server.
Re: Moving on from Rails
#3I don't understand why this article is remarkable. It shouldn't be a grand revelation that there is more to web development than what runs on the server.
Or a developer getting disinterested in the framework he has been using for a while, for that matter. It's pretty common.
Re: Moving on from Rails
#4This 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.
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.
Re: Moving on from Rails
#5This 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…
I just got finished porting an admin panel from rails views to backbone.js and doing anything in backbone.js is a lot more work. Not only that, you still end up using rails views because you probably want to send pre rendered html to the client to minimize their wait time.
Re: Moving on from Rails
#6I 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.
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.
Re: Moving on from Rails
#7great 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
Re: Moving on from Rails
#8The 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.
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.
Re: Moving on from Rails
#9This 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…
I'm not sure that is true for even the majority of cases.
Remember that most of the web is not applications but simply pages of content server from a database.
Re: Moving on from Rails
#10As 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.
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.
Cocky? Sure. A lot of fun to be part of? Hell yeah.
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.
I recommend anyone that hasn't seen it check out Foy Savas' amazing talk from FutureRuby in 2009, Polyglots, Unite!