Off-topic but: Anyone know if Alex is hosting the code for that Kudos widget anywhere? Couldn't find it on his Github.
Rails is just an API
11–20 of 114 posts
Re: Rails is just an API
#12This feels very conciliatory towards Rails, like that of a boss praising the employee he just demoted.
I'm bearish on Rails because its maintainers don't want it to just be an API. 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.
Re: Rails is just an API
#13It took me a bit to realize this wasn't Dustin Curtis' website; is this a theme or what?
Re: Rails is just an API
#14It took me a bit to realize this wasn't Dustin Curtis' website; is this a theme or what?
Maybe check out: http://svbtle.com/
Re: Rails is just an API
#15[deleted]
Re: Rails is just an API
#16One 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.
Re: Rails is just an API
#17Off-topic but: Anyone know if Alex is hosting the code for that Kudos widget anywhere? Couldn't find it on his Github.
Seems to be a product of the platform http://svbtle.com/
Re: Rails is just an API
#18So 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: 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.
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.
[1] Alright so it's not just America, but my point stands.
Re: Rails is just an API
#19So 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…
Thing is, AJAX should help with this stuff. No more wasteful page reloads where 90% of the HTML is the same, etc. Granted, we don't see that all the time, but the theory is sound.
Re: Rails is just an API
#20The 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.
This is a recurring cycle in application development. We've gone from mainframes and minicomputers serving plain text to dumb terminals, to programs running on personal computers accessing applications and data on servers, to web servers serving structured text to 'dumb' browsers, to powerful in-browser runtime engines accessing applications and data over the web.
There's no magic bullet.