Live data from Hacker News

Why Django Sucks

speakerdeck.com

131–140 of 206 posts

Re: Why Django Sucks

#131
post #52

Earlier quoted context omitted.

You sound institutionalized. Django is indeed awesome for having a ton of features immediately. Of course, once you need to start changing those features you realize you have to dislocate your shoulder to do so. Django is badass for what it is intended to do: be a kitchen sink. Flask is badass for what it is intended to do: be a platform for composable applications. If you ever need to reason about the internals of y…

"You sound institutionalized." I'm not sure what that even means, but I suspect the thing that disproves it is "The last website I built was in Yesod.". And while it may be in some sense targeted to fill the Django space, at the present time (and certainly at the time I worked in it) it was more like Flask and a couple of things lightly tacked on. No, my main point is that Django is what Django is, and while that may…

  "You sound institutionalized."
  I'm not sure what that even means
mattdeboard is referring to Red's dialogue from The Shawshank Redemption: http://www.youtube.com/watch?v=TsiFanovOSI

Re: Why Django Sucks

#132
The biggest stumbling block for me, and I imagine a lot of other users, is simply getting it installed and running. On Ubuntu I was able to do this within ten minutes, but if I choose to develop on Windows it's next to impossible to get a Django project with a PostgreSQL db running without any issues.

I'm quite fond of Python and I like what I have used of Django, but I'd be willing to wager that a lot of other people from PHP land have wanted to use Django and have been put off by how hard it is to set up.

Obviously, I could be doing something wrong, so if it's obvious that I'm doing something wrong please say so.

Re: Why Django Sucks

#133
post #9

Problem: Django has features. These features, horrors , reuse each other's capabilities. Solution: Use something that has no features. I'm not sure myself how sarcastic I'm being, to be honest. There's some truth in there too (or I wouldn't have posted this). But of course your microframework doesn't have any dependency issues. Rip all those things out of Django and it wouldn't have any dependencies either. Put them…

Rails and Java EE demonstrate that dependencies on specific implementations are not required to build a framework that offers features. In Rails, you can rip out ActiveRecord and replace it by an entirely different ORM like DataMapper. There is no real default authentication support, but you can easily plug it in. The list goes on and on: they've done a decent job (I would say 'great', but there are still some improv…

Django is a single python package but is really fairly modular. You can readily use anything in lieu of it's ORM (e.g SQLAlchemy), anything for template rendering (e.g jinja), you're absolutely not forced to use the provided auth component (it's not even enabled by default) nor the admin (but the admin of course only works with django models).

Don't take my word for it, all of this is actually written in multiple places in the docs, tutorials and/or Django site, I can't remember. Here's an excerpt that exemplifies Django's philosophy (from [0]):

> Each view is responsible for doing one of two things: Returning an HttpResponse object containing the content for the requested page, or raising an exception such as Http404. The rest is up to you.

> Your view can read records from a database, or not. It can use a template system such as Django's -- or a third-party Python template system -- or not. It can generate a PDF file, output XML, create a ZIP file on the fly, anything you want, using whatever Python libraries you want.

> All Django wants is that HttpResponse. Or an exception.

> Because it's convenient, let's use Django's own database API, which we covered in Tutorial 1.

Indeed, Django components are incredibly convenient to use, and readily included, and officially supported. But they're completely optional.

[0] https://docs.djangoproject.com/en/1.4/intro/tutorial03/#writ...)

Re: Why Django Sucks

#134
post #21

Earlier quoted context omitted.

Spoelski has a great rant about frameworks and the concept of abstractions ad nauseam: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 . In a way, frameworks are inherently stupid, but who's to decide where between assembly language and x layer abstraction people should work in? I think people who criticize Django have yet to make up their minds about what a framework is all about, and what, if anything,…

Actually yeah. Great point. I think Django rules for publishing, or building sites where your general technical competition might be Wordpress. It's frankly an awkward fit for loads of web applications. It seems to me (note: Django guy, not RoR guy) that the Rails stuff has adapted much better to applications that fall well outside of the blog/publishing sphere... but maybe that's a false impression.

I disagree, you can write anything in Django.

I'm currently writing a control panel for libvirt and it's a pleasure to use Django, so many features mean I can concentrate on the problem at hand and not on reinventing the wheel.

Re: Why Django Sucks

#135
post #103

Earlier quoted context omitted.

In Python, you wouldn't reroll your own ORM, routing and templating - you'd use SQLAlchemy, Werkzeug, Jinja2/Mako/whatever.

Ad I've still never seen a homegrown solution that ties together libraries which was better off after a few years. Your experiences may differ.

Most codebases I've seen that are badly maintained or managed over the years are horrible messes - whether Django, Rails or anything else. The last codebase I worked on - written in Django - was appallingly bad. That's no fault in any way of Django, but no framework is going to save you from poor coders, last-minute rushed requirements, chronic technical debt, or lack of investment in refactoring.

Re: Why Django Sucks

#137
post #133

Earlier quoted context omitted.

Rails and Java EE demonstrate that dependencies on specific implementations are not required to build a framework that offers features. In Rails, you can rip out ActiveRecord and replace it by an entirely different ORM like DataMapper. There is no real default authentication support, but you can easily plug it in. The list goes on and on: they've done a decent job (I would say 'great', but there are still some improv…

Django is a single python package but is really fairly modular. You can readily use anything in lieu of it's ORM (e.g SQLAlchemy), anything for template rendering (e.g jinja), you're absolutely not forced to use the provided auth component (it's not even enabled by default) nor the admin (but the admin of course only works with django models). Don't take my word for it, all of this is actually written in multiple pla…

"but the admin of course only work with django models"

I think you missed the point. In Rails, ActiveSupport does a whole lot of automatic magic with ActiveRecord. But it is not limited to ActiveRecord, as most of that functionality is factored out into ActiveModel - implement those interfaces and your link helpers and whatnot will happily support nonAR models. I use this quite often to represent things that doesn't reside in a database.

Well, most of the time. There are a few things out there that are not migrated to ActiveModel yet that really should be (the model side of datehelpers in forms comes to mind).

Re: Why Django Sucks

#138
post #128

Earlier quoted context omitted.

I'm yet to see a Django based website that outgrows any old rdbms for auth . Care to back up your claim that it's bad? Same for admin . You do realize that Django's admin is just a search result of objects defined in its ORM, and that objects defined in its ORM are very obviously stored in an rdb - right? What would you like admin to use for managing data stored in an rdb? There's barely anything other than the model…

It looks like you're new here. Make sure you understand the context before you go trolling else you might be mistaken for a chatterbot with all the non sequiturs.

I'm not new to Django or programming in general, though. Making generic statements like your original post and catering to hip trends is one thing, backing up your bs is another. Obviously you can't answer the direct and very simple questions I stated, so you resort to pointing out your paltry 3.79 karma average in an attempt to sage me. Nice.

Re: Why Django Sucks

#139
post #128

Earlier quoted context omitted.

I'm yet to see a Django based website that outgrows any old rdbms for auth . Care to back up your claim that it's bad? Same for admin . You do realize that Django's admin is just a search result of objects defined in its ORM, and that objects defined in its ORM are very obviously stored in an rdb - right? What would you like admin to use for managing data stored in an rdb? There's barely anything other than the model…

It looks like you're new here. Make sure you understand the context before you go trolling else you might be mistaken for a chatterbot with all the non sequiturs.

[deleted]

Re: Why Django Sucks

#140
post #129

I'm not quite sure I understand slide 48 which talks about constraints. Does a text editor have more or less constraints than an IDE? I would argue that it has less constraints, however I assume he is arguing that text editors are better which implies that they have more constraints. The same goes for Pen&Paper vs digital notes. Surely being able to write in any direction at any size with any style as well as draw me…

I was at the talk, and the way he explained it was that the first column allows for less customization. Kenneth said that if he would use Linux he would spend all day tweaking it, and not getting work done. The same goes for pen & paper notes over digital notes, once they're written down, you're not tweaking them anymore. A simple text editor does not have all the fancy functions to play with that an IDE does. So he…

> he would use Linux he would spend all day tweaking it

That is a fatigued point. I use Linux and store the few tweak I have to do manually in a install_note file. Next time I want a fresh install I just follow the doc and in 10 mn I have a fully adapted environment. Then I do not tweak anything more at this level. All subsequent tweaks are vimrc and bashrc modifications that are pushed to bitbucket, and I guess I would do those on MacOS anyway.

Being able to fiddle the config do not mean you have to, and the days are gone when Linux was not that stable.

The thing I actually spend a lot of time tweaking for the few days I have a new device or OS version is my phone (Android). On these little big guys I get back the tweaking excitment I got with my first PCs (Oh! Look, you can change the prompt! Look, you can move the start bar to the top!)

I think what is actually interesting with mobile phone is that they are not stabilized, a lot has to be invented for them, and each new OS version or even some apps really add new possibilities.

But for Linux, Windows or Mac, no new exciting thing is in sight, and spending too much time tweaking the config just mean you have time to spare.

Post reply on HN