That's what gives Express its appeal. Rather than a walled in environment, I can pick and choose the pieces that I need. Much more flexible if you want to move over to a different library within Express.

I understand that's why people think Express is great, but in practice you end up rebuilding a lot of the same functionality. It can work okay in a microservices architecture, but in the end you have to reinvent a lot of the wheel.

There's also a common misconception that Django is a "walled in" environment. It provides sensible default utilities for everything, but you actually don't need to use them at all. For example, you can bring anything from your own template engine to your own ORM if you want to.

Not sure what wheels I'm reinventing, I just choose to include the libraries that are correct for the application.

If I don't use half the stuff Django is offering me, only to bring in my own. Aren't we back to the same place?

The difference is that the Django ecosystem really focuses on developer productivity and has strong best practices. Look at 5 different Express apps and you'll find 5 different ways of structuring models, controllers, and routes.

Plus the fact that Django has some suggested defaults allows you to be very productive with them. For example, I really haven't found any equivalent to DRF for Express.

I want to make it clear I'm not some Node hater. Probably half my projects are still in Node, but I do know I'm much high productivity in Django.

So really all we're seeking here is a standard for application layout. I really really dislike being forced into some heavy handed framework, not that Django is that, but it's on the topic of discussion.

Ember? Sails?

Ember is not a server-side framework.

Sails is leagues behind Django in terms of everything from tooling to quality.

I thought Ember had isomorphism now...

Server-side rendering ("isomorphism") does not make a framework into a server-side framework. Ember is not designed to be a backend for your application.

cough https://news.ycombinator.com/item?id=12633191

Sorry, I'm not sure how that's relevant to my comment? I personally love the diversity of the JS ecosystem, but that doesn't have any bearing on the fact that Ember is simply not a backend framework.

Meteor

Meteor is not at all equivalent to Django. I've used both, and they're leagues apart. Meteor still can't even use SQL.

If you choose Meteor, it's going to dictate your entire stack from database to frontend framework. That's fine if what you really want is an all-in-one solution but it's definitely not a Django equivalent.