DOM and Javascript engines still need few more man-centuries of iteration to bring their performance closer to e.g. JVM which doesn't really require hacks like that anymore.
Is this the case?
I used to be pretty in-touch with Java, but haven't been keeping up from the release of 7 onwards. I've picked it up again for game development, and 100% of the performance advice I've found is to use object pooling... but nearly all of that advice is years old, and I have no idea if it still holds true for JRE7 or even JRE6.
It did strike me as something the JVM should be doing for me, so if that has been fixed, that news will be greatly welcomed by the Java game dev community.
-- Brian Goetz in 2005
This article was also written when Java 6 was starting to get escape analysis, which can result in stack allocations in some cases.
I recall taking a course in 2008 or so (Java 6). We were doing a genetic simulation of sorts, and the professor recommended using an object pool to speed things up. I implemented one and observed no measurable difference in my code's performance (these were very small objects used over and over again evolving new organisms). I hooked up a profiler and used that to guide me to some areas that could be improved, and a valuable lesson was learned.
You dont have to use all these tricks when you use IOS or Android widgets.
And usually developping with Xcode or Eclipse IDEs makes the work far more easier than using any JS ide.
Instead of using Javascript for the UI i usually use it to implement bits of business logic , algorithms i can easily port from plateform to plateform , so i get native UI and portable JS libraries.
I havent gotten too deep in native development on either platform, but don't they prioritize tasks automatically? JS doesn't, using requestAnimationFrame and web workers is doing exactly that. Wasn't the main knock against Android's UI lag because everything happens once allowing blocking and it was addressed with project Butter?
This article is correct, and provides an example, in saying that the DOM can easily create thousands of elements in milliseconds. However, the problem is that events and interactions with it all happen on a single process. Things load and block the thread, an event happens and blocks the thread, etc.
The Sencha guys did something really smart. They used an object pool with one object: requestAnimationFrame, as the core of their mobile platform and sent EVERYTHING to it. That way events, loading, or whatever, didn't block, but happened in a FIFO manor. They also kept the number of dom elements static and just reused them when needed, so an object pool of dom nodes -- no creating or destroying nodes.
The things that make working with the dom slow isn't only creating nodes, but applying styles, listeners, and destroying them -- basically creating an application.
I do agree with the overall premise that a lot of developers do not know the best methods/practices/patterns to utilize when creating complex applications. I learn new things daily and I hope that our community continues to teach itself and provide tools to make getting things done easier.