While browsing with Chrome, I noticed that it responds extremely fast (in comparison with IE and Firefox on my laptop) in terms of rendering pages, including JavaScript heavy sites like gmail.
This is what googlebook on Chrome has to say
tabs are hosted in process rather than thread.
compile javascript using V8 engine as opposed to interpreting.
Introduce new virtual machine to support javascript heavy apps
introduce "hidden class transitions" and apply dynamic optimization to speed up things.
Replace inefficient "Conservative garbage colllection" scheme with more precise garbage collection scheme.
Introduce their own task scheduler and memory manager to manage the browser environment.
All this sounds so familiar, and Microsoft has been doing such things for long time.. Windows os, C++, C# etc compilers, CLR, and so on.
So why isn't Microsoft or any other browser vendor taking Chrome's approach? Is there a flaw in Chrome's approach? If not, is the rest of browser vendor community caught unaware with Google's approach?
Chrome's approach is difficult to write, and requires forethought from the developers. IE and Firefox are both attempting to move to a process-per-tab model, but due to backwards compatibility are not able to transition quickly. Chrome, being an entirely new browser build on a clean rendering engine (WebKit), was easier to write in this way.
They have crossed over from a web browser as a tool to view web pages, to a tool optimized to work for web applications. There may be some flaws in this initial release, but they are changing the game.
IE8 uses a similar individual process per tab module, though they do not use a single process per tab, but instead spread all tabs across a process pool.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
Thats actually a WebKit feature, Chrome just inherited it.
Virtually all of these features existed in other browsers before Chrome. IE8 had process isolation for tabs. Firefox / Safari had most of the JavaScript stuff. Most browsers do their own memory management.
Chrome has a few unique features (hyperrestricted render processes, etc) which are difficult to put into other browsers due to add-on/application compatibility concerns.
The primary thing Chrome has going for it is an extremely hardcore focus on minimalism and high-performance. By focusing on these as their competitive advantages, they can appeal to users who find this area of focus compelling.
As time passes, I'm sure you will see the homogenization of features as the browsers attempt to one-up each other.
In the meanwhile, I still stick with Firefox over Chrome for the simple reason that Firefox is (i) non-profit and has a (ii) huge addon community.
Addons such as NoScript and AdBlockPlus are almost essential for me.
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
Yeah. I mentioned this on uservoice and got declined because the current size is evidently the default under webkit. Every other site I've tried with Chrome that uses textboxes to compose content manages to have a decent sized font. The default definitely doesn't work, but there's obviously some way to override it. Jeff needs to fix this!
Edit:
Jeff was nice enough to point out how to fix this problem yourself.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
I also wanted to point out that Google completely built Chrome from the ground up, with the exception of using webkit, so they have some of the advantages of not having to not deal with old-code. And of course there is the INSANLELY cool/smart developers.
The biggest chink I've found is its lousy proxy support compared to IE, FF and Opera. So it's pretty much useless at work, render pages at random, and requesting authentication for the proxy, where the others pass it seamlessly.
That said on my home machine it works great, if it wasn't for the OTT EULA I'd use it now.
thing2k
One "flaw" about Chrome is that it uses more memory upfront than all of the other browsers. I'm just guessing that this is due to the overhead associated with all the separate tab management.
After it's been open for some time, however, it doesn't use more memory than other browsers.
Many companies play a game of "What's the least we can do to get the leg up?" Marketing creates a laundry list of features needed to be better than the competitors. Project management ensures engineers stick to those features for fear that the project will exceed the time allocated... which of course it will. There's not a whole lot of room in such a system for a big picture leap-ahead. The incremental improvements you see in products, and browsers, is a consequence.
You have to keep in mind that Microsoft primary business is Rich environement (GUI) Application. Web tool is a threat to them as it is platform independant (not promoting they main product).
Of course the IE team probably had figured something like that but... Microsoft definetly won't invest a lot of money in IE if what they are selling is a Rich application platform.
Related
I am learning how to program and my goal is to build a simple functional prototype...I'm at the very beginning.
I am not concerned with the visual design at this stage, other than as it relates to being able to demonstrate the functionality.
My question is: do I need to worry about ironing out cross-browser bugs in the HTML/CSS, or can I do development on a single browser? (Perhaps a better way of asking this is does the back-end programming have any effect on which browser is displaying it).
If you are at the very beginning and only want a functional prototype, do not worry about cross browser HTML/CSS. In fact forget the CSS altogether and focus on printing just standard HTML. Since the visual design will change, focus on the content, styles can always be applied and switched later.
If you need Javascript/AJAX stuff I would recommend using a library like JQuery that has already solved many cross browser problems for you.
The back-end stuff "Perl, PHP, Python, etc" shouldn't care about the browser as it is simply printing text for the browser to render as it will.
The back-end programming will affect the way a given browser displays your page and there might well be two schools of thought on whether you should be picky about the browser compatibility issues.
On the one hand, if you're just finding your feet in web development it might be asking too much to expect to have a standards-perfect, cross-browser site or application every time. It might be better to focus on actually accomplishing a finished result and learning as much syntax and technique as possible.
On the other hand, it might be argued that it's a good idea to get into the habit of adopting good practices now and recognising the sorts of things that are going to give you headaches... probably when you view your page in Internet Explorer. This takes more time to reach a finished product, but it would teach you good habits up-front.
Really it comes down to your own approach and preferences. Do you want to be detail-oriented and turn out a polished result in a longer period of time, or would you prefer to just get to the finish line and identify issues on a case-by-case basis?
Do car prototypes have a working stereo, leather upholstery, chrome rims, dice, and other random stuff which does not demonstrate the functionality of the newly-designed car?
My rule of thumb is that if it takes you more than 10 minutes to make it look acceptable to others (I'm completely fine with a disgusting design when prototyping), you're spending too much time on the aesthetics and less time on the actual clockwork.
What good does a "pretty-looking" site do if it has no functional layout?
This depends on both your audience and on your tooling. If you are trying to support all users on all browsers, then you will certainly need to do testing on those browsers (although actively developing on those browsers may not be necessary), whereas if you only need to support WebKit-based browsers (Chrome, Safari) or WebKit-based browsers and Firefox, that is less testing that you need to do.
It also depends on your tooling. For example, if you are writing directly in HTML and CSS, then you are much more likely to run into browser compatibility issues. However, if you use a tool such as GWT, which can generate browser-specific output automatically, there are fewer such issues to deal with.
Note that you can use Selenium (aka WebDriver), to automatically test your code on multiple different browsers, even if you only actively develop within a single browser environment. That way, you can know if you've broken something, but not have to constantly manually test in multiple browsers.
I want to make a site from scratch, and Im considering to use Flex to make a R.I.A instead of the standard approach (xhtml + css + some ajax).
The kind of site I want to make is something like e-bay, but less complicated.
But.. I know that 95%+ of the sites like that are built in the previous mentioned techs... so, what are the cons and pros if I want to make a pure Flex site?
Thx.
If you write an entire website in Flash, the entire website lives at one URL. (Short of mucking around with whatever Flash provides to let you offer deeper links.)
Whereas a website written in HTML, unless you go mad with your AJAX, lets people link to the stuff they’re actually interested in, like unicorns:
http://cgi.ebay.co.uk/DESPICABLE-ME-AGNES-Unicorn-Doll-Plush-Character-Doll-/180602861597?pt=LH_DefaultDomain_0&hash=item2a0cc4f81d#ht_1755wt_907
Or for a non-eBay example, Stack Overflow questions:
Flash for business web applications - why not?
HTML also has a pretty standard and understood user interface: links, and form controls. (Mainly links.)
Flash doesn't work on iPhone/iPad. End of story.
Other reasons: not a web standard, often quite slow, not good for SEO, etc.
It requires users to have a proprietary plugin which some users don't want and other users can't have (since isn't available for all platforms (iOS being a key example)).
It also has performance and stability issues on some platforms (OS X and Linux being prime candidates).
While some search engines have started to index Flash content (so long as it exposes the information), the results aren't as good as for content rich HTML sites.
You can do that simply using traditional xhtml + css + jQuery (or any JS framework if you want to increase UX). Flex won't do much in your scenario.
In my experience, performance is not a real issue unless you play video - one can write bad programs in JavaScript, too...
Your pros are mostly on the development side: You can have a great looking site quickly, and you can almost completely forget about browser incompatibilites.
You rely on the customers having the plugin installed, though, and you rely on Adobe's technology for development and playing of the content.
If this is not important to you, and you can afford to do without all iPhone and iPad users, accessibility and standards compliance... go for it!
Flex is good if you want to install as an application using Air. ebay actually has a RIA version, or at least they did for a while.
There are several concerns with a Flash site, some of which Adobe has addressed in the last couple of years.
One is accessibility. It is more difficult to make a Flash site accessible to the visually impaired, who use screenreaders.
Related, people like to be able to copy and paste content, as well as print. With standard web pages, the developer need do nothing to support this, it just works from the browser. With Flash, you'll have to take care to make your text content selectable, and I'm not sure a user could ever select a section of text + images. I've never done it, but I can only imagine that implementing printing ability in your Flash site would be nightmarish, at best.
Another is linking and addressability. For most sites, you can copy or at least get a link that you can share or save to get back to where you want to be. With Flash, you usually go to a single address and then the rest of of your experience happens inside the Flash "window" and the browser isn't actually navigating any pages. It is far more difficult to implement this ability in a Flash site.
A Flash site is usually very slow to load, especially the first time, and page load times are immeasurably important to a site's success.
Finally, you've perhaps heard the furor over the last couple of years about different vendors supporting or not supporting Flash in their products/devices. An all-flash site would be completely inaccessible on any iPhone or iPad, for example, which do not support Flash at all. Furthermore, some employers do not allow plugins like Flash to be installed on work machines, so you'd eliminate that portion of possible traffic, as well.
Nobody has yet mentioned Silverlight.?
I mostly agree with Jay's answer concerning accessibility, but as a further note would like to add that development in Flex/Flash vs HTML/CSS/JS could be more costly not only in terms of money but also for maintenance. Many Flex/Flash devs typically charge a higher price and their dev tools, which are necessary for compilation, usually aren't free, compared to HTML/CSS/JS devs, who often use freely available text editors.
I have the feeling that Flash-based ( or Silverlight-based) websites are generally frowned upon, except when you are creating games or multimedia-content rich applications. Why this is so?
Flash is infamous for its poor accessibility.
Keyboard navigation does not usually work, and Flash (up until recently) did not have search engine support.
Flash applications does not work in mobile phones and other portable devices.
Flash is not there in the iPhone!!!
Flash is controlled by a single company (Adobe) and so it is not following any well defined standards for the Internet.
The beauty of Internet lies in the fact that you can always view the source code of any website you are in. This way you can use the same programming/design techniques in your website or you can find security flaws in the web application. This is not possible in Flash. In Flash, source code is closed.
The big question is, why should you use Flash "except when you are creating games or multimedia-content rich applications"?
jtyost2 says,
"I would also add that you can't directly link to any content inside of a Flash site, thus breaking one of the major factors that makes the Internet, the Internet, links."
content weight
usability
crawlability of search engine bots
accessibility
ease of use (disputable)
technology encumbrance (added software required to access the site)
security issues (needing to add software comes with issues involved with installing or running that software/player of the content)
[Edit] Why I place usability and ease of use separate is best explained in this link
Usability:
a result – software that is usable;
a process, also called user-centered design, for creating usable software;
a set of techniques, such as contextual observation and usability
testing, used to achieve that result;
or
a philosophy of designing to meet user needs?
Ease of use:
Effective
Efficient
Engaging
Error Tolerant
Easy to Learn
I agree with the comments on that site, but this is all debatable...could be a good stackoverflow question: is usability and ease of use the same? IMO part of usability is ease of use and vice versa, but they are not necessarily the same.
I hope I don't enfuriate the more semantical sensitive with this edit :-)
Interestingly everyone here blasts Flash/Silverlight and you would do well to recognise that this is only one side of the coin.
Flash (and Flex) allow web site designers significantly more flexibility and richer content for their site and this works in a variety of situations - e.g. sites relating to movies, or bands, sites for kids, sites for games etc.
Certainly, there are many reasons to not choose Flash/Flex/Silverlight, but one can do sites just as inaccessible in JavaScript these days. I have previously worked with JavaScript products that have no reasonable usability by blind people, or web crawlers.
Flash penetration (from a biased source to be sure) is 99%+ (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html), which means that those that say "would never visit a Flash site" are in the 1% of the population that do no install Flash, do not watch YouTube or movie trailers online.
So, you need to be mindful of your audience. Certain audiences and situations would definitely be better off with plain HTML pages and a minimum of JavaScript (government websites, programming websites are two areas that spring to mind). Other times it is because the audience are office workers that are not allowed to install Flash in the browsers.
Rich Internet Applications (RIA) is one area where there is a distinct clash/struggle between the Flex/Silverlight and JavaScript/CSS/HTML sides. I've worked with both, and I'm now of the opinion that requiring Flex/Silverlight plug-ins is fairly reasonable, though you can still lose some visitors if the application is public.
In summary - you're best to identify your audience, identify what they're willing/able to use and then based on such limitations decide on your technology.
Flash and Silverlight based sites typically go against basic Internet conventions with their closed models.
For example, most Flash & Silverlight based sites:
Ignore the back/fwd button.
Don't allow you to send anyone a URL to a specific place on the site, or bookmark a specific spot for later via your browser
Place the internet in a fixed size box. No dynamic sizing for wider monitors or higher resolutions.
"I was about to click checkout but I wanted to change something so I hit the back button"
In this next rant s/Flash/Flash or Silverlight/g
The Flash application/plugin is a closed source pot of serious undisclosed security holes that expose private data, allow modification of arbitrary files on your hard disk, etc.
Flash files are enormous for basic content. There are more efficient ways of doing things
Flash is slow. The plugin on my Windows PC can hog 100% of the CPU time to play some shitty websites.
Flash is non-standard. There isn't a supported flash plugin installed everywhere. Linux users can't run it without jumping through package management hoops. Firefox users on Windows don't get it by default (well didn't last I checked).
Flash is annoying; your users don't want to be bombarded by animations and jingles and junk just to get some basic information.
No back/forward functions unless the Flash designer wanted to implement them in
Can't view a single page without waiting for all the content/scripts that make up that "page" to load. That's really quite painful if all your user wants is a slice of text and you force the multimedia down their throat.
Most Flash-only sites are really bad; the designers seem more concerned with using all of the features of the flash engine rather than presenting something that's concise and useful to the user.
I am a Flash developer. The firm I work for has no difficulty finding clients who want us to build Flash-based products for them. There is a certain set of applications which it is much easier to develop in Flash than in other environments I have used.
But Flash has its problems. Some above have complained that Flash apps do not include keyboard support. Others say it is because the developers are too lazy to implement it. The truth is that many of the components that come standard with Flash are buggy. At my firm we have had to write our own replacements. One feature that is problematic is keyboard support. I implemented my own support for keyboard interaction. It works well, but required effort. If I were writing a Windows VB app, the keyboard navigation would be provided and would work well out of the box.
The same is true for deep-linking, back-button support, etc. A clever developer will be able to make a Flash app behave well. Some open source libraries are indispensable here.
As for flowing layouts, I just completed a proof-of-concept for this (in AS3) as well. It is possible, but requires much effort. Why do I make the effort? Because of the other things that Flash does well.
My biggest gripe with Flash is that it takes you "out of the browser" into its own totally separate application. This breaks "browser standards" - i.e. the functions I can do in my browser:
Right click
Middle click (for opening links in other tabs)
Selecting text
Copy & paste
Printing
Keyboard shortcuts (since Flash steals keyboard focus)
Back/Forward buttons and the whole "page" concept
Javascript interaction with other elements on the page (I don't think this is possible).
"Inspect element" in Firebug or Chrome, if I wanted to see the source of a particular part of the Flash file, or find the image being used.
Flash has its uses. It's good for content, not webpages.
Printing is often poorly supported and the backbutton does not work.
I think it's a matter of selecting the lowest cost medium to reach your target audience,
be it Flash or Silverlight or JavaScript or plain text.
You can have text-only, JavaScript-only, etc. versions of your site if you have the
money, and your target audience come with different prioritizes.
So my question to you would be: does your website has people who frown on Flash as its target audience? If yes, you need to stay away from it. If not, use anything to give your
visitors a good experience.
SEO is the prime issue. Still Flash is not crawlable. But Adobe is working on it.http://www.adobe.com/devnet/flashplayer/articles/swf_searchability.html for better swf indexing.
Does anybody know a site called YouTube? It wouldn't exist without flash. Flash has great video/multimedia capabilities that simply cannot be ignored.
Flash is amazing when used in the proper way, in appropriate circumstances and when the designer/coder has taken care to embed basic accessibility features.
The thing is, like all good things, there's a lot of abusive use (flashturbation). Especially in the beginning, when people just want to slap Flash wherever they can just to show off.
But I strongly disagree that Flash sites are bad: When made properly, and with good UI design and accessibility, they bring a whole new dimension to the web.
See Steve Jobs' Thoughts on Flash: http://www.apple.com/hotnews/thoughts-on-flash/
Let us not forget that Flash allows web sites to display video, animation, user interaction, etc., and it allows this to be a simple process or a geeky techie one, depending on what you want to do. Many bad Flash sites are down to the author.
If YOU don't like Flash then the answer is simple, don't use it. Don't install the Flash plug-in, or install a browser plug-in such as Flashblock on Firefox. This replaces any Flash movie with a play button, preventing and download until it is clicked.
Better than that though, if you don't like the solution that Adobe or Microsoft are giving you, then come up with a better one, or at least let them know what you don't like, they do take feedback seriously. Support some of the people who campaign for accessibility improvements in Flash, for example visit http://niquimerret.com.
Accessibility is an ongoing issue and not one that will go away, Flash accessibility is improving for people with physical disabilities. In in some cases the use of Flash enhances the experience for people with cognitive and learning disabilities, when an concept or idea is better explained when presented as an animation rather than a page of words and static images.
Flash adds another heavyweight component that's required to properly view a web page. The flash plugins are often buggy and can crash a browser. Flash pages often are used to make cutesy animations and other things that make it harder to quickly navigate a site.
All of the above is true for the wild wild web.
However, for internal business applications, Flash and Silverlight allow the user to have something close to a fully-fledged application in their browser. Accessibility, SEO, and closed source are not very important in an internal application. All that matters is making the user's life easier.
I dislike Flash based websites because what happens if your browser crash or your connection dies for a bit? You have to load it again and go back to the menu, and select the item you wanted to read about, and so on and so forth.
Just don't do it. :S
I don't install Flash on my browsers, mainly to escape the nuisance of animated ads, but also for all the security and privacy reasons mentioned by others.
So sites done completely in Flash are nonexistent as far as I'm concerned. (W.r.t. Youtube, I download videos directly into Miro.)
Probably for the same reason C programmers shied away from Win32 API, Win32 programmers from MFC and MFC programmers from Windows Forms. It's tricky to use and understand - I have tried programming in Flex and am getting along pretty well but it is not inherently designed for typical web application design e.g. there is no native (at least until Flex 3) support for databases or cookies or sessions - you need to put all 3 in PHP or another server-side page and call that from ActionScript.
Try making a simple register/login page with PHP and then again with Flex/Flash and you will see that all the server side crunching is done by someone else - again, this is probably by design since we have HTML/JavaScript for the front-end mixed with ColdFusion or PHP etc. for back-end in "traditional" web applications.
Like started by other people, Flash is bad with the keyboard - try pressing Ctrl-T in Firefox when a Flash object embedded in an HTML page has focus (mouse-over) - so that can be frustrating for the user...
Having said all that, I would still rather make a web application front-end in Flash/Flex than HTML/JavaScript/CSS since the latter needs a sharp learning curve that gets quite bewildering after a while since you have to account for the "good" design aspects of CSS and JavaScript and the bad ones too - and also the peccadilloes that JavaScript/CSS inherently have and those which are introduced by the JavaScript library vendor (Yahoo's YUI, Google's Ajax API, script.aculo.us, etc.
If you are already a web programmer who knows CSS/HTML/JavaScript very well and have a good development environment set up on your PC with all required code inspectors and runtime debuggers etc. etc. then it's easy to keep on working in that (not taking into account end-user preferences) but if you are like me and want to make a web application ready and available for use quickly and want to add features to it quickly while making it pretty all the time, then Flash/Flex is a better option, IMHO.
I am a Flash developer.. and I have found that although Flash requires more effort in coding, the potential is enormous. You can create very simple sites with simple transitions, so subtle it would seem to be a normal HTML page, while still being just as light.
At the same time, you can use OOP with ActionScript to create a website that is as complex and as inclusive, as well as feels and acts like a desktop application. WHILE ALSO REMAINING VERY LIGHT! (only the content required is loaded on demand, as apposed to 4 column HTML sites with far too much information.)
Nowadays, and this is still without migrating to ActionScript 3, but still using ActionScript 2, MY flash files contain simply 2 or 3 lines of ActionScript, only one frame, and an empty stage. Everything else is dynamically created or added at runtime.
Flash's problems are not about Flash, but about lazy development.
In its defence, most of the issues raised here about how people have implemented Flash in their websites, not about Flash itself. Flash does support accessibility it's just that most people don't consider it when building their sites. Flash does work on mobile phones - it's Flash Lite, although the ActionScript is limited in earlier versions.
Why should anyone have an automatic right to view the source code of a website?
A web author has spent time and effort dreaming up their code to share their ideas through the medium of the web. If you want to know how something works, why not put a bit of effort in yourself, and work it out? The beauty of the web is the message, not the medium.
So what if Flash is owned by a single company - Adobe bought it for a reason, and that's because it's a fantastic bit of kit. The problem comes from web authors not using it properly, trying to make it do things it was never intended to, or simply not applying standards to their sites when developing using Flash.
What is so evil about a Flash based website? Absolutely nothing.
It's like asking what is so evil about a gun. Nothing. It's the idiot wielding it that has the problem.
Flash sucks and I refuse to visit Flash-based web sites. Why? Because I can't. Why? Because Adobe is too ignorant to write a plugin for a 64-bit browser.
Look at any major car maker's website, they are ALL in Flash. It depends on what you are doing. If your goal is to provide a rich, sexy website Flash/Silverlight will give you a huge advantage in terms of development time. IF you are providing content/data HTML and JavaScript (jQuery for example) can give you a lot of whizbang without requiring additional software plug-ins (Flash/Silverlight).
Flash Player is the culprit behind more Mac OS X crashes than anything else. It's not exactly well-known for its stability.
All the above answers are focusing on Flash, Silverlight is just as bad or worse. If you are running Firefox with NoScript (you should be) then you have to click on every script that you wish to allow to run.
So build your websites with scripts, Flash and Silverlight. Just make sure that they still work with them disabled. Many of us will simply move on when we open a site and see nothing.
Many of us have had bad experiences with Flash based websites which has propagated the idea that flash is "evil". I don't really think it's fair to apply the label of evil to any technology or framework, they are each designed to cater to specific scenarios and many of them do well in those scenarios, for example, I have no problem with websites that use flash video.
A few other responses have touched on the fact that the use of flash contradicts many of the standard metaphors we use on the internet (e.g. links and navigation buttons), I hate this as much as the next web user but this doesn't really make flash evil either.
While it has been said that there are mechanisms within Flash/Flex to add support for these things, in my experience these are rarely implemented, which is not directly the fault of Flash per se, but is very annoying for the user.
Perhaps the evil is not Flash/Flex but Adobe for not making many of these things easier or more visible to developers.
For the record I have never developed in Flash
Flash isn't evil, it's what people do with it that's evil.
For goofy vector animations and maybe even for example a 360 product view or interactive diagram, yes. Flash can do beautiful Full HD animation on my ancient box # 60 fps using ~15 % cpu.
For web video, if you have no other choice, I suppose.
But for entire websites and these things called 'RIA's, no.
So shockingly a technology works better for the thing that it was designed to do.
Flash is one more stuff to learn in web development. No thanks!
There are just too many already. If I can do my job without it, I don't need it.
Programming is being paid less every day.
Our web application renders fast in some IE browsers, slow in others... It seems to be an HTML rendering problem... The first 10% of the page displays immediately, the last 90% takes up to 10 seconds, and this is static content. I've run with firefox/yslow, renders very quickly. Seems to be isolated to some users/configurations of ie. Quirks mode does not seem to make a difference.
Is there a tool or application that I can use to help me discover a rendering bottleneck? Am I doing something egregious in my code? Could it be a javascript issue? Any help or suggestions will be much appreciated. thanks.
Use Fiddler to look at the times to load images, css, js files, etc. In other words, is caching a problem? Javascript can definitely cause issues in different browser versions. There's lots of optimizations you find in some versions that aren't in others. Also, make sure your html is well-formed xhtml if possible. How the page is arranged can also affect life. If your document tree is deep, it may need to wait to render large sections until it reads all the child nodes. Another thing to note, certain toolbars and plugins do look ahead loading and can slow down life. An HTTP Proxy can help you watch what's going on network-wise at least.
Not sure if anything of those ideas might help your exact problem, but they can help life overall.
If it runs fast in FF or Chrome then it's a javascript issue for sure. IE7 is VERY slow in processing large amounts of script and complicated HTML. We had a sharepoint page that took 10 seconds to render in IE and sub 1 second in FF and Chrome. We benchmarked the page by adding a timer to the server-side processing and sending the output to the client via a Response.Write(). By doing this we could determine the server time to process the page and the client time to render the page (since you would see the timer results on the screen and then wait 10 seconds for the rest to render). The bottleneck was 100% IE on the client. This also explained why the speed was variable on different peoples machines, because depending on how fast the client machine was the page would render at some speed between 8-15 seconds.
We even had MS look at the issue and they confirmed that IE has a "rich rendering" engine which is slower.... IE8 runs much faster but that is no help to anyone today.
Are you using any behaviors in your CSS? I've seen behaviors bring an app to its knees if too many are used and/or if they affect too many elements. Check for any .htc files lurking around.
Of course behaviors only pertain to IE and they use JavaScript, so I'm sure different IE versions handle them more competently than others.
There is a special tool for such scenarios called dynaTrace which is available for free at this website:
http://ajax.dynatrace.com/pages/
This tool could really help you out because its tracking almost everything and its specially build for IEs.
Check for memory leakage in the script.
http://www.javascriptkit.com/javatutors/closuresleak/index.shtml
Steve Souders gives an excellent presentation on 14 (simple) steps to improve the performance of your web pages:
http://developer.yahoo.net/blogs/theater/archives/2007/08/steve_souders_high_performance.html
If it's hanging in the middle of the page, the first thing I would personally look to do is ensure or move all my JavaScript is at the bottom of the page.
IE is great at being a bad performer, particularly with JavaScript, so if you move it to the bottom, IE can render the page, then get on with processing the JavaScript.
I use HttpWatch for troubleshooting linked assets (images, script, css), network or HTTP related problems in IE. There's a free & paid version. Free is fine but you lose out on some nice features.
I'm looking for feedback on peoples experiences with developing sites that work across browsers. It seems to me there are at least two obvious ways to approach the task of making your site/webapp work across browser:
Constantly test across all supported browsers every step of the way; or
Pick a browser, get everything working in it as a reference implementation and then make all the other browsers match the reference implementation.
Each approach has an obvious drawback -- the problem with #1 is that you end up doing a lot of unnecessary work -- especially if you are developing a webapp that is going through a lot of iterations/prototyping/spikes etc. You will make a bunch of stuff work across browsers that will subsequently be discarded/removed.
The disadvantage to approach #2 is that while it makes the initial development much quicker and more painful it makes it much harder to figure out where some of the specific errors arose, especially for more complex issues -- whereas if you had been developing for all browsers at once you should catch it right away and know what change(s) introduced the problems.
A somewhat obvious third option would be a hybrid approach, but it seems to me that you would end up losing more by experiencing both of the problems with #1 and #2 than you would gain from the benefits of doing both.
What have you found to be the most effective way(s) to approach this challenge?
I’ve found that if you get too deep into developing a website without looking at other browsers you’ll quickly get to a place that is too much of a headache to debug. I consistently open my web pages in all the browsers I care about.
I strongly suggest you verify all browsers each time you make a large change to the site.
Make it work with all browsers up front. This will mean extra testing during development but will cause you less pain later. I find it's usually easier to diagnose problems if I've just developed the thing, rather than coming back later and trying to figure it out...along with a list of other issues.
It partly depends on whether you know it's going to have to work in all browsers up front. If you do, then you really are better off just making it cross-browser to begin with. You don't need to test that everything is 100% compliant every step of the way, but you should code toward that.
And really, it's not that hard, especially what with JS frameworks like jQuery and Dojo around that take care of the scutwork. If you find yourself continually battling one browser or another, you might want to reconsider your design, as you may have chosen to do things in a way that is inherently more difficult to do when cross-browser compatibility is important.
Well, you do #1, but you do it whilst greating a style guide. A litle bit like this: http://www.sitefromscratch.com/content/html-xhtml-css-testing.
So when designing a new site or design, you create a page containing the desired HTML for all the visual elements that will be used on your site. Ignore style for now, just use the HTML that makes the most sense.
Then you style it. Preferably, your style guide would be all on 1 page so it can be open in each browser you're supporting and all you need to do is hit refresh between changes, (avoid opting for several pages, because it will take you longer to inspect them all).
When you build your site, build from the style guide. If it's not in the style guide, add it and test it there first. If you discover a problem when building the site, (perhaps you didn't consider a particular element when it wrapped, for example), replicate and fix the problem in the style guide.
Here's the killer advantage: A new version of one of your supported browsers is released, what would you prefer to test, your entire site, or the style guide?
So that's the CSS taken care of, now you need to do that all over with your generic JS functions, if any.
I created an interface compatibility layer between the browser and my code - basically, I wrapped certain functionality and made the wrappers determine what javascript/html was needed.
As browsers change, you change this compatibility layer and you can leave the rest of your code alone.
If you have this layer in your architecture, the answer to your question becomes "whenever you want".
If you can get an enterprise lock-in then multiple browser support can become less of an issue, e.g. if your customers are all companies using Internet Explorer then why build the site to look good in Safari or Chrome?
If though you are making something for the general public then there is a hybrid approach I'd use which is that I use one browser to get all the functionality there and working and then test across browsers when I'm in that "pretifying" phase of the project. Initially the key is for it to work, then it has to look good.
I don't think I could see a logic to testing across all browsers as I initially fill out a form or do some other basic functionality as it could be a big productivity drain to test across at least a few browsers, e.g. IE 6 & 7, Firefox 2 and 3, Opera 9.5, Safari, and Chrome if one wants to get all the big boys, and at least a couple O/S as Safari on a Mac can be different than Safari on Windows, which is a lot of tests even for just one or two pages. On the other hand, near the end, this is when I can refactor my CSS and inline styling and make the code better for handing off for someone else to maintain, archive until a service pack project is planned, or keep some documents just in case something has to be done. Also, by waiting to clean things up, I can have more confidence in the final UI parts as these can evolve and change considerably over a short period of time.
I usually start out ensuring that all the HTML and controls that I write/use adhere to the specification.
Tools-->Options-->Text Editor-->HTML-->Validation-->Check Show Errors and choose your Target
This starts me out on a solid base. I functionally test new features in a single browser and then about once/twice a day test the full set of them across all browsers.
Using this approach, CSS and JS are the usual suspects when something isn't right, its rare that it's the actual HTML markup.
If you can do it right the first time. Do it then. It will probably never be right later.
Depends mostly on your experience, which could be applied to any programming activity including this one. If you know in advance what likely pitfalls you're going to have to avoid (eg. in cross-browser development, don't make it hard on yourself by trying to do something that is going to be a hassle in a different browser), then you can probably safely develop everything in one browser and then go in after it's done and tweak things to get it working everywhere.
I usually advise junior developers to keep all browsers open during development and to refresh each browser when making changes, but I myself tend to write everything with Firebug for support and then go back and see how it's doing in IE7 (etc) afterwards. Since I've been doing this for several years, most of the time I can predict what's going to be causing a headache and often immediately know where to look to fix it.
If you are new to Web Design/Development then getting things right in different browsers can be a chore at times.
However, it's really not that hard to get a website working in every major browser and coded towards the W3C standard. In my opinion EVERY designer/developer should do this out of principle, otherwise they are no better than they were in the IE years.
Develop cross-browser code, make sure it validates and never think about designing for one browser again.