Ask HN: Could I replace Django with Node.js? | Hacker News Reader

Ask HN: Could I replace Django with Node.js?

6 pointsrwhitman10 comments

I'm bidding on a two client projects right now. Both in the past I would have gone straight to building with Django. I'm obsessing over the idea of pivoting my go-to development stack from Django or PHP towards end-to-end Javascript, mostly because a lot of the best freelance engineers I work with are increasingly focused in this area. And I'm pretty skilled in Javascript myself. I increasingly feel the trend of web app development could go in this direction and the MVCs of yore will start to go the way of Perl or ASP.

But I need a serious sanity check. These projects aren't just little widgets, they have client-supplied requirements like user auth, specialized CMS, gated content, payments, user roles and permissions, user profiles and so on. The spec for one of them has upwards of 100 screens designed.

Would pivoting these types of obviously Django/Rails/PHP friendly projects to a MEAN stack be a mistake? Or am I planting a stake in the future?

Since there are a lot of components involved, let's consider them separately instead of discussing the bundle as a whole. This also helps as M-E-A-N are very independent by design and can be used independently. In fact, we are currently using AngularJS at frontend and PHP at backend.

MongoDB: is a NoSQL database designed for handling huge amounts of non-relational data. In comparison, MySQL excels at handling relational data but does not scale as well. If you need a lot of joins (relationships, user roles, etc.) then MySQL will be better and if you can benefit from the ability to keep arbitrary columns in your database tables without the need for running ALTER commands or other database hacks (CMS fits very well as most CMSs hack MySQL a lt to get the fleibility they need) then MongoDB will suit better.

ExpressJS: is akin to Django. While I am not experienced with ExpressJS, it seems more oriented towards single-page apps. Django has some good support for templating which comes in very handy for traditional websites. Single page apps don't fetch a lot of HTML from backend anyway, so this capability is not of much use.

AngularJS: has no direct counterpart in LAMP stack with Django. Angular is a frontend framework used for building single page apps. In fact, if you are building a single page app, you would want to use a frontend framework like Angular or Ember even if you use Python/Django/MySQL at backend. As mentioned earlier, we have recently built a single page web app with Angular at frontend and LAMP(PHP) at backend.

Node.js: is actually (to some extent) a counterpart of apache server and not python or django. nodejs is a performance oriented server with asynchronism at its core. While it is definitely desirable for high workload applications, it does take some getting used to. For example, even though you I was quite comfortable with AJAX at frontend, writing database queries in an asynchronous mode felt quite unnatural at first.

Overall, depending on the kind of application to develop and the kind of time luxury to learn new things, you may want to adopt MEAN partially if not fully. If constraints permit, spending some time with M/E/A/N should be intellectually and professionally rewarding.

Really appreciate the breakdown. Its actually surprising me how little I educated myself on some of the components.

From what I know ExpressJS is more of a microframework that can be used piecemeal. Closer to Flask or Sinatra maybe? Or am I way off here? Do you typically use an ORM for the DB or is the expectation to query MongoDB directly?

Thanks! MongoDB and NodeJS are fairly big projects and take some experience to fully appreciate. Even Angular vs Ember is not a trivial decision and its better to have some experience with both. I agree with czbond's suggestion of starting with smaller projects. It will also reduce abandonware risk.

Again, I don't know much about Express though microframework seems to be the right term to me. Hopefully, other community members will shed some light on this. Regarding MongoDB, an ORM is technically not needed as mongo is not relational. In fact, mongo treates its records as first class JSON objects and therefore is very object-oriented natively.

I appreciate your helping to knock some sense into me. I should know better than to go diving headlong into building large client projects in bleeding edge technology, heh

Generally, if you're using MongoDB with a Node app, most people use http://mongoosejs.com as an ORM/ODM.

I have no experience in Django, but heavy experience with Rails. I've moved to Node for a variety of reasons - but my experience is the following: The level of re-usable code is growing quickly in the node eco-system, but it obviously hasn't matured to the levels of Django/Rails in robustness. Many "out of the box" items that are well tested in these frameworks still require more work or crafting your own home grown solutions. I believe the node approach is where the industry is going over the next 5 years. That said, I would personally do smaller projects in node (to build your skillset and familiarity), while doing larger projects in your speciality unless you have a plethora of time for the project. Then swap out the portfolio mix as you become more skilled in node.

Thanks I really appreciate your incite. I may have other engineers with Node experience pick up the bulk of it so learning curve wouldn't be as big an issue. But I guess what you're trying to tell me is that I'm jumping the gun on Nodejs as Django/Rails replacement by a few years here..

I think my biggest fear is the size and fragmentation of the ecosystem. Every library out there seems to be a beta that could easily turn to abandonware in 6 mos. Is that a fair assessment?

I'd say the Django equivalent for Node.js is http://keystonejs.com

It's in very early stages, but it looks very promising and similar to Django.

So, what is your final decision and intention?

I did end up sticking with Django. Just seems like Node is still too bleeding edge for the client use cases I have right now

Reply on news.ycombinator.com