What is Digg?Sponsored by Realtor.com
Top 5 most ridiculous properties sold for a single dollar view!
realtor.com - Looking for a deal on your next home? What if you could pay a dollar? What if it was a MLB stadium or a university?!?!?
57 Comments
- jmechy, on 10/12/2007, -8/+33wow, yet another example of opera blowing away the competition (except for possibly safari) when it comes to rendering speeds.
- MikeSD34, on 10/12/2007, -2/+20Safaris rendering engine ( WebKit ) was originally based off of Konquerers rendering engine ( khtml ).
- Progranism, on 10/12/2007, -5/+19Why is this being done client-side? Shouldn't it be on the server-side?
And I agree with jmechy, the performace of Opera is impressive :D If only it had extensions like Firefox :( - sugarskane, on 10/12/2007, -2/+15It seems like more work than it's worth...
- bbatsell, on 10/12/2007, -0/+12@kubudu*
It's not any sort of an obfuscated secret; yes, Safari is based around the KHTML and KJS engines from Konqueror. The Safari team (lead by Dave Hyatt) has done extensive development of the engines (called WebKit on Mac OS X), which is open-source ( available at http://webkit.opendarwin.org/ ), and the Konqueror team has free access to the code. However, in the past the Konqueror team has complained that their code is tailored exclusively to Mac OS X and requires significant effort to merge into the Konqueror branch. This may be why you dislike Konqueror even though it appears that you like Safari. - rmccabe916, on 10/12/2007, -2/+13Have you taken a look at http://files.myopera.com/Rijk/blog/extensions.html ? It tells you whether or not you can get the same extension functionality in Opera.
- inkswamp, on 10/12/2007, -2/+10From the article: "Using innerHTML approach can be dirty, mostly because HTML code is spread around. "
That's ridiculous. I don't understand the aversion to innerHTML, and if using it seems dirty, then perhaps a closer examination of your coding habits is in order. I've used it extensively and never once had a problem because "code is spread around" or because it's "dirty." Maybe that makes sense if you're dicking around with any given HTML tag, but I tend to access innerHTML on the level of DIVs and not anywhere else so maybe that's my big secret. (For example, I don't replace the contents of an A tag, but rather surround the A tag in a DIV and then entirely replace the DIV conents, rewriting the entire A tag.)
Anyway, I have yet to have a single problem with using innerHTML and I do this stuff professionally. I think that warning is bunk. - dtfinch, on 10/12/2007, -2/+9I might stick to innerHTML. Fast, easy, simple, and clean (ymmv).
- Fullmoon, on 10/12/2007, -3/+8But Safari vastly improved upon Konquerors performance, especially in recent nightly builds of WebKit.
- FlaG8r, on 10/12/2007, -0/+4Some debate on innerHTML:
http://www.developer-x.com/content/innerhtml/ - oferrer, on 10/12/2007, -1/+5As people already said, WebKit (the rendering engine) was based on khtml, but that's as far as it goes. Safari's Interface and funcionality looks or feels nothing like Konqueror.
- pkulak, on 10/12/2007, -5/+9Adblock Filterset.G Updater Not available
- geronimo, on 10/12/2007, -0/+4That's useful for certain applications. If you have a lot of JS code, like digg, it would be very useful. You can take it a step further though. What if you have it "pre-compile" each template so it maps the name to the index in the template string, storing the text around the templates. Then you can do the template replacement a little faster -- instead of scanning through the string over and over, you simply just append things. If youre template is ":linktext" then you store the array ["",""] then you store the map {"blah"->0,"linktext"->1} when you compile the template. To use it just give it blah and link text then it appends everything accordingly.
I did a similar thing in one of my java apps(Go from String to StringBuilder/TextBuilder) and the runtime went from hours to a few seconds.
If you abuse innerHTML, these little improvements could be very worthwhile. - haackers, on 10/12/2007, -2/+6ya innerHTML is very clean and easy to implement!!
- bornhj, on 10/12/2007, -0/+3Apparently it's non-standard, but it's implemented in every browser I know of anyway. Even better than the XMLHttpRequest object (also non-standard, but not the same in every browser (IE)).
- geronimo, on 10/12/2007, -0/+3Wow, digg royally chomped up what I thought was a good example, oh well.
- sum4me, on 10/12/2007, -2/+5How is RND faster or close to innerHTML? it takes more time than innerHTML in every broswer. although, must say overall opera's numbers are impressive.
It is too complicated also. - geronimo, on 10/12/2007, -2/+5@fabriciom
"This is not practical, who is going to write a website template on JS just to gain some microseconds on rendering."
Wow. Let's see, maybe digg? Dunno. I've just written tons of js code that abuses innerHTML, and I can say for sure this is useful.
And nice spam for your consulting services. Is everyone there as ignorant, closed minded and a big jerk there like you? I think you shouldnt spam here. - akkuma, on 10/12/2007, -0/+3@inkswamp
I do this professionally as well, but the only reason to avoid innerHTML is that it isn't a standard that browsers have to support in the future as far as I recall. The problem with not using innerHTML compared to createElement for large applications (dynamically generated tables that contain 2k+ rows) is that it is extremely slow on older computers, which you have to take into consideration. On top of this, if your server is directly sending you html, innerHTML is the only solution that makes any real sense. - erikuma, on 10/12/2007, -0/+2The link doesn't work anymore.
- Fullmoon, on 10/12/2007, -3/+5Incorrect. Safari does not has big problems with badly coded "IEML" webpages.
Have you actually ever used Safari? - inkswamp, on 10/12/2007, -1/+3The Web is just too new to become a Luddite about it. While some adherence to standards is a good thing, too much can throttle progress. Whether innerHTML was standards or not didn't enter into my comments because I think it's irrelevant. When something is as widespread in usage as that, it's standards. Period.
- Agret, on 10/12/2007, -1/+3Just use innerhtml, it's less complex and from his benchmarks it is faster.
- inkswamp, on 10/12/2007, -0/+2> A significant part of the problem many people have with innerHTML
> is that it was originally a Microsoft IE proprietory property.
I doubt that's the case. But even assuming you're right, then you have to consider that the main reason people hate MS is because they do these kinds of things in the first place, so your argument is a bit circular. And anyway, I loathe MS and I'm perfectly comfortable with innerHTML so I present myself as a counter example.
The arguments againt innerHTML are valid from a certain perspective, but I don't adhere to that point of view for many reasons. The primary reason is that, underneath the argument, is the idea that we dumb Web developers have to be saved from ourselves. Well, pardon me. I understand the problems with innerHTML and I use it anyway. Then again, I code carefully enough to where the "messy HTML" issue never becomes a problem with what I write. On a certain level, I resent the attitude that I'm just too dumb to use something like innerHTML. - merreborn, on 10/12/2007, -0/+2"This is not practical, who is going to write a website template on JS just to gain some microseconds on rendering"
The performance gains are versus other js-based rendering.
The fastest rendering is still done in pure HTML, sans javascript.
As such, there is no case in which anyone would ever "write a website template on JS just to gain some microseconds on rendering". It'd be like biking to school instead of driving, because biking is faster than walking. - daikiki, on 10/12/2007, -0/+2Gods. I've encountered that myself. In IE's defence, chances are the server itself is sending a 304 "not modified" response. I'm not sure what the standards say, but it's not really surprising behaviour. Just slap a unique key/value into the get request to fix this without having to bother with the headers.
- daikiki, on 10/12/2007, -1/+3I'm not sure, frankly, what the problem with innerHTML is. I use it regularly and other than some IE specific caching problems*, it works flawlessly. I find the author's dismissal of its usage somewhat cryptic.
*Images loaded from an innerHTML element loaded after the page has loaded are not cached at all in IE. If you use the same image often, for example in a background, it gets fairly painful. The solution is to cache the image in some some static html that's loaded before the script that sets the innerHTML element is started. - inactive, on 10/12/2007, -8/+9And Opera doesn't eat memory like Firefox Extensions do.
- zambuka, on 10/12/2007, -0/+1A significant part of the problem many people have with innerHTML is that it was originally a Microsoft IE proprietory property. That's pretty much the majority of it, the thought is that since it was made by Microsoft it can't possibly be good or useful, it isn't part of the W3C DOM. There are plenty out there who refuse to make use of the property purely on principle.
Sure, innerHTML does have its problems, namely it takes any old string regardless of how badly formed and tries to stick it into the tag, it doesn't do any checking and it is easy to stick in incorrect HTML. This is easy to resolve by making sure the string you are putting in there is correctly formed HTML to begin with.
Basically there is no real reason to not use innerHTML as long as you are willing make sure you are outputting valid HTML, which you should be doing anyway. - donte, on 10/12/2007, -0/+1Just set some no-cache headers in the response on the server side... problem solved:
// Java
response.setHeader("Pragma", "No-cache");
response.setDateHeader("Expires", 0);
response.setHeader("Cache-Control", "no-cache");
I use all 3 headers because various browsers seem to look for different headers to determine if it should be cached. - vijayanand12003, on 02/15/2009, -0/+1you can get lots of templates here
http://bestwebsitetemplates.org - joshiesurber, on 10/12/2007, -0/+1My main problem with innerHTML is that I serve my pages as application/xhtml+xml (I also use XHTML 1.1) so it doesn't work with my scripts.
- lancefisher, on 10/12/2007, -0/+1Yes, innerHTML rocks, and perhaps it should be part of the standard, because it isn't going away anytime soon.
- amix, on 10/12/2007, -0/+1"Why is this being done client-side? Shouldn't it be on the server-side?"
The advantages to code some of the HTML client-side:
* Performance: Your server will choke if you render everything server-side.
* Dynamic UI: It's easier to create it using dHTML than using pure HTML.
* Bandwidth: JSON or XML data is a lot smaller than pre-rendered HTML. - vijayanand12003, on 02/15/2009, -0/+1you can get lots of templates here
http://bestwebsitetemplates.org - HoLyVieR, on 10/12/2007, -0/+0Well these comparation are not really good because if you look closer you will see that IE was a test on a completly different machine than the other one ... this may explain why is it far away from the other. IE isnt the fastest browser i ever saw but i don't think it's that slow.
- EvanCarroll, on 10/12/2007, -3/+3"super simple and super fast", so bold as not to warrant reading.
- h3smith, on 10/12/2007, -0/+0Personally, my website/application I don't support older browsers. I refuse to.
But then again, I don't think someone using IE 5 will be advanced enough to want to use my webapp anyway to store personal data... - cowardlydragon, on 10/12/2007, -0/+0A better question: why do people do all this server-side? Rather than have racks of servers to track session state and transform HTML around back-end server data, why not distribute to a source of underutilized processing power? Your PC.
I haven't looked at RND, but I do like Trimpath, which had a velocity-style macro language.
BTW, use a simple nonvisual java applet to track session, and you don't need racks of servers with huge memory spaces to store user sessions in memory. Bonus: you don't have to have sesssion timeout to conserve server memory if you put it on the web client. The session will stay around as long as the browser instance is valid. - banjopetri, on 10/12/2007, -0/+0whoopee.. it's sprintf with named parameters. probably everyone who's done some serious js programming has written that function before.
- sakabako, on 10/12/2007, -2/+2This week I had the problem where IE was cacheing the responseText from an xmlhttp call, preventing updates. I couldn't believe it.
- PileOfMush, on 10/12/2007, -0/+0The purpose of the test isn't to compare browsers or platforms. It's to compare the 4 methods of doing the same task WITHIN each of those browsers/platforms.
- yenta4shop, on 09/07/2008, -0/+0http://www.yenta4shop.co.uk/
http://astore.amazon.com/12.volt.battery.charger-2 ...
http://astore.amazon.com/5.gallon.water.bottle-20
http://astore.amazon.com/aerobed.raised-20
http://astore.amazon.com/bug.zapper-20
http://astore.amazon.com/flowtron.insect.killer-20
http://astore.amazon.com/furniture.chaise.lounge-2 ...
http://astore.amazon.com/inflatable.bed-20
http://astore.amazon.com/steam.cleaner.mop-20 - jellygraph, on 10/12/2007, -3/+2I use Konqueror, and its fast and wonderful :)
- yogastore, on 06/27/2008, -1/+0http://astore.amazon.com/la.crosse.atomic.clock-20
http://astore.amazon.com/la.crosse.technology.wire ...
http://astore.amazon.com/upright.bagless.vacuum-20
http://astore.amazon.com/dyson.upright.vacuum-20
http://astore.amazon.com/hoover.bagless-20
http://astore.amazon.com/hoover.canister-20
http://astore.amazon.com/pyrex.storage-20
http://astore.amazon.com/pyrex.storage.lids-20
http://astore.amazon.com/inflatable.bed-20
http://astore.amazon.com/aerobed.inflatable.bed-20 -
Show 51 - 62 of 62 discussions
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is