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?
"Mongo likes MEAN!"
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 love lamp.
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.
First off I'd say MongoDB is never the right tool for the job if you need transactions.
Second JavaScript is never the right tool for the job on the server side. Been there, done that, still not good for the server, but fine for the browser.
MySQL, including Maria, is still not the right tool for the job, not unless you like writing hacks because it still sucks after all these years. For instance it can't defer constraint checks until commit phase of a transaction.
When is it better to choose the well-tested, mature LAMP over this upstart collection of JavaScript-centric technologies?
always
Anons need not reply. Questions end with a question mark.
The 'A' in LAMP stands for Apache. Apache is a web server. Which one of the letters in MEAN is a web server? Hmmm????? Are these even comparable, at all? Do they even come close to doing the same things as each other????
The CGI model used in LAMP meant your front-end could scale indefinitely, but the backend (Database) had to deal with a connection create/teardown on each request, so databases where that was fast are what won that round (MySQL).
Now there's the App-Server model, which has some brittleness when people think they can save state locally, but they can't at scale (when you need more than one box). On the other hand, persistent and reused connections to backend resources mean faster TCP (already-warm). To scale this setup, something consistent is usually necessary (like Redis). The other challenge is auto-scale, which is automatic in PHP/CGI-land, but needs interaction with the app-server to do right in MEAN.
I've done CGI/PHP, MEAN, and now I'm off to GoLang's Gorilla + Angular 1.x (with templates, etc on CDN) + Redis + MySQL + Shared Filestore (SSH), so "GARMS" which gives me easy concurrency (go), consistency (log-ins on Redis), transactions (MySQL), large storage (SSH), and a fast-delivered partial-paint UI (Angular pages on CDN).
Science & open-source build trust from peer review. Learn systems you can trust.
Yes, if there's one thing professional programmers (and their PHBs) love, it's code that's almost certain to work.
The reason that's OK for everyone is that it's also "Almost Certain" to work in the original place also...
It's just that each placement has different values and flavors of "Almost". :-)
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I'm a big data advocate. I like the idea of engines designed for unstructured data. But the two examples in the article barely even register as difficulties of relational databases, "What if two people share the same address but not the same account? What if you want to have three lines to the address instead of two? 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.".
As for his comments on denormalizing, I'm wondering if he has ever head of a data warehouse and a star / snowflake schema both of which handle the "I want cheaper joins" problem without having to denormalize the dimension tables.
Not only because stuff like this, https://aphyr.com/posts/322-ca... , but also because MongoDB performance actually isn't that great. I do care about my data, and PostgreSQL is actually faster in some scenarios (eg. if you actually know what you're doing), so thanks, I'll pass. And Apache HTTPD? Who's still using that on new projects?
Remember folks, MongoDB has failed the Jepsen Test multiple times.
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
Just because you decide to use Node, doesn't mean there's any particular reason, why you should have to use Mongo and Angular. You might prefer Backbone and Postgres. Granted, then you wouldn't get such a nice acronym, but it's a perfectly reasonable technology stack. Oh, and you can throw in the L from LAMP if you want, as well.
Democracy Now! - your daily, uncensored, corporate-free
JavaScript in its current form will never have a place larger than simple website scripting in my production environment -- it's unmaintainable in anything beyond small doses and is something we work with because there's literally no other option, not because we want to. TypeScript makes things better, but being better than JavaScript really isn't that tough. It's still not as good as -- and doesn't provide benefits instead of -- existing common backend languages like Java and C#.
To me, node.js perfectly represents the age of programming we're in: people are doing things because they can, not because they should. Things that would have been just-for-fun geeky side projects 10 years ago are now somehow making their way into legitimate business-critical projects.
And, if either tool works use the one you know best. And, try to write code well, so you don't get stuck when the right decision now becomes the wrong decision later because things change.
From a data store side, there are reasons to use an RDBMS and one or more NoSQL solutions all together. They handle different situations better and if you have any decent level of complexity you find the boxes defined by LAMP or MEAN too confining. I generally stay away from MySQL due to the licensing issues, but MariaDB and Amazon Aurora fit the same space. I used PostgreSQL for one solution. Of course in the AWS case you might forgo MongoDB altogether for Dynamo because why deal with operating Mongo when Amazon will take care of that with Dynamo.
Some of us have to deal with corporate standards and actually neither LAMP or MEAN is actually allowed, which makes this whole thing a pointless flame war.
If it isn't a joke then what is it? A tragedy?
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.
I support an OLTP system where each customer can have
And the table has to be denormalized for speed because in an RDBMS a JOIN just won't cut the response times needed. Guess how wide is the table? 545 columns wide, typically 70-80% unused (fields at zero or null), and still, because you can't tell what column will hold what a simple SQL query can't be written to gather aggregates on pockets/services/accumulators.
Fortunately we're migrating to a new system with separate tables, but it uses a much simpler in-memory database.
Why not finish the job, and just move the database to a distributed one that runs in the browsers?
For client projects, if you've worked with the LAMP stack for a few years and are thinking about making a transition to the MEAN stack, I suggest transitioning gradually. For example, start by doing most of your front-end work with Angular. Once you're comfortable with that, you can move on to node and express, while still using a traditional SQL database. Once you're familiar with node, you can move to Mongo. If you take it one new technology at a time, you can build your skill with each new technology without worrying about falling behind on your deadlines. Alternatively, if you are working on a project in your spare time, there is no harm in going straight for the full MEAN stack.
The fool thinks the only reason for normalization is to save space.
All I know about it is that it installed with Debian on my laptop. And from time to time, when everything starts to bog down, its MongoDB that is hogging CPU cycles. So I sudo kill `pidof mongodb` and all is well. Nothing stops working or loses functions. So I can't figure out what the fuck MongoDB was doing clogging up my system.
Have gnu, will travel.
Instead of just guessing which is better based on an article and a few opinions, I would likely evaluate my current site/database throughput (and there are a *lot* of tools available to give hard numbers about data throughput, transaction counts, etc), and then I would look at re-implementing it in a silo and compare one against the other using the tools. Its silly to ask "which one is better for you and your site" when all of those sites are different. I didn't know about some of these pure JS technologies, and I might consider them, but it will be on a strictly 'test and see' basis. Until then, I will stick with what is, and decide when I see what's best for me.
I prefer PLOW, the Platform, Language, Operating system and Web server stack.
Enough, we can see through this ploy by the christian right... oh boy here they come again. Seriously, ANYONE can see that MEAN is just an anagram for AMEN!
Stop pushing your religion on everyone!!!!!
Just read this article today.
...richie - It is a good day to code.
Comment removed based on user account deletion
FUCK - FTP, Unix, C, Kerberos
“Common sense is not so common.” — Voltaire
There are claims on Glassdoor of significant layoffs and low sales which I guess isn't all that surprising.
Or just use more than 1 query, sometimes making things simpler and following the KISS principle when selecting data works far better than a join.
Has mongodb got around the limit of 16MB (yes MB) per document?
How webscale is that? OODBs from the 70's were more webscale than this.
Don't believe me? RTFM http://docs.mongodb.org/manual/reference/limits/ before you fuck up a good system with a slow and stupid db (and I'm being nice about the real vs claimed capabilities of mongo).
Why do I get the impression that these NoSQL guys know even *less* about proper programming than the PHP crowd?
The problem with NoSQL is, they threw out SQL (well done) but they throw out relations and proper archtecture along with it (WTF?). I'm all for ditching SQL as an apps means to access persistance. It's stupid and wasn't meant for that. Even the SQL DB engineers tell us that. But if you don't understand relations and proper application models, you have no business building webapps or - heavens forbid - database servers.
As for "MEAN" - call be back when you've got a project like Joomla, Wordpress, Drupal, Typo3, Neos ... errrm, scratch those last two ... please DON'T call me if you have a project like Typo3 or, heaven help, Neos ... EZ Publish, MOD X, TextPattern, Plone, or something along those lines to show. Even better, call me when you've built a clone of Wordpress, with something like TAL for templating, sans the crappy software architecture that come with the big PHP projects and have an installer that sets it up in 5 minutes (which the PHP projects actually have).
Until then I'm sticking with this bizar but working contraption called LAMP. Other then you academic mastubation projects it actually gets the job done.
Thank yooouuuu.
We suffer more in our imagination than in reality. - Seneca
"I just reply to you when I see you spamming Slashdot with your nonsense"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)
Why agree w/ my points on hosts then? Quoting you on it next:
"I'm not denying all those things" - by dave420 (699308) on Wednesday September 17, 2014 @11:39AM (#47927435) FROM -> http://yro.slashdot.org/commen...
Of course you're not: It's impossible to dispute FACT on HOSTS FILES superiority to other methods!
(Since they're fact in favor of hosts doing more than so-called competitors & doing more with less for more security, speed, reliability, + anonymity online - which is, of course, more than a mere trolling stalking harassing "ne'er-do-well" like yourself could *EVER* manage).
---
"I'm simply pointing out that it takes an AdBlocker to block your spamming"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)
Then WHY DON'T YOU DO THAT, shithead? Answer that!
(You stalk/harass me instead!)
If you're "so-called 'better solutions'" are BETTER, & I bother you? Use them... OBVIOUSLY, asshole, you don't & you're just a "ne'er-do-well" troll, OR you have "other motivations" (see next):
* DO YOU WORK FOR AN ADVERTISING FIRM, or ARE YOU A WEBMASTER/WEBCODER, or ARE YOU A MALWARE MAKER, or ARE YOU AFFILIATED WITH 1 OF MY COMPETITORS?
Answer that too!
I'll be waiting (but you'll avoid every question, or lie - which only makes you look stupider than ever vs. myself)
(You must be involved with 1 of those above, especially since you're TOO STUPID to EVER "get the best of me" & you know it, witness the above - & their "so-called 'solutions' are INFERIOR TO MINE on TONS of levels, evidencing their stupidity in & of itself via inferior designwork!)
APK
P.S.=> SEE Dave420 SQUIRM everybody, lol - evasions galore from him to ensue are almost guaranteed... apk
"I just reply to you when I see you spamming Slashdot with your nonsense"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)
Why agree w/ my points on hosts then? Quoting you on it next:
"I'm not denying all those things" - by dave420 (699308) on Wednesday September 17, 2014 @11:39AM (#47927435) FROM -> http://yro.slashdot.org/commen...
Of course you're not: It's impossible to dispute FACT on HOSTS FILES superiority to other methods!
(Since they're fact in favor of hosts doing more than so-called competitors & doing more with less for more security, speed, reliability, + anonymity online - which is, of course, more than a mere trolling stalking harassing "ne'er-do-well" like yourself could *EVER* manage).
---
"I'm simply pointing out that it takes an AdBlocker to block your spamming"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)
Then WHY DON'T YOU DO THAT, shithead? Answer that!
(You stalk/harass me instead!)
If you're "so-called 'better solutions'" are BETTER, & I bother you? Use them... OBVIOUSLY, asshole, you don't & you're just a "ne'er-do-well" troll, OR you have "other motivations" (see next):
* DO YOU WORK FOR AN ADVERTISING FIRM, or ARE YOU A WEBMASTER/WEBCODER, or ARE YOU A MALWARE MAKER, or ARE YOU AFFILIATED WITH 1 OF MY COMPETITORS?
Answer that too!
I'll be waiting (but you'll avoid every question, or lie - which only makes you look stupider than ever vs. myself)
(You must be involved with 1 of those above, especially since you're TOO STUPID to EVER "get the best of me" & you know it, witness the above - & their "so-called 'solutions' are INFERIOR TO MINE on TONS of levels, evidencing their stupidity in & of itself via inferior designwork!)
APK
P.S.=> SEE Dave420 SQUIRM everybody, lol - evasions galore from him to ensue are almost guaranteed... apk
> And the table has to be denormalized for speed because in an RDBMS a JOIN just won't cut the response times needed.
Multiple queries are even slower than a join. I guess a nested table would be the right answer here, but apparently the basic logic was designed when they were new. -.-'
Meteor ( https://www.meteor.com/ ) is a javascript framework that runs on top of Nodejs and it is GREAT. It is a full stack solution, it has a view engine (Blaze templating language, based on handlebars), a server (Nodejs) and a database (MongoDB) all bundled up and it just works out of the box, no configuration required. From the meteor website:
"Really, you'd like to use a combination of packages that have been not just tested individually, but tested together, since so much of the complexity in a large software project comes not from its individual pieces but from how they're integrated. Rather than leaving your package system to select the "best" combination of package versions, which could change every day and could be a totally new combination that nobody else has ever tried, you'd like to use a set of packages that has been comprehensively tested by professional release engineers that really know the platform.
That's what the Meteor Distribution provides. Similar to a Redhat or Ubuntu distribution, the Meteor Distribution is a set of package versions that have been tested and recommended for use together."
And that is just one of the great features that Meteor provides. Another great feature of Meteor is that your Javascript code runs both on the server and on the client _at the same time_. Whatever action you make that triggers a state change (change in the database) will run both on the client and on the server, the client has something called MiniMongo that caches the result from the server database and the changes happen without a roundtrip to the server. If the server state is not consistent with the client state Meteor takes care of synchronizing everything. So the application looks like is running locally there is no lag at all.
This drastically reduce the code necessary for example, you don't write form validation code twice, you write it once and show a popup message on the client and throw an exception on the server if something is wrong. Really everything in Meteor works great, there is a really good automatic deploy system (it even deploys to phonegap, also I believe you can deploy your mobile apps to app stores automatically), the API is really small, the meteor packages work great (check out the Velocity testing framework, it is awesome!) and so on
There is one big caveat though, you can't migrate parts of your existing application to Meteor, the only real optional part of Meteor is the View layer, you can discard Blaze and run your own solution. I have had a great time using React with Meteor for example.
Why is my website so slow now. It worked really great before, but now that I have more than 12 widgets and 5 customers it's getting really slow. I also have these really odd bugs and crashes that I don't know about until some piece of rarely executed code gets executed and some things don't work like I expect them to, especially when I pass a Customer object to a function that expects a Widget...
So MongoDB is now an alternative to Linux?