/dev/null » JavaScript

It’s really hard to talk about JavaScript best practices and JMVC

Michael — Thu, 15 Jul 2010 09:36:32 +0000

I was totally enthusiastic, when I first learned about JavaScriptMVC – because it brings all the best practices you are accustomed to into the JavaScript world. That means the MVC architecture, Object-oriented development with simulated inheritance, EJS templates, easy testing, OpenAjax support, powerful event delegation and so on.

However, I often have a hard time to convince other developers about those advantages. I guess testing is the easiest one, because no developer would dare to argue against testing, even though many developers don’t do it or don’t do it right. Questions and discussions about testing seem to be very rare. Developers just discuss it with their non-technical managers, if they want to get around that “effort”.

But it already starts with OpenAjax. I rarely find a developer that knows what it is and what it is good for and why you might need an event hub in JS at all. Zend, W3C, IBM and Google are some of the more well-known members of the OpenAjax Alliance. If you hear about it the first time now, take the time to have a look.

Just yesterday I was talking to an obviously experienced JS dev (who was working for a well known mobile phone company), that was browsing through the JavaScriptMVC documentation and stopped in the chapter about EJS templates: “Yeah, I saw something similar in our own project and removed it. It is confusing, if the JS code and the HTML are in separate files, because you don’t see the code together in one file. HTML should only be edited by developers who know the JS code very well”. Not sure what to say about that. Why not give up separation of concerns at all and put everything in one big file? Then you see the big picture on your hopefully big screen. Also you always need to check the full version control system diff after each change because the file name alone doesn’t tell you what was changed and you probably have more of those exciting conflicts to resolve. And: You REALLY need to be an expert to understand what is going on. The company can never fire you, because no one else would ever understand that kind of code. Sorry for being sarcastic, but that kind of attitude can seriously damage the health of innocent other people who need to clean up the mess in 20h work days afterwards, to meet the deadline of the project. Or the project is so small that it doesn’t matter. Or the company you work for can afford to pay a lot of developers who have the time to maintain a JS app without templates.

Convincing people about the usefulness of controllers is not easy too. Either you start showing an OpenAjax subscribe action – then the developer most likely won’t understand what that is good for (see above). Or you talk about event delegation, then the developer will point to jQuery’s live() method, which does event delegation too. In fact, JavaScriptMVC’s event delegation used to be one of the strong points and I admit that I am not totally up to date with the whole discussion right now, because I was busy with a PHP project during the last 6 months. I know Justin Meyer is/was working on the controller code so that it makes more use of jQuery, he contributes code to jQuery and he is in contact with John Resig. Anyways, the whole point about controllers again is separation of concerns and not so much the technical details behind the scenes. The JavaScript world is moving very fast and implementation details change a lot, but separation of concerns is not really something that you can look at as something you probably don’t need. The JS world sometimes feels like the PHP world about 10 years ago.

Ok, after getting rid of those thoughts, I will return to work now. The next 2 weeks will be quite relaxed with very little work. So maybe, I can read through the new JavaScriptMVC code and update my knowledge. It really feels uncomfortable not the be able to answer questions in detail. Also I start confusing PHP and JS syntax *lol*

Chrome Bug Tester

Michael — Thu, 10 Sep 2009 16:06:50 +0000

What these tests do, is basically constructing Arrays and one Object (in the last test), and then output the data using a “for(var i in array)” loop. All browsers do handle objects and arrays as expected and return the data in the original order, just Google Chrome fails. That means there is no way to store data in a certain order in Chrome, if you don’t want to loop over it with “for(var i = 0; i < array.length; i++)", which can result in significant code and/or processing overhead for a number of reasons.

If all tests are green, they passed. Red results indicate failures:

Especially this comment in JavaScriptCore (Apple Safari), indicates that all browsers should preserve the order of data, as this is a de-facto standard:

// lastIndexUsed is an ever-increasing index used to identify the order items
// were inserted into the property map. It’s required that getEnumerablePropertyNames
// return the properties in the order they were added for compatibility with other
// browsers’ JavaScript implementations.

The ultimate reason behind the behavior of Chrome seems to be that a NumberDictionary is used for certain array/object keys and a StringDictionary for others (handles.cc line 554):
// Compute the element keys.
element_keys = Factory::NewFixedArray(current->NumberOfEnumElements());
current->GetEnumElementKeys(*element_keys);
content = UnionOfKeys(content, element_keys);
content = UnionOfKeys(content, GetEnumPropertyKeys(current));

Also the many type casts do look scary to me =)

Sure you could use non-numeric attributes only, but those are normally part of the inline cache. To cache offsets of arbitrary arrays does not make a lot of sense. The JavaScriptCode devs recognized just that and made it right.

Object property ordering in Google Chrome

Michael — Sun, 06 Sep 2009 22:26:37 +0000

Today, I prepared for the upcoming PHP/JS conferences and had a look at the mysterious bug #883 of Google Chrome and those related to it. Also I read though SquirrelFish source, which is used by Safari 4.

The reason for the odd behavior of Chrome seems to be a if/else construct that is repeated throughout the source of runtime.cc:
// Check if the name is trivially convertible to an index and get // the element if so. if (name->AsArrayIndex(&index)) { return GetElementOrCharAt(object, index); } else { PropertyAttributes attr; return object->GetProperty(*name, &attr); }

Chrome makes a difference between properties and elements. And they do weird type casts. If you check JavaScriptCore, you see there is a better way:
inline JSValue JSObject::get(ExecState* exec, const Identifier& propertyName) const { PropertySlot slot(this); if (const_cast(this)->getPropertySlot(exec, propertyName, slot)) return slot.getValue(exec, propertyName);

return jsUndefined(); }

c’t magazine: WebZwoNullTurbo, how to optimize JavaScript

Michael — Tue, 18 Aug 2009 11:36:17 +0000

There is an article about JavaScript optimization in the current issue of the German c’t magazine. I read it with great interest and there are some tips that need to be commented:

1) Declare local variables with the keyword var, to save time for searching it in the global namespace:

function foo () { var bar = 'abc'; return bar; }

This should always be done, for sure. However the article is wrong in that the variable will be created in the local namespace, if you don’t use var. In that case it will be created in the global namespace (which is window in Web browsers).

2) Another recommendation is to use setTimeout(doSomething, time, param1, param2,…) instead of setTimeout(‘doSomething(‘ + param1 + ‘,’ + param2 +’)', time). While this would be a good idea probably, Internet Explorer does not support it. Also the use of local object instance variables like this.value to pass parameters to functions that are later executed by setTimeout is dangerous, as the context is not preserved for setTimeout. Always use the variables in the global namespace or use the var self = this hack (might cause memory leaks) to access the current context. Two examples from the Internet Explorer Developer Center:

// The first example of a closure passes the variable to a named function.
function startTimer() {
    var div = document.getElementById('currentTime');
    setTimeout(function(){doClock(div)},200);
}
// The second example also uses a closure, by referring to an argument passed to the function.
function doClock(obj) {
    setInterval(function(){obj.innerHTML=(new Date()).toLocaleString()},200);
}

3) Function inlining, that is not to use functions in loops but copy & paste the code, can speed up things a bit, however it can not be considered good style, does reduce readability and often violates the DRY (don’t repeat yourself) principle.

4) Compressing JavaScript code for use in production environments is a very good idea. I do recommend to use the YUI compressor, which does not break code and works very well with additional gzip compression. It can be integrated in automated build scripts very nicely.

5) The biggest impact for a clean architecture and less memory leaks probably comes from using Event Delegation, which was not mentioned in the article. Try JavaScriptMVC.

JavaScriptMVC 1.5 released

Michael — Thu, 19 Feb 2009 10:34:23 +0000

A new stable release of the JavaScriptMVC framework was released yesterday Justin Meyer developed it, while working with us on a new Web application. Some features like the new custom events are direct results of this project. He did an excellent job!

New features include:

Env.js/Shrinksafe based compression: A custom env to simulate the browser. As the browser encounters script tags, it adds them to a collection and then compresses them. This means instant file concat and compression from the command line with no extra work.
Env.js Testing: Prior to 1.5, tests ran in the browser only. With Env, the same tests can be run from the command line. Great for projects where you need a quick way of checking if functionality works before check-in.
Documentation:New JavaScript based documentation library split between JSDoc and NaturalDocs.
Code Generators: Added code generators and made building custom ones easy too by using EJS.
Scaffolding: Helps you develop iteratively by connecting to default Rest services and providing an easily expandable CRUD interface.
Engines+Plugins: Added a command line plugin and dependency installer. So, if a developer wanted a jQuery plugin, he can install it from the command line, and it will also grab jQuery.
Custom Event Delegation: Besides improving event delegation to cover all the cases that even live doesn’t do, they’ve expanded it to include custom events such as drag+drop, lasso, hoverenter, mousenter. Developers can have the benefits of event delegation with these complex events.
Easy Update: JavaScriptMVC can update itself from the command line.

Update on “Script error leaving page with applet tag” (jQuery)

Michael — Fri, 31 Oct 2008 21:10:25 +0000

After 9 months of waiting, there finally might be a fix for jQuery bug #2349: When you hide or remove a Java applet, you get a script error in Firefox. The impact was, that you could not really use jQuery together with Java applets. I’m really looking forward to jQuery 1.3.0!

Update on object property reordering in Google Chrome

Michael — Wed, 29 Oct 2008 12:26:24 +0000

Iterating over an objects properties can result in a seemingly random order, it’s always the same order in Chrome, but in a different order for other browsers. I posted this as bug #223 a couple of weeks ago. John Resig posted the same issue as ticket #883 a day later. It was confirmed in the meantime by the chromium developers and described as an expected behavior. Very funny.

Ajax and Rich Internet Application FAQ

Michael — Wed, 29 Oct 2008 11:58:57 +0000

Shall I use JSON or XML as AJAX transport format?

There actually is no reason to use XML instead of JSON, if you don’t plan to use XSLT. JSON is part of JavaScript which has been around since the dark ages of the web. Also, there are very fast server-side JSON implementations and JSON is the more compact protocol, thus saving bandwidth.

Isn’t XSLT much faster than to use JSON and modify the DOM with JavaScript?

First, it is highly unlikely that there are more browsers that understand XSLT than {a: ‘b’}. In fact, with JSON you are on the safe side. For a client-side templating engine like EJS, the performance is not an issue.

Processed EJS templates simply add strings together. They do not use eval() or have a processing step which is probably why typical templates run slow.

Also, XSLT is loaded from another file while EJS can be packaged with the JavaScript payload. This necessitates an extra request by the client.

Is it better to render the HTML on the client or an the server side?

There is a general decision, you need to be aware of: Are you building a Rich Internet Application or do you want to beautify some HTML output with additional (JavaScript-)effects? Is the site required to be usable without JS? If you can rely on JS and if it’s a RIA, then I would suggest using a client-side MVC framework like JavaScriptMVC, which comes with client side controllers, template engine and model classes. Your server will mainly provide JSON-API functions and the basic page grid then, and not deliver complete HTML pages. Lots of logic (and therefore code) will move to the browser/JavaScript: In effect, you will need more JavaScript developers and less server-side developers for your projects. On the other hand, you will see a gain in consistency and also performance, as you have way less client/server communication, once the JS code is loaded (which can be pretty fast, thanks to compression). Many popular Web applications are using this approach.

Which JavaScript library shall I use (Dojo, jQuery,…)?

The choice of JavaScript DOM/Ajax library is IMO not so important, as long as it doesn’t leak memory, has a small code size and offers fast DOM queries. See

http://www.domassistant.com/slickspeed/

The real problem you will have, is that normal event binding causes problems because of memory leaks (circular references which can’t be handled by the garbage collection of most browsers) and also because you need to loop through all elements and refresh everything after doing changes to the DOM (for example after AJAX requests that modify the HTML). So, at the end of the day, you will want to use event delegation, which comes for free with the controllers of JavaScriptMVC.

I know there is JavaScript “integration” in my favorite Java/PHP/Python/Perl development framework. Am I ready for building a Rich Internet Application now?

Server-side generated JS, like what you will get when using any framework that offers JavaScript support (I’m not talking about JSON/REST here), can be a pain, because almost certainly, you will have a very limited feature set and maybe also problems with deployment and testing, because the common server-side frameworks can’t really test JavaScript code nor is there a smart way to optimize generated code or structure it. Most of the approaches I’ve seen just generate some inline JavaScript which is good for enhancing forms a bit with new input elements/validators or offer some nice visual effects – but that’s it. If something like this needs to be customized a lot and grows big, you might be in trouble. Again, the question is “JavaScript enhanced Web site” or “Rich Internet Application”? To generate JavaScript with a server-side language/framework has it’s limits and is very often not consistent, if you use hand-written JavaScript code at the same time.

What features should a JavaScript framework for Rich Internet Applications offer?

I would argue that a good JavaScript framework allows an average developer to produce effective and structured code. jQuery and the like however are just browser abstraction layers (like Zend_Db is an abstraction layer for databases). Raw jQuery will almost certainly produce the same mess as raw PHP or any other server-side language that does not imply a clean application structure (MVC). You end up with reinventing the wheel and you will have different code to do similar things. Or it will just be plain slow, because without dispatching events (event delegation) you end up with looping over elements to attach events and effects, which simply gets slow for many elements. Also you will have no overview and especially inline JavaScript can’t be compressed, which means you will transfer the same source code with every request. That said, I vote for separating server-side code, JavaScript and HTML and have clearly defined interfaces. A sound architecture is a great help for all developers, as soon as there are more lines of code than fit on a screen. You don’t want to start guessing, if the code you look for is hidden in a JavaScript file, in a template, in a view helper or some other file.

Which browsers are commonly supported for Rich Internet Applications?

Compatibility is not a big issue anymore, if you are fine with supporting IE 6+, Safari 3+ (incl. iPhone), Firefox 2+ and Opera 9.5+. IE < 6 is very hard to support (I would simply refuse to do so). IE 6 is slow with JavaScript, but the real pain is it’s lack of good CSS support.

I want to use W3C standards only (W3C DOM, XML and semantic XHTML) for my Rich Internet Application. JSON, innerHTML and DIV elements are evil, right?

No. If you have a closer look, then you will notice that semantic HTML (for example, using the table element to render a table instead of DIVs) or not using innerHTML sometimes offers very bad performance for DOM manipulations, thus render the complete application useless. innerHTML very often delivers the best performance for inserting content to the DOM. So, don’t decide on certain implementation details upfront, especially if you plan to support IE6, which simply is an old browser and needs some special treatment. JavaScript forces you to be very pragmatic sometimes.

See http://www.quirksmode.org/dom/innerhtml.html

JSON is a standard because it is implied by EMCAScript. See JSON vs. XML.

Using parallel requests to get data from the server seems to be a good idea to speed up performance. Is there any downside?

Depends. A major issue with modern Web applications is that the initial loading causes many parallel requests, as you just deliver the page grid and the JavaScript client side code then renders all the other elements from client-side templates and loads the corresponding data (if needed) using the mentioned JSON-APIs. A constant overhead is produced when using comet. Parallel requests frequently cause problems, as some server-side session handler implementations lock the session (other requests have to wait then, until the session is accessible again). Also the many requests might require lots of memory and server processes.

I want to thank Justin Meyer (maintainer of JavaScriptMVC) for all the interesting discussions and his input on the JSON vs. XSLT debate.

First Google Chrome bug found

Michael — Tue, 02 Sep 2008 23:30:19 +0000

I just found my first bug in Chrome: If you iterate over object properties (using jQuery’s $.each()) and insert HTML generated inside that loop into the DOM, then that HTML appears in random order. Very funny. Might be a problem with threads or Chrome changes the order of object properties by itself:

http://code.google.com/p/chromium/issues/detail?id=223

JavaScript Components

Michael — Sun, 06 Jul 2008 20:05:02 +0000

My blog was a calm place for a while now, because I’m terribly busy with writing code (like it should be…). With this posting, I want to present the prototype of JavaScript Components, which are comparable to Swing Components in Java. They make use of the Composite Pattern. That means every Component can act as a container for other Components. Together with Models, Views and a Controller (Event Dispatcher), they can form reusable widgets. Other projects did work on similar things (for example jMaki Widgets), but from what I see, they target different audiences. The suggested Components use a client-side only approach. They are tested with JavaScriptMVC, but may be useful for other frameworks as well. jQuery is required for DOM operations.

There already is a LayersComponent, which implements a content stack. Any component can be added as a new layer and only the respective top layer is visible.

Please check out the demo application (download as ZIP).