Move over LAMP. MEAN is the new kid on the block.
It’s what all the trendy startups are using. It’s fun. It’s hip. It’s new. MEAN is taking over the web development world. But how does the stack stack up?
What’s LAMP?
Linux, Apache, MySQL and PHP. The holy grail of web development for at least as long as I can remember. This stack represents the foundation of the web.
While its age may be showing, its maturity is strong. The LAMP stack can be altered to replace MySQL with MonogDB, and PHP with Python. The acronym defines a low level configuration for web applications.
What’s MEAN?
MongoDB, ExpressJS, AngularJS and Node.js makes up the MEAN stack. A powerful JavaScript driven stack with diverse capabilities.
Comparatively to LAMP, the database layer is replaced completely with JSON storage using MongoDB. JSON is the native data language of JavaScript. While relatively young, the framework has a growing number of supporters.
This stack is basically a JavaScript lover’s dream.
Which to Choose?
As always, the answer is: it depends.
Both stacks have advantages and disadvantages. Which one to use depends on the type of web application to be built. Providing a blanket statement of superiority would be greatly oversimplifying software development.
Isn’t PHP Dying?
This has long been cried by the anti-PHP crowd. For years we’ve been hearing that PHP is on the way out. Yet PHP maintains a stronghold on the Internet. It powers an insanely high number of websites globally.
PHP has undergone major revamping through its recent major releases. PHP 7 is just around the corner, expected to bring along language and performance improvements.
Possessing a long history and maintaining backwards provides a disadvantage of innovativeness. Especially in comparison to the light development history of Node.JS. Node.JS however doesn’t offer the same level of maturity. Over time, libraries and frameworks will be built to further improve the infrastructure of Node.JS. Regardless, PHP isn’t going to die any time soon.
JavaScript on the Front, JavaScript on the Back
One common touted advantage of using JavaScript for both the server and the client is code reuse.
While it sounds good in theory, it’s rarely seen in practice. Separation of concerns is a very good thing. Keeping server and client codebases separate can have security benefits. It’s just not a common case to have to move a function from server to client.
Using JavaScript for both the front and back end however may make it easier for some teams to easily switch developing between the two. It creates a more homogeneous workflow. This is especially important when you have one or two full stack developers working on the application as a whole.
It can be quite a challenge to switch between using PHP or Python for the server, then having to use JavaScript and HTML for the client. If you only know JavaScript and nothing else (which could be the case for a new programmer), then MEAN is the easier choice.
If a MEAN stack makes your development life easier, then you should probably choose that.
End Users Could Break Your Website
It’s difficult to predict future behavior of consumers.
Ad blocking has become more commonplace as of recent years. Privacy has become an increasing concern. While most users have JavaScript enabled, some users do not. Some users disable JavaScript to better protect their privacy. Others don’t like unknown code to be executing on their machines.
Various browser extensions allow users to selectively choose which scripts they permit to run. And which they don’t. This may effectively break your web application if it’s dependent on JavaScript.
You might not need to cater for users with JavaScript disabled. Many web applications, like Facebook, are practically useless without JavaScript enabled.
Some users may even use client readers such as Pocket to circumvent visiting your website altogether. Considering today’s options for digesting content, it wouldn’t make a whole lot of sense for a blog to be accessible only with JavaScript enabled.
Disabling JavaScript in your browser can make a lot of the web unusable. AdBlock has been known to break a few websites too. Some websites have countered the rise of AdBlock by neglecting or even banning that segment of users.
JavaScript certainly helps add a modern dimension to web apps. It might not even be feasible to cater for users with JavaScript disabled. Still, accessibility and compatibility is a factor to take into account. MEAN depends on JavaScript. If users disable JavaScript, they’ve killed your web app.
What might be uncommon today may become more common tomorrow. Utilizing lots of JavaScript on the client’s side may turn to backfire if they opt not to run it. The user’s browser is outside of your control.
JavaScript Slows Down the Browser
Speed is another concern.
If you’re developing for any non-first world country, then relying on a JavaScript heavy frontend is probably not the best choice. On older phone devices especially, performance can be slowed down to a crawl. Sometimes it can be cubersome to load even jQuery, let alone processing-heavy AngularJS for modulated views.
Wait, Isn’t Node.JS Super Fast?
Node.JS is incredibly quick. When optimized, so too is PHP.
Node.JS has an advantage of being event-driven (illustrated above). This allows many concurrent requests with less slowdown. Traditional Apache setups are multi-threaded and resource heavy. As a result, LAMP can be slow.
PHP’s speed can be dramatically enhanced through the use of Nginx, Lightspeed or optimizing Apache configuration. While Apache is multi-threaded in nature, Nginx is more similar to the event-driven nature of Node.JS.
For the most part, Apache can be replaced with Nginx in many LAMP based applications. However, an optimized setup requires additional complications and expertise. Considering how many existing scripts and virtual machines automate the setup process, this isn’t too much of a problem.
While Node.JS can be easily configured, setting up a well performing LAMP stack (or LNMP, replacing Apache with Nginx) can add a little extra time to configure.
These speed differences are likely not to become problematic until heavy load is experience. Most startups never live long enough for this to even be an issue. Scaling is a good problem to have. If you need to scale, then that means your startup is doing something right.
Both LAMP and MEAN virtual machines can be spun up really quickly for development, testing and even production. Node.JS has some advantages for future scaling. But that’s not to say that LAMP can’t scale.
Don’t Neglect the Client
What’s neglected in a lot of speed comparisons is the client side processing. Most servers can serve up pages relatively quickly – within fractions of a second.
Where users are left waiting is from loading up client-side resources like CSS, JavaScript, images and video. For speed improvements, developers should place most of their attention on the client side rather than the back end. A fraction of a second speed improvement is negligible when most websites take much longer than two seconds to load.
Especially on mobile devices, modern JavaScript intensive web applications can be slow. Web apps are cool, but sometimes you’re probably better off developing a native mobile app. To get high performance from mobile web apps, you generally need to cut back on the JavaScript libraries.
AngularJS, while bundled in the MEAN stack, is an independent JavaScript client side library that can easily integrate into web applications. Including LAMP based stacks. Adding more and more client side processing by including additional JavaScript libraries can significantly slow down an application. This slow down really has very little to do with the stack itself. Both LAMP and MEAN applications can become incredibly slow once lots of client side resources are added.
Further speed optimizations can be obtained through utilization of CDNs, lazy loading, resource minification and minimizing the total number of requests.
The Unfair “A”
There’s no direct replacement for AngularJS in the LAMP stack. MEAN cuts out the HTTP server (the Apache in LAMP) completely since Node.JS runs independently (though in a production environemnt you may very well add a HTTP server). AngularJS is also an independent framework that could be added to any LAMP stack.
In this sense, comparing LAMP to MEAN is unjust. MEAN includes a front end component, whereas LAMP refers to just the back end. LAMP refers more to low level, whereas MEAN is more high level. There’s no operating system reference in MEAN, though you’ll most likely borrow Linux from LAMP.
There’s no reason you couldn’t add a front end component to LAMP. In fact, most implementations do. At the very least jQuery is usually added, or sometimes Backbone.js. There’s nothing preventing you from using AngularJS on top of LAMP. Or replacing AngularJS in a MEAN stack. There are also many competing libraries to choose from (like React and Ember).
MEAN does have the advantage in that it’s more GUI-focused. The GUI is baked into the stack itself, instead of being left outside.
When Would I Use LAMP vs MEAN?
It probably wouldn’t make much sense to migrate an existing LAMP application to MEAN. But if I were starting a brand new UI-focused application, I’d probably opt for a MEAN (or maybe MEN, cutting out AngularJS and possibly replacing it with something else).
Whether or not I’d use MongoDB or MySQL would depend on the type of data being planned to store. I may very well set up both. Or if it were a really data heavy application that required quick searches, I may even add in ElasticSearch or Solr.
If all you need is a simple website, it’d be quite foolish to opt for MEAN. LAMP topped with a powerful CMS like WordPress or Drupal can meet the needs of many business websites. For most eCommerce businesses, there’s plenty of existing software to handle the job. MEAN should only be considered for tech-heavy businesses.
Too many times I’ve seen startups struggling with their software development because they’ve opted for new and cool over mature and stable. Just because you can do just about anything in LAMP/MEAN, doesn’t mean you should. You should use the best tool for the job. If you want to adopt a new technology, be prepared for potential debugging nightmares and a lot of reinventing the wheel.
Another thing to consider would be the team. PHP programmers are generally much more common. Subsequently, PHP programmers can be hired for lower costs than Node.JS programmers. If I were working with a team that knew PHP well, but wasn’t experienced with Node.JS, then it probably wouldn’t be worthwhile to teach the whole team a new development platform. Or vice versa. You need to stick with what you know.
If I were building a backend API, I’d probably almost always choose a LAMP based stack, opting for Python and perhaps MongoDB (and probably ditching Apache in place of Nginx). There are many REST libraries written to make your life easier.
A startup’s success is not determined by its stack
Although a lot of dogma exists in software development, there really isn’t any better or worse. Software developers tend to become emotionally attached to one platform over another as it requires an enormous amount of personal investment (in the form of time and effort) to master a platform. New developers may be fond of MEAN, whereas older developers are probably more likely to cling onto LAMP.
Deciding between LAMP and MEAN is really project specific. Depending on available skills, business constraints and application demands, one could be forgiven choosing either option.
What we need to keep in mind is that a startup’s success is not determined by its stack. What determines success is execution. Time spent between contemplating LAMP vs MEAN can usually be better spent elsewhere. Like, actually obtaining customers and figuring out what you need to build.
AngularJS removes the need to manage the DOM. This allows for pretty applications, but difficult for search engine parsing. If SEO is an important marketing channel for you, then utilizing AngularJS might not be such a great idea. Google will probably become better and add support for such web apps in the future, but right now we’re out of luck.
It Doesn’t Have to Be One Or The Other
Some applications you may have both stacks. You may have LAMP for the API, and MEAN for the GUI.
The technologies in each stack are not exclusive. You may use a relational database like MySQL or PostgreSQL, or a non-relational database like MongoDB or Cassandra.
You may choose to utilize JavaScript and Python. Or PHP. Or Go. Maybe even Erlang. Or one of hundreds of other programming languages that may suit your project better.
Your final stack may not neatly fit into an existing religious acronym. That’s perfectly okay too.
DataTask 