21–30 of 114 posts
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.
This was posted on edgeguides but it's since been removed some reason (http://edgeguides.rubyonrails.org/api_app.html).
The caveats in moving state to the client is that it's a huge perceptual shift for developers, with a steep learning curve. 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: https://github.com/rails/rails/blob/efd557a60cd976ac17be9e23... 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. This was posted on edgeguides but it's since been removed some reason ( http://edgeguides.rubyonrails.org/api_app.html ).
Now, put that aside, I do agree :)
The caveats in moving state to the client is that it's a huge perceptual shift for developers, with a steep learning curve. 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.
It's in both mobile apps, browser based JS app, etc.
My talk was rejected. PUNKS!
The caveats in moving state to the client is that it's a huge perceptual shift for developers, with a steep learning curve. 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.
We're also taxing browsers more, while simultaneously trying to run on less-powered devices. It almost defeats the point of a thin client.
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.
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.
There's still plenty of responsibility for the backend.
It took me a bit to realize this wasn't Dustin Curtis' website; is this a theme or what?
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. Rails/Backbone will work well for the time being…
The problem with fat client-side models is that allows malicious users to potentially break your code. Inject bad things. Re-assign users. Etc. We'll always need some sort of server-side last-mile, tamper-proof validation. So given that, I'm not sure the benefit of duplicating it on the client side.
You duplicate validation logic on the client side in order to provide rapid feedback to the user. But it's a huge mistake to not let the backend have the final say.
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 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…