Converging on Full Stack Nirvana – Part 1 – Graduating from the MEAN Stack

Last year, I had the opportunity to start a product architecture from a blank sheet.  For a change, there were legacy products to consider.  I needed to stand back, access the current available toolsets and dive in.

The target app was an MVP for a startup and required iPhone, Android and web clients, Bluetooth connectivity to custom wearables and real time social features.

The first platform I selected to hammer out the initial iterations with was the MEAN stack, from (MEAN = Mongo, Express Angular and Node).  This was a great starting point as I honed my JavaScript skills.  I also used, Ionic (an Angular based hybrid mobile app development tool) to produce the mobile apps.

The Good


Angular does a great job separating concerns and I was able to re-use many client side services in both the mobile apps and web site versions. Device specific styling was isolated in specific HTML files.  It was great being able to invent your own HTML directives.  For example, a signal strength chart could be placed on your page with an element like <ble-signal-strength device= “{{device}}”></ble-signal-strength>


Mongo makes storage a snap.  Although, you can get yourself into scalability trouble by using it wrong and, as your app increases in complexity, you will miss relational features, it’s a great choice for an MVP.

Ionic for Android and iPhone

Hybrid apps actually work very well. (Yes, even with a custom Bluetooth device).  It is, of course, a trade off, and if you have a big development budget or perhaps seasoned native app developers on staff, native is still often the most appropriate choice.   But, for an MVP that requires both Android and iOS, Hybrid is usually a clear winner.

Development Velocity

After you climb the steep learning curve, development velocity is good

Great Online Resources

The components of MEAN are popular and there were many excellent third party libraries and solutions to problems on blogs, stack overflow and the product forums.

It was free

I spent more on books than on software.  (The only software I actually purchased, WebStorm, an excellent IDE from Jet Brains.)


It’s BIG and has a Steep Learning Curve

From top to bottom, there’s just a lot of stuff.  Here’s a partial inventory of technologies in play in the app I developed: CSS, HTML, HTML 5 graphics (e.g. SVG and/or Canvas), graphics libraries (e.g. JSChart on the client and GraphicsMagick for image processing on the server),  JavaScript itself (it’s a super powerful language that takes time and dedication to master), Angular 1.X and its many services and 3rd party components (a beast to be sure), Ionic (there CLI and styling libraries), build tools (e.g. grunt or gulp), testing tools (e.g. Jasmin, etc.), Node, Express, (features like middleware), Mongoose and Mongo (a whole new database concept and query language), deployment tools and hosting services, certs for HTTPS, figuring out Apple’s ridiculous app signing process, Android app store, git, Linux, OSX and/or Windows and I can go on and on.  The point is, it’s BIG.

  • Mitigations: Learn what you need when you need. Call a friend.

Lots of Bad Examples to be Found

It’s great that the JavaScript stacks are rapidly evolving.  This does present a bit of problem for newbies.  Most of the answers and approaches you find online and in books illustrate how people did it in the past, and in many cases best practices and new releases make the examples you find less than ideal.  For example, you find lots of examples leading you into $scope soup and solutions to problems that are no longer relevant.

  • Mitigation: Be aware that things are changing quickly, note article dates, seek out (recent) articles on best practices. Trust nothing, think it through.

Lack of Integration between Web and Mobile Out of the Box. has great out-of-the box capabilities for a web site and Ionic has great mobile app capabilities.  They both use a very similar set of technologies. However, there was a quite a bit of engineering (read ‘head-banging’) to get them working smoothly together and sharing a common code base.

  • Mitigation: I’ll be discussing some solutions in future blog posts. Some key components are Meteor 1.3 and ES6 imports.

The Curse of Silent Failures (works great, until it doesn’t)

Often, one little mistake, would cause something not to work with no errors on the consoles, no hints, no clues. It’s like the universe was saying, ‘Ha, ha. You did something wrong and I’m not going to tell you what it is’. (Maybe that’s why they call it the MEAN stack.) Many libraries have this problem, with ui-router being a particularly bad culprit.

  • Mitigation: Make small changes.  Making big changes to your code base with numerous assumptions about the environment is a recipe for time waste.   Make a small change, test it, fix it, commit it.

Lack of Compile time and IDE Error Checking

JavaScript, being a dynamically typed language, takes a “sure, I’ll run that” attitude towards your code.  It may not be remotely what you want, but “sure, I’ll run it…”

  • Mitigation: Typescript. Use it now. And you will never go back.  Typescript is a superset of JavaScript that formalizes type definitions so your IDE and compiler can catch many mistakes.

Disconnection of Server Models and Too Much Typing for CRUD

With MEAN, you can define your document schemas using Mongoose. This is useful, but your client code is completely disconnected from it and doesn’t benefit from your work to define the model.  Furthermore, there’s a lot of (boring) typing to get the data to the client.  1) Define your model, 2) Define your RESTful API and security model, 3) Implement a client side services to consume the RESTful API, 4) Write unit tests for everything, 5) now, finally, you can integrate with your HTML views.

  • Mitigation: Meteor. Perhaps, a future post will elaborate in this, but in short:
    • turn off Meteor’s reactive mode (because it’s computationally expensive and needless in most use cases),
    • use it as automatic CRUD (DDP eliminates need for much typing)
    • write your JavaScript libraries to execute on either the client or server
    • easily customize CRUD with an RPC mechanism (Meteor.Methods) when the automatic CRUD isn’t a fit.

Lack of Momentum and Libraries Behind MEAN

  • Compared to other communities, (e.g. Meteor or React), there just isn’t that much happening in the MEAN world. While Meteor has a vast set of libraries (with a poor signal to noise ratio, though), there is very few drop in libraries for MEAN.


In conclusion, the MEAN stack is a great starting point and worth the time to learn (at least at a high level) as many of its core components will live on for some time yet. However, the JavaScript related technologies are rapidly evolving with frequent major releases and new innovations come out at break neck speed. This rapid evolution is leaving what has been previously defined as the MEAN stack in the dust.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s