Slashdot Mirror
MEAN Vs. LAMP: Finding the Right Fit For Your Next Project
snydeq writes: LAMP diehards take note: The flexible simplicity of MongoDB, ExpressJS, AngularJS, and Node.js is no joke and could very well be a worthwhile stack for your next programming project, writes InfoWorld's Peter Wayner. "It was only a few years ago that MongoDB, Express.js, AngularJS, and Node.js were raising eyebrows on their own. Now they've grown up and ganged up, and together they're doing serious work, poaching no small number of developers from the vast LAMP camp. But how exactly does this newfangled MEAN thing stack up against LAMP? When is it better to choose the well-tested, mature LAMP over this upstart collection of JavaScript-centric technologies?"
>This isn't a problem if every single entry fits into exactly the same format, but how often is the world that generous?
> What if two people share the same address but not the same account?
You dont make it a unique field?
> What if you want to have three lines to the address instead of two?
You have an empty field?
> Who hasn’t tried to fix a relational database by shoehorning too much data into a single column? Or else you end up adding yet another column, and the table grows unbounded.
Yeah, I cant read this crap considering the very next section is 'Disk space is cheap'. If it's cheap, who cares about 1 extra field in the database.
Remember guys MongoDB is webscale
Your hair look like poop, Bob! - Wanker.
Which is a better tool for outdoor work, a lawn mower or a snowblower?
Never heard of "MEAN" before now, but that doesn't align with the term "LAMP" which describes the entire server/platform. "LAMP" includes the operating system (Linux) and web server (Apache) in the name https://en.wikipedia.org/wiki/...
While MEAN does not https://en.wikipedia.org/wiki/...
So would it be "LAMEAN" perhaps? :)
I can't comment on the other technologies, but Angular has transformed how I build the interactive parts of web pages.
When you first approach Angular it seems like an over-engineered, incomprehensible edifice, and the tutorial throws you straight into writing your whole website as a single-page application. But once your realise that you can use a small lump of it on a single page to bind some UI elements to javascript state objects, you find yourself using it all the time even for small things. For me at least, it's as much a revelation as jquery was.
Among the great revelations of relational databases was the JOIN command. With JOIN, we could save disk space by removing repeated fields like city, state, and ZIP code. By storing this frequently accessed and repeated data in separate tables that can be included in future results through a JOIN, we keep our database tidy and our disks slim. But JOINs can be tricky for some and hard on RAM, and though it's still a good idea to isolate and access data in separate tables through JOINs, there's not as much need to save disk space now that disk drives are measured in multiple terabytes. The space is so cheap that some database designers end up denormalizing their data because the JOINs are too slow.
This is just so wrong. If you store, let's say, city/state/zip redundantly, then you run the risk of having the copies, that should be kept synchronized, diverge. This is especially true in the absence of all-or-none transactions. And not to mention the fact that having to update the "same" datum in multiple places is going to affect performance.
Remember folks, MongoDB has failed the Jepsen Test multiple times.
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
There is exactly a zero percentage chance that I will ever use MongoDB in another project. On the surface it was great. I evangelized my friends about it and the whole NoSQL thing. But as time went by I realized that it wasn't made for people to use. Almost nothing was intuitive. For each new feature that I wanted I had to look up a tutorial and generally found a list of gotchas. If you design your project around MongoDB then it will work. But if you try to wrap MongoDB around your project then you are completely screwed.
Basically MongoDB halved the initial quarter of data storage design and programming. But as the project progressed the time spent screwing with Mongo went up exponentially until the project was shoved out the door and primary feature in version 2 was the complete removal of MongoDB.
I could make a mile long list of places the project stumbled. But a few key ones would be that there are no good data management tools for accessing a MongoDB. The second was that huge schema screwups were way too easy. It was very hard for programmers to get a mile high overview of how data being stored was being structured. That is a data layout was easy but putting the results into your head was really hard.
I am finding other NoSQL approaches are far superior. Things such as use of JSON, memcaches, MariaDB (or the excellent PostgreSQL) working together allows the project to dictate how things function instead of Mongo very quickly shaping the project architecture because of its marked strengths and weaknesses.
Redis is the environment presently being explored for version 4 and so far it is looking very interesting. But I am not joking when I say that at this point I would use access on windows as my backend datastore before I would use MongoDB.