next »

[m0nkeymafia]

Not contributed anything here yet so heres a little advice for yall

Not sure if you guys do, but dont use innerHTML where you can help it in ur js.

Not only is it not in the proper specs but it sucks big time for a number of reasons:

- It leaks like a whore, seriously, any intensive or persistent web app using innerHTML will probably die
- What you think you assign using innerHTML isn't what gets written, your browser adds stuff
- This means if you think you can traverse your new elements like you thought you could, your wrong
- It promotes bad programming practice with regards to JS, you should be creating objects, and children the proper way
- DONT USE IT

I managed to get IE's memory footprint up to about 600mb after I left one of my ajax apps running using innerHTML.

[perkiset]

Sorry MM, gonna have to disagree with you here...

- It leaks like a whore, seriously, any intensive or persistent web app using innerHTML will probably die

Persistent webistes with JS running leak all by themselves. innerHTML is no more leaky than JS IME. They all leak and suck though...

- What you think you assign using innerHTML isn't what gets written, your browser adds stuff
- This means if you think you can traverse your new elements like you thought you could, your wrong

Don't get you here... I'm a pretty strong JS/DOM guy and I do exactly that all the time. The DOM tree looks wonderful after I drop some HTML into an object. It is important to note that HTML itself will not necessarily create a DOM tree the way you expect it... for example, if you go <table><tr> in FF that's what you'll get... but if you do that in IE you'll get a table node that contains a TBODY node that contains your row... you have to explicitly add the TBODY in FF (and everywhere else I've test for that matter).

In fact, I'm working on the next installment article for my "Argument Against Ajax" thread in ajax discussion and I'm using one of my pride-and-joy pages that does a whole bunch of combo innerHTML, DOM walking and standard JS element assignment all wrapped up into one extraordinary (if I may say so myself  ) packge. Has been working wonderfully for more than a year now.

- It promotes bad programming practice with regards to JS, you should be creating objects, and children the proper way

I'd agree if you're using innerHTML instead of proper JS assignments because you don't know what you're doing... if you only know innerHTML then you're REALLY missing out. You're absolutely right that innerHTML is NOT a panacea... but it is a great tool to have in the toolbox as well. My next article will discuss this very point in detail.

I managed to get IE's memory footprint up to about 600mb after I left one of my ajax apps running using innerHTML.

Like that's some big feat... I can blow out Safari and FireFox almost effortlessly - and IE is just a JOKE. "Garbage Collection" and "Managed Memory"  that simply means that you have no idea when you're about to run out or start swapping... Grrrrrr snap snarl rowr.... hate that shit.

 

OK I'm better now.

/p

[m0nkeymafia]

Persistent webistes with JS running leak all by themselves. innerHTML is no more leaky than JS IME. They all leak and suck though...

Not true, I managed it with a bit of care and attention. [in IE6 too]
It grabs new data every 6 seconds, uses an XSL parser etc

It runs indefinately on IE 6 and everything else.
XMl / XSL and a call every 6 second.
I construct graphs, tables, charts, and even do opacity n stuff!

RE Dom Tree
Yes it looks beautiful because you KNOW what IE is going to "add" to the html you specify, 99% of people out there dont.

The point I was badly trying to make was that innerHTML isnt a standard, so there is no defined method of operation.
Meaning you cannot be guarunteed that innerHTML in IE7 will work the same way in IE8 and so forth.

[perkiset]

I construct graphs, tables, charts, and even do opacity n stuff!

... alpha channel stuff in straight JS? What is this voodoo?

Meaning you cannot be guarunteed that innerHTML in IE7 will work the same way in IE8 and so forth.

Fair enough. You're correct, that the vast majority of my turn-up time in JS was dedicated to ferreting out the fucking browser diffs... my solve was to write classes around them so that I can talk in <my> way without regard for how the browser wants to talk. But I also don't think there are that many people out there that cross over between innerHTML and walking the DOM... so if they're only able to use innerHTML then they prolly won't care *what* the DOM is doing.

Re. leaky: I have an app that simply loads an array with image sources every 30 seconds (6 elements) for a manually created animation. It is essentially a timer, an image source loader and replacer eg.,

Code:

function onTimer()
{
if (++currentPtr > maxImages) { currentPtr = 0; }
theMainImageOnTheSite.src=arrayElement[currentPtr].src;
}

... leaks like a seive. The replacement of the images is what does it I think - JS should be disgarding the original memory if I replace the array graphic reference, but it would appear that it does not... or maybe it's in the DOM item where I am replacing the image... but in any case it leaks horribly. And it's not a race or lack of time for garbage collection because the site is quite for 30 seconds inbetween.

I think it sounds like you've done great work locking down your app... my point was not to slam your coding but moreso that if you and I have these sorts of troubles, can you imagine what troubles first-year programmers that are copy/pasting JS code into a site must get? Yikes.

/p

[m0nkeymafia]

Yeah all true bud

I think you solved your own problem.
JS keeps loading the images back in, and is probably getting lost [though you may have a circular reference thingy going on]
So instead of loading new images, why not create a class for each state in css.
Then all you need to do is swap classes.  Meaning the browser [and not the js, if we can make that distinction] will take responsibility for loading and managing the memory of the images.  That should help the leak loads.

Also if your still having problems, and if you can, try tile your images into one big image and use css to position them.
That way you could only have one image, contained X other images, and you simply position the image as a background to an element in order to show the right image!

P.s. I use JS + XSL to create my xhtml fragments with the right classes and the opacity stuff is all done via css.

[perkiset]

So instead of loading new images, why not create a class for each state in css.
Then all you need to do is swap classes.  Meaning the browser [and not the js, if we can make that distinction] will take responsibility for loading and managing the memory of the images.  That should help the leak loads.

Oooh... got the gears spinning there.. gonna have to give that a think in context with this app, but understanding the dynamics of that sort of technique is good. Nice one!

P.s. I use JS + XSL to create my xhtml fragments with the right classes and the opacity stuff is all done via css.

I didn't think that opacity was a universally supported (or consistent) property for CSS... do you find otherwise? I just did a quick google and it looks as though it's supported now... honestly I haven't given that a thought for a couple years  ... fuck dude you've got me gears spinning about cool stuff when I should be working!!! 

/p

[m0nkeymafia]

Haha
Luckily I learnt all that through my job, and trust me, you will see this everywhere, my web design will literally be in hundreds of thousands of "places" worldwide, and im not talking net

But yeah wickid mate always good to invoke new thought into an old / current project
Let me know how you get on

P.s. i think that css image thing is called css tiling, try google it

P.p.s the opacity thing requires a few css hacks, so not overly clean but aint too bad really