
Mean Stack - keva161
http://mean.io/
======
alanh
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.

~~~
aroman
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.

~~~
trimbo
> very appealing option in a number of cases.

What cases do you have in mind?

~~~
aroman
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.

~~~
PuercoPop
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?

~~~
aroman
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/](http://docs.mongodb.org/manual/core/write-concern/)

------
wasd
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](https://github.com/creationix/postgres-js)

~~~
cuttooth
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.

~~~
drhayes9
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?

~~~
10098
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...

~~~
drhayes9
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.

~~~
pekk
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.

~~~
10098
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...

------
d0m
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.

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

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

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

------
begriffs
This would be even smoother as a Yeoman generator.
[http://yeoman.io/generators.html](http://yeoman.io/generators.html)

------
olegp
We've been using almost the same stack at StartHQ
([https://starthq.com](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](https://github.com/olegp/common-
node)), as well as Stick
([https://github.com/olegp/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.

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

`mean create myapp`

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

~~~
arunoda
awesome.

------
amoshaviv
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!

------
ErikAugust
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

------
dmak
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.

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

~~~
bemurphy
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.

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

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

------
digitalzombie
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".

