<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: How to structure your JavaScript code</title>
	<atom:link href="http://ajaxian.com/archives/how-to-structure-your-javascript-code/feed" rel="self" type="application/rss+xml" />
	<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code</link>
	<description>Cleaning up the web with Ajax</description>
	<lastBuildDate>Thu, 17 May 2012 07:43:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: gonchuki</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-269107</link>
		<dc:creator>gonchuki</dc:creator>
		<pubDate>Fri, 14 Nov 2008 17:41:42 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-269107</guid>
		<description>FAIL @ spelling of &#039;intuative&#039; :)
.
but, grammer (d&#039;oh!) aside, abusing the module pattern is a bad idea. It may be good for small pieces of code (like a short snippet with a couple of sub-functions and variables as a means to not pollute the outer namespace) but it&#039;s completely useless if you intend to use it to encapsulate your public API.
.
Just the fact that each time you need to add a public function/property you have to repeat yourself by writing both the &quot;internal&quot; implementation and it&#039;s interface completely throwing the dynamic part of the language out the window, makes me wonder why you are coding in javascript and not C++ or Java.</description>
		<content:encoded><![CDATA[<p>FAIL @ spelling of &#8216;intuative&#8217; :)<br />
.<br />
but, grammer (d&#8217;oh!) aside, abusing the module pattern is a bad idea. It may be good for small pieces of code (like a short snippet with a couple of sub-functions and variables as a means to not pollute the outer namespace) but it&#8217;s completely useless if you intend to use it to encapsulate your public API.<br />
.<br />
Just the fact that each time you need to add a public function/property you have to repeat yourself by writing both the &#8220;internal&#8221; implementation and it&#8217;s interface completely throwing the dynamic part of the language out the window, makes me wonder why you are coding in javascript and not C++ or Java.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shiftb</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268538</link>
		<dc:creator>shiftb</dc:creator>
		<pubDate>Thu, 30 Oct 2008 05:22:15 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268538</guid>
		<description>FAIL @ spelling of &#039;sanatize&#039;</description>
		<content:encoded><![CDATA[<p>FAIL @ spelling of &#8216;sanatize&#8217;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kimson</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268537</link>
		<dc:creator>Kimson</dc:creator>
		<pubDate>Thu, 30 Oct 2008 01:52:48 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268537</guid>
		<description>Thank you.</description>
		<content:encoded><![CDATA[<p>Thank you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PeterMichaux</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268521</link>
		<dc:creator>PeterMichaux</dc:creator>
		<pubDate>Wed, 29 Oct 2008 16:46:31 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268521</guid>
		<description>&gt; 1. “dot” notation is (for me) much more intuitive when dealing with nested namespaces...Thus, it just looks wierd.

Why is dot notation more intuative? Because some other languages use it for namespacing? Since JavaScript identifiers don&#039;t usually use underscore, it is available for some other meaning like namespacing. Using a dot costs as property lookup in JavaScript.

&gt; 2. Dot-notation allows you to make convenience aliases to any node in the namespace hierarchy. For example, if I’m going to be referring to various members of the Logger class, I can do “var logr = acme.widgets.Logger” inside my function, and then refer to “logr.foo”. It’s easier to type and more compact.

I can do &quot;var foo = acme_widgets_Logger_foo;&quot; and then just refer to &quot;foo&quot; which is less characters and executes faster. I&#039;m not worried about &quot;this&quot; as I don&#039;t use it in API functions.


&gt; 3. Dot-notation allows for a variety of shortcuts when constructing nested APIs. For example, you can use the literal object syntax to build a nested API like this:
&gt;
&gt; var acme = {
&gt; widget: {
&gt; Scroller: function () {
&gt; }
&gt; }
&gt; }


I don&#039;t see this as a significant advantage. It isn&#039;t so hard to write

acme_Scroller = function (){}

I don&#039;t think there is any need for a middle &quot;widget&quot; namespace.

&gt; 4. Dot-notation is easier to type.

I don&#039;t end up typing underscore as often as you might think.</description>
		<content:encoded><![CDATA[<p>&gt; 1. “dot” notation is (for me) much more intuitive when dealing with nested namespaces&#8230;Thus, it just looks wierd.</p>
<p>Why is dot notation more intuative? Because some other languages use it for namespacing? Since JavaScript identifiers don&#8217;t usually use underscore, it is available for some other meaning like namespacing. Using a dot costs as property lookup in JavaScript.</p>
<p>&gt; 2. Dot-notation allows you to make convenience aliases to any node in the namespace hierarchy. For example, if I’m going to be referring to various members of the Logger class, I can do “var logr = acme.widgets.Logger” inside my function, and then refer to “logr.foo”. It’s easier to type and more compact.</p>
<p>I can do &#8220;var foo = acme_widgets_Logger_foo;&#8221; and then just refer to &#8220;foo&#8221; which is less characters and executes faster. I&#8217;m not worried about &#8220;this&#8221; as I don&#8217;t use it in API functions.</p>
<p>&gt; 3. Dot-notation allows for a variety of shortcuts when constructing nested APIs. For example, you can use the literal object syntax to build a nested API like this:<br />
&gt;<br />
&gt; var acme = {<br />
&gt; widget: {<br />
&gt; Scroller: function () {<br />
&gt; }<br />
&gt; }<br />
&gt; }</p>
<p>I don&#8217;t see this as a significant advantage. It isn&#8217;t so hard to write</p>
<p>acme_Scroller = function (){}</p>
<p>I don&#8217;t think there is any need for a middle &#8220;widget&#8221; namespace.</p>
<p>&gt; 4. Dot-notation is easier to type.</p>
<p>I don&#8217;t end up typing underscore as often as you might think.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nosredna</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268515</link>
		<dc:creator>Nosredna</dc:creator>
		<pubDate>Wed, 29 Oct 2008 14:47:40 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268515</guid>
		<description>Thanks for reminding us to use the backslash. I do have a couple places in my code where I was doing a concat.</description>
		<content:encoded><![CDATA[<p>Thanks for reminding us to use the backslash. I do have a couple places in my code where I was doing a concat.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mikedeboer</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268506</link>
		<dc:creator>mikedeboer</dc:creator>
		<pubDate>Wed, 29 Oct 2008 09:37:35 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268506</guid>
		<description>Wow, the comment formatter totally screwed up parts of my code blocks..
Take 2:
&lt;code&gt;
// Delimiting strings with a backslash &#039;\&#039; saves you a string
// concat and still allows you to format your code within 
// 80 characters with indenting:
LIB_upateElement(parser,
  &#039;&lt;div class=&quot;Logger&quot;&gt;\
    &lt;p&gt;&lt;a href=&quot;#&quot; class=&quot;clearLink&quot;&gt;clear&lt;/a&gt;&lt;/p&gt;\
    &lt;dl class=&quot;log&quot;&gt;&lt;/dl&gt;\
  &lt;/div&gt;&#039;);
&lt;/code&gt;</description>
		<content:encoded><![CDATA[<p>Wow, the comment formatter totally screwed up parts of my code blocks..<br />
Take 2:<br />
<code><br />
// Delimiting strings with a backslash '\' saves you a string<br />
// concat and still allows you to format your code within<br />
// 80 characters with indenting:<br />
LIB_upateElement(parser,<br />
  '&lt;div class="Logger"&gt;\<br />
    &lt;p&gt;&lt;a href="#" class="clearLink"&gt;clear&lt;/a&gt;&lt;/p&gt;\<br />
    &lt;dl class="log"&gt;&lt;/dl&gt;\<br />
  &lt;/div&gt;');<br />
</code></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mikedeboer</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268505</link>
		<dc:creator>mikedeboer</dc:creator>
		<pubDate>Wed, 29 Oct 2008 09:30:38 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268505</guid>
		<description>Not only do I agree with broofa here on the semantic side of things, but there is also a practical consideration to not use the module pattern as stated by Peter Michaux:
When you&#039;re using a JS framework to aid in developing your webapp, like everyone does or should do nowadays, the namespace provides a hook for your custom code to be attached to a single global scope like this:
&lt;code&gt;
// in case you&#039;re using Javeline Platform. Imagine YUI, jQuery or 
// anything else if you prefer them...
jpf.myApp.func1 = function() {
  var appy = jpf.myApp; // one lookup
  // ...do stuff... 
};
&lt;/code&gt;
This saves us a lookup, because global lookups are expensive.
The declaration of &#039;myApp&#039; during the script initialization costs one lookup, but that is no different than the module-approach.

Additionally, the &#039;(function(global){})(this);&#039; syntax is not necessarily bad as it provides access to the global scope in exotic JS engines like screenreaders or standalone spidermonkey/ Rhino, but it forces a function call during script initialization, which will slow down the startup of your app. Using this method to declare your own namespace globally, shows another advantage of using a namespace:
&lt;code&gt;
(function(global){
  // declaring your namespace here saves you from using the
  // (function(global){})(this); struct anywhere else.
  global.jpf = {
    // stuff...
  };
})(this);
&lt;/code&gt;

Another thing I noticed when looking at Peter&#039;s code, is his &#039;LIB_updateElement()&#039; statement, which contains a string, concatenated with the &#039;+&#039; operand. It works, but is unnecessarily slow. I suggest using the following syntax whenever and wherever possible:
&lt;code&gt;
// Delimiting strings with a backslash &#039;\&#039; saves you a string concat and
// still allows you to format your code within 80 characters with
// indenting:
LIB_upateElement(parser,
  &#039;\
    &lt;a href=&quot;#&quot; rel=&quot;nofollow&quot;&gt;clear&lt;/a&gt;\
    \
  &#039;);
&lt;/code&gt;
With all the research &lt;a href=&quot;http://ajaxian.com/archives/everything-you-wanted-to-know-about-string-performance&quot; title=&quot;String concat&quot; rel=&quot;nofollow&quot;&gt;flying around&lt;/a&gt;, I&#039;d recommend this syntax to all.

I don&#039;t have a test page with raw metrics online somewhere, but I can put one up if someone feels I should (again :P) prove my aforementioned statements.</description>
		<content:encoded><![CDATA[<p>Not only do I agree with broofa here on the semantic side of things, but there is also a practical consideration to not use the module pattern as stated by Peter Michaux:<br />
When you&#8217;re using a JS framework to aid in developing your webapp, like everyone does or should do nowadays, the namespace provides a hook for your custom code to be attached to a single global scope like this:<br />
<code><br />
// in case you're using Javeline Platform. Imagine YUI, jQuery or<br />
// anything else if you prefer them...<br />
jpf.myApp.func1 = function() {<br />
  var appy = jpf.myApp; // one lookup<br />
  // ...do stuff...<br />
};<br />
</code><br />
This saves us a lookup, because global lookups are expensive.<br />
The declaration of &#8216;myApp&#8217; during the script initialization costs one lookup, but that is no different than the module-approach.</p>
<p>Additionally, the &#8216;(function(global){})(this);&#8217; syntax is not necessarily bad as it provides access to the global scope in exotic JS engines like screenreaders or standalone spidermonkey/ Rhino, but it forces a function call during script initialization, which will slow down the startup of your app. Using this method to declare your own namespace globally, shows another advantage of using a namespace:<br />
<code><br />
(function(global){<br />
  // declaring your namespace here saves you from using the<br />
  // (function(global){})(this); struct anywhere else.<br />
  global.jpf = {<br />
    // stuff...<br />
  };<br />
})(this);<br />
</code></p>
<p>Another thing I noticed when looking at Peter&#8217;s code, is his &#8216;LIB_updateElement()&#8217; statement, which contains a string, concatenated with the &#8216;+&#8217; operand. It works, but is unnecessarily slow. I suggest using the following syntax whenever and wherever possible:<br />
<code><br />
// Delimiting strings with a backslash '\' saves you a string concat and<br />
// still allows you to format your code within 80 characters with<br />
// indenting:<br />
LIB_upateElement(parser,<br />
  '\<br />
    <a href="#" rel="nofollow">clear</a>\<br />
    \<br />
  ');<br />
</code><br />
With all the research <a href="http://ajaxian.com/archives/everything-you-wanted-to-know-about-string-performance" title="String concat" rel="nofollow">flying around</a>, I&#8217;d recommend this syntax to all.</p>
<p>I don&#8217;t have a test page with raw metrics online somewhere, but I can put one up if someone feels I should (again :P) prove my aforementioned statements.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: nbr</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268504</link>
		<dc:creator>nbr</dc:creator>
		<pubDate>Wed, 29 Oct 2008 08:34:55 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268504</guid>
		<description>I stopped reading after the silly &quot;sanatize&quot; (!) function that encodes first occurences of [&amp;&lt;&gt;].</description>
		<content:encoded><![CDATA[<p>I stopped reading after the silly &#8220;sanatize&#8221; (!) function that encodes first occurences of [&amp;&lt;&gt;].</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: broofa</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268500</link>
		<dc:creator>broofa</dc:creator>
		<pubDate>Wed, 29 Oct 2008 02:02:48 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268500</guid>
		<description>I&#039;ve never been a fan of the &quot;prefix-as-a-namespace&quot; naming style. There are a variety of reasons for this that I&#039;d like to hear Mr. Michaux&#039;s thoughts on.

1. &quot;dot&quot; notation is (for me) much more intuitive when dealing with nested namespaces.  For example,  &quot;new acme.widgets.Logger()&quot; just reads better than &quot;new acme_widgets_Scroller()&quot;.  The latter creates a cognitive clash between two nameing conventions I&#039;ve long since grown accustomed to.  &quot;_&quot; separated identifiers tend to be all lower (or upper) case, but in JavaScript the convention is to capitalize Class names but not generic objects.  Thus, it just looks wierd.

2. Dot-notation allows you to make convenience aliases to any node in the namespace hierarchy.  For example, if I&#039;m going to be referring to various members of the Logger class, I can do &quot;var logr = acme.widgets.Logger&quot; inside my function, and then refer to &quot;logr.foo&quot;.  It&#039;s easier to type and more compact. 

3. Dot-notation allows for a variety of shortcuts when constructing nested APIs.  For example, you can use the literal object syntax to build a nested API like this:
&lt;code&gt;
var acme = {
  widget: {
    Scroller: function () {
    }
  }
}
&lt;/code&gt;

4. Dot-notation is easier to type.  You young pups may not care, but as a professional programmer of 20+ years, my hands and wrists will feel the difference between a &quot;_&quot; convention where I have to use SHIFT all the time, and a &quot;.&quot; convention where I don&#039;t, after a long day of coding.

&quot;Now get off my lawn!&quot; ;-)</description>
		<content:encoded><![CDATA[<p>I&#8217;ve never been a fan of the &#8220;prefix-as-a-namespace&#8221; naming style. There are a variety of reasons for this that I&#8217;d like to hear Mr. Michaux&#8217;s thoughts on.</p>
<p>1. &#8220;dot&#8221; notation is (for me) much more intuitive when dealing with nested namespaces.  For example,  &#8220;new acme.widgets.Logger()&#8221; just reads better than &#8220;new acme_widgets_Scroller()&#8221;.  The latter creates a cognitive clash between two nameing conventions I&#8217;ve long since grown accustomed to.  &#8220;_&#8221; separated identifiers tend to be all lower (or upper) case, but in JavaScript the convention is to capitalize Class names but not generic objects.  Thus, it just looks wierd.</p>
<p>2. Dot-notation allows you to make convenience aliases to any node in the namespace hierarchy.  For example, if I&#8217;m going to be referring to various members of the Logger class, I can do &#8220;var logr = acme.widgets.Logger&#8221; inside my function, and then refer to &#8220;logr.foo&#8221;.  It&#8217;s easier to type and more compact. </p>
<p>3. Dot-notation allows for a variety of shortcuts when constructing nested APIs.  For example, you can use the literal object syntax to build a nested API like this:<br />
<code><br />
var acme = {<br />
  widget: {<br />
    Scroller: function () {<br />
    }<br />
  }<br />
}<br />
</code></p>
<p>4. Dot-notation is easier to type.  You young pups may not care, but as a professional programmer of 20+ years, my hands and wrists will feel the difference between a &#8220;_&#8221; convention where I have to use SHIFT all the time, and a &#8220;.&#8221; convention where I don&#8217;t, after a long day of coding.</p>
<p>&#8220;Now get off my lawn!&#8221; ;-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pianoroy</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268497</link>
		<dc:creator>pianoroy</dc:creator>
		<pubDate>Tue, 28 Oct 2008 23:09:13 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268497</guid>
		<description>@fforw:
The module pattern allows you to place the module (its globals and everything) within whatever context you like. If you run it like: &quot;(function(){ var global=this; ...})();&quot;, then global will be assigned to window. But you can also do this:
(function(){ var global=this; ...}).call(My.namespace);
... and then, the global inside will be assigned to My.namepace. This pattern is nice because it allows for changing the context without changing the code much.</description>
		<content:encoded><![CDATA[<p>@fforw:<br />
The module pattern allows you to place the module (its globals and everything) within whatever context you like. If you run it like: &#8220;(function(){ var global=this; &#8230;})();&#8221;, then global will be assigned to window. But you can also do this:<br />
(function(){ var global=this; &#8230;}).call(My.namespace);<br />
&#8230; and then, the global inside will be assigned to My.namepace. This pattern is nice because it allows for changing the context without changing the code much.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TNO</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268489</link>
		<dc:creator>TNO</dc:creator>
		<pubDate>Tue, 28 Oct 2008 18:20:08 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268489</guid>
		<description>correction: won&#039;t -&gt; will</description>
		<content:encoded><![CDATA[<p>correction: won&#8217;t -&gt; will</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TNO</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268488</link>
		<dc:creator>TNO</dc:creator>
		<pubDate>Tue, 28 Oct 2008 18:18:49 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268488</guid>
		<description>Because you assume window is the global name. If you move your code into a different environment, it won&#039;t break when it assumes.</description>
		<content:encoded><![CDATA[<p>Because you assume window is the global name. If you move your code into a different environment, it won&#8217;t break when it assumes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fforw</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268486</link>
		<dc:creator>fforw</dc:creator>
		<pubDate>Tue, 28 Oct 2008 17:56:12 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268486</guid>
		<description>What I don&#039;t understand is why why people tend to use this &quot;var global = this; this.foo = ...&quot; construct or just &quot;this.foo = ...&quot; and not just &quot;window.foo = ...&quot;. 

Is there any benefit of *not* using &quot;window.foo = ...&quot; ?</description>
		<content:encoded><![CDATA[<p>What I don&#8217;t understand is why why people tend to use this &#8220;var global = this; this.foo = &#8230;&#8221; construct or just &#8220;this.foo = &#8230;&#8221; and not just &#8220;window.foo = &#8230;&#8221;. </p>
<p>Is there any benefit of *not* using &#8220;window.foo = &#8230;&#8221; ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nosredna</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268484</link>
		<dc:creator>Nosredna</dc:creator>
		<pubDate>Tue, 28 Oct 2008 16:56:55 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268484</guid>
		<description>@shadedecho,
.
Oh, I hadn&#039;t thought of that. Nifty.</description>
		<content:encoded><![CDATA[<p>@shadedecho,<br />
.<br />
Oh, I hadn&#8217;t thought of that. Nifty.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shadedecho</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268483</link>
		<dc:creator>shadedecho</dc:creator>
		<pubDate>Tue, 28 Oct 2008 16:49:33 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268483</guid>
		<description>@Nosredna-
&quot;var global = this&quot; when wrapped inside the outer &quot;(function(){ ... })();&quot; construct will by default make global (and this) point to the global &quot;window&quot; object, which is global and in scope of everything in JS on a webpage.  This happens because a function by default runs in the context of &quot;window&quot; unless otherwise bound, so that outer anonymous function call does automatically bind its &quot;this&quot; to &quot;window&quot;.</description>
		<content:encoded><![CDATA[<p>@Nosredna-<br />
&#8220;var global = this&#8221; when wrapped inside the outer &#8220;(function(){ &#8230; })();&#8221; construct will by default make global (and this) point to the global &#8220;window&#8221; object, which is global and in scope of everything in JS on a webpage.  This happens because a function by default runs in the context of &#8220;window&#8221; unless otherwise bound, so that outer anonymous function call does automatically bind its &#8220;this&#8221; to &#8220;window&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ajaxianreader123</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268477</link>
		<dc:creator>ajaxianreader123</dc:creator>
		<pubDate>Tue, 28 Oct 2008 16:05:43 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268477</guid>
		<description>I&#039;ve always used objects as namespaces.  He says that&#039;s bad, but doesn&#039;t elaborate.  Any idea what he&#039;s talking about?</description>
		<content:encoded><![CDATA[<p>I&#8217;ve always used objects as namespaces.  He says that&#8217;s bad, but doesn&#8217;t elaborate.  Any idea what he&#8217;s talking about?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ilazarte</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268469</link>
		<dc:creator>ilazarte</dc:creator>
		<pubDate>Tue, 28 Oct 2008 15:01:51 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268469</guid>
		<description>I&#039;m a fan of the module pattern.  I use it so often to get so much done I don&#039;t understand the need for classical inheritance in javascript.</description>
		<content:encoded><![CDATA[<p>I&#8217;m a fan of the module pattern.  I use it so often to get so much done I don&#8217;t understand the need for classical inheritance in javascript.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nosredna</title>
		<link>http://ajaxian.com/archives/how-to-structure-your-javascript-code/comment-page-1#comment-268467</link>
		<dc:creator>Nosredna</dc:creator>
		<pubDate>Tue, 28 Oct 2008 14:55:26 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4907#comment-268467</guid>
		<description>It&#039;s always great to see how other programmers code. Thanks!

Is &quot;global&quot; really global? What I would expect from a variable called global (in a JavaScript program) is an object that hold global variables for the use of the entire program. (I&#039;m in the habit of &quot;var that=this;&quot; instead, mostly because I see other people use it so much.)

The misspelling of sanitize drives me crazy. If I recall correctly, on the Atari ST, all the color functions had the word &quot;palette&quot; misspelled as &quot;pallete.&quot; Every time I got to one of those functions I had to slow down, grit my teeth, and think.</description>
		<content:encoded><![CDATA[<p>It&#8217;s always great to see how other programmers code. Thanks!</p>
<p>Is &#8220;global&#8221; really global? What I would expect from a variable called global (in a JavaScript program) is an object that hold global variables for the use of the entire program. (I&#8217;m in the habit of &#8220;var that=this;&#8221; instead, mostly because I see other people use it so much.)</p>
<p>The misspelling of sanitize drives me crazy. If I recall correctly, on the Atari ST, all the color functions had the word &#8220;palette&#8221; misspelled as &#8220;pallete.&#8221; Every time I got to one of those functions I had to slow down, grit my teeth, and think.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

