
JavaScript: The Right Way - gnuwilliam
http://jstherightway.org/
======
manish_gill
Having recently started getting into Javascript, I have to say it is _the_
most confusing ecosystem ever. Learning the basics of the language is easy
enough, but as soon as you start trying to create a non-trivial application,
bam, you're hit with information overload - X framework, Y library. It's
different from Python, Ruby et all because at least with them, there are good
consistent popular choices that you can rely on. With Javascript, more often
than not, I'm left scratching my head as to what I should exactly use.

:/

~~~
TheZenPsycho
There's a lot of choices, and that's not a bad thing necessarily. Javascript
is in a heavy growth period right now. But I totally get the choice overload
thing. There's a lot of people interested in javascript from all different
areas of computer land, and they all have different ideas of what "best" is,
and they all want to make javascript more like lisp, or more like ruby, or
more like java, or more like c# or more like flash, and so on and so forth.

If you just need a choice, somewhere to start. I'll make some choices for you.
Here's the zen selection. My view of the standard javascript library:

jquery ($)

underscore (_)

mustache ({{}}) (possibly accentuated by iCanHaz)

Backbone (Backbone)

And that's your basic starter pack. It's a confused ecosystem because it was
only since about 2007 that people started to realise that javascript was an
actual programming language and not just a stupid toy. I remember that year
chatting with people on #javascript on IRC who simply didn't believe that I
had an actual full time job writing server side javascript. the idea seemed
too absurd. And so here we are, a mere 7 years later and we've pieced together
a very humble ecosystem in the face of that level of bald hatred and
misunderstanding. I remember it wasn't so long ago that flash was in a similar
position, and not long before that, java, with its popular image being its
slow crummy applets.

So, yes, in conclusion, you're right, and it's because it's young and every
language goes through this stage.

~~~
jffry
Backbone may or may not be right for you. Fortunately it's small, and fairly
easy to read. The annotated sources [1][2] for BackBone and Underscore are
fairly accessible.

Also, I would highly recommend adding an AMD loader like require.js to your
"basics kit". Code organization gets very important very fast, and it helps to
think modular-and-reusable from the beginning.

[1]
[http://underscorejs.org/docs/underscore.html](http://underscorejs.org/docs/underscore.html)

[2]
[http://backbonejs.org/docs/backbone.html](http://backbonejs.org/docs/backbone.html)

~~~
SkyMarshal
Plenty of debate these days over whether to use an AMD-based loaders like
require.js [1], or to bundle all your js into a single file with Browserify
[2]. Worth someone new being aware of, but that debate can get rather
complicated.

[1]:[http://requirejs.org/](http://requirejs.org/)

[2]:[http://browserify.org/](http://browserify.org/)

~~~
clavalle
All of you are giving good advice but I just have to chuckle at how quickly
you all proved OPs point.

~~~
georgemcbay
Yeah this is one of the best examples of people proving a point by trying to
disprove it I've ever seen.

"The ecosystem isn't (that) confusing, just use X Y and Z"

\- "No, use X Y and A"

\-- "Who uses Y? Use C"

Myth: confirmed!

~~~
TheZenPsycho
Well, I wasn't trying to say it wasn't confusing. Just trying to reduce the
confusion by picking a starter pack. It doesn't work if everyone else flinches
and decides they have a better starter pack than me!

------
rmason
Nice site but I take exception that backbone is the most popular framework.

While I don't think popularity alone is how you should chose a framework. It
appears that AngularJS tops all except jQuery at this time.

[http://www.google.com/trends/explore#q=angularjs%2C%20backbo...](http://www.google.com/trends/explore#q=angularjs%2C%20backbone.js%2C%20emberjs%2C%20knockoutjs&cmpt=q)

~~~
gojomo
That might be a 'confusionRank' moreso than a 'usageRank'!

------
mcgwiz
Given that the greatest challenge to JavaScript testing is the browser
environment, it'd be worthwhile to mention Zombie.js (simulated DOM) and
PhantomJS/CasperJS (V8). Code organization is also important for any large
codebases, which is often addressed with browserify or RequireJS.

------
shangxiao
Nice, I like what you're trying to do, but things like

"Backbone.js: The most popular JS client-site framework"

worry me. Most people I talk to avoid Backbone nowdays in favour of the other
popular frameworks.

Also: some descriptions appear to be lacking/missing & you definitely should
mention Grunt under "Helpers". At least it's a GH repo and I assume you'll
accept PR's? ;)

~~~
joepour
What are the reasons these people cite for not using Backbone?

~~~
acjohnson55
As someone who lives and breathes Backbone at the moment, I think its biggest
problem is that the framework itself provides not nearly enough guidance to
write maintainable and testable code, nor does its documentation. It's not
nearly clear how to start your app in a sensible way, where to put stateful
non-view, non-model logic, and how the pieces should all communicate. So, you
start cobbling your Backbone app together, making architectural decisions as
best you can, and then months later, you realize you've created an
unmaintainable mess. I've had this experience coming into two large projects
so far.

I'm sure everyone's second Backbone app looks a lot better than their first,
but it's still an underdesigned framework, IMO. I think Marionette does a lot
of good in terms of adding those missing structures and best practices,
though. And I'm also intrigued by the idea of replacing views with React
components.

------
exodust
Is there a "too clever" mentality in frontend web dev culture of late? An
overly fragmented workflow toolset?

Not sure the cause, perhaps the influx of engineering "computer science
disciplined" brains into the frontend world. Or a panicked competitive race to
achieve a nirvana dev environment. Or a tendency to think that workflows for
large websites with countless modules is the best workflow for a one-page web
app.

Overkill for the intended task, or cluttering your project with too much
technology, is the thing to watch out for in the frontend aspect.

Layers of tools and libraries and plugins can easily get out of control and
beyond a joke. Don't forget you've got a web app to build while you mess
around with the "right way" to build it.

You do not need a cup-holder on your scaffolding.

Just using plain JS with Jquery, and perhaps some additional smaller specific
plugins/libraires, is enough to do a lot of cool stuff if we're talking
"javascript" projects. Then just get a good editor and off you go.

~~~
marknutter
> Just using plain JS with Jquery, and perhaps some additional smaller
> specific plugins/libraires, is enough to do a lot of cool stuff if we're
> talking "javascript" projects. Then just get a good editor and off you go.

These new tools and frameworks are becoming numerous and popular precisely
because for large, complicated front-end applications you can't just get away
with using "plain JS with Jquery" without it becoming an unmaintainable mess
and writing boilerplate DOM manipulation code all over the place. The only
people I meet who have an aversion to these modern JS frameworks are front-end
devs who refuse to learn them or server-side devs who hate javascript.

~~~
Silhouette
_These new tools and frameworks are becoming numerous and popular precisely
because for large, complicated front-end applications you can 't just get away
with using "plain JS with Jquery" without it becoming an unmaintainable mess
and writing boilerplate DOM manipulation code all over the place._

That's a rather negative view, and I don't think it's entirely realistic. I am
involved with multiple long-running web projects that have been using things
like (real) MVC architectures and single-page applications since long before
any of these trendy JS frameworks existed. The projects have been built using
sound software development principles and usually a small number of carefully
chosen supporting tools and libraries. They are still doing their jobs just
fine, and they have stood the test of time in terms of maintainability.

 _The only people I meet who have an aversion to these modern JS frameworks
are front-end devs who refuse to learn them or server-side devs who hate
javascript._

Please consider that there is at least one more option, which I imagine
applies to many of the older readers here. Some of us have seen before the
rapid evolution of an ecosystem as a programming language takes off, and we
simply don't buy the hype.

We saw the arrival of Java, with all its garbage collected wonder. Then we saw
the nightmarish descent into over-engineered hell that followed.

We saw the arrival of Boost for C++ and the potential of community-developed,
peer-reviewed libraries. Then we noticed that in 2014, C++ still doesn't even
have basic features for working with filesystems or rendering a simple UI as
standard.

We saw the evolution of very dynamic "scripting" languages like Python and
Ruby into widely used server-side languages for real applications. Then we saw
people trying to maintain those applications a few years later, when they
weren't prototypes any more and when quality and performance mattered.

More recently, we've seen front-end web development shift toward JavaScript
and move away from the likes of ActiveX controls, Flash plug-ins and Java
applets, as language support became more consistent across browsers and some
real effort went into improving performance. Today we are also seeing the
inevitable explosion of the surrounding ecosystem as JS becomes a tool for
building more heavyweight software, signalled by the arrival of vast numbers
of different automation tools and libraries and frameworks.

But with the cynicism of the industry veteran, we also see that many of these
new tools will do 80% of a job easily but make the last 20% much more painful.
We know that some are merely short cuts aimed at people who now work in front-
end development but whose backgrounds aren't necessarily in programming and
who haven't yet developed their general software development skills in that
way; there's nothing wrong with that, of course, but such tools have no (or
negative) value to those who have moved beyond the level where they are
helpful. Most of all, we know that five years from now, as the ecosystem
evolves standards and consolidates, it is highly unlikely that most of the
currently trendy tools will still be as effective and well maintained as they
are today, but that like the five-year-old projects some of us work with
today, someone will still have to maintain those projects after all the
hypesters have moved on.

This doesn't mean that we somehow refuse to learn new technologies. It just
means that if I can see what looks like a fire, and it feels as warm as I
expect when I get close enough to examine it, I'm not still going to jump in
for a few minutes just to see if it's really as hot as it looks because I read
on a web site somewhere that all the cool kids were doing it.

Now get off my lawn. :-)

~~~
marknutter
> We know that some are merely short cuts aimed at people who now work in
> front-end development but whose backgrounds aren't necessarily in
> programming and who haven't yet developed their general software development
> skills in that way; there's nothing wrong with that, of course, but such
> tools have no (or negative) value to those who have moved beyond the level
> where they are helpful.

No, they are aimed at people who have worked in front-end development for a
long time and whose backgrounds are in programming precisely because they are
sick of reinventing the wheel every time they start a new project and are able
to understand the technical value behind concepts modern frameworks give us
like dependency injection, unit/e2e testing, modularity, and separation of
concerns. The myth that front-end developers are not "necessarily from a
programming background" is poisonous thinking and it unfortunately usually
comes from older programmers or non-front-end developers; the very people who
could help guide the front-end world into maturity.

~~~
Silhouette
_sick of reinventing the wheel every time they start a new project and are
able to understand the technical value behind concepts modern frameworks give
us like dependency injection, unit /e2e testing, modularity, and separation of
concerns._

You write as if we didn't understand the technical value of those things
before a couple of years ago when the current crop of JS frameworks arrived,
and as if using one of those frameworks is somehow necessary to achieve them.

In reality, everything you mentioned has been widespread in other software
development fields for _decades_. It's stuff the junior guy on the team learns
in his first few months.

Moreover, I think there is a reasonable argument that of your chosen examples,
testing is the only one that has sufficiently common requirements for building
large but general tools to be worthwhile. The other design principles are
valuable, but how best to use them will be highly project-specific, and
therefore any widely useful framework will tend to be over-engineered and
over-generalised for most applications. See also the Java nightmare I
mentioned previously, the trend toward lightweight frameworks on the server
side, etc.

Edited to add:

 _The myth that front-end developers are not "necessarily from a programming
background" is poisonous thinking and it unfortunately usually comes from
older programmers or non-front-end developers; the very people who could help
guide the front-end world into maturity._

There _is_ a difficulty in the industry that significant numbers of people are
coming into this kind of front-end development from some sort of HTML/CSS
and/or design background. They used to use a bit of JS here and there that
they copied off a demo site to get their buttons to animate, and now they're
being asked to move into more of a mainstream programming role, but neither
they nor the people asking them necessarily appreciate what that involves.

That's not anyone's fault. It will be fixed over time as the industry matures,
both because knowledge will spread and because more specialised roles than
"front end developer" will probably evolve. But right now, today, it _is_ the
situation in large parts of the industry.

------
harlanlewis
Good resource, nicely presented.

"We recommend you whenever possible to verify you code style with a Lint
tool."

That's not all they need a Lint tool for!

~~~
gnuwilliam
Thanks for the feedback! We'll improve that. :)

------
gnuwilliam
Hey guys!

I see there's a lot of great suggestions and critics here!

Since it's an open source project, you can feel free to open a pull request
telling which resource you think it's better to be there, or which one should
be removed. As well help me correct the grammar errors. I'm from Brazil, and
my english is not that good.

I'm really glad about all the opinions, and for sure the site will be improved
from now on.

Thanks!

~~~
ericdahl
How does this website relate to this repo [1]? I was going to contribute some
fixes to the page, but when I cloned the repo, I found significantly different
content. I'm also confused as to why the website [2] says that it is based on
itself [2] at the bottom of the page.

[1] [https://github.com/braziljs/js-the-right-
way](https://github.com/braziljs/js-the-right-way) [2] "Based on a work at
[http://jstherightway.org"](http://jstherightway.org")

------
meritt
Some additional comprehensive JS resources:

[http://eloquentjavascript.net/](http://eloquentjavascript.net/)

[http://shichuan.github.io/javascript-
patterns/](http://shichuan.github.io/javascript-patterns/)

[https://github.com/airbnb/javascript](https://github.com/airbnb/javascript)

~~~
sehr
Dont forget:

[http://addyosmani.com/resources/essentialjsdesignpatterns/bo...](http://addyosmani.com/resources/essentialjsdesignpatterns/book/)

~~~
meritt
Thanks this one is awesome, I had never seen it before.

------
jkleiser
I would have expected to find React
([http://facebook.github.io/react/](http://facebook.github.io/react/)) among
the frameworks.

------
usablebytes
Excellent work there. I always wanted to work on such a public collection but
kudos to these guys on making it a reality. I've used/read-about/tried-out
most of the stuff listed there and appreciate the hardwork that has gone into
putting all of it together.

I think Polymer (Google) and Brick (Mozilla) deserves a mention there as Web
Components have a very high possibility of becoming the ultimate way for the
future of web development.

------
NigelTufnel
I occasionally code in Javascript and I always get the feeling that I'm
working with a language without a decent built-in standard library.

Want to work with dates? Use a third party library (or use built-in 1995-style
library). Want to format a string? Use a third-party library. Want to do X?
Use a third-party library.

Coding in e.g Python feels completely different: almost everything I need is
in the standard library.

------
citrin_ru
It funny, but clicking to this link caused high CPU usage for N seconds and
message from Firefox:

A script on this page may be busy, or it may have stopped responding. You can
stop the script now, or you can continue to see if the script will complete.

Script:
[http://jstherightway.org/js/jquery.js:1144](http://jstherightway.org/js/jquery.js:1144)

~~~
rhizome31
Same here. Probably one of those modern web sites optimized for Google Chrome.

------
jasonkostempski
This is JavaScript: The Infinitely Many Ways. Shouldn't the right way remove
at least a few options from the table?

I've found a sweet spot for myself, at least for single page apps which is
what I work on most of the time. jQuery, Require.js, text.js and JSLint. r.js
for building release versions. Those, along with a small "view" class I wrote
whose constructor takes an html string, finds all elements with a data-vid
attribute and adds properties to itself pointing at those elements. Markup is
kept in bite-size html files, loaded by require during development but
compiled into the single js file for release. Also, I can't remember the last
time I used a jQuery selector.

------
garaboncias
Strange that it's just refer several times but not list jQuery as a framework
but did with Zepto.

It's not mention lodash / underscore which is very elementary if you want to
avoid reinvent the wheel.

------
EvanYou
Karma's author is not Isaac Durazo - he is the logo designer. Karma is written
by the team behind Angular (mostly by Vojta Jina).

~~~
gnuwilliam
Fixed! Thanks. :)

------
tchaffee
The command pattern is featured in the article. Why would you use that pattern
in a language that supports first-class functions?

~~~
Millennium
For tasks that are created, executed, and processed purely in code, you
wouldn't. But it still has uses in other areas, especially when you need to
build something up from user input.

~~~
tchaffee
Could you give a concrete example? Why wouldn't you be able to use first-class
functions when building something up from user input? How about giving us a
code snippet? The consensus in the CS community is that the command pattern
disappears (becomes overkill) for languages with first-class functions. This
has been noted as early as 1998 by Norvig when comparing C++ to Lisp. It's one
of my criticisms of Addy's JS Patterns book. He just blindly copies the GoF
patterns and many of them are not needed in languages with modern features.

------
novaleaf
I started web development 8 months ago. First I started by reading "The good
parts" but honestly it's not really a good book to learn from 0 with.

The thing that really got me going? Typescript. Not only does it help with
abstracting javascript syntax, but the intelisence made me not have to google
every 20 characters i write.

------
_mhr_
What I've never understood is how to effectively use both objects and
functions in a multi-paradigm language like JavaScript. Most introductions to
JavaScript explain how to use functions in their own section and explain how
to use objects in their own section, but they never explain how to combine the
two techniques.

------
outworlder
> "Different from C, C# and Java, JavaScript is an interpreted language. It
> means that it needs an "interpreter"."

I have an issue with the above statement. There are no compiled or interpreted
"languages". There are only implementations.

There's nothing preventing someone from "compiling" it.

~~~
Pacabel
The distinction can very much exist in practice, depending on the existence
and capabilities of production-quality implementations.

While there have been attempts to compile a language like Python down to
native code, they are still very limited and not useful in a practical sense.
Hence, Python is a de facto interpreted language, since its usable
implementations are implemented as interpreters.

The same goes for JavaScript today. Given that all of the usable
implementations are interpreters, JavaScript can currently be considered an
interpreted language.

~~~
magicalist
> _The same goes for JavaScript today. Given that all of the usable
> implementations are interpreters, JavaScript can currently be considered an
> interpreted language._

This hasn't been true for quite some time. SpiderMonkey and JavaScriptCore do
include interpreters, but only use them while code is first running. If a
function gets hot, they then JIT compile the code. V8 has no interpreter at
all, only JIT compilers (and is certainly usable and in wide use). And finally
SpiderMonkey even just added an AOT compiler for compliant asm.js code (which,
while a subset, is indeed valid JS code).

------
semerda
Nice site. Cheers for sharing!

JavaScript Patterns by Stoyan Stefanov (made the list under reading/books) is
a must for anyone wanting to learn JavaScript the right way. The content
volume is just right with great examples. Can be read in a week easily and get
you rolling writing better code fast!

------
frik
found a dead link in the article:
[http://killdream.github.io/2011/10/09/understanding-
javascri...](http://killdream.github.io/2011/10/09/understanding-javascript-
oop.html)

------
j_s
It would be nice to see the browser versions supported by all these projects
in one place... this simplifies the process of elimination for those who have
to support older browsers.

------
CmonDev
"JavaScript has strong object-oriented programming capabilities"

What would be an example of a language with weaker OOP capabilities?

PS: "The bad parts" section did not fit the page?

~~~
boomlinde

        > What would be an example of a language with weaker OOP capabilities?

Something without the concept of objects built in? C?

~~~
CmonDev
That's absent OOP capabilities.

~~~
boomlinde
No, C is perfectly capable of OOP. I can't think of a general purpose language
that inherently isn't.

------
elwell
Should add jashkenas [0] to "WHO TO FOLLOW".

0 - [http://github.com/jashkenas](http://github.com/jashkenas)

------
nazka
A similar website posted on HN. Very well done.

[http://superherojs.com/](http://superherojs.com/)

------
Torn
Nice collection of resources on a single page.

There's a fair amount of typo's and grammar mistakes however.

------
smenko
For something containing "the right way" in the heading, this has awful
grammar.

------
macco
Besides the questionable choice of framework. Does this guide make sense?

What would you remove or add?

~~~
tipiirai
How about [https://moot.it/riotjs/](https://moot.it/riotjs/) ?

~~~
aaronem
Yep, that's a questionable choice of framework, all right.

------
revskill
Javascript is the bare tool, in order to build abstraction, you need science,
i mean something like algorithmic way in rendering view with framework like
React framwork, it makes sense because it makes all developer around it thinks
in the same way. It's the right way to do all successful thing.

------
stevewilhelm
Wow, no mention of Ember.js (we switched from Ember to Backbone last fall).

~~~
bstamour
It was mentioned in a section about frameworks:
[http://jstherightway.org/#frameworks](http://jstherightway.org/#frameworks)

------
LordQuas3000
Thank you very much for posting this, very useful.

------
pingsifu
I am not too fond of the styling. Looking at it on my desktop PC, the page
could use some left/right margin. On my iPhone on the other hand its rather
unreadable.

~~~
sehr
Fork it and add your own styling?

------
Lauricio
no meteor?

