Top 10 Reasons Why Firefox is still Better than Chrome for Web Development

Contents

Browsers market share evolution

Top 10 Reasons Why Firefox is still Better Than Chrome for Web Development

Conclusions

Browsers market share evolution

About one year ago I wrote another post telling what many of us already knew, which is that PHP developers are switching to Google Chrome as their browser to access the Web.

As you may notice in the following chart, that trend continues to be true this year. These numbers are taken from the statistics of developers that logged in the PHPClasses site during the last 30 days.

As you may see, Chrome almost doubled its share in one year, while Internet Explorer dropped to a little more than half. Firefox also dropped a bit.

The gain of Chrome is more than the loss of Firefox and Internet Explorer. This means that Chrome also gained share lost by other browsers.

Top 10 Reasons Why Firefox is still Better Than Chrome for Web Development

Given the fact that Google Chrome share is continuing to grow a lot, you may wonder about the reasoning for this article title. The fact that Chrome is continuing to get more popular for Web browsing, it does not mean that when Web developers are working on their projects they still use Chrome.

For me that is not the case. Often when I am doing Web development work, I feel the need to switch to Firefox for the reasons that I am listing below.

Keeping in mind that this article is not exactly a rant against Google. Google gaves us, Web developers, a lot to be thankful to them, but when comes to Chrome there is still a lot to desire.

I decided to write this post now in the hope that maybe somebody at Google reads it and does something to address these issues that more than often really upsets many of us, as we do not want to be switching browsers all the time.

1. HTML viewing

When the code of our sites has bugs, often it generates HTML code that is incorrect or even invalid. So we need to examine the HTML code to help figuring what is wrong.

Firefox has this awesome feature that lets you select a portion of a page and it shows the exact HTML that corresponds to selected page portion. There is no such feature in Chrome.

The best you have is an Inspect Element feature that lets you find the HTML code for the page element under your mouse pointer. It is not the same thing. If I selected a region of the page, I would like to view the whole region HTML, not just a single element.

Another annoyance is that Chrome tries to beautify the HTML code. This means that if you have malformed HTML, you will not see where it is malformed, as Chrome will show you a beautified version of the HTML code after have been already fixed. I wish there was an option to disable beautification.

2. HTML Validation

Another great feature of Firefox is the possibility to show you any HTML validation errors that you may have. Actually, this is a feature provided by the HTML Validator extension.

I tried several extensions for the same purpose in Chrome but nothing was nearly as good. Some only used the W3C validation service passing the page URL, which is not good because when you are developing a non-public page, the W3C service cannot access it, neither can access it as an eventually logged user of the site you are developing.

Other extensions tried to copy the currently loaded page and pass it to the validator service but none showed the eventually invalid HTML as the Firefox HTML Validator extension does.

Also this Firefox extension does not rely on an external validation service. This means that you can validate your pages even if you currently do not have Internet Access.

So, for all these reasons, an equivalent version of Firefox HTML Validator extension is seriously needed for Chrome.

3. Disable JavaScript

Sometimes you need to test your site with JavaScript disabled. The only way to disable it in Chrome is going to preferences and disable it there. This is a real drag.

In Firefox you can use the Web Developer extension by Chris Pederick to add a button to the browser toolbar to quickly disable and re-enable JavaScript any time you want.

For Chrome there is also the Web Developer extension by the same developer but it does not provide a means to disable JavaScript.

The problem is due to a limitation of the Chrome API exposed to extensions. It does not provide a way to disable JavaScript from extensions.

There is a feature request for the Chromium project to implement the necessary support to disable JavaScript. The feature implementation was even assigned about 1 year ago to be implemented, but it never happened. Oddly users were disallowed to post further comments to that feature request.

4. Empty the browser cache

Sometimes you need to force the cache of the browser to be emptied, so fresh content is retrieved from the server of the site you are developing.

It is the same limitation as of disabling JavaScript. You cannot do it from an extension. You need to do it by going to the Chrome preferences.

There is also a feature request to enable support to empty the browser cache from an extension. This one was requested more than 2 years ago, but only 3 months ago it was assigned to be implemented.

5. Switching the browser user agent identification

Sometimes you need to access your site in development pretending to be using a different browser, so you can check if your site adapts to the current browser as you expect.

For instance, if you are serving an RSS feed to be handled by Feedburner, you need to redirect all browsers to the Feedburner feed URL, unless the current user agent is Feedburner itself checking if your feed was updated. So, it would be useful if you could make the browser pretend to be Feedburner, so you can check if it is working well as needed.

In Firefox you can use the User Agent Switcher extension also by Chris Pederick. In Chrome there is also an extension named User Agent Switcher. The problem is that it does not work. Well it does, but not in the way you expect.

This extension can only change the browser identification exposed to JavaScript. This means that the HTTP requests sent to the server will not use the user agent identification string that you need to be sent.

I suspect there is a feature request to have this implemented in the Chromium, but I did not find it. Until that feature is implemented, we have always to resort to Firefox which works well as necessary with the User Agent Switcher extension.

6. Buttons in the status bar

One good thing about Firefox and most other browsers is that you can have useful buttons below in the browser window in the status bar. That is were the Firebug and other useful extension buttons appear. When you want to use them, it is very easy to click a button to open Firebug and debug your JavaScript code.

Chrome practically eliminated the status bar. It is only used to show some temporary messages. If you want to open the developer tools to debug your JavaScript code or check the page HTML, you need either to find that function in the menus or memorize a non-trivial key sequence.

Eventually you will get used to this but it would be much more user-friendly if you could reach those extensions if they appeared in the status bar below or even at the browser window top.

7. Caching of posted pages in the browser history

Sometimes you need to go back in your browser history to a page that was presented after submitting a form using the POST method. However, you do not want to repeat the request that was sent to the server when that page was served.

8. The Flash extension crashes frequently

I do not develop sites in Flash. However, sometimes I need to access certain Google sites that provide useful information presented using Flash. That is the case of Google Analytics and Google Webmaster Tools.

Unfortunately, the Flash extension shipped with Chrome crashes frequently. That does not happen when using Firefox to access the exact same pages.

I would prefer that Google did not use Flash in such sites. Most of what they present did not really need to use Flash. I assume that changing such sites to not rely on Flash would take Google more development resources than they want to spend. In that case, it is necessary that Google fixes Flash extension that ships with Chrome.

9. HTML editing generates malformed HTML

Nowadays, most sites that publish HTML content submitted by the users, provide a rich text WYSIWYG editor interface. This is done setting the contenteditable HTML attribute, for instance of a div tag.

I have seen HTML meta tags appearing out of nowhere in the middle of HTML pasted after being copied from other parts of the same HTML document being edited. I also often see bogus CSS styles named Apple-style-span appearing in pasted HTML, when such styles never existed before in the HTML being edited.

This is just a reminder that you need to have an HTML validator and filtering system on your server side scripts to clean-up any messy HTML submitted to the served after being edited on Chrome.

It is always a good idea to use such filters, as there is no guarantee that all browsers will always submit valid HTML. But the fact is that if you use Firefox you do not seem to get such malformed HTML.

10. No feedback to bug reports

I tried to report some of the problems above using Chrome built-in bug reporting system. You go on the menu Tools and then Report an Issue, and it shows a nice bug report page which may even include a screenshot of the current page you were browsing.

The problem is that I never got any feedback of my bug reports. So I do not know if the bugs were submitted and received properly, let alone having been seen and acted upon.

I do know if the time I spent trying to describe the bug reports was worth it. I suspect that it would probably be more efficient if I reported any bugs to the Chromium project directly.

Maybe I am getting this wrong, but sometimes I get the feeling that Google people does not see the act of providing feedback to the user community as an important thing.

This reminded me about the AppEngine issue of supporting PHP. It was the most requested feature for the AppEngine project. Google people decided to not support PHP in any sense, giving as justification the lack of resources. That is a bit odd thing to say for a company that makes many billion dollars in profits every year.

They also disallowed anybody from posting any further comments to that feature request. It seems that it is not relevant for Google what the PHP developers community can provide of feedback, despite it is probably the largest Web developers community.

Conclusions

This article is mostly my opinion and does not necessarily represent what most PHP and other Web developers think of how of Google should sort the priorities of development of Chrome and other Google products.

It is possible that I may have misunderstood certain aspects of how Chrome can work to address Web developer needs. Whether you agree or disagree with my opinions or you have other suggestions to solve the problems presented above, please feel free to post a comment telling what you think about it.