3 ms·
I would take a serious look at Django. You can use it as scaffolding and get rid of pieces as you write you own, the first to go will be the use of the automat
by mrtron 19y ago
I would take a serious look at Django. You can use it as scaffolding and get rid of pieces as you write you own, the first to go will be the use of the automated admin site, and I find myself writing a custom pieces across the board.
However, being able to rapidly deploy a prototype has been priceless time and time again, and they have the basics that you need down and well tested.
If you don't like ORM, or find yourself writing a lot of custom queries for performance, that is fine. I would still use an ORM now and customize some queries for performance later. The reason? Speed of building your app...I think not writing the DB code saves me about 20% of my time.
I used to be always against using frameworks since they were massive, crappy, and relied on so much magic you didn't know what was going on behind the scenes. I am really glad I went with Django, it saved me from writing almost the identical feature set.
- jgrahamc 19y agoIt's interesting that you mention Django. Of all the frameworks it's the one I most liked as I was investigating for one major reason: the community around Django seemed welcoming and open to ideas. This was very much in contrast to the RoR community which seemed to have a "we know better than you" attitude. John.
- mrtron 19y agoThe community is quite good overall. It is especially good about allowing random people to contribute pieces of code that are useful. I also like how their goal is to make everything as straightforward as possible, and eliminate the 'magic' that most frameworks have. If you have any questions about it, feel free to ask.
- tocomment 19y agoDo you feel like you know what's going on behind the scenes in Django? That's my biggest concern with it. (haven't tried it yet.)
- adrianh 19y agoI think you'll find that the stuff Django does behind the scenes is quite clear, with very few exceptions. The basic parsing of HTTP requests is dead simple, and although the code for the ORM is hairy in places, what really matters is the SQL it generates, which is pretty clean. And like somebody else said, there's nothing that says you have to use the Django ORM. One of the nice things about Django is that it's just Python. You can always look at the import statements in a module to see exactly what code is being run and where it's coming from. I've never used Ruby on Rails, but I have the impression it can be opaque in this area. ("Just create a file named makeasite.rb and put the single word 'create' in it, and Rails will do the rest!") Personally, I'm vehemently against "magic" in a framework / programming environment, which is one of the reasons I love Python -- and one of the reasons we don't have a lot of magic in Django. Let me know if you have any specific questions. Adrian (Django cocreator / core developer)
- nanijoe 19y agoNo reason to knock the 'magicality' of rails. It works for some people; And since it is only code at the end of the day, you can always get to the bottom of the magic if you do a little digging. While we are on the topic, I have always wondered why the Django team insists on being an MTV (Model Template View) framework..don't you guys think just conforming to MVC would make life easier for people new to Django? (This is a serious question)
- icky 19y ago> No reason to knock the 'magicality' of rails. The problem with relying on magic is that you won't know what to do when it stops working.
- HiddenBek 19y agoThe Rails magic is well defined though, and it's all documented. It doesn't simply 'stop working'. It's really nothing more than a set of conventions that happen to make certain things really convenient.