Hacker News Reader

Comment by shroom | Hacker News Reader

I don't have any experience with Django. I'm hoping to learn Django next as it seem to solve a lot of backend complexity and provide a nice way to model data.

The reason I choose Node for the backend on one project was to have the same codebase and not maintain two systems (this project is in React so Node is a nice fit). But in hindsight I feel like I should have evaluated Django more. Node is difficult to maintain since it is so active with lots of dependencies to track :)

Would also like to hear someone else's experience with maintaining a Django project vs. Node.

View on HN

I'm in the process of moving a project from Django to Node, these are some of the reasons: 1) Typescript everywhere: we are developing several frontends using Typescript, mostly with Angular and some Nativescript. Too many times I terminated a Python backend line with ";", mixed "true" and "True" or tried to solve a problem with a stream of (reactive) functions; 2) Django is sta(b)le: major changes, like Django Channels for websockets support, tend to have a difficult time in replacing the status quo and being first class citizens. This has a chain effect on the ecosystem which usually rely on the stable core. You may see this as feature because of the stability or as a limitation. If you, like me, may need websockets or GraphQL subscriptions, you will probably see the limitation first. Another issue related to stagnation is some degree of features overlap: if you are doing REST with Django you are probably using the Django REST framework, a third party framework built on top of Django. If you are using the DRF you will probably notice some similarities between forms and serializers and, as a matter of fact, serializers can replace forms and it is a good idea to do so, to avoid repetition. There are other similar cases, this is just an example; 3) The Django automatic admin is a trap: at the beginning it is a dream come true. You can do those boring CRUD parts literally in seconds, right? Then you start to push business logic into it. You do the first compromises: "ok, adding this single feature to the admin may require a little bit more time than what it would have taken with a stand alone dashboard, but the admin saved me tons of time so who cares?". Then you do it again. And again. And you will even change the way you reason about models because they will impact the UI the admin will generate. Very soon you will have a nightmarish mutation which will fight every new line of code. Of course I'm not saying that a feature should be avoided or considered bad because it can be used in a wrong way. I'm saying that you must know the tool and its limits to avoid the side effects, and often the ability to better see the bad parts come with experience; 4) performance: this is a very complex topic and depends on many different factors. For starters you may not need better performance at all, maybe your application can handle your workload without missing a beat because often web applications are IO bound anyway. But you must know that Django use a blocking IO design and this has some consequences regarding the number of concurrent clients served, the process model, memory usage, etc...

Reply on news.ycombinator.com