Better Javascript

Javascript needs to grow. The Javascript libraries such as Prototype and JQuery should barely exist. Before you say anything, let me refine the statement. Firstly, I am not discrediting them because they are very usefully libraries. Why should they barely exist? Much of their functionality, as I believe, should be provided by the semantics of Javascript and its core libraries (DOM, regexp, window, etc). This functionality is the majority of my use of JQuery and Prototype.

My Wish List of Core Functionality

  • Inheritance

    An easy way to inherit a class, call the parent’s constructor, call a parent’s version of a method, and to set members as protected, private, or public. There are examples that go towards achieve this; but, native support is magnitudes of an improvement just for the sake of improved readability. (It would be really sweet to have reflection.) For what Mozilla is planning for Javascript 2.0, a more traditional class support will be added.

  • Get Elements with XPath and CSS Syntax

    There are many more ways to specify elements than by tag name and id. For example class name, attribute, relationship placement, any of the CSS selectors, and any combination of all them. This is where JQuery shines; it allows for all of these. XPath allows for much of this and is starting to gain browser support (Mozilla and Opera). Now I often want to use a CSS style because I have been using it to match elements for several years now. In the end, I just want something that is rich enough to get elements which may be a combination of XPath, XQuery, CSS syntax, and simple new methods such as getElementsByClassName.

  • Add/Remove Class

    Prototype has it, JQuery has it, and YUI has http://developer.yahoo.com/yui/docs/dom/YAHOO.util.Dom.html#addClass. People want it so just add the functionality of adding a class name, removing a class name, retrieving a list of class names, and checking if an element has a class name to the DOM Element.

  • DOM Aliases for Common Task

    Back in my early programming class, I learned that if you constantly reuse the same few lines of code (even if they are simple task) to save yourself time and wrap them up in a function. I mention this because it leads me to the fact that a lot of commonly reused DOM code exist.

    • Creating an element with only a text node as child

      var elem = document.createElement("span");
      var text = document.createTextNode("Some text.");
      elem.appendChild(text);
      //OR
      var elem = document.createElement("span");
      elem.appendChild(document.createTextNode("Some text."));

      I suggest for the addition of document.createElement( <tag name> [, <text for child text node>]).

    • Insert an element before or after another element

      Element.insertBefore and Element.insertAfter never seemed intuitive to me. At first glance I thought it worked as such referenceElement.insertBefore(newElement) instead of parentElement.insertBefore(newElement, referenceElement). So what do I do most of the time (well I use JQuery’s $.before): referenceElement.parentNode.insertBefore(newElement, referenceElement). To make matters worse, to insert an element after another element I use the following (again not really because I use JQuery’s $.after): referenceElement.parentNode.insertBefore(newElement, referenceElement.nextSibling).
      My suggestion is overload the method insertBefore so that if only one parameter is passed that it then will act as I how I first thought it did and to likewise add a simlar insertAfter method.

There is plenty more I can add but not today. In conclusion, I feel that developing in Javascript gets bogged down because of the extra brain power to remember the work around or the extra brain power to deterimne which library to use to mask the laborious details.

Leave a Reply

All comments are moderated for approval after submission. Attention spammers do not waste your or my time by trying to comment.

Your Personal Information
Author Name .
Email Address .
Website Address .
Your Comment
Send Your Reply