Mean Stack
mean.io
mean.io
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.
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?
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.
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.
What cases do you have in mind?
Those are two areas in particular where I would first look to Mongo.
As for JSON, Postgres has first class support for JSON data field types.
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.
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.
Just because the query language is JSON-esq and has a javascript shell, it's therefore "Javascript" and a target of derision and scorn?
If I want to move forward I can switch to mongoose or move over to postgres and node-pg.
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.
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.
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.
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.
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 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.
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.
@cuttooth and @PommeDeTerre, since you both are pushing the "JS is a flawed language" angle, what do you find are its greatest flaws?
Not to get to Yoda-y, but the anger here is real and deserves some scrutiny.
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...
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.
I didn't - which article are you referring to?
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.
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.
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.
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.
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.
That's a pretty rude response to an honest question.
Thanks for the list.
https://github.com/brianc/node-postgres
EDIT:
Whoops, its clearly just a client and not an ORM. How about
https://github.com/dresende/node-orm2
instead?
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.
I think this is the killer use of Mongo IMO.
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'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.
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.
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.
`mean create myapp`
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!
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 also just informed me of the app.param api in express. I had no idea.
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".