3 ms·

Ruby/Rails seems to have a more developer-friendly approach to the web development stack than Python/Django. (I am but an egg, more comfortable in Python/Djang

Ruby/Rails seems to have a more developer-friendly approach to the web development stack than Python/Django. (I am but an egg, more comfortable in Python/Django but learning Ruby/Rails, I wouldn't argue with more experienced folks about any of the following.) Ruby/Rails seems easier to develop and test the full stack application, from client JavaScript to server Ruby response and back. It supports Ajax through injection of injection of JavaScript into HTTP responses served up, based on specifications in server side code. The test architectures seem to reach across the client/server divide, for example checking server side responses to triggering client-side JavaScript. Python/Django are trying, with like lettuce and splinter, but these don't yet seem to be quite to the same standard. Also, because RoR has a lead on web development, new developments in that space seem generally better integrated. For example, Backbone is a young JavaScript MVC style framework for client side development. I've just been fooling with using it with Django, and discovered that its stringification of Json objects for POST doesn't work with Django's parsing of the client request. Maybe more experienced developers spotted and fixed this easily -- my fix is only a couple of lines -- but it's the sort of thing that makes me wonder just how many folks have tried to integrate Django w/ Backbone. I'm guessing that the Backbone community has already spotted and fixed any such issues with RoR. Now I'm not sure how I feel about RoR, it often feels like magic and I'm a little suspicious of stuff like super-convenient JavaScript injection. Maybe when I understand it better it will seems less magical and more convenient. But it isn't hard to see why the web development community likes it.

funksta 15y ago
One of the differences between Django and Rails is that the former makes almost no assumptions about how you are going to write your front end. I don't know much about Rails, but it seems to me that it is much more opinionated in that regard. Re: Django & Backbone, you should check out djangbone. It makes it dead simple to create a basic backbone-compatible APIs in Django, and is easy to extend if you need more advanced functionality (full disclosure- I'm its author): https://github.com/af/djangbone https://github.com/af/djangbone
alinajaf 15y ago
RE: javascript injection, it's totally optional and in years of doing rails dev work I've never used it (I presume you're talking about the 'remote' option). Actually, the vast majority of my rails stuff recently has been RESTish (or at least Backbone compatible) json endpoints with a CoffeeScript frontend. The front and back end in that case are totally decoupled (though rails does do some nice things to help you organize your frontend code). This would have been hard a few years ago but I've found that as time has wore on rails has become quite a bit more forgiving when you disagree with DHH, e.g.. you can use whatever templating language, testing framework or ORM you like, and there will be others who made the same choice you can look to for support. It's still opinionated about defaults, but you can switch out whatever libraries you like these days, for the most part.

funksta 15y ago

One of the differences between Django and Rails is that the former makes almost no assumptions about how you are going to write your front end. I don't know much about Rails, but it seems to me that it is much more opinionated in that regard. Re: Django & Backbone, you should check out djangbone. It makes it dead simple to create a basic backbone-compatible APIs in Django, and is easy to extend if you need more advanced functionality (full disclosure- I'm its author): https://github.com/af/djangbone https://github.com/af/djangbone

alinajaf 15y ago

RE: javascript injection, it's totally optional and in years of doing rails dev work I've never used it (I presume you're talking about the 'remote' option). Actually, the vast majority of my rails stuff recently has been RESTish (or at least Backbone compatible) json endpoints with a CoffeeScript frontend. The front and back end in that case are totally decoupled (though rails does do some nice things to help you organize your frontend code). This would have been hard a few years ago but I've found that as time has wore on rails has become quite a bit more forgiving when you disagree with DHH, e.g.. you can use whatever templating language, testing framework or ORM you like, and there will be others who made the same choice you can look to for support. It's still opinionated about defaults, but you can switch out whatever libraries you like these days, for the most part.