Having been put on a web project a couple of months ago that requires emulating a ten-year-old design with some serious data transfer problems, I've been making sure to test my code in three different browsers: Microsoft Internet Explorer 8 (with "compatibility view" on and off), Mozilla Firefox 3.5, and Google Chrome 4. My default browser when not testing, though, has been Firefox 3.5.
Why do I use Firefox 3.5? It's simple, AdBlock Plus. This extension blocks most if not all unwanted ads, and I find pages easier to read without the ads. The lack of ad-blocking kept me from switching to Chrome.
Well, Chrome now supports extensions, and one of those extensions is AdThwart (https://chrome.google.com/extensions/detail/cfhdojbkjhnklbpkdaibdccddilifddb). AdThwart can use the same filter lists as AdBlock Plus. I tried out AdThwart, installed it, and have now switched over to Google Chrome as my default browser. Why? Because it gives me more screen real estate, usually-faster-but-sometimes-slower page loading, nice highlighting of active fields, and appears to use less memory to browse the same amount of web pages (using Task Manager to compare memory usage - no proper benchmarking yet).
It was dirt-simple to import my bookmarks, stored usernames, and stored passwords from Firefox into Chrome (this scares the hell outta me! I thought those passwords were stored securely?!).
So, is anyone else using Chrome as their default browser? Are there any pitfalls I should watch out for? Are there any things you like about it that you want to share with the world?
I am using it on my Work PC I have been going back and forth between ADBlock and AdThwart... I find AdThwart jumbles some pages I go to, nether have the same deep hooks that are in the FireFox version so I notice a flash before ads are removed on some sites.
AdBlock https://chrome.google.com/extensions/detail/gighmmpiobklfepjocnamgkkbiglidom
AdBlock button add-on: https://chrome.google.com/extensions/detail/picdndbpdnapajibahnnogkjofaeooof
I am using the built in bookmark sync between my work and home systems, it works very well. Over all I find it very clean and smooth to use, as well as a little faster than Firefox.
Watch that memory use though, each tab is its own process, raeofsunshine always leaves a piles of tabs open and we looked at her use under both and found Chrome used much more memory over all but was more responsive and memory was freed better when tabs closed.
She also has noticed how often FlashCrashes as Chrome has a Sick computer logo that appears when plugins die.
More recommended plugins.
Google Mail Checker Plus https://chrome.google.com/extensions/detail/gffjhibehnempbkeheiccaincokdjbfe
IE Tab https://chrome.google.com/extensions/detail/hehijbfgiekmjfkfjpbkbammjbdenadd
I have FF, IE, and Chrome in use, just to see what is the best option for me.... and well it seems I still need all three to make things work.
IE for a lot of Microsoft/Vendor application sites that still don't work so hot even with IE Tab.
FF for web development plugins and greasemonkey support.
Chrome for simple web browsing and general surfing as it seems to work fastest at this.
Most of the time though I'm in FF which is plugin loaded at work for a lot of different things. Chrome is catching up, but just doesn't have everything I need.
Quote from: Lazybones on February 24, 2010, 01:12:21 PM
I am using the built in bookmark sync between my work and home systems, it works very well. Over all I find it very clean and smooth to use, as well as a little faster than Firefox.
I haven't gotten there yet, but that sounds like an awesome idea - keeping bookmarks synced between different computers. Except, of course, if you really want to keep your work and home bookmarks separated so you don't accidentally click on NSFW bookmarks.
Quote from: Lazybones on February 24, 2010, 01:12:21 PM
Watch that memory use though, each tab is its own process, raeofsunshine always leaves a piles of tabs open and we looked at her use under both and found Chrome used much more memory over all but was more responsive and memory was freed better when tabs closed.
Because each tab runs in its own process, Windows has an easier time of swapping memory in and out as well as being able to handle a tab crash more eloquently. This, in turn, will make each tab seem more responsive. Keep in mind that all those tabs you're not using can get their entire memory space written to the page file, so if there are a lot of tabs open chewing a lot of memory, but those tabs are all in the background, then just up the pagefile size.
Thanks for the suggestions on other extensions. I looked at GMC+, but I have Trillian installed at work to notify me of emails, and can click on unread emails in Trillian to do something with them in Gmail. IE Tab, well, I just use IE when I need it. Sorta weird, but there's three browsers on my machine now (both at work and at home).
Hehe, speaking of Trillian, I'm using a different multi-messenger called Pidgin now. Trillian would just crash to often for me :(
Hmm, haven't had any crashes with Trillian yet. And it's been on my work machine for several months. Mind you, I'm using Trillian Astra, and have read reports of crashes in older versions.
How is Pidgin treatin' ya?
This thread (http://forums.righteouswrath.com/index.php/topic,7199.0.html) might be better for the IM discussion. FYI about Pidgin is that it stores all your account passwords in plain text locally.
My normal browsing habits don't allow me to use Chrome. Its worse with memory than Firefox is. At least firefox will run decently for a few weeks before I need to kill it, where as chrome will easily eat up 2-4G in a few days, if not less.
Remember the good old days of running only one program at a time? I remember when TSR (Terminate and Stay Resident) was an absolutely mind-blowing concept! Now we're complaining about not being able to leave four dozen programs running for weeks on end.
Anyway, as an open-source proponent, have you made any bug reports to the Chromium project, upon which Google Chrome is built? If not, I'm sure they'd be happy to hear of your memory woes.
As for memory usage, I've had the opposite effect here at work - Firefox quickly climbs to above 500MB, and if I leave it running overnight the the next morning it's over 1GB memory used. And then my machine really starts lagging, as Windows doesn't seem sure how much of Firefox's memory can be swapped out. With Chrome, I haven't noticed said morning-lag.
I use Chrome, you know why? Firefox, even stripped of plug-ins etc is a SLOW ASS BITCH.
Seriously, I go to a lot of script-heavy sites (goddamn sploicers, err, I mean art sites) and the only thing that doesn't make it pure pain is Chrome. Quicky, easy, you get in you get out.
There's a lot of stuff I don't like but, it's fast so it wins.
I used to be a plugin junkie, but really I can use other programs for a lot of that stuff.
Quote from: Thorin on February 24, 2010, 05:40:18 PM
Remember the good old days of running only one program at a time? I remember when TSR (Terminate and Stay Resident) was an absolutely mind-blowing concept! Now we're complaining about not being able to leave four dozen programs running for weeks on end.
Anyway, as an open-source proponent, have you made any bug reports to the Chromium project, upon which Google Chrome is built? If not, I'm sure they'd be happy to hear of your memory woes.
As for memory usage, I've had the opposite effect here at work - Firefox quickly climbs to above 500MB, and if I leave it running overnight the the next morning it's over 1GB memory used. And then my machine really starts lagging, as Windows doesn't seem sure how much of Firefox's memory can be swapped out. With Chrome, I haven't noticed said morning-lag.
If you're a light user, Chrome /seems/ to be ok memory wise. But open up a few windows, with two of them having 20+ tabs open, you'll see Chrome eating up 2-4GB ram easily. Where as at that point firefox sits at 1-2G. (which imo is still too much, the only reason I'm not using konqueror still is because its buggy as crap right now)
I really did like how fast Chrome was, but its not worth it for me when it makes my dual core laptop with 4G ram feel like a p2 500 ;) or my quadcore with 2-4G (2G right now, 2G recently died) ram feel like a p2 400 running XP.
I'll probably try Chrome again, its possible it was just the build I tried that was buggy or something. But not right now ;D
It may wear on the CPU and eat memory a bit more heavily but I'm willing to give up spare cycles and a couple of gigs of ram to be able to cruise the net without waiting for the browser to play catchup.
I swear, after FF3 it all went to hell for Mozilla...
Quote from: Mr. Analog on February 25, 2010, 05:49:57 PM
It may wear on the CPU and eat memory a bit more heavily but I'm willing to give up spare cycles and a couple of gigs of ram to be able to cruise the net without waiting for the browser to play catchup.
I swear, after FF3 it all went to hell for Mozilla...
I wouldn't mind a couple Gigs much, but when I start swapping massively because Chrome uses WAY too much memory, its going a little too far.
Quote from: Mr. Analog on February 25, 2010, 08:02:12 AM
I use Chrome, you know why? Firefox, even stripped of plug-ins etc is a SLOW ASS BITCH.
Seriously, I go to a lot of script-heavy sites (goddamn sploicers, err, I mean art sites) and the only thing that doesn't make it pure pain is Chrome. Quicky, easy, you get in you get out.
There's a lot of stuff I don't like but, it's fast so it wins.
I used to be a plugin junkie, but really I can use other programs for a lot of that stuff.
I've managed to find a problem in the latest stable Chrome release (actually, it's in the underlying WebKit, so Safari will have the same problem). What's this problem? Well, on pages that are a bit larger, with scripts running that access data that is sent in different chunks, Chrome grinds down to a measure-in-minutes-instead-of-seconds speed.
It's been reported to Google here (http://code.google.com/p/chromium/issues/detail?id=35207) and here (http://code.google.com/p/chromium/issues/detail?id=35723). Here's my scenario:
I have a page with a grid with a dropdown list of values for each row in the grid. Normally, this would mean a large amount of HTML in the page to tell the dropdown lists what values to have in their lists. I need to reduce page size, so I use Javascript to load the values into the dropdown lists after the page loads.
When there are only a few values to load, this runs fast (300k page loads in ~2.4 seconds, including running said Javascript). As soon as there are more than twelve or so values to throw in the dropdown lists, this runs horribly slow (same page loads in ~157 seconds, running said Javascript for about ~141 seconds of that).
What I've learned is that browsers get sent web pages in chunks of data; once all the chunks arrive, the page will have been completely downloaded. Looks like Chrome starts rendering and running Javascript before all the chunks arrive, causing a lot of re-rendering and re-running the Javascript, in turn causing a horrendous slowdown (in my case about 65 times slower). Also, this seems to be a Chrome 4 issue, not present in Chrome 3.
Firefox and Internet Explorer may be slower, but I haven't encountered these kinds of bugs creeping into either of them. Probably because they're not pushing their new versions out quite as fast - Google seems content with occasionally breaking its software.
Quote from: Thorin on February 26, 2010, 10:15:54 AM
What I've learned is that browsers get sent web pages in chunks of data; once all the chunks arrive, the page will have been completely downloaded. Looks like Chrome starts rendering and running Javascript before all the chunks arrive, causing a lot of re-rendering and re-running the Javascript, in turn causing a horrendous slowdown (in my case about 65 times slower).
setTimeout("X();", 50) is your friend -- my guess is if you have that at the very bottom of the page, it will execute after all those "chunks" are actually loaded, and your function can do the populating or field modifying or whatever magic it does.
Also could have a ".onload" event that fires X() -- but from my experience it's the same result, but more "dependable" with the end-of-document .setTimeout() method.
My script is already using timers (from the setTimeout() method, not intervals from the setInterval() method - they are different beasts even though most online tutorials discussing the two treat them as interchangeable).
I've optimized the script to the point where it's still fairly responsive to the user but runs quick. setTimeout() injects a lot of unnecessary waiting, so I run through one-tenth of my dataloading loop then use setTimeout() to let the UI update, then run through the next tenth. I think they call this "green threading", where you simulate a thread interrupt using a timer. In Firefox and Internet Explorer, this gives acceptable updates to the user while still running at a decent speed.
More UI updates = longer time to finish loading, less UI updates = shorter time to finish loading but users who think it froze and click refresh. So I've picked the arbitrary value of one-tenth, and used that as my frequency updater. If I'm loading 1,000 dropdown lists, then I'm calling setTimeout() 10 times, once to kick off each batch of 100 data loads.
My first call to setTimeout() obviously has to come when the page has finished loading. In ASP.NET this is done by registering a startup script, which I do. Said script is emitted at the end of the page. There'll be a few bits after it (ending script tag, ending body tag, stuff like that), but the script is clearly in the last chunk of the page.
Thing is, packets don't travel across the internet at exactly the same speed or even order. The chunks a web page are sent in are one or more packets in size. Browsers are supposed to be smart enough not to start rendering until all chunks are completely received (meaning all packets have been received), but in the latest WebKit, that Chrome and Safari are based on, some bug crept into the rendering/script-running engine that causes it to re-start rendering and running scripts hundreds of times for operations that take over a certain amount of memory. See the bug reports I attached earlier. If I go back to Chrome 3, my script runs blazingly fast, so it really is a bug in Chrome.
Quote from: Thorin on February 27, 2010, 02:47:31 PM
My script is already using timers (from the setTimeout() method, not intervals from the setInterval() method - they are different beasts even though most online tutorials discussing the two treat them as interchangeable).
I've optimized the script to the point where it's still fairly responsive to the user but runs quick. setTimeout() injects a lot of unnecessary waiting, so I run through one-tenth of my dataloading loop then use setTimeout() to let the UI update, then run through the next tenth. I think they call this "green threading", where you simulate a thread interrupt using a timer. In Firefox and Internet Explorer, this gives acceptable updates to the user while still running at a decent speed.
More UI updates = longer time to finish loading, less UI updates = shorter time to finish loading but users who think it froze and click refresh. So I've picked the arbitrary value of one-tenth, and used that as my frequency updater. If I'm loading 1,000 dropdown lists, then I'm calling setTimeout() 10 times, once to kick off each batch of 100 data loads.
My first call to setTimeout() obviously has to come when the page has finished loading. In ASP.NET this is done by registering a startup script, which I do. Said script is emitted at the end of the page. There'll be a few bits after it (ending script tag, ending body tag, stuff like that), but the script is clearly in the last chunk of the page.
Thing is, packets don't travel across the internet at exactly the same speed or even order. The chunks a web page are sent in are one or more packets in size. Browsers are supposed to be smart enough not to start rendering until all chunks are completely received (meaning all packets have been received), but in the latest WebKit, that Chrome and Safari are based on, some bug crept into the rendering/script-running engine that causes it to re-start rendering and running scripts hundreds of times for operations that take over a certain amount of memory. See the bug reports I attached earlier. If I go back to Chrome 3, my script runs blazingly fast, so it really is a bug in Chrome.
Well technically most browsers try to start rendering before all of the content (images and stuff) arrive. As for packets arriving in odd orders, TCP makes that impossible. The actual html content will all arrive in an ordered stream, a TCP app will never see packets arrive out of order as the OS has re assembled the TCP stream. But yes, a browser should try and be smart about when it starts rendering.. If theres scripts in the head, most browsers will not do any rendering till the entire page has arrived, since the js usually depends on the html content.