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

This seems like exactly the right way to use a framework -

* start by using it as it is intended. Save lots of time by being up and running quickly.

* find a flaw.

* realize that the workaround is more work than rewriting a piece of the framework.

* stop using that part of the framework, but continue to use the rest of the code that you still haven't had to write.

Exactly right. This is not an argument to not use Django.

I think a lot of us have come to the same conclusion as this author: the abstractions frameworks provide are often too high level. Very quickly the needs of your project cannot be served by their generalizations. Especially in a language like Python, it's often easier just to roll your own systems.

However, starting off with a framework is a great way to get off the ground quickly. If you were to write everything from scratch from the beginning, you might burn out before you even produce anything usable.

Personally, I think CherryPy is the way to go. You're probably not going to need to rewrite HTTP [1], so that's an abstraction layer with which I'm comfortable. Everything else will need to be easily customizable for your project.

[1] Unless the threaded model doesn't work for you, like it doesn't for our chat backend.

"Exactly right. This is not an argument to not use Django."

No, but it might be an argument to consider frameworks that make it easier to replace parts as they become more trouble than they are worth.

From what I read, it didn't sound like he had much trouble. And, honestly, the various "swappable components" frameworks are basically in the same boat as far as I know: the ability to mix and match decreases dramatically once you've written application code, because their emphasis is on the up-front choices, not on swapping things later on.

It certainly wasn't easy. Although the vast majority of the difficulty can be attributed to porting application code, some difficulty can be attributed to Django. I would have preferred a framework which makes it easier to swap out components, but it is unclear how much it would have really mattered except for in terms of psychology.

Well, this is something I've been quietly agitating about for a while, because I have a feeling that your case is one where "swappability" doesn't help much -- once you've written your application code around a particular component, switching to another component is going to involve rewriting. How much rewriting may vary, but AFAIK there's nothing that can automagically port code, say, between popular Python ORMs.

Have you tried Werkzeug (http://werkzeug.pocoo.org/)? It's a very interesting piece of technology. Like CheeryPy plus a Rails-like dispatcher.

Agreed. I eventually moved from django to pylons going exactly through this process- except that instead of rewriting pieces I was able to just plug them in with pylons. I believe the reddit guys had a similar experience.

Applications are open for YC Summer 2018

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