I’ve been helping out some friends with setting up a new site for their endeavors. The basic requirements were

The site needs to be a ‘single page application’ (SPA) Should be light weight Should be easy to deploy to one of the many available hosted environments

MEAN stands for the set of technologies used in application development, much like the LAMP (Linux, Apache, MySql and PHP) stack before it. The technologies and frameworks involved in the MEAN stack include Mongodb, Express Js, Angular Js, and Node Js. From a comparative standpoint, I believe that MEAN is popular today, for many of the same reasons that the LAMP stack gained popularity earlier.

Despite their limitations, both development stacks received a strong push from the community, have ubiquitous ‘Hello, World!’ tutorials, are supported on a number of cheap (and sometimes free!) PAAS hosting providers, and required little to no prior experience to get off the ground, giving instant results with minimal effort. They might not be the best dev stacks of their times, but the sheer inertia from their communities has also played a major role in the two being among the most popular web development platforms in the world today.

Why use the MEAN stack

One of the primary advantages of the MEAN stack that the code is written in Javascript, through all layers of the stack. This means that the programmer’s experience with one language (Javascript), is reused for everything, including persistence and server side code (in addition to the usual client side manipulation using a UI framework, which in this case, happens to be AngularJS)

The other big advantage of having javascript at all levels in your dev stack is that objects don’t need to be marshaled and unmarshaled when moving from one layer to another, usually removing the boilerplate code responsible for such conversions. This also helps developers take advantage of Javascript’s loosely typed nature to manipulate data as and when needed. Considering that Mongodb is a document database, and ‘documents’ don’t really *need* to have a fixed schema, this lines up pretty well with Javascript’s the loosely typed nature allowing us to do some really interesting things.

One of the drawbacks that I have personally experienced, however, of the MEAN stack is that developers with prior experience primarily in relational databases tend to continue to think in terms of tables. Relating collections to tables, and documents to records isn’t wrong, conceptually, but the patterns for relational patterns don’t necessarily lend themselves favourably to NoSql databases. Relational databases tend to have long, mature histories with a standardized set of interfaces and features that a developer can reasonably expect to get if he chooses any of the competing options out there.

Sadly, in my experience, NoSql is nothing like that. Different implementations (read databses) have widely differing ideologies on the ‘Right Way’™ of doing things, and they are correct! This is mostly because each implementation seems to be built for a slightly different use case, that needs different trade-offs to make the system function efficiently (for the chosen scenario). This doesn’t mean the databases can’t be used for anything outside their original intended mainline use cases, just that the default settings for the system may not be the best for you. The minor differences in behaviors also means that again, patterns identified for one NoSql database may not be the best for a different one.

While this may change in future as the stack matures and ‘enterprise patterns’ (I hate that term, but it seems apt for this situation) emerge and become ‘common knowledge’ ingrained in a majority of the developers out there, this is not the case today.

Check out the next post on how we got started.