dean.edwards.name/weblog/2007/03/rules/

Comment: #1

Dean, one src (about 6 Kb on Gz compatible browsers), JS 1.5 Standard for every browser, without Object prototypes and with every prototype implemented as standard (and few extra features not prototyped too).

This is to tell that You released a library (Base2) that’s not so different from my old JSL concept (and goal) and my new FW … but You was faster than me to release “officially” this cool library.

What do You think about merging our code for a better standard “BaseFX” library development?

I can send You my debugged sources (point 4 and 5 of this post) to implement correctly even XMLHttpRequest for IE 5 or greater (as new perfect String.replace and every other Native methods)

Regards

Comment: #2

I agree with most but life is tough in JavaScript land…

1) Being unobtrusive is not easy http://peter.michaux.ca/article/553

3) Don’t extend built in objects at all. Then you don’t have to worry about clashes. I don’t see much difference in writing forEach(myArray, function(a){return a;}) then myArray.forEach(function(a){return a;});

It looks like there is some strong sniffing at the top of base2-bom.js

“You must slavishly read every blog to find the next hack”

I don’t think any code in a library should be a “hack”.

9) The Base OOP code seems quite long. JavaScript OOP with “super” in eight lines: http://www.kevlindev.com/tutorials/javascript/inheritance/index.htm

11.1) Writing documentation is a valuable way to look at library code though a different set of glasses. It really helps my development process.

11.2) Namespacing allows people to use a library in a legacy environment. Those who don’t want to type the namespaces can import the namespaced properties into the window object. Without namespaces you are leaving out the legacy developers.

Just some thoughts. The more JavaScript libraries the better since there is more ideas and analysis of browser scripting difficulties. It is unfortunate that we all have such different sets of priorities and can’t just have one library.

Comment: #3

The Base OOP code seems quite long.

Yes it is. But I’m happy with it. I don’t really like the other solutions available.

It looks like there is some strong sniffing at the top of base2-bom.js

It is a JavaScript library.My intent is that you should eliminate sniffing for the user of the library.

You must slavishly read every blog to find the next hack

That was a joke.

Comment: #5

It is a JavaScript library.My intent is that you should eliminate sniffing for the user of the library.

Then, if you’re a fan of jQuery, why don’t you introduce your library to the jQuery developers so as to drop all of their sniffing and depend on base2? That way we could use jQuery and base2 together without problems I guess.

Comment: #6

@knocte – if you like jQuery already then I really recommend that you continue to use it. base2 offers nothing more than jQuery already provides. Byte for byte, jQuery provides a lot more power.

This library is not really meant to compete with jQuery or Prototype. Those libraries already provide lots of functionality that base2 does not.

base2.DOM is really aimed at:

• teachers and students who are learning JavaScript and the DOM
• programmers, who are already familiar with JavaScript but don’t want to learn a new API
• web standards zealots

Comment: #8

Thank You Dean to ignore me totally, regards.

Comment: #9

Indeed you are right on with all these, but this also leads me to believe that no library is doing all these things. With my recent release of D|C I went through the annoying hassle of writing documentation. I suppose some documentation is better than none, no matter how long your phone number is

Predictability is also key since there’s nothing worse than thinking something is something that it isn’t. That is one main reason I allowed the ability to change D|C through registration.

Another thing… man I’m really glad you posted this… because D|C has a simple plugin method which allows you to extend the library without touching the source… one thing I knew I needed to have. And lastly your first rule. Always a given. That was my big argument over the “just add a classname widget philosophy.” Das no good.

Comment: #10

About point 4 (Follow Standards)

Both your Function.apply and Number.toFixed don’t respect standards.

function bug(){return [].slice.apply(arguments)};
alert(bug(1,(2).toFixed(2),3));

apply accepts one *optional* argument (as call) and (2).toFixed(2) should return string “2.00” . As I said, bytefw has just solved these common problems … and, for example, the fastest version of unshift should be something like this

[].unshift = function(){
	this.reverse();
	while(arguments.length)	this[this.length] = arguments[--arguments.length];
	return this.reverse().length
};

This post just to tell You that a collaboration should be better without wasted time and with less bugs because, as You said:

look to see if it has not already been fixed

and for example, again, your encodeURIComponent implementation is not standard too while mine one is (and unescape as decodeURIComponent is a bad practice, imho).

bye

Comment: #11

@Andrea – what’s wrong with my version of encodeURIComponent()? And, can you keep questions about base2 on the base2 page please?

Comment: #12

Dean: how would you propose to implend for instance toJSONString() without prototyping Object?

Comment: #14

@Dean, about your encodeURIComponent [tested with FireFox]

example

And, can you keep questions about base2 on the base2 page please?

Sure but these are errors about fourth point of this list (these functions don’t respect standard and don’t follow the Leader too)

Regards

Comment: #15

@Tino Zijdel – you don’t have to extend the Object.prototype to make json work. Prototype (http://www.prototypejs.org/, rev 1.5.1rc2) has json support built in and they extend the Object singleton (not the prototype). var foo = Object.evalJSON( myJSONString );

@Dean – I dig your article. Great points. I like the idea of a build page to let me choose what components I want to add. As libraries get bigger, and they do overtime, its nice to just pick out what you need. For example, the Prototype SVN repo has all the main parts like (ajax,string,number,event,core) sep. into their own files, but no official build page 8(.

@Andrea Giammarchi – this is a post over Dean’s work, not a place to promote your framework. I like your blog posts too, but try to keep them separate. Your comments on the bugs though, are great. Frameworks should be beaten on by users. Many times I miss little errors in my projects becuase I am too close to them. An outside eye can really help.

Comment: #16

j: what I was actually aiming at is that toJSONString() and parseJSON() are expected to be added in ECMA4. If you like to take the standards approach – as Dean is doing here with Base – that means that in order to have these (near) standard methods available in older (now current) browsers you probably need to prototype Object.

Another example: how would you ‘backport’ for instance the hasOwnProperty() method to IE5?

Comment: #17

@Tino – well some things are impossible.

Comment: #18

“9. Small is Better”

You hit one of the points why I wrote jsPax. A growing part of my js-code uses jQery and various plugins. I had the options of

1. make a huge bundle with all plugins and load it on every page, regardless if necessary. That way the first visit to the web would be annoyingly slow.
2. make a smaller bundle for every page. That makes the first page start up faster, but does not use the browser cache at all.
3. have quite a number of script tags in the head. Only loads the scripts that are necessary and makes perfect use of browser cache.

With jsPax I usually have two script tags on a Page and still make perfect use of the browser cache. BTW I can dynamically change the set of loaded libraries according to the content of the page. That way I don’t have to care if I change the HTML if the according script will be loaded.

Comment: #20

Although base is a different library as jQuery and has a different target audience, I still think that there should be more collaboration between you so as to give a really nice JS framework, avoid code duplication, etc.

Comment: #21

I think you should add another two rules:

1 – test your code (Mochikit seems pretty keen on this point)
2 – benchmark your code – speed optimization, stress testing, etc… I think the whole discussion about memory leaks apply here too.

On rules #4 and #5: I must be the only person in the world who thinks forEach loops are bad =(

Comment: #25

Dean,this is a very nice set of rules, and it is not pompous at all. I would do great work if I was able to stick to just some of them, as I always have some memory leaks and over-extending is my specialty. Thanks for the post, now I can see how many things I was doing wrong.

Comment: #26

“base2.DOM is really aimed at:

teachers and students who are learning JavaScript and the DOM programmers, who are already familiar with JavaScript but don’t want to learn a new API web standards zealots”

Dean Your right im one of the studentsAnd i fully agree with that what You say.

Comment: #27

These are some great rules. I totally agree with you on number 6 – Be Flexible, in my opinion it should be the most important rule and much more programmers should stick closely to it, including me. It happened more than few times to me when I had to rewrite most of my code just to change one little behavior thing and that can be really frustrating. So flexibility is a great thing if it can be achieved.

Comment: #28

Are there any documents out there explaining a good way to lazy-load classes and utilities as needed?

I am concerned with the size of my current js library (one file) growing with functions that are not necessarily needed on every single page that the library is included on.

Comment: #29

Flexibility is a key to success. I would make “Be Flexible” rule #1 in this list.

Good luck with base2 Dean.

Regards, Marcus

Comment: #30

I would reccomend that people who right JS libraries create different extensions, rather than stuff everything in one file, have the ability to extend it so you only have what you need, it is no good having some fuctions that will be rarely used in a website adding to the size of the file. Have the ability to easy extend the library with files, as and when you need them.

I think this goes with rule 9 you mentioned, this will keep your code small, but still have the functionality to add different functions that you need I think that is a must have.

Do you know of the best way to allow extension inclusion? As in ways to load the extension files into the main core file.

Thanks for the guide Dean!

Comment: #31

Nice, the tenth rule seems my favorite

Comment: #32

Hi Dean, quite a nice collection of rules you have placed here. But don’t you think that in reality one is actually never able of keeping all rules at once? In my opinion everybody has to fix priorities and must find out which of the rules is the most important one for himself. Rule Nr. 9 is very important for me. It’s difficult to understand why there are so many programmers who write that extremely exaggerated code. There still exists a large of number of peoples who is only provided with a bad connection to the Internet and DSL is not yet very widespread.

Comment: #33

2. Object.prototype is verboten! =========================

I don´t know much about programming, nevertheless I sometimes stroll over pages like this, to get an impression and ideas.(even without going deep into it, there are sometimes chances, and – what a luck – I have a programmer for such things. But without understand a lot, I was smiling about using the german term “verboten” in relation to a seemingly strict “order” or recommendation about using a coding Please believe me: not everything in Germany is “verboten” But if something is “verboten” – obey! (ok, that´s a little offtopic, just smile, as I did!) regards from sunny Munich, Germany Hans

Comment: #34

Ha ha, I also studied German language in high school and I know that verboten is a really strong word! Dean, cool rules collection, luckily not all of them are “verboten” so they can be bent a little, but if they were only a little bit respected they can be really helpful.

Comment: #35

I love tenth rule– but thank you for whole list

Greg

Comment: #36

web standards zealots

Yar!

Comment: #37

Hi Dean, Thx for providing us rules for JavaScript library authors. Indeed you are right on with all these. Make it small, flexible and standards-based:) looks great to me.

Comment: #39

These rules are really good, if everyone follow these rules the code will be much better to support and to insert little changes…