31–40 of 43 posts
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?
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.)
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 f…
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.
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 f…
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…
mySingleton = {
initialized: false,
init: function() {
if (this.initialized == false) {
this.initialized = true;
// Initialize the singleton here
}
return this
},
}
singleton1 = mySingleton.init()
singleton2 = mySingleton.init()
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
Sorry, I couldn't resist...
Earlier quoted context omitted.
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 langu…
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.
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.
It is a pity that so many teachers give such a devotion to design patterns.
Earlier quoted context omitted.
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 langu…
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.
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.
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.
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.
Earlier quoted context omitted.
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.)
It does support server side authentication logic, it's just not very well documented yet ;-)
Earlier quoted context omitted.
There are no modules in JavaScript as well. At least not in ES5.
Module pattern. It is easily one of Javascripts greatest strengths.
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.
