[meow_mix]

This was a really bad time to post this framework, the disillusionment for javascript is at an all time high right now.

That being said why Mongodb? NoSql are advantageous for write speeds, which as far as I know isn't particularly important for new applications. I understand that you want "javascript everywhere" but is that really worth the cost of losing the speedy and convenient join statements? I think postgres might have been a better choice.

[dceddia]

I can't say if they considered other databases, but "MERN" is a play on "MEAN" (Mongo, Express, Angular, Node) -- I imagine they were aiming for a React-centric version of the popular MEAN stack.

[pygy_]

Waiting for the NERD stack.

Node, Express, React, $DataBase.

[ravendug]

There's no need to wait: https://github.com/Xantier/nerd-stack

[pygy_]

Crikey... What a world we're living in!

[batat]

Could be a drinking game: pick random word, add "js" and google for it. If google finds something related, take the shot.

[mawburn]

Or just really big fans of Tyler Perry movies.

[iamdave]

Bringing the total number to 1?

[CodyReichert]

No, it's two. Don't forget Tyler Perry.

[infecto]

Glad I am not the only one. I do not understand why most JS frameworks use a NoSQL store. Even from their FAQ.

"You can always replace Mongo with another DB like RethinkDB, CouchDB or something else you like. :)" What about SQL??!?!

[nnq]

Most of the "nodejs generation" would take simple queries + aggregates (https://docs.mongodb.org/manual/aggregation/) + some flavor of map-reduce (https://docs.mongodb.org/manual/core/map-reduce/) over SQL anytime. Mostly because you only need the first for 90% of the cases, and for the rest, SQL is "brain hurting" and hard to optimize anyway. I also happen to agree that SQL should be finally killed and buried (and invent a more "in code" and closer to mathematical language notation for when you really need to do relational algebra, something like a "relational GraphQL maybe"), though most of the colleagues of my age would prefer to bury me for expressing this opinion :)

[jowiar]

Working at an organization that does both, the thing that jumps out to me is that SQL is a bit painful from the "application developer" side, but fantastic from the "ad-hoc data analysis" side.

It's tough for me to say "finally killed and buried" when I have a couple dozen colleagues being wonderfully productive with SQL as one of their primary tools. Application developers and analysts don't need to use the same tool, though.

[jowiar]

2 theories:

(1) Node sprung up at the exact same time that NoSQL was in it's "fad" phase (which had much to do with fighting the now-mostly-solved scaling challenges of the SQL databases of the time). Both caught on with people who liked trying the hot new thing in 2010.

(2) There's definitely a bit more impedance mismatch when you're working with a SQL database from JS. If what you're trying to do is persist a blob of JSON, a NoSQL object/document store works at that level, whereas a SQL database requires thought and planning.

This is not to say that I prefer NoSQL, or that these are reasons why someone starting something now should choose NoSQL, but they do jump out to me as why backend JS dev has been a bit more NoSQL-happy over the years.

[xhrpost]

Can be worthwhile if you take advantage of embedded documents. Storing your data in the same form that you use it in your application, can at appropriate times be very helpful. I recently started using an ORM that does not support embedded documents when using Mongo and found I essentially had all of the problems of a NoSQL DB with none of the advantages.

[elliotec]

Needs to be PERN (postgres replacing mongo). Everyone loves PERN.

[sebringj]

Web Assembly will dissolve that monopoly, not sure when though.

[nnq]

Wake up. People don't use Mongo because of it's better write performance. They use it because it increases junior developer productivity at building a shipable MVP and allows for more "natural" data models 99% of the time.

Reason: real-world data is almost never relational by nature, and you never really need ACID (even for financial data you can find a subset of ACID that's appropriate for you use case and complies with your regulations, and tweak a nosql solution to achieve it) and any relational model of data will be "awkward" in one way or another. Trying to get a more natural data model, it's always a question of either (1) storing graphs in a tree db (read "document db") or (2) trees in a graph db (no good open-source and easily scalable graph dbs around, too much developer inertia). Couple (1) > (2) for now, with the fact that write performance is more important than versioning for most (mostly because "naive" versioning at "big data scales" takes too much space), hence CouchDB < MongoDB and also "column dbs" being really odd for most general use cases and "nosql document dbs" remain the only sensitive choice for most projects.

I've finally seen the light and stopped recommending Postgres over Mongo to people :)

Rethink is probably a better idea. And there's also Arango. And I happen to love Neo4j. But Mongo is "good enough" for most, hence the obvious choice for a general purpose web framework.

[dang]

> Wake up.

Please don't. Your comment becomes much better if you simply take out that rude bit.

[k__]

Really?

I had the feeling that data-models of document stores like MongoDB often only fit one use-case and fail after that.

A blog, for example.

You have Article and Comment and when using a document store, it comes naturally to embed Comment in Article, because, well the first thing you need is to display comments below articles.

Then you want to show the comments of a user, but they are stored inside the articles...

If you had a relational data-store the way to retrieve the data for both cases would be the same mechanism, a join.