7 ms·

JavaScript best practices

93 points by arash_milani 11y ago

csvan 11y ago
Not sure why hoisting is listed under "the good parts"
- Rapzid 11y ago
  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.. :|
- s986s 11y ago
  I was thinking the same thing about loose typing
yeskia 11y ago
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.
paulcole 11y ago
Lots of dudes on the Who to Follow section? Anyone have any female JS experts to recommend?
- csvan 11y ago
  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.
  - TheAceOfHearts 11y ago
    Heck, I've been following @sebmck for months, and I just thought he was a cat for the longest time...
  - richmarr 11y ago
    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 inviting you to level up. It's time.
    - paulcole 11y ago
      Thanks, you said this about a million times better than I did.
      - richmarr 11y ago
        Thanks. Although it seems I didn't say it well enough :/
      - WorldWideWayne 11y ago
        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.
    - WorldWideWayne 11y ago
      > 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.
- tigroferoce 11y ago
  Not sure if she can be considered a "JS expert", but a good starting point could be Angelina Fabbro
- JeffKilborn 11y ago
  >Anyone have any female JS experts to recommend? Why would you care about the sex of someone? To stalk them or something?
- akbar501 11y ago
  Pamela Fox https://twitter.com/pamelafox https://twitter.com/pamelafox
  - paulcole 11y ago
    Thanks!
omgtehlion 11y ago
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 11y ago
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.
mandeepj 11y ago
Great content and organization but awful layout and design. Sorry for being negative.
moopsy 11y ago
TL;DR just read this book http://addyosmani.com/resources/essentialjsdesignpatterns/book/ http://addyosmani.com/resources/essentialjsdesignpatterns/bo...
haberman 11y ago
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 11y ago
  I recently read this article, which is a nice primer: https://www.airpair.com/javascript/posts/the-mind-boggling-universe-of-javascript-modules https://www.airpair.com/javascript/posts/the-mind-boggling-u... 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.
erokar 11y ago
JS isn't Java. It usually doesn't need the design patterns of more brittle OOP languages.
TheAceOfHearts 11y ago
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.
- eric_bullington 11y ago
  > 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).
github-cat 11y ago
It's a good guideline for JavaScript developers though there are more to be added.
threatofrain 11y ago
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?
babby 11y ago
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.

93 points by arash_milani 11y ago

csvan 11y ago

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

Rapzid 11y ago
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.. :|
s986s 11y ago
I was thinking the same thing about loose typing

yeskia 11y ago

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.

paulcole 11y ago

Lots of dudes on the Who to Follow section? Anyone have any female JS experts to recommend?

csvan 11y ago
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.
- TheAceOfHearts 11y ago
  Heck, I've been following @sebmck for months, and I just thought he was a cat for the longest time...
- richmarr 11y ago
  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 inviting you to level up. It's time.
  - paulcole 11y ago
    Thanks, you said this about a million times better than I did.
    - richmarr 11y ago
      Thanks. Although it seems I didn't say it well enough :/
    - WorldWideWayne 11y ago
      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.
  - WorldWideWayne 11y ago
    > 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.
tigroferoce 11y ago
Not sure if she can be considered a "JS expert", but a good starting point could be Angelina Fabbro
JeffKilborn 11y ago
>Anyone have any female JS experts to recommend? Why would you care about the sex of someone? To stalk them or something?
akbar501 11y ago
Pamela Fox https://twitter.com/pamelafox https://twitter.com/pamelafox
- paulcole 11y ago
  Thanks!

omgtehlion 11y ago

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 11y ago

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.

mandeepj 11y ago

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

moopsy 11y ago

TL;DR just read this book http://addyosmani.com/resources/essentialjsdesignpatterns/book/ http://addyosmani.com/resources/essentialjsdesignpatterns/bo...

haberman 11y ago

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 11y ago
I recently read this article, which is a nice primer: https://www.airpair.com/javascript/posts/the-mind-boggling-universe-of-javascript-modules https://www.airpair.com/javascript/posts/the-mind-boggling-u... 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.

erokar 11y ago

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

TheAceOfHearts 11y ago

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.

eric_bullington 11y ago
> 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).

github-cat 11y ago

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

threatofrain 11y ago

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?

babby 11y ago

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.