Mern: Build JavaScript apps using React and Redux
mern.ioFRAMEWORK (shitty tragedy in one act)
Dramatis Personae
PROGRAMMER, programmer
HIPSTER, hipster
* * *
ACT I
Small room. There are a table with paper stacks, opened "Perrier" bottle, two huge monitors and a programmer sitting behind. Programmer reads papers, looks on first monitor, then on second and typing something. From time to time he says "damn idiots". Number of "damn idiots" is divided equally between papers, first and second monitor.
Door opens loudly
PROGRAMMER: Who's there?
Hipster runs into waving his hands
HIPSTER: Framework! New awesome framework! Just look, it's awesome! Just look!
Programmer looks into hipster's iPad
@moccachino.render()
helloWorld({
view: "myProject.sample.view.Hello",
div: "myContainer",
data: {
message: "Hello World!"
}
});
PROGRAMMER: Damn idiots.
Exeunt.
(sorry for my English)
It illustrates "Chekhov's bottle" very well:
"Remove everything that has no relevance to the story. If you say in the first chapter that there is a bottle of Perrier on the table, in the second or third chapter it absolutely must land on a hipster's head. If it's not going to be smashed, it shouldn't be sitting there."
And perhaps the moral of the play is yet another variant of Chekhov's gun, but this one would be "Chekhov's framework"!
I don't see the reason why would you apologise for your english when you use the words like 'Exeunt' ... Otherwise good joke.
I understand your point, but 'Exeunt' is Latin! :P
Probably because the author was compelled to choose his words wisely to comply with forum policies. In essence "damn idiots" is a toned down version of something far more expressive.
We don't give a shit if you swear. We care about how people treat each other.
Really? Several times I thought I saw threads mysteriously being ranked downwards, only to find out they contained a formal (or other) discussion of swear words, so I always concluded that there's some sort of "shitstorm detector" at play. But maybe I'm just imagining things...
Your observations were probably real but you might have misinterpreted them. We do penalize subthreads for being shitstorms, flamewars, or off-topic. (Tediously off-topic, that is. Whimsmical offtopicness is fine.) And profanity is more common when people are upset, so one would expect a correlation. But profanity isn't a moderation concern per se.
So this is a repo that is being cloned on your computer [1]. I have a couple of questions :
1. Why not just creating yeoman generator?
2. Don't you think it is too opinionated and inflexible to be useful?
1: https://github.com/Hashnode/mern-cli/blob/master/lib/main.js
I much rather clone than use yeoman. What is the benefit?
Well yeoman can be configured to ask you questions about the setup you want. Think "less or sass?"
Why would something that is opinionated and inflexible not be useful? See Rails.
NIH Syndrom?
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.
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.
Waiting for the NERD stack.
Node, Express, React, $DataBase.
There's no need to wait: https://github.com/Xantier/nerd-stack
Crikey... What a world we're living in!
Could be a drinking game: pick random word, add "js" and google for it. If google finds something related, take the shot.
Or just really big fans of Tyler Perry movies.
Bringing the total number to 1?
No, it's two. Don't forget Tyler Perry.
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??!?!
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 :)
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.
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.
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.
Needs to be PERN (postgres replacing mongo). Everyone loves PERN.
Web Assembly will dissolve that monopoly, not sure when though.
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.
> Wake up.
Please don't. Your comment becomes much better if you simply take out that rude bit.
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.
Not that it has any practical implications, but I grew up next to a tiny tiny town in Denmark that was called exactly Mern. Famous for being full of people who wanted to fight.
FWIW 'isomorphic javascript' was pretty much supplanted by 'universal javascript' last year per this medium post [1]. You might consider changing the copy.
Edit: At the very least Dan Abramov (Redux creator) is ok with universal [2]
[1] https://medium.com/@mjackson/universal-javascript-4761051b7a...
[2] https://github.com/gaearon/react-redux-universal-hot-example
FWIW those of us in the JavaScript community who don't care to create buzzwords for everything call it JavaScript. No Isomorphic, no Universal. There's nothing different. It's just JavaScript.
> There's nothing different.
It's still JavaScript, but how you design/write it is fundamentally different when you're writing for both the client and server.
No the libraries you use are different.
On the client you wouldn't use `fs` module, but on the server you wouldn't use jQuery unless you were manipulating the dom through scraping with Cheerios.
Many people still don't agree, neither do I. There's no doubt that the term "universal" is more correct, however, languages don't work that way. In the JS land isomorphic has a very specific meaning. Universal is a flexible word. "A universal api for observables" means something (works across libraries), "An isomorphic api for observables" means something else (works across environments) .
FWIW no it wasn't. Everyone (everyone who javascripts anyways) already knows what "isomorphic javascript" means, and "Universal" is a fucking terrible name for what it is being applied to (it sounds like it is translated into all languages, or runs equally on Windows and Macs, or who knows, it's made for aliens or something).
Universal JavaScript is incorrect. There are more JS runtimes than Node and the Browser. Does React run in Postgres? In Duktape?
Lets not get caught in 'war of words'. There is no standard to it and I don't think it matters as long as you understand what it means.
> There are only two hard things in Computer Science: cache invalidation and naming things.
> -- Phil Karlton
I like the self referential version:
"There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors."
> as long as you understand what it means.
Isn't the whole effect of litterary words to be specific but exclusive?
I was under the impression that the community as a whole had agreed to switch to that term as well. :( Given your name I reckon you feel strongly about this, too.
But isomorphic sounds cooler...
Your demo needs fixing, it's open to XSS and that has been tried and tested, as expected for this crowd. :)
MERN scaffolded apps depend on Mongoose. I wrote a plugin that maybe could fix that, its called mongoose-sanitizer: https://www.npmjs.com/package/mongoose-sanitizer
As a curious noob, could u explain what is the source of the XSS vulnerability in this case? Is it simply that the site isn't being served over tls/ssl?
Not sanitizing input, by either scrubbing out any <script> tags, or escaping those characterst to html entities.
Please don't "sanitize" input, just escape accordingly.
"<script>" might be a legitimate input.
You need both. Sometimes the legit input is HTML such as from rich text editors. In those cases if someone types a bold <script> then the form should submit the escaped <b><script><b> but also needs to sanitise to make sure that other HTML element types are not present.
If you escape one step further you'll lose formatting or the message, so sanitisation is important too, it is reductive to say "always escape never sanitise".
I think your first problem is whitelisting HTML entities. Unless you're composing HTML-formatted email, it's usually better to use a different markup syntax like a minimal markdown or asciidoc that can safely be escaped.
I agree, although for non-technical users, the better wysiwyg editors are still HTML based, unless you have a recommendation for an in-browser wysiwyg editor that returns/exports markdown?
Oh yes, XSS attack on a bare minimum blog app! There's a reason why its called starter app!
Might as well just store credit card info and passwords in plain text while we're at it. Starter app! Disruption!
Precisely my point, who the hell stores credit card info in a f*ing starter app! And your obsession about seeing a disruption in every damn thing!
This sub-thread is a little snippy, but it seems like a good opportunity to mention something I mention to a lot of people.
Sample code is documentation. For a lot of users, the sample code is the only documentation they're going to read when they're starting out. If you consider that, doing it the right way in your sample code is critical.
Further, it feels a lot like false advertising. If input validation is awkward in your framework, and I don't discover that until later on down the road, I'm probably going to feel deceived. If the "demo code" is a screenful of code, and doing the same activity but doing it in a secure way (i.e. no XSS, etc) results in 10 screenfuls of code, I'm going to feel that either: a) the author of the framework doesn't know what they're doing, or b) they were trying to make the framework look super minimal, when it actually requires the same amount of boilerplate junk that everyone else requires. Either way, I'm not going to be super pleased. Just show it the right way upfront!
The page keeps mentioning 'isomorphic apps' but I have no idea what those are.
From googling, they appear to be JS code that can run client and server-side? Not what I would have guessed!
An isomorphic app is basically a Single Page Application (think Angular / React / Ember application) with the special ability to be rendered server side. The interest vs a simple SPA is that on the first page load, instead of loading just javascript, and having to wait for XHR request and JavaScript rendering to draw the data, you get the page properly rendered in the first place. But when you navigate to go to a different page, you use javascript to repopulate the data. It's the best of both world for the users. But for the developers it usually means extra work.
Also it's better from an SEO point of view, since depending on how you implement your SLA Google may be unable to read it.
It's one of those instances where developers went looking for a word that perfectly articulates what it's doing, but is so esoteric as to be useless.
> being of identical or similar form, shape, or structure
I call it fronty-backy-samey-samey and everyone knows what I'm talking about.
It's not really esoteric... it just kind of has the wrong connotations, because it's used rigorously in mathematics, and here it just means "portable between different JavaScript runtimes," pretty much.
To me the word makes me imagine a web application that can parse its own rendered HTML and get back the application state. Which sounds kind of interesting...
It's not about runtimes. It's about environments. The difference between Node and Chrome isn't so much the runtime as that one is on the server (with arbitrary network and file I/O) and the other is a browser (with a DOM and Web APIs).
Isomorphic means that the same code can be used to "pre-render" an app on the server and to interactively run the app on the client, preferably without losing input state if the client-side execution is delayed (i.e. not throwing away the rendered content but attaching to it).
More generally it means that the code wraps any underlying APIs to make it behave similarly (but not necessarily identically) in node and the browser. Like isomorphic-fetch, which uses a polyfill (i.e. a fallback implementation in the absence of a native API) for the Fetch API in the browser or a node-based implementation in node.
The reason some people prefer the term isomorphic over universal is that isomorphic has no conflicting definition in the context of web apps. Universal on the other hand is extremely vague and ambiguous (ranging from "takes accessibility into account" to "works with different third party APIs" to "language independent").
The reason some people prefer the term universal over isomorphic is that isomorphic as a scientific term has unrelated meanings in mathematics, chemistry and other fields which can be domains for web apps.
Of course the real joke is that the definition is only about node and browsers, making no claim whatsoever about "all JS environments" or even "most". This is one of the reasons I personally don't like the term "universal": it implies a scope that simply isn't intended by most projects the term would be applied to. Something that only works in Edge and Node 5 might be "universal" but it isn't universal at all.
it just kind of has the wrong connotations, because it's used rigorously in mathematics
And the original use was in Philology[0]. Just because a word has two different meanings in two different contexts doesn't means it's wrong. I'm certainly glad the linguists didn't get up in arms when the mathematicians gave the 'wrong connotation' to isomorphism.
[0] - https://books.google.com/books?id=hZpeAAAAcAAJ&pg=PA711&lpg=...
Well, I didn't mean to claim it's prescriptively wrong, just that to my mind, maybe because I've been around a lot of mathematicians and coded a lot of Haskell, the usage jumps out as kind of weird... and anecdotally, I've mostly heard "isomorphic JavaScript" used kind of ironically, with a wink bordering on a cringe.
By the way, for the broader point about language mutation, and prescriptivism vs descriptivism, I think there's a common stance against prescriptivism that also seems to rule out any negative opinion about language change—to which I say, hey, negative opinions are part of the whole mess too, even from a descriptivist standpoint. But this is a derail already; sorry.
Consider "fronty-backy-samey-samey" stolen
Isomorphic means hybrid client/server view rendering.
SPAs are (relatively) slow to load. To improve perceived performance, the view requested is prerendered on the server with the ability to capture user input. The user sees a fully functioning site while the app bootstraps in the background.
Once the app is finished bootstrapping, the user inputs are replayed on the actual app.
This fixes the problem of poor perceived initial load times that come with SPAs. Once the app is bootstrapped everything is fast/snappy as one would expect with a SPA, incl no page refreshing between URIs.
Isomorphic React is already supported. Isomorphic Angular2 (ie Angular Universal) is in the works. I don't know about Ember but I'd assume they already support it.
> 'isomorphic apps'
…also known as 'universal apps' nowadays
(see https://medium.com/@mjackson/universal-javascript-4761051b7a...)
Ok, here's some helpful criticism (not that all of this is unhelpful):
Overall the presentation of your system is great. However, the documentation needs work, particularly on how to create a complete mini-MVP. Examples, even if dinky, help a lot. Many developers will just download an example and start messing around and see how it feels.
An important note on app structure:
I noticed how the approach you take involves maintaining lot of file structure, all reflecting the underlying conceptual framework. IMO, even when generated, complex file structures draw away from our developer productivity. Think about "flattening" some of that. Think about organizing the system around the aspects of the implementation, even if it is at the cost of (for lack of a better word) consistency.
The framework should serve the primary concerns in the mind of the developer: user, group, post, item, etc. rather than the primary concerns in the mind of the framework maker :)
Hope this helps, and good luck in Dodge City!
Great response. I read the one page presentation and looked at the source files and it feels like one of the hundreds of skeleton repos for React. Why is this different, why should we use this one instead of another?
The whole point is to make it easy to work with this full stack framework, so, that means to have excellent docs and StackOverflow support.
Way to spoil the fun with thoughtful and pertinent comments.
From what I can see, this is a boilerplate project with a fancy command line installer. So if you don't plan on using their exact stack, remember there are hundreds of other boilerplates you could use that are no more difficult to install.
I just don't understand the motivation for the cli. Isn't it much easier to just clone the mern boilerplate repo, rather than npm installing some cli, then running a command. If there are no options, what's the point? Admittedly, I might be missing something.
I think a cli tool is usually easier because you don't have to rm -rf .git in order to set up your own repo.
You can use the following git command to move everything except for the .git files to a new location [1]
[1] http://www.tekkie.ro/methodology/use-git-checkout-index-init...git checkout-index -f -a --prefix=/path/to/folder/
I think it's a great idea to try and bring some of RoR's developer happiness to JS. Universal React + Redux is a great stack but I could see why beginners, unfamiliar with starter repos, could get overwelmed reading the respective docs. This project is a good attempt at lowering entry.
My 2 cents, I've been enjoying using websockets and redis with this stack. And +1 for considering the term Universal in the tagline.
> I think it's a great idea to try and bring some of RoR's developer happiness to JS.
That's been around for a while: http://ember-cli.com/user-guide/#using-ember-cli
Yep! Love Ember. I think it's good that this project it trying to bring some of the RoR and Ember ideas to the React Redux stack.
Why MongoDB?
Because people hate the constraints put in place by SQL. It doesn't really matter that they'll spend dozens of hours re-implementing stuff they would've gotten for free with SQL in a RDBMS (not to mention the benefit of serious stability), what matters is that the initial effort to make a change is much lower, and thus developers feel like they're saving a lot of time/hassle. They don't seem to connect the cost on the backend with its cause, or they just don't mind it.
With NoSQL you do have to reimplement all of the constraints in the application but this will likely be necessary even for SQL code because you'll need to provide both server and client side validations on user input.
SQL can be even more of a pain because you'll need additional checks to handle the SQL server's particular blend of error handling if/when something goes wrong.
In both SQL and NoSQL, any decent ORM should provide models, validations, sane error handling, and constraint checks so none of those really matter.
Unless, for whatever reason the business logic is defined in SQL SPROCS. Then, good luck if/when they don't work properly.
Like ORM, NoSQL looks as a good decision at the beginning...
http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...
Why would an SQL ORM provide validations? The database itself already does.
Additionally, user data isn't the only data that needs to be validated. The vast majority of our data is generated by the program itself, and schemaless databases have given us endless headaches with this.
Client-side validation are much more important that server-side validations.
Preventing a user from sending bad data to begin with avoids the poor usability of having to send bad a failed request and reset the form for editing.
Database constraints only avoid bad data in the database. They still have to be duplicated for error checking in the server and client.
Is JS is used on both the server and client, it makes a lot more sense to have ORM models that act as the single source of truth for structure (ie model/schema), condtraints, testing, and validations.
Issues with unstructured data come either from laziness (ie not using schemas in production code) or mismanagement (ie not handling migrations properly between schema changes).
Having the ability to use completely schema-free, unstructured data doesn't mean schema/validations should be ignored altogether.
You wouldn't blame the gun if you shot yourself in the foot, would you?
ORM or not, you still need constraints in the database, though.
There may be more than one client connecting to the database at the same time (or even internal inconsistencies within the same process), and the only way to prevent data inconsistencies is to hand the final responsibility of validation to the thing that is actually storing the data, ie. the database.
In the end, your database is the single source of truth, as it is the only part of your architecture that is technically capable of doing so. Client-side validation and server-side validation (in the application) are niceties for UX purposes, but do not and cannot replace database constraints.
>You wouldn't blame the gun if you shot yourself in the foot, would you?
If it was unreasonably easy to do so, then yes. This is why there are gun safeties. The phrase "hairpin trigger" or "hair trigger" derives from guns with light triggers that made a premature or accidental discharge too easy.
"A poor workman blames his tools" only works if you have real tools. It's OK to blame tools when you're forced to use a twig as a hammer.
Mongo is often quick to get people started and simple to work with. No migrations, or joins, etc. etc.
It's not for every project, but quite nice for prototyping.
It's not that you don't have migrations, it's that you move that logic to your application code. I personally find that to be a terrible trade-off. People make the same arguments in favor of mutable data structures: you benefit initially from having everything mutable, but then you start writing code to compensate for the flexible nature of it and suddenly you have a whole new set of issues.
Except people have bad tendency to not throw out prototypes and are unwilling to do the work to deal with bad decisions from the prototype time...
That sentence should be written someplace where everyone can see it everytime a project starts.
Migrations don't actually take more time than defining the schema implicitly in your application, and you don't even need to think about joins at all if it's only going to be a prototype.
MongoDB is far from "simple to work with". This is 100% marketing bullshit (along with dubious claims like it being "fast" when it never has been), trotted out by MongoDB's marketing department. Let's not forget that it has always been a commercial project.
EDIT: And to clarify, relational databases and document stores are not interchangeable. You need to pick the one that reflects your data model most accurately.
Usually that's going to be "relational", sometimes it will be "documents" - but even if it is, there are better options than MongoDB.
Not only prototyping. If the final product will have a moderate amount of users generating a moderate amount of data, there is really no drawbacks with mongoDB. The real cost is development time.
Of the mongoDB projects I've been involved with, I've always wanted to do large complex joins and filters which was just didn't perform as well as relational databases, and there is no support (as far as I know) for geo-coded data.
That's why I suggest it's good for prototyping, maybe it will work for some projects long-term, but I don't think it's the norm as mongoDb would suggest.
However, most prototypes don't end up as successes, so that's where I figure it's worth the switching cost once a go-nogo decision is made.
There are many drawbacks when using MongoDB, especially in the development time department: http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne...
It's a completely fallacious argument. Using MongoDB doesn't save you time, it just shifts the effort towards a later point, where it will require several times as much effort to fix shit, which may not even succeed and you may end up with corrupted data.
It's really not worth it.
I use MongoDB because I can instantly save down a JavaScript object and later retrieve it in the same state. I don't have to worry about anything else. No configuration, nothing. That's all I need but if there are better options I'm all ears.
You're not "saving down a JavaScript object", as MongoDB does not speak JavaScript. What you're doing is passing an object to your database driver, which then converts it to JSON, and sends it to MongoDB.
JSON is an entirely separate language from JavaScript, and it can be used from just about any language. This "convert a native object into the query format" thing is also literally what almost every database driver in almost every language does.
This has precisely zero to do with either MongoDB or JavaScript.
Ok, so I'm saving it down as a JavaScript Object Notation which looks exactly the same as JavaScript. I think that's very convenient and don't see how it's the same as converting for example PHP to MySQL where I'm bound by a schema which looks nothing like my data structure in PHP.
> JavaScript Object Notation which looks exactly the same as JavaScript.
Whether it looks the same is irrelevant. It doesn't even have the same syntax rules. For example, this is valid JavaScript:
... but would be completely invalid in JSON, in more than one way. No, they are not the same.{ one: "two", three: undefined }> don't see how it's the same as converting for example PHP to MySQL where I'm bound by a schema which looks nothing like my data structure in PHP
And in 99% of cases, this is a feature, because you can't represent most data as a flat list of nested objects. See also this article: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
Aside from that, if you want a native nested representation of data in your database, so including relations, you use an ORM. For example, in PHP with MySQL, you might use Eloquent.
How data is represented in your application and how it's represented in the database, are two entirely different things. There's no advantage to be gained from trying to make them the same thing - that's the concern of the database abstraction that you choose to use.
It's not irrelevant for me. When I look at a record in my database it looks the same as when defining it in code. This is a big advantage for me. Using an ORM is way more complicated than just inserting/retrieving my JS object. As I said, I don't want to configure stuff. I just want to save the object and be able to retrieve it by some key in the object.
> No configuration, nothing.
You still have a server to run, auth to check, etc...
Here's a real database with no configuration, no nothing, actual real plug-and-play:
It's nice with zero configuration. Especially the no password by default thing. Why bother with limiting your database with host access and passwords ;)
I use environment variables so the configuration is basically setting up the host/username/pw in the Heroku interface. But ok, almost no configuration then...
You can do that with almost any language and any storage. JSON.
MongoDB plays very well with the rest of the javascript based stack, which mean development and testing is simpler. For many use cases the development time is the real cost, and the database itself is simple enough that what it is running on does not really matter much.
Most people are not building Big Data systems.
Why not rethinkdb or couchdb then ? Mongo is not the only Javascript friendly document oriented database.
Mongo isn't even "Javascript-friendly". It just accepts JSON for queries, that's all. JSON is approximately as related to Javascript as Javascript is related to Java.
Its shell accepts JavaScript commands IIRC. Not sure if that's enough to call it JS Friendly though.
It might, but you're not going to be using that shell in an actual application, so that would hardly make a difference. The querying is all JSON.
> MongoDB plays very well with the rest of the javascript based stack
Every major database does. This is in no way exclusive to MongoDB.
Actually MongoDB is used quite a bit in big data systems.
It has very good integration with Hadoop, Spark etc.
because MongoDB is web scale
So mean.io with React instead of Angular.
I'm not sure I like the trend of tethering an application to a specific backend, especially regarding databases. I think it would be more interesting to, if we're looking to be isomorphic, generate a front-end template and an API gateway . I say this because often when you're not working in tiny startups, your backend is handled by a different team and is loosely coupled.
Are there any isomorphic frameworks or examples that aren't tightly coupled?
I can't understand how to get a development team starting with something like this to something like a microservices API without a complete/major rewrite or painful decoupling/transition sprint(s). Or am I missing something here?
I think what you're missing is that this is the opposite of having decoupled microservices by design. Their point is no configuration, seems like they're trying out the "monolithic" convention-based architecture with the modularity of react components, etc.
How do you handle sessions and user auth?
This is just a boilerplate, you can add auth on top of it like any other app. Anyway, soon we will add another example which uses auth and handles sessions.
What happened to yeoman? Wasn't it supposed to do exactly this and even more?
does anyone else think the whole LAMP/MEAN... and now MERN is a bit contrived. Why do we need acronyms for everything? Why can't technologies be used independently of one another when they are useful. Why do need to cargo-cult tech trends?!
how does this work with existing tools like webpack? how does this work with es6?
It uses Webpack along with Babel to compile ES6.
Nelly came up with that already.
window.__INITIAL_STATE__ immediately made me think about __VIEWSTATE
demo page seems broken
Looks like some folks have fun with XSS
You keep using that word. I don't think it means what you think it means.
Could I suggest the title is changed to something like "MERN: Build isomorphic JavaScript apps using React and Redux" which is the page title, rather than just the domain which tells us nothing.
Sure.
Edit: I forgot that isomorphic is a trigger word. Took that out.
I don't think isomorphic means what you think it means.
https://en.wikipedia.org/wiki/Linguistic_prescription
vs
https://en.wikipedia.org/wiki/Linguistic_description
You might dislike it but it's become common usage in the js community so by any reasonable non-prescriptive definition of 'means' it 'means' what this author says.
Right! One of my favorite instructors (a computational linguist) in one of my favorite classes (linguistics) always used to say "We as linguists do not prescribe language, we describe language".
I don't think "means" means what you think it means.