Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 2.0 released

docs.djangoproject.com

Post reply on HN
Print view View original

61–70 of 177 posts

Re: Django 2.0 released

#61

Post by mundanevoice »

whalesalad wrote: post #55
mundanevoice wrote: post #53

Earlier quoted context omitted.

Well. I disagree that it is not a real thing. For better debugging, you need to know more what's behind the scenes. Personally, I have seen some of my colleagues struggling to find the cause or better architect the thing because most of the decision has been hidden/taken by the framework. Not saying, it's true for all Rails dev but for some beginners, it really bites them.

Sure but there is magic everywhere. You trade convenience for the risk of not knowing the underlying mechanism in action. The inverse is long boilerplate code, setting up multiple services and factories and fooWidget stuff just to do a simple thing. It’s more clear, yes, but is it always better? Rhetorical question by the way... just food for thought. There is a balance. I happen to love the convention rails imposes…

> The inverse is long boilerplate code, setting up multiple services and factories and fooWidget stuff just to do a simple thing

Are you not talking about Java here? ;)

Clearer code makes it easier to reason and hence easier debugging. Correct me if I am wrong.

Also, it really depends on person to person on how they write the code. Django does not mean big boilerplate nor does Rails.

My main question was on performance. How do they stack up next to each other? Python3 with Django is really working well these days. You can also check out the performance improvement on Instagram because of it. https://thenewstack.io/instagram-makes-smooth-move-python-3/

Re: Django 2.0 released

#62

Post by mattgreenrocks »

jrs95 wrote: post #41
paulie_a wrote: post #28

Earlier quoted context omitted.

Also APIStar from the creator of DRF is something to keep an eye on. It has Django integrations and I believe is async.

It's not inherently async, but it supports async. Although database support for that isnt great, so I'd recommend just sticking to synchronous stuff for now unless you don't mind using raw SQL. If it were me, I'd probably use something else before I tried to squeeze that much performance out of Python at this point to though. I hope library support catches up and it becomes more convenient, but I don't think a predom…

AFAIK, C# navigated the sync-async transition well. Admittedly, this is a function of time, as it has had async/await for quite awhile.

Re: Django 2.0 released

#63

Post by whatyoucantsay »

lima wrote: post #43
whatyoucantsay wrote: post #36

Earlier quoted context omitted.

> as it's the shortest path to a win. Rails is the "shortest path to a win". Django is well made, but it just hasn't had the same level of focus on RAD or the same level of intensity of community support. Edit: My goodness there are some insecure, vindictive Django advocates here! What I wrote above is the truth and no level of tribalism can change it.

But the trade-off isn't usually worth it. The time you save initially you'll later spend fighting the framework or debugging its internals. Python's "explicit over implicit" scales a lot better, especially with large teams. (personal opionion of someone maintaining production-critical Django and Rails applications)

It was worth it in the case of Airbnb, Twitter, Teespring, Coinbase and many, many others. Once you find product market fit, you can afford to rewrite your entire backend if needed. If you don't win round one, then it doesn't matter how well your stack could have scaled.

Re: Django 2.0 released

#64

Post by JelteF »

cdancette wrote: post #42
baby wrote: post #21

Earlier quoted context omitted.

I would rather use Flask for that.

Flask for a CRUD ? I'd agree with you for a very simple API (like a simple slack/irc bot), but for a CRUD, you'll need to write a LOT of boilerplate code with Flask

There's flask-restless, which removes most of the boilerplate. There's still good reasons to choose django over flask though, but easy rest apis can be achieved with both.

Re: Django 2.0 released

#65

Post by knivets »

whalesalad wrote: post #51
fulafel wrote: post #37

Earlier quoted context omitted.

Interesting. What would you say is the biggest reason for this >10x development speed difference?

Django forces you to declare everything. Lots of manual boilerplate. Example, you must define every bit of a model in order for it to work. Rails is the opposite. ActiveRecord will ‘just work’ with the database. You can run rails on an existing db for example if it follows what are widely used conventions such as lowercase model name is the table, foreign keys are foo_id, etc... This is where people fear the “magic”…

Rails is definitely more convenient to prototype, but the magic issue is real. You never know where a variable or a function comes from by reading the source -- you'd need to run a debugger to do that (in Python you can just follow the import statements). The overall Rails architecture feels convoluted and unnecessary complicated (Railties, Engines etc). I also dislike the fact that there is no single source of truth for data in Rails. You have schema.rb, but you can't edit that directly, it is generated by running `rails db:migrate`, so one might say that migration files are a single source of truth, which is inconvenient: I need to generate a migration, then edit the migration file to add any modifications not supported by generator script and finally add accessor and validators in model file. In Django we have a model definition as a single source of truth (data model, validations). Also, once I've created (or updated) a model definition, I run `manage.py makemigrations` and all necessary migrations (which capture the current data model state + what's necessary to do to perform a database migration automatically) are created automatically. I also like the fact that in Django data integrity is enforced by default.

Though, when it comes to prototyping, I think Rails is a much more convenient option. In Rails I can launch a working CRUD app with authentication in 10 minutes, literally. In Django I have to manually create directory structure, manually specify each route mapping, create and program controllers (views), etc. Django doesn't even have a built-in authentication templates, only controllers (views), so I end up writing this boilerplate over and over again. The other thing is that the authentication requires a username and password, which feels kind of clumsy, when every other authentication relies on email and it is not very trivial to modify that (built-in admin dashboard relies on built-in authentication for example).

Re: Django 2.0 released

#66

Post by y04nn »

Does anybody know if there is better support for WebSockets? If I remember right, with Django(1) it is not easy to do it. And is it possible to use GraphQL?

Re: Django 2.0 released

#68

Post by orf »

y04nn wrote: post #66

Does anybody know if there is better support for WebSockets? If I remember right, with Django(1) it is not easy to do it. And is it possible to use GraphQL?

With Django Channels there is great support, with some quite interesting things you can do. GraphQL can be handled by a third party package, there are a few out there at the moment.

Re: Django 2.0 released

#69

Post by trowawee »

orf wrote: post #68
y04nn wrote: post #66

Does anybody know if there is better support for WebSockets? If I remember right, with Django(1) it is not easy to do it. And is it possible to use GraphQL?

With Django Channels there is great support, with some quite interesting things you can do. GraphQL can be handled by a third party package, there are a few out there at the moment.

Seconding this. Channels was actually shockingly easy to implement, maintain, and expand, even at a small startup with a fairly small and relatively inexperienced team.
Post reply on HN