6 ms·

While I prefer Django to Rails, I'm glad to see both teams taking support for real-time applications seriously. Some will note that Node has had real-time for

While I prefer Django to Rails, I'm glad to see both teams taking support for real-time applications seriously. Some will note that Node has had real-time for years, but with all due respect to the Node ecosystem, nothing in it (edit: I'm referring to server-side frameworks; I love Ember-CLI) is as nice for developer happiness and productivity as Django and Rails. The best practices that have taken years to be baked into these frameworks make it more difficult to bring in new functionality, but I feel more confident that when new features are implemented, they will be done right.

geebee 11y ago
I have a feeling there are a lot of people looking at this from a similar angle. I feel that we are in a very transitional time for web development right now. This is a field with a pretty high rate of change in general, but every now and then, things change dramatically even by web programming standards, and we go through a period of technological uncertainty. The last time I remember feeling this way was the rise of object relational mappers, dependency injection, model view controller frameworks, and various tag libraries on the front end[1] in javaland. I remember from a previous HN discussion that there is a web counter measuring the number of days since the last javascript framework was released. I remember feeling the same way about struts, struts2, spring MVC, tiles, tapestry, JPA, hibernate, ibatis, spring DI, pico, guice, and so forth… Interestingly, much of this didn't so much get resolved as swept aside - Ruby and Rails, Django, and a few other technologies "appeared" [1, again] at this moment. I do remember feeling extremely grateful for ruby and rails, because I had started to hate programming. It wasn't the Java verbosity that I objected- I rather enjoyed programming with servlets/jsp and jdbc + the java web cookbook, and I never minded data structures and algorithms in Java - it was the churn and incredible amount of complexity just to do simple things that made me unhappy. Rails got some bloat here and there, expand and consolidate, but I feel that it did accomplish its main goal, at least for me, which was that I felt happy and productive programming again. Now, with the disruption of SPAs, we are clearly back in framework churn, and I'm not loving the model of writing the back end in rails-api and using a javascript front end. I may warm up to this as my knowledge of javascript increases (and I certainly never minded going outside rails and writing sql, so I can't really say I object to more than one language). I've done a bit of ember, and it seems heavy to me, I have to duplicate so much routing, model, persistence, data tier work (I'm a noob, I may be doing it wrong, fully possible). I don't like looking at javascript as much as I like looking at ruby. I also do remember feeling a bit frustrated with Rails in the beginning, before I understood it well enough to do an end-run around conventions, so like I said, I may really warm up to javascript frameworks. But I really like Ruby, and I'm very satisfied with Rails (and if not rails, sinatra or something like that would be fine too). Like I said earlier, I studied a lot of java-based MVC/DI/ORM approaches and ended up going with something that I hadn't even considered (Rails). I do think that in these highly transitional periods, this tends to happen - that you are surprised by the solution that ends up working for you. At this point, it's getting so speculative that I'm not highly confident in predicting things, but I wouldn't be too surprised if the "isometric" transpiled languages (like ruby and opal) end up changing things dramatically (ie., just as I didn't end up "picking" a java-based MVC/DI/ORM approach, I may not end up picking a javascript framework, I may end up surprised by a new and different approach). [1] I understand these weren't really "new" ideas, many of them (like a lot of CS) go back to the 1970s, but they hit the scene in that they became an issue in day to day development for ordinarliy up-to-date but not cutting edge web developers, the people who just wanted to get things done.
- steveklabnik 11y ago
  > I've done a bit of ember, and it seems heavy to me, One thing about Ember: it's specifically for "ambitious" applications. The idea is that you're going to be building something which needs all those things, so it's better to have them in the framework, where best practices can be shared across projects. Once you've built out those features yourself, you've built a custom framework anyway. An interesting point about frameworks, generally: they have a constant overhead. So for smaller projects, the framework dominates the application, but as the application grows, the application will dominate the framework.
  - sandstrom 11y ago
    We're using Rails (in 'API-mode') with Ember. It's a great combination in my view. Thrilled to see Rails 5 providing even better support for this combination. @steveklabnik Thanks for spearheading Rails-api! :) Re: Ember being heavy; yes, it is a bit heavy but that has huge payoffs as your application grows.
    - steveklabnik 11y ago
      Any time. It's been a few years, but it's finally in. Frankly, I had very little to do with it becoming eventually included, I believe that was Dan Gebhardt's work.
  - geebee 11y ago
    I should probably give some context for that statement. When I first learned Rails, it actually wasn't easy. People will probably be surprised to hear me say this, but Rails felt heavy! Seriously, compared to jdbc, servlets, and jsp, it felt heavy. I'd guess that people who were programming in PHP or perl/CGI probably felt it was "heavy" at first too. Of course, my code base was getting "heavy" too, since it was disorganized and mixed a lot that shouldn't be mixed. But if I wanted to do something, I didn't have to figure out the rails or spring way of doing it. I could go to the java web cookbook, or just write it up however I pleased. It feels a little weird calling jdbc "low level", but at the level of the task I was trying to perform (getting stuff into a database, programming logic on data, putting stuff back into a database, displaying stuff to a user), servlets and jdbc are actually kind of low level. You can do pretty much whatever you want, quick and dirty request-response, or build out your own MVC, ORM, and DI framework. Now, on the other hand, compared to Struts or Spring MVC, Hibernate, and Spring DI, Rails felt lightweight. But if you compare someone else's MVC framework, like Rails, to a database connection and a programming language that can write out a server response, it's going to feel a little heavy, and you're going to feel a bit lost at first, no matter how good it is. It took me a while to get used to Rails even though I consider Rails to have a friendly learning curve. So I do want to be clear that I don't necessarily consider Ember to be "heavy" in the context of what Ember seeks to accomplish. To me, the real issue here is that if I'm going the rails-api route, I will have to use something non-ruby on the client. And then the question becomes why not just use javascript on the server, too, with node.js? Honestly, my initial study and experimenting with node and express have been positive, but I don't like the idea of giving up on ruby, or that all these wonderful server-side languages are obsolete now because for the moment, javascript rules the browser. Nothing wrong with node.js, at all, for those who like it but I have trouble believing that all web development, server side as well as client side, slowly migrates over to javascript, and that python and ruby become legacy languages because, well, why use anything other than javascript? At this point, I'm just repeating myself, but I'll restate my very tenuously held belief that isomorphic, transpiled languages will play a big role in the resurgence of non-javascript languages for full stack development.
jbhatab 11y ago
I don't want to start a rails vs Django conversation, but why do you prefer Django over rails? I'm a rails dev and am just curious where Django is at with things.
- ralmidani 11y ago
  A little bit of background: I learned Django first. Then I learned Rails via Code School, and flirted with building my app with Rails instead of Django. I saw the asset pipeline specifically as a Rails advantage over Django (I write Emblem, indented Sass, and CoffeeScript whenever I can avoid HTML/Handlebars, CSS, and JS). Also, building JSON APIs with Rails has better out-of-the-box support than it does in Django. I always felt Rails' model layer is clunky compared to Django's. What is the definitive representation of my model? The validations in SomeModel < ActiveRecord::Base or what's automatically generated in schema.rb when I run migrations via Rake? In Django everything, including migrations (in simple cases), is derived from the classes in models.py. But I thought it would be worth it to persevere, due to the above-mentioned advantages. Then I realized I could (and should) compile assets via Ember-CLI, and Django Rest Framework is just a pip install away. So the two main advantages of Rails disappeared, and switching back to Django became, for me, a no-brainer. Edit: I also prefer Django's less magical approach. This may seem ironic given my love of Ember, but Ember's magic is easier for me to understand than that of Rails.
  - JohnBooty 11y ago
    Personal opinion, obviously, but I also find Rails to be way too magical sometimes.
- dasil003 11y ago
  I am also a Rails dev, but one feature I think Django really got right that is head and shoulders above Rails are Form Objects (https://docs.djangoproject.com/en/1.9/topics/forms/ https://docs.djangoproject.com/en/1.9/topics/forms/). Rails' attr_accessible stuff and even strong_parameters really pales in comparison.
  - 11y ago
ryanSrich 11y ago
As a designer that started programming in rails, that now uses front-end frameworks like Angular to build prototypes, I absolutely agree with you. JavaScript MVC experience vs. Rails/Django is night and day. I know it's not an apples to apples comparison, but JavaScript, npm, grunt, etc. etc. are all a real drag imo.

geebee 11y ago

I have a feeling there are a lot of people looking at this from a similar angle. I feel that we are in a very transitional time for web development right now. This is a field with a pretty high rate of change in general, but every now and then, things change dramatically even by web programming standards, and we go through a period of technological uncertainty. The last time I remember feeling this way was the rise of object relational mappers, dependency injection, model view controller frameworks, and various tag libraries on the front end[1] in javaland. I remember from a previous HN discussion that there is a web counter measuring the number of days since the last javascript framework was released. I remember feeling the same way about struts, struts2, spring MVC, tiles, tapestry, JPA, hibernate, ibatis, spring DI, pico, guice, and so forth… Interestingly, much of this didn't so much get resolved as swept aside - Ruby and Rails, Django, and a few other technologies "appeared" [1, again] at this moment. I do remember feeling extremely grateful for ruby and rails, because I had started to hate programming. It wasn't the Java verbosity that I objected- I rather enjoyed programming with servlets/jsp and jdbc + the java web cookbook, and I never minded data structures and algorithms in Java - it was the churn and incredible amount of complexity just to do simple things that made me unhappy. Rails got some bloat here and there, expand and consolidate, but I feel that it did accomplish its main goal, at least for me, which was that I felt happy and productive programming again. Now, with the disruption of SPAs, we are clearly back in framework churn, and I'm not loving the model of writing the back end in rails-api and using a javascript front end. I may warm up to this as my knowledge of javascript increases (and I certainly never minded going outside rails and writing sql, so I can't really say I object to more than one language). I've done a bit of ember, and it seems heavy to me, I have to duplicate so much routing, model, persistence, data tier work (I'm a noob, I may be doing it wrong, fully possible). I don't like looking at javascript as much as I like looking at ruby. I also do remember feeling a bit frustrated with Rails in the beginning, before I understood it well enough to do an end-run around conventions, so like I said, I may really warm up to javascript frameworks. But I really like Ruby, and I'm very satisfied with Rails (and if not rails, sinatra or something like that would be fine too). Like I said earlier, I studied a lot of java-based MVC/DI/ORM approaches and ended up going with something that I hadn't even considered (Rails). I do think that in these highly transitional periods, this tends to happen - that you are surprised by the solution that ends up working for you. At this point, it's getting so speculative that I'm not highly confident in predicting things, but I wouldn't be too surprised if the "isometric" transpiled languages (like ruby and opal) end up changing things dramatically (ie., just as I didn't end up "picking" a java-based MVC/DI/ORM approach, I may not end up picking a javascript framework, I may end up surprised by a new and different approach). [1] I understand these weren't really "new" ideas, many of them (like a lot of CS) go back to the 1970s, but they hit the scene in that they became an issue in day to day development for ordinarliy up-to-date but not cutting edge web developers, the people who just wanted to get things done.

steveklabnik 11y ago
> I've done a bit of ember, and it seems heavy to me, One thing about Ember: it's specifically for "ambitious" applications. The idea is that you're going to be building something which needs all those things, so it's better to have them in the framework, where best practices can be shared across projects. Once you've built out those features yourself, you've built a custom framework anyway. An interesting point about frameworks, generally: they have a constant overhead. So for smaller projects, the framework dominates the application, but as the application grows, the application will dominate the framework.
- sandstrom 11y ago
  We're using Rails (in 'API-mode') with Ember. It's a great combination in my view. Thrilled to see Rails 5 providing even better support for this combination. @steveklabnik Thanks for spearheading Rails-api! :) Re: Ember being heavy; yes, it is a bit heavy but that has huge payoffs as your application grows.
  - steveklabnik 11y ago
    Any time. It's been a few years, but it's finally in. Frankly, I had very little to do with it becoming eventually included, I believe that was Dan Gebhardt's work.
- geebee 11y ago
  I should probably give some context for that statement. When I first learned Rails, it actually wasn't easy. People will probably be surprised to hear me say this, but Rails felt heavy! Seriously, compared to jdbc, servlets, and jsp, it felt heavy. I'd guess that people who were programming in PHP or perl/CGI probably felt it was "heavy" at first too. Of course, my code base was getting "heavy" too, since it was disorganized and mixed a lot that shouldn't be mixed. But if I wanted to do something, I didn't have to figure out the rails or spring way of doing it. I could go to the java web cookbook, or just write it up however I pleased. It feels a little weird calling jdbc "low level", but at the level of the task I was trying to perform (getting stuff into a database, programming logic on data, putting stuff back into a database, displaying stuff to a user), servlets and jdbc are actually kind of low level. You can do pretty much whatever you want, quick and dirty request-response, or build out your own MVC, ORM, and DI framework. Now, on the other hand, compared to Struts or Spring MVC, Hibernate, and Spring DI, Rails felt lightweight. But if you compare someone else's MVC framework, like Rails, to a database connection and a programming language that can write out a server response, it's going to feel a little heavy, and you're going to feel a bit lost at first, no matter how good it is. It took me a while to get used to Rails even though I consider Rails to have a friendly learning curve. So I do want to be clear that I don't necessarily consider Ember to be "heavy" in the context of what Ember seeks to accomplish. To me, the real issue here is that if I'm going the rails-api route, I will have to use something non-ruby on the client. And then the question becomes why not just use javascript on the server, too, with node.js? Honestly, my initial study and experimenting with node and express have been positive, but I don't like the idea of giving up on ruby, or that all these wonderful server-side languages are obsolete now because for the moment, javascript rules the browser. Nothing wrong with node.js, at all, for those who like it but I have trouble believing that all web development, server side as well as client side, slowly migrates over to javascript, and that python and ruby become legacy languages because, well, why use anything other than javascript? At this point, I'm just repeating myself, but I'll restate my very tenuously held belief that isomorphic, transpiled languages will play a big role in the resurgence of non-javascript languages for full stack development.

jbhatab 11y ago

I don't want to start a rails vs Django conversation, but why do you prefer Django over rails? I'm a rails dev and am just curious where Django is at with things.

ralmidani 11y ago
A little bit of background: I learned Django first. Then I learned Rails via Code School, and flirted with building my app with Rails instead of Django. I saw the asset pipeline specifically as a Rails advantage over Django (I write Emblem, indented Sass, and CoffeeScript whenever I can avoid HTML/Handlebars, CSS, and JS). Also, building JSON APIs with Rails has better out-of-the-box support than it does in Django. I always felt Rails' model layer is clunky compared to Django's. What is the definitive representation of my model? The validations in SomeModel < ActiveRecord::Base or what's automatically generated in schema.rb when I run migrations via Rake? In Django everything, including migrations (in simple cases), is derived from the classes in models.py. But I thought it would be worth it to persevere, due to the above-mentioned advantages. Then I realized I could (and should) compile assets via Ember-CLI, and Django Rest Framework is just a pip install away. So the two main advantages of Rails disappeared, and switching back to Django became, for me, a no-brainer. Edit: I also prefer Django's less magical approach. This may seem ironic given my love of Ember, but Ember's magic is easier for me to understand than that of Rails.
- JohnBooty 11y ago
  Personal opinion, obviously, but I also find Rails to be way too magical sometimes.
dasil003 11y ago
I am also a Rails dev, but one feature I think Django really got right that is head and shoulders above Rails are Form Objects (https://docs.djangoproject.com/en/1.9/topics/forms/ https://docs.djangoproject.com/en/1.9/topics/forms/). Rails' attr_accessible stuff and even strong_parameters really pales in comparison.
- 11y ago

ryanSrich 11y ago

As a designer that started programming in rails, that now uses front-end frameworks like Angular to build prototypes, I absolutely agree with you. JavaScript MVC experience vs. Rails/Django is night and day. I know it's not an apples to apples comparison, but JavaScript, npm, grunt, etc. etc. are all a real drag imo.