
JavaScript best practices - arash_milani
http://jstherightway.org/
======
TheAceOfHearts
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.

~~~
jdlshore
> 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](http://www.letscodejavascript.com) . It's
been going for three years and has tons of content on this subject.

------
haberman
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](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.

~~~
nchelluri
I recently read this article, which is a nice primer:
[https://www.airpair.com/javascript/posts/the-mind-
boggling-u...](https://www.airpair.com/javascript/posts/the-mind-boggling-
universe-of-javascript-modules)

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.

------
yeskia
Was hoping this would be similar to PHP: The Right Way
([http://www.phptherightway.com/](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.

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

------
omgtehlion
Loads of bullshit if you ask me.

e.g. "Singleton pattern in JS": var x = {}, that’s enough, folks, do not write
pages of code when all you need is just one line.

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

------
csvan
Not sure why hoisting is listed under "the good parts"

~~~
Rapzid
My recent experience of doing quite a bit of JS/coffee script at a new place
is that scope is the topic of conversation far too often.. :|

------
moopsy
TL;DR just read this book
[http://addyosmani.com/resources/essentialjsdesignpatterns/bo...](http://addyosmani.com/resources/essentialjsdesignpatterns/book/)

------
erokar
JS isn't Java. It usually doesn't need the design patterns of more brittle OOP
languages.

------
threatofrain
Aren't there way too many options for something advertised to a beginner?
Shouldn't one dare to have a pedagogical opinion and so curate?

------
github-cat
It's a good guideline for JavaScript developers though there are more to be
added.

------
mandeepj
Great content and organization but awful layout and design. Sorry for being
negative.

