Glancing at this, it has some clearly outdated information... And it has a lot of links but I don't see a lot of meaty information. It's very shallow.
JS best practices are questionable at best. As an example, when React came out everyone was saying how much of a terrible idea it was (with me being one of those people, unfortunately), and how templates and code should be kept separate... But then I tried it, and I realized just how wrong I was. It makes a lot of sense to keep related things together. Your component's logic / template can be in one place, and your application logic is kept elsewhere.
I read a lot about JS, and I get the impression a lot of people are just hacking together websites with JS sprinkled on top, or hackathon-style apps that they don't plan on maintaining for longer that a few weeks. So their "best practices" end up being questionable at best. Basically, who are you to claim that whatever you're doing is a "best practice"? It seems like a pretty bold claim, so I'd argue that it's not unreasonable to expect someone to back up their claims.
As a side-note, why don't people ever talk about testing? And not just linking to some tools, but actually talking about how you figure out what things are worth testing, and how you test em.
> As a side-note, why don't people ever talk about testing? And not just linking to some tools, but actually talking about how you figure out what things are worth testing, and how you test em.
I have a screencast on this subject at http://www.letscodejavascript.com . It's been going for three years and has tons of content on this subject.
> So their "best practices" end up being questionable at
> best. Basically, who are you to claim that whatever
> you're doing is a "best practice"? It seems like a pretty
> bold claim, so I'd argue that it's not unreasonable to
> expect someone to back up their claims.
This is why IMHO the best advice comes with a list of pros and cons. It tells me that the author has thought deeply enough about the subject to understand not only the solution, but the contexts where the solution isn't a good fit. (Two books that spring to mind that do this: Patterns of Enterprise Applications by Fowler, and Design Patterns by Gemma et al.)
On the subject of testing, I think it's important that people don't follow testing methodologies blindly.
In the 1960s, Djikstra said "Testing shows the presence, not the absence of bugs", which is true.
Testing is a good tool to prevent regressions. A form of testing that I find quite interesting - and wish more people would look into - is property based testing. A good example of this can be found here http://fsharpforfunandprofit.com/pbt/. Scott Wlaschin is also quite good at teaching across coding paradigms, not just functional.
> 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:
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
This is great, but what I think is sorely needed is a roadmap to navigating the maze of module systems, transpilers, preprocessors, packagers, etc.
Why do npm and bower both exist? What is the difference between UglifyJS and Closure Compiler? Do I want WebPack or Browserify? Should I use these standalone or should I use them together with Gulp, Grunt, or another build tool? Which of the hundreds or thousands of plugins for the build tools should I use (Gulp has 1,532 plugins and Grunt has 4,403!!)? Should I use CommonJS, ES6 modules, AMD, UMD, or something else? Don't even get me started on application-level frameworks like React, Angular, Ember, etc.
I have reasonably good answers to these questions in my head right now, but three days ago I had no clue. And it really is a maze, because while all of these projects have flashy web pages and nifty "getting started" guides, their docs rarely explain the role of their tool in the big picture, and its relationship to other tools, they just give you examples and point to recipes. And there aren't a set of best practices for setting up a project that cover 99% of common needs painlessly -- you really have to get your hands dirty and configure the tools, in my experience.
I mean, take a step back and writing JavaScript in 2015 is pretty weird. Writing JavaScript in Node.js involves writing things like require() that the browser doesn't understand at all. So you have to run code like that through a tool before you can use it in a browser at all. But what tool exactly? There are so many to choose from, all of which have their own way of being configured. To write JavaScript in 2015, you basically have to sit down and choose a language dialect design a compiler pipeline to match.
I mean, just look at the Babel "setup" guide and how many different variations there are in the instructions based on what tools/frameworks you are using! https://babeljs.io/docs/setup/#make
The point of all this isn't to criticize, but more to offer my experience of being extremely confused/overwhelmed.
Hopefully a lot of this will get better once ES6 is ubiquitous.
I would not say that it answers all of your questions, but I thought it was nice. I guess the short answer for me was CommonJS and thus Browserify on the front-end.
Note: I'm not a JS expert, but at work we have a number of repos written in JS, both "back-end" Node.js projects, and "front-end" JS and a Chrome extension (also JS). I know for a fact that I don't know what I'm doing (I am not going to take the time to learn about CommonJS, AMD, UMD, "Interop", etc., and I've just learned the basics of ES5 and am not eager to rush into ES6 or Babel) and when I find myself in such cases I like to take the simplest approach that seems to work.
Was hoping this would be similar to PHP: The Right Way (http://www.phptherightway.com/) where everything you need to know is on the one page with links for more information available, rather than just links to other sites.
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.
Whoever made this page: have you actually tried to use it?
I'm confident that all of this could fit neatly on 3 or 4 vertical scrolls (not 20+ as it stands currently)... Without making any compromise to readability, without the rainbow zebra bands.
This is to be expected from a field which is traditionally male-dominated. Personally I don't think gender matters at all - it is great to want to give exposure to minorities, but people should be valued for their skill, not genitalia.
With respect, you're flat wrong here. The consequences of this kind of thing are serious for our industry.
This is to be expected...
Software isn't a 100% male field; maybe 80-90% in my experience. That means:
(a) This list is missing great people, e.g. @ErisDS who was the lead engineer (now CTO) for the Ghost blogging platform
(b) This list is thoughtlessly unsupportive of the minority 10-20% in terms of role models. What's the effect of women being constantly portrayed as an underclass of developer by the lack of profile given to successful female devs?
Personally I don't think gender matters at all
That's exactly what someone who hasn't experienced any gender-related workplace problems would think.
This utopian finger-in-ears attitude ignores the reality of the harrassment and the systemic uphill battle female devs face in terms of diminishing remarks ("Oh, you must be the designer") and community bias (events typically provide beer & pizza & mens t-shirts).
It's okay, you may not know about all this stuff, or have thought about it from that perspective.
I'm surprised that you thought your off-topic trolling was saying anything well, but berating someone based on bad assumptions made from 2 sentences is certainly not saying it any better.
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.
@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.
> An attempt to justify why there are zero women listed (despite women making up 10-20%).
You're arguing against a strawman with statistics that you yourself said that you only have anecdotal evidence for. Saying what one expects is vastly different than saying that something is justified.
According to you, men are horrible jerks to women in this industry, so why then would you expect those men to honor women by listing them as people to follow? It doesn't make any sense.
> Sure, you could interpret this either as...
You didn't even try try asking what he meant. Instead you went with the full-on attack. You're setting a great example for the world of tolerant and open-mindedness that you're allegedly arguing for.
> Back in reality, the playing field isn't flat yet so any talk of meritocracy is based on false assumptions.
How will you possibly know if any one person is already in the proper mindset if you attack them when they say things that you actually agree with like "Gender shouldn't matter at all..."? No, you're right. Shoot first and sort them out later.
> Uh huh. For criticising his comments rather than holding hands in a prayer circle?
There you go again. You're arguing against your own assumptions. I downvoted you for your unwarranted vitriol, end of story. Have a nice day!
I downvoted you for your unwarranted vitriol, end of story.
Please point out anywhere I was cruel, or criticised @csvan as a person, rather than the maturity of the ideas he expressed. @csvan hasn't replied yet but I'm happy to apologise to him if he felt any of my criticism was directed at him rather than the ideas he expressed.
Maybe (correct me if I'm wrong) you saw the "level up" comment as a personal criticism. Well my intention with that comment was to include @csvan and make it clear that he could let go of that opinion and grow. It wasn't vitriol at all.
As for the rest of your comments, I honestly don't know if you're trolling me or not. You complain about me using straw men to attack @csvan, then use straw men to attack me ("According to you, men are horrible jerks to women in this industry"). You complain about me not providing data, then provide none yourself. You complain about me not giving @csvan a chance to explain himself then downvote me without engaging in a conversation yourself.
What do you see as the root cause of this disagreement?
The root cause of my responses is your attitude. You berated this person for no good reason after reading two sentences of what they had to say. Regardless of what you think about how I'm responding to this, I wish you would just acknowledge that simple fact.
Telling someone that they are sticking their fingers in their ear (strongly implying that they're acting like a child) and then telling them to "level up" clearly conveys vitriol. It's just a bullshit, reactionary, polarizing and inflammatory statement to make. You say that you want everybody to respect each other, but then you do that. I don't think I can spell it out any more clearly.
(Also, when I said "According to you, men are horrible jerks" I was referring to your view of the "utopian finger-in-ears attitude [which] ignores the reality of the harrassment and the systemic uphill battle female devs face". Clearly one can say that you think industry men are horrible jerks without creating a strawman. It's a misunderstanding, I didn't quote you out of laziness. There's a fine line between a misunderstanding and a strawman, but it's there. Why don't we just chalk this whole exchange up as a misunderstanding?)
You're hot on the subject of women's rights. I get it. But I'm glad that paulcole's original question that started the whole sub-thread got many downvotes here because my own opinion is that I'm sick of hearing about women's plight in the first world. Give me a fraking break. This is a post about Javascript. Let's talk about that and if the alleged 10-20% of women in the industry decides to join in to talk about the actual fraking topic, let's not make a big deal about it.
Telling someone that they are sticking their fingers in their ear
(strongly implying that they're acting like a child) and then
telling them to "level up" clearly conveys vitriol.
I think @csvan shared an immature opinion, and I'm happy to stand by that.
It's not a personal attack. Everyone has shared immature or half-informed opinions; it's a human thing to do. Do I think @csvan is a bad person? I sincerely doubt it.
Vitriol means "bitterness or cruelty". Why do you think it vitriolic for me to treat @csvan's comments as immature?
He made his comments because he considers himself a good guy, defending meritocracy. I'm making my comments because there's plenty of evidence of flawed assumptions rotting away underneath that meritocracy. I'm not angry with him, or bitter, and I don't want to hurt his feelings. All I want to do is change his mind, and whoever else reads this thread. Yours too.
This is a post about Javascript. Let's talk about that...
No, this is a post about "JS The Right Way" and all it entails, authors, visual design, and content, including the list of people to follow. Stop deflecting.
...my own opinion is that I'm sick of hearing about women's plight in the first world.
The "first world" comment is red herring; just because a baby dies or a bomb goes off in some distant country doesn't mean we should ignore lesser problems closer to home. That leaves you being "sick of hearing about women's plight". If you were just bored of hearing about it you'd just stop listening, so this is something else.
Am I wrong? Does hearing about the tech industry being inhospitable to women make you angry? If so, why?
I had the displeasure of reading most of what you wrote and am writing this to convince you of something:
Please stop. Your SJW politics is off topic and in my opinion; utterly trivial nonsense. You were out-argued and still you found it in yourself to write more damage control comments.
I'm certain the reason people on HN don't call you out on this more often is the latent fear of being shadowbanned due to political correctness.
You made this your personal little soapbox and your posts reek of entitlement. Stop.
I disagree. If you'd like to explain how you believe that, I'm happy to listen, but my guess is that since you're using 'SJW' as a snarl-word you've read this entire thread through the filter of confirmation bias.
Your SJW politics is off topic...
Explain how. The topic is the page linked to (with a nudge towards what might be of interest to hackers), not just one aspect of the page, but the entire page... author, design, and content including the list of who to follow.
It's your choice whether you want to narrow your conversation to just the programming language aspects of that page, but I don't see how you justifiably claim I'm off-topic.
JS best practices are questionable at best. As an example, when React came out everyone was saying how much of a terrible idea it was (with me being one of those people, unfortunately), and how templates and code should be kept separate... But then I tried it, and I realized just how wrong I was. It makes a lot of sense to keep related things together. Your component's logic / template can be in one place, and your application logic is kept elsewhere.
I read a lot about JS, and I get the impression a lot of people are just hacking together websites with JS sprinkled on top, or hackathon-style apps that they don't plan on maintaining for longer that a few weeks. So their "best practices" end up being questionable at best. Basically, who are you to claim that whatever you're doing is a "best practice"? It seems like a pretty bold claim, so I'd argue that it's not unreasonable to expect someone to back up their claims.
As a side-note, why don't people ever talk about testing? And not just linking to some tools, but actually talking about how you figure out what things are worth testing, and how you test em.