MEAN vs. LAMP: Choosing the Right Stack for Your Software
When we’re working with clients to create the plans and roadmaps that will guide us in converting their software visions into custom-built realities, one of the first decisions we make is which technologies will best fit the clients’ particular needs.
In early years of web applications development, a technology stack called LAMP was dominant in the field. But in recent years, evolving technologies have given rise to for dominance in the development field, businesses are asking which stack to use to reduce risks as much as possible in their systems development.
At Syberry, we love thinking through these questions with our clients, and we’re always happy to advise on the right technology stacks for your projects. But for now, let’s break down some of the key decision-making points between LAMP and MEAN in an effort to illustrate the pros and cons of each and help you start to make the decision for yourself.
First Things First: What Are MEAN and LAMP?
Conveniently enough, the stack names are acronyms that stand for the technologies used in each.
LAMP breaks down like this:
- Linux: a dominant family of operating systems used for hosting web applications
- Apache: a popular, configurable web server
- MySQL: a relational database for data storage
- PHP: a general-purpose programming language designed to create dynamic, interactive webpages
And MEAN contains its own set of technologies:
- Mongo: a non-relational (NoSQL), document-oriented database
- Express: a collection of best practices for building typical web application
- Angular: a client-side application framework for building rich, single-page applications
- NodeJS: a run-time environment allowing developers to write server-side business-logic for the system in Javascript
There is no one-to-one technology mapping between the two stacks, and both have their advantages and disadvantages depending on what a developer aims to accomplish. Let’s take a look at a few of the key distinctions.
Javascript Makes MEAN an Attractive Option
One of the most important functional differences between MEAN and LAMP is the underlying programming language. MEAN is Javascript driven, while LAMP is grounded in PHP. So what does this mean, practically speaking?
The big advantage of the MEAN stack is the usage of Javascript both in the browser and on the server. On the development end, this allows the team to be truly cross-functional, which makes it much easier to balance the workload between front- and backend engineers. Additionally, the crossfunctionality makes troubleshooting easier, as a single person can access and inspect the entire application.
On the user side, the recent extensive development of Javascript as both a technology and a tools ecosystem has made it a popular choice for building rich, interactive client-side applications.
But PHP Has its Benefits
PHP is an older programming language, and many Javascript fans perceive it as outdated or missing various features that have become standard to programming languages in recent years. However, as the standards evolve, different programming languages have converged more and more in terms of the features they support. PHP is no exception here, and all of the major advancements and functionalities are available in newer versions of the language.
While the feature sets between PHP and Javascript aren’t equal, they are close enough from an engineering standpoint that you may not see a lot of difference development from one to the other — especially at scale. What PHP lacks in modernity, it makes up for in maturity, with availability of rich frameworks such as Symfony with long-term support.
An Argument for LAMP
While the Javascript functionalities of the MEAN stack are useful for highly interactive, feature-rich web applications, the PHP-driven LAMP stack often makes more sense for classic, business-oriented systems.
In these systems, while the user experience and interface are important, the focal points are the functionality and logic of the system that supports the business. In our experience, it’s much more efficient and economically sound to build the classic way, using templates to build static HTML-based user interfaces. For these, the templating tools available in all popular PHP frameworks are sufficient, and there’s no need for Angular or other client-side-oriented frameworks that are available in LAMP.
Another budgetary benefit to this approach is that a back-end engineer may be able to create a solid user interface for a classic business system, which eliminates the need to staff a team of front-end engineers.
Additionally, Javascript is usually an asynchronous language and, therefore, writing clean, efficient code is a more complex and time-consuming task. Working with Javascript, therefore, raises the bar for quality development and engineering expertise, making hiring much more difficult.
Especially if you’re using the MEAN stack, it’s important to hire developers who understand these concepts and who recognize that it will be more difficult to scale the team to speed development.
The Devil Is in the Database
Another key difference between the two stacks is the type of database they use. MySQL, used in the LAMP stack, is a classic example of a relational database built around the concept of relations (tables) and records.
Mongo, on the other hand, the database used in MEAN is document-oriented, which means that each unit of data is stored as its own document, and different documents in the same collection may have different — or even nested — attributes.
It is important to understand that there are no inherent pros or cons to either approach, and the proper choice is dependent on the nature of the data the system stores and how users will need to work with that data.
If your system requires strong schema and a lot of join operations over multiple data sets — such as you see in reporting — a relational database is a better choice. This is usually the case with an internal business system. But if your data has weak schema and is centered around key objects such as user profiles, the NoSQL solution found in the MEAN stack might be better. Additionally, Mongo’s scalability potential is higher than MySQL’s, so if you expect your application to grow in its data usage load, Mongo will be the better choice. (Though it should be noted that, if you’re working with a sufficiently large system, you may need to consider using a combination of both types of database.)
Ultimately, Scaling Isn’t about Stack
Though the stack you use may play a factor, if you take a bird’s-eye view to the issue of scalability, you’ll see that the key factor isn’t the specific set of technologies you choose (though you’ll likely run into trouble if you choose haphazardly). In fact, with tools like Docker that allow you to move specific components and technologies into isolated units, you’re no longer even restricted to a single stack. What matters for scalability is actually your approach to the architectural design of the system.
If you plan for the system load to grow rapidly, you must plan for that from the start by building in horizontal scalability — in other words, giving yourself the option of adjusting for the workload by adding more computational power in the form of commodity server nodes (as opposed to scaling vertically by buying a more powerful server). Building for horizontal scale means being very intentional about how you organize primary components like state, business logic, and presentation layers.
Conclusion
As is the case with so many strategic questions about both software and business development, there is no one right answer as to which technology stack is superior. Each company must work with its development team to make the strongest choice for the individual situation.
The most important rule of thumb we can offer is that, the smaller the application and the scale of development team, the more specific stack choice matters. The opposite end of the continuum — large-scale projects — is all about building proper architecture rather than nailing a programming language or database choice the first time out.
