
Ask HN: Could I replace Django with Node.js? - rwhitman
I&#x27;m bidding on a two client projects right now. Both in the past I would have gone straight to building with Django. I&#x27;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&#x27;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.<p>But I need a serious sanity check. These projects aren&#x27;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.<p>Would pivoting these types of obviously Django&#x2F;Rails&#x2F;PHP friendly projects to a MEAN stack be a mistake? Or am I planting a stake in the future?
======
vijayaggarwal
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.

~~~
rwhitman
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?

~~~
vijayaggarwal
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.

~~~
rwhitman
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

------
czbond
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.

~~~
rwhitman
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?

------
krrishd
I'd say the Django equivalent for Node.js is
[http://keystonejs.com](http://keystonejs.com)

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

------
nvcken
So, what is your final decision and intention?

~~~
rwhitman
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

