JavaScript best practices

> and how templates and code should be kept separate... But then I tried it, and I realized just how wrong I was.

Indeed. In fact, experiments with different configurations have led me to start developing large React applications using a system that organizes applications by components like this:

    src/index.js
    src/ButtonThing/index.js
    src/ButtonThing/view.js
    src/ButtonThing/controller.js
    src/ButtonThing/model.js
    src/FormThing/index.js
    src/FormThing/view.js
    src/FormThing/controller.js
    src/FormThing/model.js

Then, you can simply import these components using something like:

    var FormThing = require('../FormThing');

And you can compose them, with one large component consisting of multiple small ones. For this reason, I've found it useful with large applications to create a separate library of smaller components that are used in multiple larger components, so I don't end up having to hard-code multi-level imports (ie, '../../../MyUsefulComponent').

You'd need to use a slightly different structure with ES6 modules, but the main idea is the same.

If you're using something like Flux to manage data, you can probably skip using the `model.js` modules and simply stick with a `view.js` and `controller.js` (or however you wish to name it).

The way I've done this, all CSS goes into the view.js modules, but you could use a separate style.css in each component.

I've found that this organizational approach works great for large JavaScript applications.

Finally, regarding testing, with React I've finally been able to consistently apply easy command-line unit testing to DOM code without worrying about setting up PhantomJS or JSDom and struggling to get initial tests working. It's made unit testing much, much easier, and I find I'm much more inclined to keep a high level of test coverage maintained with React applications than with previous JS applications I've created. React makes testing very easy (I know AngularJS also is said to offer easy testing, but I've not used it outside of a few small JS applications).

Testing requires a certain level of experience that most JS developers just don't possess yet. My hope is over time a few good talks on the subject bubble up to expose more people to the how/when/why

Here is one such example that shows how to build a kanban board from the ground up (test-first). It's from EmberConf back in March but a lot of the concepts are truly framework agnostic

http://youtu.be/2b1vcg_XSR8

This is a mostly garbage. It doesn't even mention control flow; callbacks, promises.

A big problem with JS is in part its best quality; flexibility. New and old developers need to be shown how JS has evolved to be written. I see massive code-quality and structure discrepancies in various large modules throughout the JS community and it only serves to dissuade contribution.

I'm not sure if it exists, but there should instead be a site dedicated to: "JS, done right."

It could outline actual best practices. - Building, usage of precompilers - Control flow - Code structures - Tests - Everything in between

Usage of precompilers. - Browserify, for modularity - Babel, for next-gen features and code elegance

Control flow - Bluebird, for promises

Tests - What libraries to use - How to build tests and how the big guys do it - Guides for complex tests

Then you could introduce other somewhat subjective deviations, like CoffeeScript, other promise libraries, other control flow techniques.

Describing code structures is another big one. With the use of Babel, the example-code can feature ES6 classes which would remove a nice chunk of the confusion newbs might associate with JS's prototype system (Not to say it shouldn't be introduced).

Then describe when to use each code structure.

My last thought would be to link to Github repos; for example, applications in both node.js and the client, which could describe a standardized filestructure, explain build steps, introduce tests, supply a step by step guide, etc..

Then I might say that if someone makes it through that gauntlet (and everything I missed in between), they might just be a competent JS dev.

> I'm inviting you to level up. It's time.

Appeal to authority noted. You think you know better than csvan, but without any real arguments, you resort to using moral platitudes that you think speak to the crowd.

csvan said "a field which is traditionally male-dominated.". You agreed with this yourself by stating that Software is 80-90% male in your experience. Then he followed up with an opinion, stating "I don't think gender matters at all". This was followed by more opinions about what he thinks people should do.

So we've established that what you consider "flat wrong" is actually more like "Your one fact is correct, but I disagree with your opinion". Let's bask in the sunlight of agreement for just a moment before moving onto the statement that ultimately drew your ire.

   Personally I don't think gender matters at all

I wonder if you'd have gone on this rant if csvan had said "Personally, gender doesn't matter to me at all..." or "Personally, I don't think gender should matter at all..." because I'm 90% positive that the latter is what he meant to convey.

And he's correct. And you agree with him. Gender shouldn't matter at all and people should be valued for their skills instead of their genitalia. Perhaps you would have learned that by having a conversation or thinking about it some more, but you chose to attack instead of giving someone the benefit of the doubt.

So, have a downvote. You deserve it.

Okay, let's start from the top.

  @csvan: This is to be expected from a field which is traditionally male-dominated. 

An attempt to justify why there are zero women listed (despite women making up 10-20%).

  @csvan: Personally I don't think gender matters at all

Sure, you could interpret this either as a statement of not-yet-reached ideal or as a statement of eyes-closed naivity. Considering he opened with a rationalisation, a statement of assumed meritocracy, I chose the interpretation that fit. You chose the other one for some reason, which is fine.

  @csvan: it is great to want to give exposure to minorities, but people 
  should be valued for their skill, not genitalia.

It's a common position, but dropping it into this discussion implies that positive discrimination is required in order to list any women on that page, that there are none who deserve to be there. Again, this chimes with my interpretation of "I don't think gender matters", not yours.

  @WorldWideWayne: And he's correct. And you agree with him. 

The only thing he said that I agree with is that this is a male-dominated field, and even then, he's implying that women are rare enough to have not produced anyone worthy of high profile. Which isn't true.

  @WorldWideWayne: Gender shouldn't matter at all...

Sure, when we get to that world we can have this conversation again. Back in reality, the playing field isn't flat yet so any talk of meritocracy is based on false assumptions.

  @WorldWideWayne: So, have a downvote. You deserve it.

Uh huh. For criticising his comments rather than holding hands in a prayer circle? For using a couple of rhetorical devices?

By your rules I'm pretty sure you should give yourself a downvote.

I wonder if you'd have gone on this rant is I hadn't suggested @csvan "level up". Or maybe it's because you agree with him that we're already in a meritocracy. You've been pretty reticent about your actual opinions.