Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mern: Build JavaScript apps using React and Redux

mern.io

Post reply on HN
Print view View original

111–120 of 141 posts

Re: Mern: Build JavaScript apps using React and Redux

#111

Post by Kiro »

joepie91_ wrote: post #99
Kiro wrote: post #19

Earlier quoted context omitted.

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…

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.

Re: Mern: Build JavaScript apps using React and Redux

#112

Post by dang »

nnq wrote: post #89
meow_mix wrote: post #76

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 m…

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…

> Wake up.

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

Re: Mern: Build JavaScript apps using React and Redux

#114

Post by dang »

ascorbic wrote: post #45

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.

Re: Mern: Build JavaScript apps using React and Redux

#115

Post by dang »

omk wrote: post #71
Stamy wrote: post #62

Earlier quoted context omitted.

I don't see the reason why would you apologise for your english when you use the words like 'Exeunt' ... Otherwise good joke.

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.

Re: Mern: Build JavaScript apps using React and Redux

#116

Post by jamespitts »

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!

https://en.wikipedia.org/wiki/Dodge_City_(1939_film)

Re: Mern: Build JavaScript apps using React and Redux

#117

Post by visarga »

jamespitts wrote: post #116

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 involve…

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.

Re: Mern: Build JavaScript apps using React and Redux

#118

Post by dsp1234 »

mbrock wrote: post #29
tomelders wrote: post #24

Earlier quoted context omitted.

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

Re: Mern: Build JavaScript apps using React and Redux

#119

Post by tonyarkles »

webcc wrote: post #107
pc86 wrote: post #61

Earlier quoted context omitted.

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!

Re: Mern: Build JavaScript apps using React and Redux

#120

Post by EvanPlaice »

StavrosK wrote: post #44
EvanPlaice wrote: post #37

Earlier quoted context omitted.

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 sho…

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?

Post reply on HN