JavaScript best practices(jstherightway.org)
jstherightway.org
JavaScript best practices
http://jstherightway.org/
13 comments
> 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.
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.
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.
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:
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).
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
var FormThing = require('../FormThing');
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
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 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.
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 recently read this article, which is a nice primer: 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.
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.
[deleted]
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.
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.
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.
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.
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.
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.
TL;DR just read this book http://addyosmani.com/resources/essentialjsdesignpatterns/bo...
JS isn't Java. It usually doesn't need the design patterns of more brittle OOP languages.
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?
It's a good guideline for JavaScript developers though there are more to be added.
Great content and organization but awful layout and design. Sorry for being negative.
paulcole(4)
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.