For further actions, you may consider blocking this person and/or reporting abuse
Read next
Build & Deploy a Real-Time Sports Voting App with Express.js, Next.js, Node.js, & SSE on Vercel & Google Cloud App Engine
Peter Kelvin Torver -
Django bookmark management software
Piotr -
RabbitMQ with Web MQTT Plugin vs. Node.js : Performance and Memory Usage Comparison
Aris Kurniawan -
Stop Writing Boilerplate! Build Node.js APIs in Seconds [2024 Guide]
Ivan Ivanov -
Top comments (4)
Express. Number 1 reason: JavaScript.
Express > Node > JS
Front end > Feature Framework > JS
Data (JSON) > Database (whether document or SQL) > JS
Using JS for everything from turtle soup to deez nuts was the very first time I heard Full Stack Developer. I'm not bagging on Django in the slightest. It's as big as a honking house, and has all the features. And it hums nicely when you get it wired up the way you want.
But Express and Full Stack JS. . . I mean there's a lot of value in language consistency between deriving your data and displaying it to the user.
Reason #2: JavaScript.
Chrome recently added a node inspector. VSCode editor (near IDE these days) also has an inspector for node. You can have a Node console, while using Nodemon (a server code monitor for restarting), with a server output console, all from within VSCode, without having to set up a dev environment for the node executable or webserving the project.
IOW: The dev environment is simple.
Lastly: I'll bet you thought I was gonna say JavaScript. But it's about the ecosystem.
A couple years ago, JS Fatigue was a thing. There were seemingly DAILY releases of frameworks, tools, etc, and each one was an increment on the last. This has settled down quite a bit. There are still quite a few different and varied tools, but this is mainly from the mindset "Do one thing, do it well". All of these tools that I have used have at least a 7/10 community and support path.
Generally speaking, the brand name JS tools are well supported and have a deep community.
On the other hand, Django . . . would you be using Python 3.6 or 2.7? (The question is sarcastic.)
Well, as with all things, it depends.
What do you value in a framework?
What is your ultimate purpose?
Apart from the language, the biggest difference between the two frameworks is that Django tells you how to do everything(opinionated), whereas express gives you more flexibility(unopinionated). For example, you need to use Django's ORM for interacting with the database, but you can choose any tool you like in the express case.
If you just want to learn a framework, learn them both and later choose which to master, based on your gut feeling and how much you enjoyed the process.
If you want to find a job, check the job boards and which one is more in demand at the moment, in you area.
If you need the 'easier' path, then express. If you need an all-inclusive experience, then django.
Good luck and enjoy.
I think the question is very general, so it's hard to answer. For example, if your main concern is finding a job, then the intrinsic merits of the technology don't matter. What matters is how many companies are hiring for each of these technologies. I don't know the answer, but it should be possible to do some searches of well known job sites to get an idea.
From a technology standpoint, I think the single biggest difference is the concurrency model:
In Node, I believe all requests for a given process are handled by a single thread, and the concurrency for all users being served by that process is done cooperatively within a single thread. That means you have to be very careful about crafting your code so that no one task is taking up too much CPU, or else the responsiveness will drop for all of your users.
On the other hand, if you have a lot of users who are doing small bits of I/O bound work on your site, then adding more concurrent users should be easier in a node application, at least in theory.
In Django, I believe a certain number of threads are allocated to a python process. Since threads are pre-emptive, you don't need to worry about the problem of one part of your application hogging the CPU as much.
However, it also means that, at least in theory, the concurrency model is more resource-intensive in a technology like django. My understanding is that in Linux one can spawn thousands of threads without it being a huge problem. That means that whether this issue matters to you in practice really depends on the kind of scalability you need.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.