Hacker News new | past | comments | ask | show | jobs | submit login

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.



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

[2] - https://docs.djangoproject.com/en/2.1/releases/2.0/#mobile-f...

[3] - https://github.com/django/django/pull/2692


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/#...

[2]-http://www.django-rest-framework.org/

[3]-https://docs.djangoproject.com/en/2.1/topics/class-based-vie...


I fear you've contrived to miss both underlying points.

In order to access a JSON endpoint in Django, I need to install DRF, integrate it with Django, configure it, edit my urls.py and perhaps set up a serialiser. I won't detail the procedure in your first link because I think you very well know that is simply a response object with a crude serialiser and a content header set. The inclusion of both misses the point, which is that in Rails, I would simply navigate to /model-name.json (so in fact, yes, it is absolutely a burden to go through that when you compare the two). That's it. No parsing. No route configuration. No concerning myself with edge-cases unless I'm doing something odd. Requirement satisfied, and I can sleep soundly knowing I'm not bequeathing some custom car-crash on whoever inherits my codebase. Debate aside, I wholeheartedly encourage you to try out this framework sometime - I've found going from Django to Rails to be an absolute joy to develop with.

Generic Views. Ah. Well that has its own set of problems. Why am I wading through the docs (or more accurately ccbv.co.uk because the actual docs are a verbose, time-sinking miasma; recall that in my previous comment, I am championing the development-velocity of Rails in contrast to Django) to discover which method from which class I need to override to implement the functionality I need? I can intuit a lot more now, after doing this for years, but why do I need this knowledge at all? It is the job of the framework to abstract and ameliorate bullshit. Corollary: why is it that every Django codebase I inherit has at some point converged on its natural state of 'car-crash' because of the combination of a bunch of rigid inheritance chains and my predecessors not putting in an escape hatch? At risk of being a bit of a zealot, MI is almost always an anti-pattern and I would prefer the flexibility afforded to me by composing things in the traditional fashion.

In Rails, I would build a model like this in my shell: `rails g scaffold Blog title:string content:text`. That's again, literally it. From that, I now have a Blog model with title and content, created and updated fields, controllers (or 'Views' in Django parlance for some reason) and both HTML and JSON views ('Templates', in Django-land), unit tests, assets for my asset pipeline (we don't have to run collect static btw - it seamlessly transitions into production because it was designed on the basis that people might actually be deploying their projects), my equivalent of urls.py has been updated to accommodate my new model and I have full CRUD functionality at this point. Genuinely, I implore you to try this framework. Django has come a long way since I first used it but it's nowhere near the level that modern frameworks like Phoenix [1] (you should give this a go too - the third party libs aren't quite there yet but it's a really well thought-out framework) are at, and I'm genuinely curious as to why.

[1] - https://phoenixframework.org/


We'll have to agree to disagree about Django. I think Django and Rails both offer good developer productivity/velocity, they just make different tradeoffs. Django tends to be more explicit, which might lead to a slightly higher learning curve, but after that I've found it's easier to trace through Django applications to understand what's happening.

I've seen my fair share of terrible Django and terrible Rails applications. Bad code can be written in any language and framework.

Don't get me wrong, Django definitely has its pain points, but I think it offers a very competitive alternative to Rails.

I definitely agree with you on Phoenix though! Elixir/Phoenix is my current stack of choice. I actually think they do a really great job of capturing the high points of both Rails and Django while also improving on the weak points of both as well. (For example, Phoenix offers a lot of the "magic" of Rails but it's all backed by explicit code that Phoenix generates while creating your project.)


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.


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.


>Why are websockets ... not present in a 'kitchen-sink' web framework?

They are.

Django Channels: https://www.djangoproject.com/weblog/2016/sep/09/channels-ad...


Right. Last I checked it was being brought into the fold but it hasn't been - I still have to install a third-party library to get what is rapidly becoming a normal thing to have in a web-framework. My point was more "why isn't this in my kitchen-sink framework" more than "I don't know how I would go about integrating websockets in Django"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: