Hacker News new | past | comments | ask | show | jobs | submit login

For a long time in the early 2010s, Chrome had superior developer tools built-in, while Firefox needed addons like Firebug and the Web Developer Toolbar. While these addons were good, you needed to know about them and download them separately, whereas Chrome shipped with better out of the box.

It took several years for Firefox to catch up [1], and in that time, Chrome's market share exploded, and Chrome's underpinnings V8 and Webkit found new uses outside of Chrome. Furthermore, Firefox was late to Android, where the Android Browser, and later Chrome dominated.

Part of the problem is a website/webapp developed and debugged using Chrome will work with Firefox more often than not -- so some people have been cultured to not even bother checking it in Firefox. Ironically, if more things broke spectacularly, more people would test in another browser.

This PR effort is nice, but it won't reverse the tide on its own. However, once Servo is released and sees use in an embedded setting, developers will no longer be able to get by without developing (or testing) on a Mozilla engine.

[1] https://techcrunch.com/2013/03/18/mozilla-promises-to-improv...




> For a long time in the early 2010s, Chrome had superior developer tools built-in, while Firefox needed addons like Firebug and the Web Developer Toolbar. While these addons were good, you needed to know about them and download them separately, whereas Chrome shipped with better out of the box.

I agree regarding the relative quality, but developer tools have no place in a default Firefox install; the whole point of Firefox was to streamline Mozilla by moving as much as possible to plugins. It's unfortunate that they've recently started bundling stuff again (developer tools, PDF reader, pocket (whatever that is), etc.).

> Chrome's underpinnings V8 and Webkit found new uses outside of Chrome

To be clear, WebKit came from Apple (as a fork of KDE's KHTML), so this wasn't really due to Chrome devs; they were just part of the WebKit bandwagon.

Gecko (Firefox's rendering engine) was already quite widespread before Chrome existed, e.g. it was/is used in Gnome and GTK programs (Epiphany for sure, and I assume other HTML-consuming applications like Liferea); similar to the way KHTML is used in KDE programs, although it was more painful to integrate. Some of these programs were cross platform, so may have had a reasonable userbase (I don't know; I've used Linux exclusively for about 15 years).

Programs based on the XUL toolkit presumably had a much larger installed base; e.g. Thunderbird, RSSOwl, Songbird, Miro, etc.

I didn't notice any conspicuous users of Mozilla's Javascript engine except for Gnome 3, although there were other JS engines around for those who wanted them (e.g. Rhino for JVM applications). V8 certainly opened the floodgates for embedding JS though; I think I first started treating JS as a serious language when the D8 repl came out; node.js followed quite soon after.

> Furthermore, Firefox was late to Android

Well, Chrome and Android are both Google projects; we could say that Chrome was late to FirefoxOS ;)

> Part of the problem is a website/webapp developed and debugged using Chrome will work with Firefox more often than not

This is tricky; when I was doing Web dev around that time, I'd do a quick checking in FF or Chrome (whichever I had open) to spot glaring problems, then switch to IE6 for my serious testing.


> but developer tools have no place in a default Firefox install

Completely agree! But the fact is, Google shipped them anyway, and so people began using them. Now Firefox has to live with the (unintended) consequence of their decision.

> Well, Chrome and Android are both Google projects; we could say that Chrome was late to FirefoxOS ;)

Sure, but marketshare! My point is, Mozilla is doubly disadvantaged by having to battle against a vertical entity (Google), AND also being very late to the game on that platform.

> I'd do a quick checking in FF or Chrome (whichever I had open) to spot glaring problems

I'm pretty sure this is what most people do, and that's the problem, because most of the danger is from stuff that's only subtly broken, that a quick look won't catch. The non-web world has automated tests to help with this. Maybe we need tests that can run inside the browser script engine to test our webapps.


I remember that CouchDB used SpiderMonkey before switching to V8.


Even today the Firefox dev tools are quite far behind in my experience. For example, source maps are completely unsupported in the web console [0], so you get a useless trace pointing to app.js:22312 while Chrome will tell you the target is actually indicator.js:21 right out of the box. That's a showstopper right there for any dev that's using Babel, Webpack, Browserify etc.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=670002


Agreed. Chrome even manages to work with 2 layers of source maps for my project (TS->JS->require). Not to mention that the FF "source file" view is this huge dropdown that is terrible to use when you have hundreds of files in various folders.


> Not to mention that the FF "source file" view is this huge dropdown that is terrible to use when you have hundreds of files in various folders.

They are working an another JS Debugger prototype with a different UI, see https://twitter.com/jlongster/status/737831071379783682 and https://github.com/jlongster/debugger.html


Another thing benefiting WebKit (and now Blink)’s dominance is its portability. WebKit runs on more platforms than I care to number, even finding its way into things like pre-smartphone Symbian devices. It can run where XULRunner is impractical or undesirable and has bindings for just about any popular language, and both of these factors have proven beneficial to its takeup.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: