91–97 of 97 posts
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".
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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. Clic…
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 conf…
I didn't - which article are you referring to?
Earlier quoted context omitted.
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".
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.
Earlier quoted context omitted.
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 conf…
> 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?
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.
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?
Earlier quoted context omitted.
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?…