Software development · MEAN

MEAN.js vs other stacks?

Asad Shaikh AWS/NoSQL/Big Data Architect at Capital One

March 13th, 2015

I was wondering if folks can share their experience if they have used the MEAN stack for development and why they chose it over others.

Vishal Kumar

March 14th, 2015

I built couple of websites in the past month using MEAN.js and love it for the following reasons:

1) They selected a pretty good and widely used set of technologies like NodeJS, MongoDB database with Mongoose, Express, Angular, Jasmine, Grunt, Passport.

2) The framework code is very well laid out with functionalities segregated into their own modules.

3) It includes good support for unit tests for both the apis and front end. Some tests get generated as part of the boiler plate code when you install the codebase and you can build from there.

4) They use Yeoman generators to create boiler plate code for any new functionality that you want to add. This is the reason I preferred MEAN.js over The generators enabled me to be productive very fast. You can start with the boiler plate code that creates the basic CRUD for your feature, and you can build from there.

5) The basic authentication with sign in and signup already comes with the framework including integration with social logins. I have spent considerable time at the start of a lot of projects implementing just that.

6) It is very easy to run and deploy.

7) They have a good community on Facebook where you can share and ask questions.

So it proved very valuable for me when creating small prototypes or simple websites in a very short time. I will choose it again for creating any new prototypes that have similar use cases. There are obviously a lot of other choices which might even provide the above 7 features in some way or the other, but MEAN.js came out to be the winner when I did my research couple of months back.

Having said that, it would be naive to think that it can be the solution to every problem. When creating large complex scalable solutions that will exist for long time, each and every choice of technologies have to be well researched and chosen with care. For e.g. a non relational database like MongoDB might not be the right solution when you really need a relational database. NodeJs is great and very popular for it's non blocking code but traditional languages should be preferred for very complex and heavy CPU intense processes. AngularJS fits the bill for the most part, but you might prefer React if a few microseconds difference in rendering speed is still important to you.

In conclusion, using a framework with a set of technologies and boiler plate code works very well for rapid prototyping and generic solutions. And MEAN.js does well in that respect. But any framework like that will start to become less useful when each technology decision is mission critical for your app.

Tom Maiaroto Full Stack Consultant

March 14th, 2015

I've gone from LAMP (to flipping out Apache with Nginx) to MEAN to all sorts of stacks. It didn't really make sense to make funny acronyms anymore =)

Using Node.js for development is nice in many ways. Especially if you're familiar with, and a fan of, JavaScript. There is a wealth of tools for testing, auto updates in your browser when you change code developing, and automatic deployment. This is why I chose it (on top of being asynchronous).

I really think the MEAN stack solves many problems when it comes to process -- but you need to be disciplined. It could also turn into a nightmare. The codebase can also get quite dirty and there's some pitfalls to watch out for like "callback hell" for example.

I've moved away from Node.js and into using mostly Go now for my own projects. It has all the same tooling around testing and continuous integration...But it's very straight forward code. It's meant to be easy to follow. Simple even. There is no callback hell, though you can easily have memory leaks if you aren't paying attention. There are some profiling tools to help you with that though it's a little rough around the edges and the community isn't nearly as large as Node.js' community. I believe that will change in the near future though. The language just makes better use of the hardware and is faster for concurrent and distributed applications dealing with data.

I consult for people with regard to software architecture and strategy. I still recommend Node.js in many cases, but not all. It really depends on what you're trying to do. You can't simply look for and believe in the "best" stack because it doesn't exist to be frank. Requirements change and that should change the technology one reaches for.

Mathieson Sterling Senior Software Engineer at Apprenda

March 14th, 2015

MEAN is great, especially as you need to increase the team (who doesn't know javascript?).

The drawbacks I've seen are that it requires much more discipline for programmers to keep the code well-crafted so you can have a version 2.0 than in compiled languages (C#, Java).  Second is mobile - if you need a native type app. C# and Xamarin allow reuse between client and server, whereas with javascript that's primarily true only for the web (and some phonegap).

Kent Hamilton Lead UI / Angular Developer (AngularJS Architect) at AT&T - (eHire)

March 16th, 2015

MEAN is one of the latest and greatest so developers want to use it. Besides that, it is very fast for development and is easy to run/port the entire app on each development machine.

Cons: Hosting is not as simple a setup as LAMP or Ruby. We used AWS (Amazon Web Services). While AWS is amazingly flexible it proved difficult to pick up while developing in a new stack. It took about 1 week to figure out how to get MEAN running up on AWS for us. At least we know now.

I can't really see a business reason to go with MEAN over other stacks except that developers want to use and learn it as it beefs up their resume and makes them more valuable. So I guess in this sense it will help you find developers but they will cost more.


Brent Goldstein

March 16th, 2015

Similar to what others have voiced regarding tech strategy, MEAN is not necessarily better than other stacks, but regardless it can fit nicely into you strategy depending on your goals/constraints.

One point I'd make is that MEAN works well because the stack is well-aligned owing to being all JS, and the nature of a rich client connecting to a server via stateless API calls, in particular REST.

Being new to the JS and the entire stack before I started my project, I can say that MongoDB and a collection based DB structured worked extremely well for rapid prototyping and pipelining data from the DB, through the server, and into the client app (in this case, Angular). If you design your collection structure well from the start, there is very little transformation required through he pipeline, which means the application will extend will much less effort.

As expected, your team's technical expertise plays into the choice. Because I've been doing the server/DB development myself, Mongo was a huge advantage because my strengths are web/server systems, less so SQL databases; developing Mongo is very much like traditional software development.

For deployment I went with Heroku and MongoLab and found it very easy. Heroku's stack deployment automation is nearly transparent for Node.js, and MongoLab just works out of the box.

One caution I'd provide is that Angular has a steep learning curve, to do it right that is. It's very powerful, but you can easily build some really poorly structured code, if your not careful, that's hard to maintain. Angular is evolving fast, and in a good way, but do your homework before committing.


Alec Lebedev Team Architect: Proofpoint Social Platform for Archiving

March 16th, 2015

I would suggest separating M (MongoDB) from EAN (Express, Angular, Node) for the sake of discussion. 

Your business requirements should drive the choice of MongoDB over an alternative data store, such as a relational database, e.g. MySQL. How is your data used? Is it read or write heavy? Would you need to do a lot of data mining? Which database transactions need to have ACID properties (google for "mongodb acid")?

Other people on this thread commented extensively on the EAN part. But I would leave the choice of EAN to your developers. If they are more comfortable with programming backend in Java or C# - that's fine too. The only thing that EAN buys you over alternatives is a consistent model language (JavaScript) between the front end and back end. One thing I would add to other answers about EAN is that it makes SEO harder.

For my last webapp I used MJAJ (MySQL/Jersey/Angular/Jetty) and was pretty happy with how it turned out. At the time when I started working on the webapp tooling around EAN stack was poor and it was hard to quantify the quality of the code with testing and code coverage tools. Hence, I went with Jersey/Jetty combination. I chose Angular for the front end mainly because it encouraged backend developers to build clean REST-based services and I didn't need SEO for my enterprise-level webapp. MySQL was chosen based on the answers to the questions at the top of my post.

Hope this helps.

Stephen Williams CTO & cofounder at Change My Path

March 16th, 2015

I'm most interested in the ANNE stack, with GoLang as the alternate services implementation.  Java's also fine on the server side if you avoid gigantic, complicated stacks.  There's a lot to be said for JS everywhere, especially for fast initial page load.  Graph databases, like Neo4J that ANNE assumes, are more powerful and flexible than MongoDB (which has scalability issues and is a document store) or MySQL (where the relational model is well known but clumsy).  Neo4J isn't a semantic web RDF triplestore, but it is more or less compatible with that model while being easier / better to use.
Uses GrapheneDB to provide graph database (Neo4J) as a service, which simplifies a number of things.

While I'm not totally sold on Angular.js, it seems like a good starting point and seems to have overwhelming market share.  One interesting branch is (F/A).  I just wish they would finish and release mixed mode! (Fully WebGL enabled.)