I’m not a NoSQL expert, but everyone I know who is considers Mongo a joke in production. And I would never use Angular in production apps (“painfully slow” is reason enough but I have ideological differences as well). That makes saying “no” to this stack easy.

Does "everyone you know" have recent experience running Mongo in production? Because I have, and from my perspective calling it "a joke" is borderline trolling.

I'm not trying to be hostile, but you've got to understand that Mongo is most certainly not a joke, has lots of support, and is a very appealing option in a number of cases.

> very appealing option in a number of cases.

What cases do you have in mind?

Mongo sucks. I've used it in production for millions of people. I would never recommend it ever again. It's convenient, about the same way a hooker is.

Maybe your app wasn't suited for what it's good as. A File system would suck as a relational database... that doesn't mean it sucks in general. I suspect you had the same problem with Mongo.

It's confusing to see responses like this.

We continually hear about how great MongoDB supposedly is from its advocates, with them claiming it's suitable as a general-purpose database.

Yet when somebody who has apparently used it in a production setting speaks out against it and its numerous flaws, the problem isn't with MongoDB. No way! It's a "problem" with the app "not being suited for" what MongoDB is "good at".

I don't thing any database/technology is well suited for everything. And never said as such.

But as a counter point... We don't know this was a 'general purpose' problem... so your point isn't even valid even if you were responding to something I said... Unfortunate.

Rapid iteration comes to mind (as a result of its lack of schemas). It's also great if your objects are JSON documents, and as such it's particularly suited for uses such as a backend to Backbone.

Those are two areas in particular where I would first look to Mongo.

Don't lie to yourself, it has schemas. They are just implicit. Want to write JavaScript migration scripts for changing the Schema? I sure don't. But that is not even the begining to describe how broken mongodb design is. getLastError as a way to do write confirmation?

You can call them whatever you want, but I don't need to write any migration scripts when I change the schema. Writing a migration script MIGHT be a good idea, depending on my setup, but I definitely don't NEED to.

I don't really know what you mean about the design being "broken", unless you mean that it's "different", in which case I would agree.

As for write confirmation, you have flexibility in that regard. You don't need to be checking getLastError for write confirmation[0], though if you wanted to use a broken pattern, you could.

[0] http://docs.mongodb.org/manual/core/write-concern/

The first reason sounds a lot like 'hacking things out.' That is wonderful in the early stages of development, but 'production' doesn't just getting the app live quickly. With an ORM, let's take Rails as an example, migrations make schema changes extremely fast.

As for JSON, Postgres has first class support for JSON data field types.

I haven't seen any benchmarks that make it seem like Angular is "painfully slow." AFAIK, its on par or faster than ember.js and knockout.js. What would you use instead for MV* in the browser?

Our relatively simple Angular app was regularly consuming 100% CPU for literal minutes and ate up 600MB of RAM until we dramatically reduced not-actually-that-crazy number of API calls we made on load (from less than 100, mostly prefetching data – to less than 15, pr-fetching sacrificed). It is mostly related to Angular’s “dirty checking” and ajax management. I have met others with the same problem. (Their solution? Use Backbone!)

I think its a lot to ask but would you consider making a sample application that replicates this same behaviour?

I haven't actually seen any decent benchmarks between those systems as a whole. Most comparisons seem to shy away from that (between some candidates it probably doesn't make sense to benchmark anyways). But if you've seen anything interesting on that front, I'd be thankful if you could post it. And, you're right, so far Angular hasn't let me down regarding speed.

Mongo is incredibly productive. In the "lean startup" sense it is an easy database to start with.

Exactly the discussion i had today with a colleague. Mongoose makes it incredibly easy to get started and iterate rapidly.

I have yet to experience MongoDB in a large scale production environment and the common pitfalls often cited, but let's face it - If you're Start-Up has scalability issues, it's prob a nice problem to have.

Based on my personal observations, i suspect the lack of adoption is because founders are thinking about scale prematurely - which is rather Anti Lean Startup and Anti-Pg anyway.

Sounds like the information you've been given is in the wrong context.

I've had MongoDb running on my laptop in less than 5 mins and used it locally for multiple projects without issues.

The kind of problems you mention probably occur on very heavy use but i've never witnessed it myself.

For small scale stuff and getting up and running quickly, i've not used anything as convenient as Mongo

Note: I'm on Windows.

Also consider MongoHQ - They have a really good Start-Up package.

please ignore. I always manage to click the wrong button to reply on the mobile app

Is MongoDB the right DB for every size of startup? What about the people who just want to try different projects on 1 (one!) single server?

What I've read about MongoDB, it wants to use all the memory it gets. So it's only usable if it is running on its own server. (And in the beginning of MongoDB it had to be 2 servers if you didn't want to lose data.)

Is this a false information again? Am I falling for anti MongoDB FUD again?

quick someone tell doubleclick that angularjs is painfully slow

I love Angular and have never found it to slow working with even quite complex directives and tons of filters. API responses take longer than Angular does to load.

What about asking these people: http://www.mongodb.org/about/production-deployments/ if it's a joke in production?

I saw a couple engineers from Craigslist present at a Mongo event within the last year, and they strangely acted as if Mongo were a joke—that is, they treated it like a playground, continuously talked about how and where it broke, and continuously reminded us that they didn't care about its data integrity because they were just messing around.

What's wrong with Angular? Why is it slow?

What's the deal with MongoDB and the node.js community? I don't find non relational databases that enticing and there are javascript drivers for postgres [1].

[1] https://github.com/creationix/postgres-js

Probably because mongoose is so well written, it feels inferior to use another kind of ORM library. I'm guessing nobody has written something as good as the activerecord library in the ruby world for node.

I mean you're kind of trying to say "Why not X?" The answer is X would probably work fine, but Mongoose got there first, set the standard, has lots and mindshare, and is very well written and tested.

Could most everyone use D instead of Go or Java? Yeah, probably they could. Is one significantly objectively better than the others? Probably not.

I've used Mongoose extensively and it just works. It feels really idiomatic and has a lot of love in the community. I don't have a reason to look anywhere else.

You can't really compare node-postgres and Mongoose. The former is a simple Postgres client, while the latter is a fully-featured ODM.

It's nice to be able to get up and running and just throw documents into a database without having to specify what that data will look like up front.

I guess that makes sense but do most people who use node.js use mongo in production or just as a scaffolding tool?

Who the heck just uses mongo as a scaffolding tool? I don't know anyone who does that.

what he meant (i think) is use MongoDB in a lean manner - which is to say, try to get something off the ground, and if it takes off, switch to the most appropriate DB then (which might be Mongo).

I think this is the killer use of Mongo IMO.

Yeah, this is exactly what I meant.

JavaScript "developers" feel the need to not use any other language than JavaScript, so they decided to shove it into as many unnecessary places as possible, even if their code more frequently ends up being an unmaintainable mess with no noticeable performance gains.

You are so right. Why try new things and test new ideas. Everything we have is perfect as it is! No need for a car, walking will get you there! We don't need moving pictures, books are fine!

Do you even know anyone that works in Javascript? I happen to like JS but pull out PHP or Python or whatever I need to get the job done when I have to. And I'm not an exception.

I've seen your flawed argument used more and more often around here lately. It's pretty disappointing to see.

Somebody speaking out against deeply broken technologies or bad ideas that have received a lot of hype lately does not mean that such a person "hates progress" or is "resistant to change" or any utter nonsense like that.

Likewise, adopting so-called "new ideas" or "new technologies" does not necessarily mean that real progress is actually being made. JavaScript and NoSQL, for example, are generally regressions in most respects, even relative to 1990s- or 1980s-era technologies.

True progress happens when we move beyond our current abilities. It is not progress in any sense when we start using inferior programming languages or databases, for example.

I always seem to see you in any thread involving "new" technologies that you find "inferior", most of which are not very new and, like all technologies, are tough to put on a precise inferiority/superiority scale in an objective context-insensitive way. I'm beginning to move past annoyance to pure curiosity - why do you care so much what technologies other people find useful? In what way does people's enjoyment of Ruby/Rails, Javascript, NoSQL, etc. harm you so much that you have decided to come and be nasty any time anybody speaks positively of them?

Software doesn't exist in a vacuum. It often has a lifespan far in excess of the involvement of the original developers. It can also have a very serious impact upon its users, its subsequent maintainers, and any organizations they may belong to.

I could not care any less if hobbyist developers want to use Ruby on Rails, JavaScript and NoSQL for own their personal projects that nobody else ever uses or has to maintain.

It's a different situation when such objectively-flawed technologies are used beyond that, however.

The broken software you or others write today using such horrid technologies may very well end up being inherited and maintained by me or one of my teams later on. We won't be happy when we have to waste time, effort, money and opportunity dealing with it and its flaws.

There are numerous, far better options out there. There are just no excuses for using poor technologies these days.

Your goal of seeing higher adoption of technologies you like and lower adoption of those you don't makes sense but your approach is misguided. I rarely see you speak positively of technologies you like, rather than negatively of those you don't. I rarely see you reasonably describe the shortcomings of technologies you don't like from a place of apparent expertise, rather than making ungrounded categorical statements ("hobbyist", "objectively-flawed", "horrid", "poor") about technologies that it doesn't seem like you have bothered learning about in any depth except that necessary to confirm your biases.

Plenty of people would prefer to inherit my broken software using horrid technologies than your broken software using different horrid technologies, and vice-versa. This unnecessary us-versus-them-ism in technology drives me crazy.

The "developers" dig seems unnecessary.

@cuttooth and @PommeDeTerre, since you both are pushing the "JS is a flawed language" angle, what do you find are its greatest flaws?

I can tell you why I dislike programming in JavaScript (those aren't necessarily faults of javascript itself):

1. Complex code usually contains some horrible callback spaghetti, which is not pleasant to debug at all.

2. General flakiness, or, as I call it, the "WTF happened?" syndrome. I run into this all the time. Change or add something - suddenly you find the web page broken. Okay, so there's a bug somewhere. Click developer tools - console... blank. No error messages, nothing. Just you and the broken web page. Just the other day I was trying to integrate a select2 input field into some angular.js-powered page and ran into all kinds of weird issues. But why does it even have to be a problem? Why can't I just stick a new control into a web page with a click and maybe a few lines of code? Hey, remember those things called "Visual Basic" and "Delphi"? UI programming with these was a blast, all the controls looked and behaved the same across all applications. And then there was ActiveX. The idea behind ActiveX is almost futuristic compared to the shit we have to put up with.

3. Type system. Made a typo in a variable name? Bad luck, Javascript will introduce a new variable and you'll have fun chasing a non-existing bug. Oh, look, here's a function: "function foo(param)". I wonder what does it do? Unfortunately, the previous maintainer has not left much comments, so now I have to dig through the implementation to find out what the parameter should be and what values the function may return.

These are my main issues with javascript. I hope sometime in the future we'll throw out the whole Javascript/HTML thing and start writing web application front-ends in a language that is more geared towards UI programming. I can imagine having a nice declarative language (instead of HTML) to describe what the interface looks like, and a statically typed imperative scripting language to describe UI behavior. It would also be awesome if these technologies allow for painless integration of independent UI components (a bit like ActiveX controls). But those are just dreams...

I hear you. I have extensions to your points and disagree here or there but, in general, all your points come down to the same thing: the developer toolchain for JS really frickin' sucks.

Web development is a pain. Web developers have to deal with at least five separate technologies to get anything non-trivial to show up on the page. HTML, CSS, JS, server-side language, persistent store. Each one brings its own config languages or preprocessors, maybe some kind of build system, and, of course, mo' tech mo' problems as they say.

(An aside: I think select2, specifically, is really beautiful and an absolute pain to actually use with any other framework in real usage)

There's some truth to the argument that JS development is merrily rediscovering development methodologies pioneered decades ago:

1. "Yay! With RequireJS I can do real dependency management!" 2. "Did you see that article on how to do conditional breakpoints in Chrome dev tools?" 3. "Using type annotations in the Closure Compiler let you add some kind of type checking!"

All that said, it is getting better:

1. Always use a linter. JSLint if you wanna cry, JSHint otherwise. 2. Callback spaghetti in JS is equivalent, in my mind, to cryptic one-line pointer arithmetic in C/C++. It's a symptom not of the language itself but of the programmer's hostility to future maintenance. 3. Declarative widget-y tech is the future of web front-ends: between AngularJS directives and the evolving Shadow DOM specification (to name two), we're moving in the re-usable component direction.

We're never going to throw out JS. Ever. Every browser vendor would have to simultaneously switch to some staggeringly amazing technology all at once as well as convert all the old browsers as well. It's not going to happen.

JavaScript, if measured by installed runtimes, is the most popular, wide-spread language on the planet. Count the devices in your home that can run JS. That's its true strength, I think.

It isn't necessary for everyone to switch to something new at once. If one big browser accommodates a different language, someone will use it. If it is popular, it will be adopted more broadly.

Not to mention, it can be compiled to javascript at first, for backward complatibility. Actually, Google's Dart comes to mind, but I haven't really used it to make an informed judgement about it...

> 2. "Did you see that article on how to do conditional breakpoints in Chrome dev tools?"

I didn't - which article are you referring to?

It was kind of a joke, but here's the Chrome developer tools page on debugging JS: https://developers.google.com/chrome-developer-tools/docs/ja...

The problem with javascript and the tooling related to it isnt something to do with the existence of great tools. Ofcourse, tools that are pretty mature and really good, as found for other languages dont exist for javascript ( like the tooling for java for ex ) but that doesnt mean there is nothing out there.

I use Intellij and I have noticed that I dont do any mistakes likes missing commas, accidental global declarations etc because my IDE ( intellij ) tells me about them. It infact corrects me when I make any such mistakes. The real problem is with people still using simple text editors to write javascript code because they dont think there is any advantage of using a full fledged IDE which does anything , because they think that there is nothing out there which actually helps.

The numerous flaws with JavaScript (the programming language) are well-known and well-documented. A few search engine searches should bring up ample information.

As for its "greatest flaw", I think that may be the JavaScript community, and the general attitudes within it.

There is, unfortunately, a very high degree of ignorance within the JavaScript community. There are far too many JavaScript programmers who only know JavaScript, or an equally-horrid language like PHP. Having such a limited world view, they don't realize how inherently bad their tools are, and they don't realize how much better they could be.

This ignorance has many side-effects. One big one is that we see a near-complete lack of improvement of the language itself. Any changes that have happened never really address any of the serious flaws with the language.

Another side-effect is that we see JavaScript used in ways that it shouldn't be used, in places that it shouldn't be used. Large browser-based applications and server-side applications (of any size) are two good examples. Asm.js is another. Emscripten is yet another.

There are various other issues with the community, their attitude, and their ignorance, too. We could go on for a very long time about this.

The JavaScript community ends up earning a lot of animosity, if not outright scorn, from those developers who have experience with many programming languages, and who have spent years, if not decades, developing production-grade software in a much more sensible, proper manner.

I don't think that anyone would really care if JavaScript users used it solely as a hobby. But the moment they try to use it professionally, for real-world software systems, they'd better be prepared to defend themselves and their technological choices. They can't bring their amateurish programming language and ignorance to the table and not expect to be treated harshly.

You haven't outlined any points here about the language. I don't want Google to tell me what other people think its flaws are, I was asking you what in your experience are its flaws. Looking at your past comments on HN, you seem to leave comments like this a lot.

I guess I'm looking for lists like this:

C/C++

1. The preprocessor allows for horrid misuses with a broken "macro" system that doesn't deserve the name compared to Lisp's.

2. The preprocessor #include system makes compilation slower and more complicated. So much so, in fact, that Google invented a language, in part, to get around it.

3. Dynamically linked libraries are a joke that have no real use in production software.

4. The language syntax is complex enough that creating good parsers for it is extremely hard leading to bad error messages in most compilers.

Y'know, stuff like that.

Why do you think that the flaws that I've personally experienced with JavaScript differ from those that others have experienced and already documented? The flaws are there regardless of who is using JavaScript.

I'll list some of the most obvious and serious ones for you, since you seem incapable of finding this basic information on your own:

- Its type system is horribly broken.

- Its scoping is horribly broken.

- Its comparison operators do not behave sensibly.

- Its prototype-based OO system is impractical, and quite poor compared to other prototype-based languages.

- Its lack of class-based OO leads to awful hacks using its awful prototype-based OO functionality.

- Its lack of support for proper modules and namespacing makes large-scale software development tedious.

- The fact that something as obviously-dumb as semicolon insertion is even conceived of and supported in the first place.

- It's so rife with other bad language features that one of the most widely-respected books about it, Crockford's "JavaScript: The Good Parts", is all about not using large parts of the language.

- Its standard library is extremely limited, and what does exist works quite poorly.

- Its tooling (editors, debuggers, profilers, etc.) is lacking in many respects, and is often entangled within web browsers.

- Its performance is lacking.

- Its community is generally inexperienced and incompetent, and produce a lot of very bad code.

- There's little evidence that things will improve in the future.

While other languages have flaws, none (aside from maybe PHP) have as many utterly stupid, unnecessary and unjustifiable flaws as JavaScript does. And at least these other languages make some real effort to eliminate such flaws, as well. We just don't see that from the JavaScritp community.

> ... since you seem incapable of finding this basic information on your own:

That's a pretty rude response to an honest question.

Thanks for the list.

I know you feel like you just explained its flaws, but there's nothing here that couldn't also be said about any other mainstream language.

Nonsense. There's a huge, and very obvious, difference in the overall level of experience, ignorance and competence within the various programming language communities.

The JavaScript, PHP and Ruby communities have an abundance of ignorance, often due to a severe lack of experience. These are the most-hyped languages, and the ones that new developers often flock to. It's quite obvious why so many bad decisions (like using these languages in the first place, or using NoSQL databases) and so much bad code comes out of these communities; their members often just don't know any better, and often aren't willing to learn.

This is much less of an issue within the communities that attract experienced and competent developers. We're talking about C, C++, Python, Haskell, Erlang, Scala, and even Java and C#. Thanks to the wider and deeper experience that the developers in these communities tend to have, we see far fewer blatantly obvious mistakes being made. That's not to say they don't happen; they do. But the quality of the software that is produced is generally much better than what we see produced by the JavaScript, PHP and Ruby crowd.

It's easy to pretend that these very real differences don't exist, but the reality is that they do.

The opinions of one who writes "Javascript 'developers'" are probably not worth knowing. Javascript has stupid scoping rules, and some other obvious flaws, but it's not flawed as in unusable, and it's certainly not flawed as in "'developers'".

Maybe, but dismissing people doesn't sit right with me.

Not to get to Yoda-y, but the anger here is real and deserves some scrutiny.

I think very few javascript developers only know javascript. This some kind of late 90s C++ elitism or sarcasm?

No, I think it's just the unfortunate reality.

The problem with your argument is that those who know programming languages other than JavaScript end up seeing its flaws extremely clearly. Such people won't willingly subject themselves to something that is so inherently broken, especially given that they're aware of the alternatives. Many would feel quite ashamed to associate themselves with it in any professional manner.

Some of us want to get things done rather than sit in an ivory tower being pompous. The notion that a person is not a developer simply because they expanded their knowledgebase to include a language you dislike is asinine.

Plenty of people who know multiple languages use Javascript every day. Of their own free will. Because they want to.

What is it about JS that you find so broken that you have such animosity?

I for one know C, Perl, PHP (not just Wordpress either) and even Coldfusion. I'm currently learning Python because I want to.

And I chose to work in Javascript as my main language because I want to. I have no real issues with scoping, am comfortable with the fact it has no 'class', have a good handle on the fact that everything (including functions) is an object.

It is flawed? Yes. But then again there isn't a single language in existence that isn't.

Have you tried development with node.js and in particular npm (node package manager)?

I used to have the same thoughts about JavaScript. It really is a new world with these two things - and that is coming from a Ruby background.

is the "developers" dig really necessary? MongoDB is fine-- at least until you start seeing significant scale, and even then, it's going to run into the same issues as everything else would if you hit it too hard, too often.

Just because the query language is JSON-esq and has a javascript shell, it's therefore "Javascript" and a target of derision and scorn?

I don't feel like you addressed the parent post. It was asking why people use mongodb instead of JavaScript bindings for PostgreSQL.

I have used both. I find it easier to iterate using mongodb because you do not even need a schema to begin with.

If I want to move forward I can switch to mongoose or move over to postgres and node-pg.

MongoDB is used in almost every community. Especially for new languages.

You can easily find relatively mature MongoDB drivers from the start for new languages, but don't hold your breath for PostgreSQL. See Rust.

I'm not sure that Rust is really a good example. While promising, the language itself and its standard library are still immature and subject to a huge amount of disruptive change on an ongoing basis.

I've had some experimental code I wrote in Rust become essentially unusable after only a few months due to significant language and standard library changes. I sure hope that somebody wouldn't spend time on a PostgreSQL library for it until the language itself becomes more stable. They'd be wasting a lot of time and effort if they did try to write such a library now.

Rust is a perfect example: http://blog.mongodb.org/post/56426792420/introducing-the-mon...

So are many other newer languages and frameworks. See vibe.d (http://vibed.org/) for D which has only database drivers for MongoDB and Redis.

So much hate on HN these days. Thanks for sharing, that's definitely a very useful and productive stack that I keep going back to again and again for every projects. Will give it a try next time.

Love it - except for the Angular part - can we get a MEEN stack with Ember.js?

Was going to say the same thing.

What don't you like about Angular? The template engine makes the insanity of explicit updates go away...

Some would say data-binding and logic in HTML attributes is insanity.

Oh no! They're pronounced the same! No end of confusion...

we deeply encourage any kind of forking of this project. have fun break rebuild!

This would be even smoother as a Yeoman generator. http://yeoman.io/generators.html

We've been using almost the same stack at StartHQ (https://starthq.com) with great success. Mongo and Angular make it easy for us to iterate quickly. Performance hasn't been an issue with up to 300 concurrent visitors on site running on a AWS micro instance.

The one thing we do differently is that we're using fibers and Common Node (https://github.com/olegp/common-node), as well as Stick (https://github.com/olegp/stick) instead of Express. This lets us write complex business logic with less code and without having to worry about explicitly handling errors, since we get to use exceptions.

How about providing a npm module(binary) as well. So we can use it like this.

`mean create myapp`

A good example is phonegap: http://npm.im/cordova

actually this is the next step for us, we just started to work on it.

awesome.

Guys as the author of this project one of the guidelines i had was to create it as modular and familiar as i can, so whenever I could I tried using a popular module(mongoose, passport etc.)

I deeply encourage anyone who wants to break, replace, remove, add any part of this project to go ahead and do so! Like any recipe this is just our serving suggestion.

I'd love to see an ember fork!

I spoke of the "MEAN" stack today - cool to see others using to a tee - with Mongoose and Passport.

Two other nice packages:

Nodemailer - for emailing - npm install nodemailer

Moment.js - for time/date formatting, and a ton more (manipulation, etc) - npm install moment

It's pretty sweet, I cloned this project to get started and it was much harder to learn at first since there wasn't an example of the basic CRUDs; They added examples now, so the learn curve is less steep.

Looks a lot like this node+express+mongo boilerplate: https://github.com/madhums/node-express-mongoose-demo

Thanks for sharing this. I've been getting into express lately and this boilerplate is a little leaner for the reading.

It also just informed me of the app.param api in express. I had no idea.

the background image makes it unreadable on small windows... i suppose it's the same on mobile devices

It is. The text blends in to the background image on my iPad and makes it very difficult to read.

Not on my Nexus 4 with firefox nightly

I had worked with several people that chose Mongodb.

Their reasons were the database is easy and it "scale".

The real reason why they chose it because they think SQL is too hard. Really, they were self taught programmers that couldn't bother to learn SQL and jump straight to NoSQL hype and the fact it was "easy".