Javascript the right way(jstherightway.com)
jstherightway.com
Javascript the right way
http://jstherightway.com/
8 comments
Looks more like JS the java way. Singletons make no sense in a language that has global variables and never lets you stop an object from being duplicated. The command pattern makes no sense in a language with first-class functions. I'd steer clear of this resource if you want to write javascript the right way.
I somewhat agree with your points.
You can't just explain every single design pattern available in any given language and then say, you now know how to write that language "The right way!".
Thats the feeling I got from this, it just goes into way too much detail about way too many things, and forgets to start with the basics, which is all you need to know to write JavaScript the right way.
How can you write any language the right way without knowing the basics?
This book could be an absolute disaster in the hands of people who don't know any better.
+1 for steering clear of this resource.
You can't just explain every single design pattern available in any given language and then say, you now know how to write that language "The right way!".
Thats the feeling I got from this, it just goes into way too much detail about way too many things, and forgets to start with the basics, which is all you need to know to write JavaScript the right way.
How can you write any language the right way without knowing the basics?
This book could be an absolute disaster in the hands of people who don't know any better.
+1 for steering clear of this resource.
Yeah. I was expecting things like "use semicolons", "global variables are bad", "=== is often what you want, not ==". These are the things that many devs will need to learn. A bunch of design patterns was not what I expected.
While I agree with the fact that the title is misleading, I would have been even more disappointed if it was just a restating of "JavaScript: The Good Parts".
Intermediate JS devs need online resources too. Imo, an in-depth explanation of inheritance and the module pattern would be the best possible resources for people at that level of the learning curve. In other words, just read Doug Crockford.
For explanation of JS inheritance I would recommend reading http://killdream.github.com/blog/2011/10/understanding-javas..., it's actually superior to what you will find in Crocoford's book.
Almost every javascript library you use is a singleton, so your second sentence makes no sense. Check the example, it is just the module pattern. If a programmer wants to deviate away from a pattern, the language lock-in won't stop them.
Also, the command pattern is a great tool for handling undo/redo on a UI. I think you are being way to dismissive of some good advice. Just because someone is trying to share a better way of doing things that is based on ideas created in another language does not detract from their value.
Also, the command pattern is a great tool for handling undo/redo on a UI. I think you are being way to dismissive of some good advice. Just because someone is trying to share a better way of doing things that is based on ideas created in another language does not detract from their value.
Can you give an example of a JavaScript library that is a singleton?
In JS, a singleton is a reference to a module. It is used to ensure you invoke the module only once.
Global variables are irrelevant since your global namespace most likely resembles a tree structure.
edit: you may be right about the command pattern, I've never used something like that. It may just be the example is half-assed though.
Global variables are irrelevant since your global namespace most likely resembles a tree structure.
edit: you may be right about the command pattern, I've never used something like that. It may just be the example is half-assed though.
There are no modules in JavaScript as well. At least not in ES5.
Module pattern. It is easily one of Javascripts greatest strengths.
It's a very useful hack but I would hardly call it a great strength. As a module system it completely sucks.
It does leverage one of the language's great strengths, lexically-scoped first-class functions, but that doesn't make it a strength on its own.
It does leverage one of the language's great strengths, lexically-scoped first-class functions, but that doesn't make it a strength on its own.
Not sure if anyone will ever see this...
It is not a traditional module I will agree. However I see it as a hybrid class/interface/module and in this role, it works very well and allows you a tremendous amount of flexibility due to the dynamicness of js.
It is not a traditional module I will agree. However I see it as a hybrid class/interface/module and in this role, it works very well and allows you a tremendous amount of flexibility due to the dynamicness of js.
Obligatory:
http://norvig.com/design-patterns/
http://norvig.com/design-patterns/
design patterns have completely failed. Sometimes, they appear in my code, but knowing them has never helped me to code better.
What helps me is to know language idioms and code patterns.
It is a pity that so many teachers give such a devotion to design patterns.
It is a pity that so many teachers give such a devotion to design patterns.
I used to think as you do, and I still think that too much emphasis is placed on patterns, and too many poor coders stitch them together in complex ways to achieve exceedingly simple tasks.
However, when part of your design begins to take a form similar to a well-known pattern, there is a good reason to convert your design to use the specific pattern if possible: communicating with other programmers (including yourself, six weeks later). It means that instead of bogging down in documentation of exactly how that component works, you can just say "it's this pattern", and everyone familiar with the pattern will instantly know how it works, minus a few details.
In addition, knowing about patterns and seeing how they're used in practice (rather than toy examples that make them seem masturbatory) can help you to reason about problems in the future. Not because you necessarily use those specific patterns, but because you have understood how they achieve what they achieve.
However, when part of your design begins to take a form similar to a well-known pattern, there is a good reason to convert your design to use the specific pattern if possible: communicating with other programmers (including yourself, six weeks later). It means that instead of bogging down in documentation of exactly how that component works, you can just say "it's this pattern", and everyone familiar with the pattern will instantly know how it works, minus a few details.
In addition, knowing about patterns and seeing how they're used in practice (rather than toy examples that make them seem masturbatory) can help you to reason about problems in the future. Not because you necessarily use those specific patterns, but because you have understood how they achieve what they achieve.
Care to point us to some better resources?
I've shipped very little JS code, so take this with a grain of salt. However I have had to ship JS code, and since I'd heard horror stories, I tried to find some solid resources to make sure I wasn't shipping garbage. I found these really helpful:
Eloquent JavaScript, a freely available book with an in-browser REPL and a lot of fun exercises
http://eloquentjavascript.net/
Douglas Crockford's JS master class, which covers a lot of the same material as his "JavaScript: the Good Parts" but in video format, and I think in a much more digestible way. The Good Parts book is very, very dense and probably best used as a reference. (why he thought starting with a formal definition of the langauge's grammar was a good idea completely escapes me)
http://shop.oreilly.com/product/9780596809614.do
I don't actually know if these are really up-to-date, and all the cool kids are using CoffeeScript anyway, so anyone with more experience please correct me if these aren't any good. They definitely point out how to avoid the most painful quirks of the language, and how to leverage the core that is actually decent.
Eloquent JavaScript, a freely available book with an in-browser REPL and a lot of fun exercises
http://eloquentjavascript.net/
Douglas Crockford's JS master class, which covers a lot of the same material as his "JavaScript: the Good Parts" but in video format, and I think in a much more digestible way. The Good Parts book is very, very dense and probably best used as a reference. (why he thought starting with a formal definition of the langauge's grammar was a good idea completely escapes me)
http://shop.oreilly.com/product/9780596809614.do
I don't actually know if these are really up-to-date, and all the cool kids are using CoffeeScript anyway, so anyone with more experience please correct me if these aren't any good. They definitely point out how to avoid the most painful quirks of the language, and how to leverage the core that is actually decent.
I really like the nav highlighting used on this (and http://phptherightway.com). Specifically, I like that it highlights the nav element(s) for whichever sections are in view, rather than highlighting only one nav element at a time. Very elegant.
Check out Bootstrap's Scrollspy[1]. Its one implementation (of probably many) that I've seen of the nav highlighting that you mentioned.
[1] http://twitter.github.com/bootstrap/javascript.html#scrollsp...
[1] http://twitter.github.com/bootstrap/javascript.html#scrollsp...
The way how Addy Osmani implements singleton pattern is rather disputable. I would implement singleton as a regular object that returns itself immediately if initialized for the second time.
His prototype pattern also doesn't look like the right way of doing things. Is there actually anyone that uses plain object descriptors? I would just create helper method that wraps Object.create() and takes prototype object as first argument and instance object as second argument. There is no need to use constructors in this pattern (either directly or inside helpers) unless you are targetting legacy browsers.
I also dislike the fact that public/local scope is emulated by misusing the return statement - this is ugly, confusing and it doesn't play nicely with other patterns such as prototype. If you need some notion of public/private scope then just use underscore notation.
His prototype pattern also doesn't look like the right way of doing things. Is there actually anyone that uses plain object descriptors? I would just create helper method that wraps Object.create() and takes prototype object as first argument and instance object as second argument. There is no need to use constructors in this pattern (either directly or inside helpers) unless you are targetting legacy browsers.
I also dislike the fact that public/local scope is emulated by misusing the return statement - this is ugly, confusing and it doesn't play nicely with other patterns such as prototype. If you need some notion of public/private scope then just use underscore notation.
The singleton pattern he presents is pretty common and pretty powerful. It is a self-invoking module. It allows you to use the module pattern (very solid js pattern) and probably has less code than your method.
Also, javascript has closures, use them. this._private is a hacky java-esque way of doing things. return {public_methods...} is a solid way of working towards the strengths of the language and doing proper js encapsulation.
As for the prototype pattern, there are a million ways you can do that. Best to learn the fundamentals so you can use whatever works best based on the situation.
edit: I should add that one of the reasons I like JS patterns is that there are multiple correct ways to implement them based on the situation. There are many wrong ways too, of course :) but it is a very flexible language.
Also, javascript has closures, use them. this._private is a hacky java-esque way of doing things. return {public_methods...} is a solid way of working towards the strengths of the language and doing proper js encapsulation.
As for the prototype pattern, there are a million ways you can do that. Best to learn the fundamentals so you can use whatever works best based on the situation.
edit: I should add that one of the reasons I like JS patterns is that there are multiple correct ways to implement them based on the situation. There are many wrong ways too, of course :) but it is a very flexible language.
Here is what I prefer to call a singleton in JS, I don't think it could be any simpler than that:
mySingleton = {
initialized: false,
init: function() {
if (this.initialized == false) {
this.initialized = true;
// Initialize the singleton here
}
return this
},
}
singleton1 = mySingleton.init()
singleton2 = mySingleton.init()
Why does this site say (at the bottom, under the license) Based on a work at http://jstherightway.com. ?
I noticed that PHP The Right Way (the inspiration for this site) says something similar: Based on a work at www.phptherightway.com.
I noticed that PHP The Right Way (the inspiration for this site) says something similar: Based on a work at www.phptherightway.com.
Since it's on Github - I guess it's for anyone who might fork and modify it, so that there's a link back to the original:
https://github.com/braziljs/js-the-right-way
https://github.com/braziljs/js-the-right-way
Ah, that makes sense (as does the answer given by sjs382). Thanks.
Is it because it's CC BY-NC-SA? And showing you how they prefer to be given attribution?
No mention of Crockford? :(
First thing I thought of too. Time for a pull request?
With all due respect, Crockford jumped the shark some time ago.
Douglas Crockford should be named in my opinion, he loves javascript! ...
Javascript: The Good Parts is a pretty good book, good real world examples, like one where Crockford shows you how to split a url with regular expressions in javascript
JSlint is a pretty good tool, great parsing, using C, going on in the source
JSON is great for data. Data is pretty important.
Javascript: The Good Parts is a pretty good book, good real world examples, like one where Crockford shows you how to split a url with regular expressions in javascript
JSlint is a pretty good tool, great parsing, using C, going on in the source
JSON is great for data. Data is pretty important.
In what sense?
Crockford is as important to modern JS as Lerdorf is to modern PHP. He has a very minimal role in the community, and most of that involves resting on his laurels and being divisive.
Really? I'd see him as quite important to modern JS. Heck, he discovered JSON, that's certainly important, and he helps shape the ECMAScript standards. To ignore him would be foolish.
Probably in the sense that half the community got butthurt over his rant about semicolons.
A very nice initial listing for applications, I'd love to see it completed!
One framework I think is missing in the category "server-side" is derby.js ( http://derbyjs.com ), have you thought about adding it to the list?
One framework I think is missing in the category "server-side" is derby.js ( http://derbyjs.com ), have you thought about adding it to the list?
I loves me some Derby (and Racer), but it's not ready for production use until it supports server-side authentication logic. (Supposedly it's on the way.)
If you use JavaScript on the client side, you do it to drive the user interface which consists solely of DOM element objects. So why not make those DOM elements object oriented instead: https://github.com/hafriedlander/jquery.entwine
http://i.imgur.com/Ml2Jb.jpg
Sorry, I couldn't resist...
Sorry, I couldn't resist...
Hi guys! This a WIP, and we'd like to ask for your help to get this guide more complete! It's a live document.
Please, feel free to fork the project and send a pull request, we really want to make this guide a reference for JavaScript developers.
Please, feel free to fork the project and send a pull request, we really want to make this guide a reference for JavaScript developers.