5 ms·

I think Django comes close to Rails with regards to productivity. Granted, Django has slightly more overhead to get started, but Django also includes an admin i

by erokar 8y ago

I think Django comes close to Rails with regards to productivity. Granted, Django has slightly more overhead to get started, but Django also includes an admin interface and a built-in auth system, which Rails does not.

0xADEADBEE 8y ago
I work in a lot of Django shops and my Ruby is nowhere near as good as my Python but I'll pick Rails every time if I'm working on a side project. Why? Because the development velocity when using it is unparalleled. I can have an MVP up orders of magnitude quicker than I can with Django/Flask/Twisted. You're absolutely right on the Admin interface and auth, but auth is a gem install away [1] and Django's admin won't fit my requirements more often than it helps; I can seldom justify exposing it to end users and it's a hideous undertaking to extend it meaningfully (I gather this is one of the reasons it is a bit of a laggard compared with the rest of the framework. We only got mobile support out the box in 2.0 for example [2]). Other reasons I enjoy Rails: - Scaffolds allow me to have CRUD support for any model I want with one command (combined with auth, I have Django's admin, more or less) - JSON views without a third party library (surely this is pretty standard for a web framework in 2018 in most cases?) Other reasons I don't enjoy Django so much: - I can't think of an eloquent way to phrase this but Rails values my time. With Django I'm doing menial minutiae like creating a directory for my app's templates before it'll serve a page. Why? I know 'magic' is anathema to the Python community but context switches like this shouldn't be there when I'm trying to get an app up and running at speed - I feel like it's stewardship is bordering on begrudging: Why are websockets (and JSON for that matter, but I've touched on that) not present in a 'kitchen-sink' web framework? I'm not sure why we're worrying about master/slave DB terminology [3] when there are axiomatically more pressing technical and adoption-related issues at hand. Django is a fine web framework, and perhaps the best-in-breed for Python, but it feels miles behind where it should be at this point and I'm not really sure why. [1] - https://github.com/plataformatec/devise https://github.com/plataformatec/devise [2] - https://docs.djangoproject.com/en/2.1/releases/2.0/#mobile-friendly-contrib-admin https://docs.djangoproject.com/en/2.1/releases/2.0/#mobile-f... [3] - https://github.com/django/django/pull/2692 https://github.com/django/django/pull/2692
- vinceguidry 8y ago
  The source of Rails ease-of-use appears to flow from Ruby's object model, which I have yet to see a more elegant one outside of the Smalltalk ecosystem. Ruby's semantics just seem to be a natural fit for the web, where visual presentation of information seems to almost demand a truly-flexible set of tools. You want a smooth progression of tooling that you can approach and slowly clarify ever-finer approaches to over time. The object model is the base of the pyramid, it's the thing you rely on when nothing else solves the problem, you know you can always invent a new kind of object hierarchy by refactoring to BasicObject, obliterating stdlib semantics with a veritable flamethrower. I've never put such a thing into production, because I know there's always less drastic ways to define, mold, shape, and extrude abstractions. With less semantically-fluid languages, you wind up relying on the same few tricks over and over and over again, because they solve problems, albeit poorly and opaquely. This flows, again, from the underlying approach to typing. Python is dynamically typed, which keeps it from being totally unworkable any time you need to do something special or cross-cutting, which is absolutely a need in the web world, but it's structured enough to where you need to devote library-level amounts of thought into coming up with clean, semantic abstractions that are easily traversed, something Ruby just comes with out of the box.
  - 0xADEADBEE 8y ago
    I would wholeheartedly agree that the object model confers a large advantage to Ruby; I hadn't considered your Python point but you're absolutely right - there are demonstrably fewer ways to solve certain problems. I sometimes wonder what Python would look like if it were easier to differentiate between an attribute lookup and a method call.
- pythonaut_16 8y ago
  You might know Python but it sounds like you don't know Django very well. Django does have built in JSON support[1]. There's also Django Rest Framework[2], which while not built into the core, is well supported and hardly a burden to add. And finally, Django's "scaffolding" functionality is built around its models. You define your model as a plain Python class inheriting from Django's model class, and then the various generic[3]/"scaffolding" views work by being told what model they're for, with the ability to override and extend whatever you want to. [1]-https://docs.djangoproject.com/en/2.1/ref/request-response/#jsonresponse-objects https://docs.djangoproject.com/en/2.1/ref/request-response/#... [2]-http://www.django-rest-framework.org/ http://www.django-rest-framework.org/ [3]-https://docs.djangoproject.com/en/2.1/topics/class-based-views/generic-display/ https://docs.djangoproject.com/en/2.1/topics/class-based-vie...

by erokar 8y ago

0xADEADBEE 8y ago

I work in a lot of Django shops and my Ruby is nowhere near as good as my Python but I'll pick Rails every time if I'm working on a side project. Why? Because the development velocity when using it is unparalleled. I can have an MVP up orders of magnitude quicker than I can with Django/Flask/Twisted. You're absolutely right on the Admin interface and auth, but auth is a gem install away [1] and Django's admin won't fit my requirements more often than it helps; I can seldom justify exposing it to end users and it's a hideous undertaking to extend it meaningfully (I gather this is one of the reasons it is a bit of a laggard compared with the rest of the framework. We only got mobile support out the box in 2.0 for example [2]). Other reasons I enjoy Rails: - Scaffolds allow me to have CRUD support for any model I want with one command (combined with auth, I have Django's admin, more or less) - JSON views without a third party library (surely this is pretty standard for a web framework in 2018 in most cases?) Other reasons I don't enjoy Django so much: - I can't think of an eloquent way to phrase this but Rails values my time. With Django I'm doing menial minutiae like creating a directory for my app's templates before it'll serve a page. Why? I know 'magic' is anathema to the Python community but context switches like this shouldn't be there when I'm trying to get an app up and running at speed - I feel like it's stewardship is bordering on begrudging: Why are websockets (and JSON for that matter, but I've touched on that) not present in a 'kitchen-sink' web framework? I'm not sure why we're worrying about master/slave DB terminology [3] when there are axiomatically more pressing technical and adoption-related issues at hand. Django is a fine web framework, and perhaps the best-in-breed for Python, but it feels miles behind where it should be at this point and I'm not really sure why. [1] - https://github.com/plataformatec/devise https://github.com/plataformatec/devise [2] - https://docs.djangoproject.com/en/2.1/releases/2.0/#mobile-friendly-contrib-admin https://docs.djangoproject.com/en/2.1/releases/2.0/#mobile-f... [3] - https://github.com/django/django/pull/2692 https://github.com/django/django/pull/2692

vinceguidry 8y ago
The source of Rails ease-of-use appears to flow from Ruby's object model, which I have yet to see a more elegant one outside of the Smalltalk ecosystem. Ruby's semantics just seem to be a natural fit for the web, where visual presentation of information seems to almost demand a truly-flexible set of tools. You want a smooth progression of tooling that you can approach and slowly clarify ever-finer approaches to over time. The object model is the base of the pyramid, it's the thing you rely on when nothing else solves the problem, you know you can always invent a new kind of object hierarchy by refactoring to BasicObject, obliterating stdlib semantics with a veritable flamethrower. I've never put such a thing into production, because I know there's always less drastic ways to define, mold, shape, and extrude abstractions. With less semantically-fluid languages, you wind up relying on the same few tricks over and over and over again, because they solve problems, albeit poorly and opaquely. This flows, again, from the underlying approach to typing. Python is dynamically typed, which keeps it from being totally unworkable any time you need to do something special or cross-cutting, which is absolutely a need in the web world, but it's structured enough to where you need to devote library-level amounts of thought into coming up with clean, semantic abstractions that are easily traversed, something Ruby just comes with out of the box.
- 0xADEADBEE 8y ago
  I would wholeheartedly agree that the object model confers a large advantage to Ruby; I hadn't considered your Python point but you're absolutely right - there are demonstrably fewer ways to solve certain problems. I sometimes wonder what Python would look like if it were easier to differentiate between an attribute lookup and a method call.
pythonaut_16 8y ago
You might know Python but it sounds like you don't know Django very well. Django does have built in JSON support[1]. There's also Django Rest Framework[2], which while not built into the core, is well supported and hardly a burden to add. And finally, Django's "scaffolding" functionality is built around its models. You define your model as a plain Python class inheriting from Django's model class, and then the various generic[3]/"scaffolding" views work by being told what model they're for, with the ability to override and extend whatever you want to. [1]-https://docs.djangoproject.com/en/2.1/ref/request-response/#jsonresponse-objects https://docs.djangoproject.com/en/2.1/ref/request-response/#... [2]-http://www.django-rest-framework.org/ http://www.django-rest-framework.org/ [3]-https://docs.djangoproject.com/en/2.1/topics/class-based-views/generic-display/ https://docs.djangoproject.com/en/2.1/topics/class-based-vie...