>As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users. Maybe because it's just easier than making them optional extensions? Does anyone know about what year this started?

This is total conjecture but I wouldn't be surprised if it had something to do with competitive advantage. The best browsers to develop for have a better chance to become the browsers of choice because when things were less standardized (or browsers adhered to standards less) webpages could run better in one browser than another (if they even worked in multiple browsers at all). IE kind of breaks that theory but they had other ways to push IE that did not depend on quality or ease of development.

Good point, less development friction gets web developers to "sign up" for your browser. Web developers who are using your browser to develop make sites that work well in your browser! This makes perfect sense! I can't believe I didn't think of that.

Personally, I absolutely love that developer tools are included in all browsers. I think its absolutely fantastic, just surprising to me it ended up that way.

It's basic marketing, appeal to the thought leaders. It's how Google marketed Chrome.

The other vendors were just playing catch-up, especially Microsoft.

Plus it was handy for their own devs and aligned with their strategy (make the web awesome because more web is more Google ads).

> Personally, I absolutely love that developer tools are included in all browsers. I think its absolutely fantastic, just surprising to me it ended up that way.

Only one of the browsers I regularly use contains dev tools (Firefox); there are no dev tools built in to w3m, dillo, conkeror or lynx.

There were also no dev tools in eww, w3, konqueror, arora, midori, links, elinks or netsurf last time I used them.

In fact, I've only ever seen dev tools in two browsers, Firefox and Chromium, although my observations are biased since I only use Free Software ;)

You sound like a bit of an edge case.

For what? Firefox DevTools? I use Firefox, spent several years as a Web dev, and use FireBug pretty much every day, so I think I'm part of the core demographic. That's unrelated to my use of other browsers though: right tool for the right job, and all that.

The parent just-so-happened to make a tangential comment about "all browsers" bundling dev tools, which I found quite short-sighted. If you're QA testing a commericial Web site then by all means use "all browsers" as a shorthand for "the popular browsers". But if you're commenting on the general development of browsers and their features, such statements need to be qualified. After all, there are some good sibling comments discussing WorldWideWeb, Netscape, etc. Should they be dismissed as "edge cases"?

Maybe instead of listing the software I actually use, I could have taken a guess at how many mobile browsers lack dev tools; I imagine there are many users of such browsers, which is far from an "edge case", although I avoided making such conjectures since I've never browsed the Web on a mobile phone.

Opera, Safari also have dev tools, although those are both webkit-based, these days. IE's had (non-sucky) dev tools since... IE9? 10? Something like that. I'm sure Edge has dev tools.

Part of the issue with a lot of these alternative web browsers is that they don't have fully-fledged JS engines, or WebGL, or a number of other features that web developers like to use to make their sites fancier (and more bloated, etc etc).

This is interesting; why dev tools are not seen in these FOSS offerings?

Some want to be small and lightweight, e.g. Dillo, so I can imagine them rejecting such features altogether.

Others don't have features like DOM, Javascript, etc. so there's not much they could offer that "view source" doesn't already do.

Others don't have a suitable interaction model, e.g. w3m is effectively a pager for turning HTML into ANSI escape codes; conkeror is keyboard driven so would need a radically different UI for it to be effective; etc.

Others, like Netsurf, Konqueror and the Webkit wrappers (Midori, Arora, etc.) would probably like a dev tools feature, but don't have enough developer power to implement one.

I'm pretty sure competitive advantage plays a role. Looking at myself and most front-end devs I meet, we tend to use Chrome as a primary browser in part because of the dev tools.

In my case I remember there was a point where I preferred Chrome's dev tools over Firefox' built-in dev tools as well as Firebug, and that played a role in my use of Chrome as a primary browser. Things may have changed, but here I am still using Chrome.

The downside is that I need to remind myself to properly test in Firefox and Safari and, to my shame, it has happened that I entirely forgot and the testing department ended up being that reminder.

Also, Could it be that another reason for dev tools' existence might be that browser developers use it themselves?

There might be some truth to this. I use Firefox as my primary browser (despite everyone I talk to from my co-developers to my teenagers expressing shock that I don't use Chrome since "everyone" uses Chrome) because I use Firebug. I've tried using the Chrome developer tools a few times, but I'm so productive in Firebug from long years of use that I just can't get used to it. Maybe now I'll be forced to do so :-(

In Mozilla's case, some of the rationale for including devtools by default is that part of their mission is to make the web accessible to everyone, rather than erect a wall between users and developers (though this does potentially cause some problems). Was Firefox the first browser to make "View Source" a default option in the right-click context menu?

No. View Source far predates Firefox, which is relatively new with respect to the history of the web.

The ideal that the Web shouldn't be write-only is not new, either—it's been around around since the birth of the Web; Tim Berners Lee included features to publish pages in the first browser, WorldWideWeb. The idea of built-in devtools in Firefox also isn't new.

Firebug's predecessor DOM Inspector was shipping in Mozilla Application Suite and in Firefox up until Firefox 3. For Firefox 3, the team decided that DOM Inspector's utility to the masses didn't justify its costs. Mozilla Corp was a lot smaller then—150 or so employees. It was a common theme at that time to challenge every part of the browser both because of the QA involved and the ideal of shipping a light, focused product was still something that the team was aiming for. The DOM Inspector code was already mostly self-contained, so it was built and released through addons.mozilla.org as an extension.

The main reason the built-in devtools got included in Firefox aren't so much rooted in user-focused principles as it was convenience for the devtools team. Someone might appear in this thread to dispute this (I half expect Rob Campbell to show up), but it's truer than the idealism line. Bundling the new devtools into Firefox gave two advantages for the people working on it:

1. You're automatically given a big install base, i.e., you don't have to convince people to download your extension.

2. Maintaining features as an extension introduces some work that you don't have to deal with if you just shove your code into the mozilla-central codebase. In 2010, extension authoring sucked. If Gecko couldn't do what you needed or browser.js didn't have hooks for you, you just roll those things into the same patch that introduces (or fixes) the feature you're working on.

Fun fact: The number of years that Firefox has shipped with a built-in inspector actually outnumbers the years that it was without one. Firefox 3 was the first release that didn't include DOM Inspector. That was 2008. A couple years later the devtools project was announced, and it was slotted to ship in Firefox 4—which ended up delayed for 6 months or so. (If I recall correctly, devtools either ended up still missing the boat, or it shipped with parts turned off because they weren't mature/stable enough yet and they were reenabled within the next few releases after Firefox had switched to the rolling release cycle.)

EDIT wrt your comment about no distinction between "developers and users": Firefox Developer Edition's existence is a contradiction

  > Firefox Developer Edition's existence is a contradiction

It isn't a contradiction. The only devtools that are in FDE but not in Stable are experimental ones that are on the path to stabilization. It's a testbed, not an enclave.

I'm not involved with Mozilla anymore, but last I heard, there are things you have to use Developer Edition for that can't be done with vanilla releases (like working on add-ons).

Developer Edition enables a number of features not currently available for regular Firefox. The two major ones are build time features which can't be enabled in other releases (besides Nightly). One build feature is Unsigned Add-ons, which allows for add-on development where it isn't possible otherwise. The other is Async JavaScript callstacks which are very useful to capture but tend to slow down regular browsing otherwise. Besides build features there a lot of prefs we turn on to make development easier. If you try using Chrome or Firefox release with DevTools you will need to do something extra to be able to "paste into the console" (something that prevents people on facebook from owning themselves) and that guard isn't on by default in Developer Edition. [I'm the Product Manger for Firefox DevTools]

> Unsigned Add-ons, which allows for add-on development where it isn't possible otherwise

It is possible, you've just chosen to disallow it.

To be clear: the Firefox team took deliberate steps to make sure that add-ons can't be tested or developed in the stock builds of Firefox downloaded from Mozilla.

Don't think you're right. You can use FDE for add-ons development, just like parent said.

See your sibling below: > Unsigned addons cannot be enabled on beta or release. That was only available for a limited time. Now they can only be enabled on alpha (aka developer), nightly, or special unbranded builds.

Please read and understand the entire comment chain you're replying to. I'm well aware that you can use Firefox Developer Edition to develop add-ons. (I'm the one who first mentioned it!)

AFAIK this isn't correct. FDE has some about:config flags set to different defaults than the Stable release, which could mean that a user of Stable might need to flip a switch to allow loading unsigned addons, but there's nothing stopping you from doing so (and addons aren't exactly part of the web platform).

Unsigned addons cannot be enabled on beta or release. That was only available for a limited time. Now they can only be enabled on alpha (aka developer), nightly, or special unbranded builds.

You can make a userscript without any of that hassle, though.

I stand corrected!

It's a long way back for my memory but didn't Netscape Navigator have a WYSIWYG editing mode? That would be at the end of last century.

I think it had. It was later spun put as Composer or something.

> write-only

I think you mean read-only, no?

No

https://en.wikipedia.org/wiki/Write-only_language

in this context it's about having the source code accessible itself, instead of only a binary/bytecode available (or some obfuscated/minified code)

Good response, but as easy as it would be to pretend that this is what I intended all along, intellectual honesty dictates otherwise. Read-only is what I was thinking at the time I wrote it, but I flubbed the words during revision what with all the double negation happening in that sentence. In the world of inspectors on the modern Web, though, the concept of something being write-only is also strongly relevant.

> Was Firefox the first browser to make "View Source" a default option in the right-click context menu?

Not even close. Netscape had this in the late nineties, IIRC.

I don't know which browser first added View Source, but I know it has been there since at least 1995.

This was standard in Netscape 4.x on, if I remember correctly.

You do. It was standard in Netscape & IE 2. First thing I used, about 30 seconds into viewing my first webpage ever.

i also remember netscape having a built in web editor. I built my first web page in it, consisting of gif animations, links to friends web sites, a link to download duke3d-demo and a big "in construction" sign.

> and a big "in construction" sign

Those were the days

> As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.

AFAIK the firefox devtools team has plans/ideas that the devtools could just used like a normal Web App (loaded from a server). Currently, they are migrating XUL based components over to normal html what would make this possible.

As an example, just like debugger.html which can even be used from any browser in a not-builtin way: https://github.com/devtools-html/debugger.html

Back in the IE 6 days, I used Firebug Lite [0] by adding a script tag in my HTML that would recreate the Firebug interface and most of its capabilities as a panel injected into the page.

[0] https://getfirebug.com/firebuglite

Yes, in 2017 we'll be shipping DevTools outside of Firefox. At first it will probably be an add-on and we'll evolve from there. But it should mean less time between features and fixes and deliver to developers.

>the firefox devtools team has plans/ideas that the devtools could just used like a normal Web App (loaded from a server)

Someone from the old Opera team must have joined them, no less!

I don't understand. Can you elaborate? Have there been previous plan like this by old Opera?

Dragonfly[0], Presto's old dev tools, was essentially a web app (and, IIRC, although cached was loaded as if any other web app), though it had access to some APIs normal websites did not, to be able to communicate with the browser through the Scope protocol[1].

[0]: https://github.com/operasoftware/dragonfly

[1]: https://operasoftware.github.io/scope-interface/

Safari/Webkit DevTools (a fork also in Chome) is a web app as well and older.

I miss Dragonfly. One of the best.

Best i can tell, at least Mozilla still adhere to the notion that the web empowered individuals by allowing anyone to publish something online.

This started with Netscape. They had a fairly awesome built in web page editor. My guess is to make the web and creating web pages an inclusive experience for all users.

This is true but not even close to the same way.

The Netscape had a distribution called Communicator that shipped the browser 'Navigator' alongside a mediocre but serviceable WYSIWYG editor 'Composer'. Other products were included too: an email client, and for a while, a Calendar; the codebase lives on as Mozilla Seamonkey. This was a play towards small businesses, and not an 'Inspect Element' hook.

Meanwhile, integrated devtools started with Chrome in 2008, two years after Firebug was released in 2006. My guess is Chrome wanted to provide a browser experience that was noticeably superior to a variety of demographics, and gain marketshare on merits. Meanwhile, IE began a huge effort to prove that they're not an old dinosaur of a browser holding the web back, but they didn't have easily-installable addons, so they built it in. These factors created pressure on Mozilla [1] to improve their devtools and consider shipping them with the browser.

[1] https://news.ycombinator.com/item?id=12042767#12044962

> Meanwhile, integrated devtools started with Chrome in 2008, two years after Firebug was released in 2006.

I'm very very sure integrated devtools could be traced back to WebKit Inspector Tool[1] in 2006 (with Drosera[2], the JavaScript inspector, being separate application). Then in 2007, the WebKit team rebuilt the Inspector Tool into Web Inspector[3] and merge Drosera into it. Chrome inherited the Web Inspector when it was released in 2008. I even remembered the first few versions of Chrome still has the Mac metal looks (even when running on Windows).

[1]: https://webkit.org/blog/41/introducing-the-web-inspector/

[2]: https://webkit.org/blog/61/introducing-drosera/

[3]: https://webkit.org/blog/108/yet-another-one-more-thing-a-new...

It's already been mentioned; the comment about integrated tools first showing up in Chrome was off.

But Safari wasn't the first either. WebKit Inspector was built under Dave Hyatt after being lured to Apple. It was meant to bring the tools available to Mozilla developers over to WebKit/Safari. Joe Hewitt's DOM Inspector was checked in to the Mozilla codebase in 2001, and Robert Ginda's Venkman JS debugger in 2003.

(After leaving Netscape, Hewitt took a second run at integrating both tools' featuresets, and that's where Firebug came from.)

There’s a gap in the middle of your timeline that was filled by DOMi and Venkman. I seem to recall those being built in at one point, although I might be wrong (I wasn’t doing professional front-end dev at that point).

Venkman was built into the Mozilla Suite [1], and it was also made into an addon for Firefox [2] when Firefox was released.

DOMi was built into Firefox since November 2003 if you used the Windows installer's 'Custom' installation and selected the checkbox for inclusion [3], then in Firefox 3 it was removed and made available as an extension [4]. It was also included in the 'Custom' installation of the 'Complete' Mozilla/Seamonkey Suite [3].

But Prototype.js came out in 2005, jQuery in 2006. Ajax the term was coined in 2005 [5][6][7]. We don't talk about the dark days before then.

[1] http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html [2] https://addons.mozilla.org/en-US/firefox/addon/javascript-de... [3] http://kb.mozillazine.org/DOM_Inspector [4] https://addons.mozilla.org/en-US/firefox/addon/dom-inspector... [5] http://www.quirksmode.org/blog/archives/2005/01/with_httpmap... [6] http://adaptivepath.org/ideas/ajax-new-approach-web-applicat... [7] http://www.quirksmode.org/blog/archives/2005/03/ajax_promise...

Oh yeah, the custom installation checkbox! Had forgotten about that, thanks for the memories.

Hrm... my apologizes, I stand corrected then. I started getting into web development after Netscape was, for all intents and purposes, dead and IE6 was king.

Well you're in luck, check out SeaMonkey composer today!

http://www.seamonkey-project.org/

MS used to bundle a similar WYSIWYG editor with IE as well, Frontpage Express (a stripped-down version of the commercial MS Frontpage).

Well a WYSIWYG editor built in is not really comparable with the features of Firebug.

Sure, but Netscape Composer was a WYSIWYG editor as well, not a web page inspector/debugger like Firebug. Honestly, there was not much to inspect or debug in web pages at the time...

View Source has been around since the beginning, so it's not entirely new.

What's new seems to be all the work on making the dev tools comprehensive and "IDE-like", and I think that has as much to do with it is as useful to the companies building the browsers as the users of the browser. Such that Chrome probably added them in directly to save Google developer time and needing a separate IDE/toolkit/extension install, and the rest of the browsers followed.

It's interesting too in that Edge now uses the Dev Tools as a way to tier the user experience, such as the traditional View Source, out of the base experience. If you open the Dev Tools Edge asks if you are a developer and lights up a bunch of functionality that "ordinary" users don't need to see, like View Source.

I believe WorldWideWeb.app didn't originally have View Source: it provided a WYSIWYG editor which was intended to be the main way to edit pages, AIUI.

> As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.

That percentage is actually pretty close to correct. For that reason and user studies of regular users Edge has already turned off their DevTools by default ( https://blogs.windows.com/msedgedev/2016/11/22/balancing-use... ).

Firefox is currently pursuing moving the DevTools out of the browser and will likely use a similar system to Edge / Safari for activating them. Going the extension route does have complexity drawbacks but being able to ship fixes faster, to a wider audience will be a greater benefit. Additionally as all browsers adopt WebExtensions this could mean that any Firefox panel developed as a WebExtension will be available for use within Chrome or Edge.

That would be a welcome change. I even say so as a Developer. You can't imagine how often I hit some keys by accident and some DevTools panel turns up - I wonder how that must feel to "normal" users (thinking of my mother here ;)

> I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.

Not of use to many, but I'm still glad that Chrome includes them - I needed to upload several GB of data the other day, and having both an available web interface and the bandwidth limiting feature in the Dev Tools Network section let me do that upload without impacting other users at the office for the 30-40 minutes that it would have taken when unthrottled.

> As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.

I wish this wasn't the case, but I use built-in devtools inspector to work around bad websites that impose invisible ad overlays which are somehow not caught by the combo of uMatrix+uBlockOrigin. I have to use the Inspector to select and delete the overlay so that I can use such sites. Thus DevTools serve a purpose to non-development browser sessions.

Oh yea, for sure, I do the same. I especially modify the DOM to get around "lol, no copying into this form field." That's not really the point I'm trying to make though, 99.9% of users don't have the know-how to do this. You pretty much have to be a web developer to be able to use the browser this way.

I agree, although it helps lower the barrier to entry, so that 99% might become 95% or 90%. More than a few times, I showed people a few simple tricks in the Inspector. They felt empowered and it encouraged some of them to continue digging on their own.

Sure, they could install an addon, but that can be very intimidating if they have never done so. If I "wanted to show them a quick trick", I would have already lost their attention completely by the time the addon is installed.

I don't know why but I like it this way - I at least have some assurance that what my dev tools show me is what the browser actually sees.

Also, let's all be thankful to Joe Hewitt for his work on Firebug and the huge change it brought to web development.

I still use Firebug daily and find it better and easier to use than the Firefox Devtools which in turn is slicker than Chrome Devtools, although the latter enables you to easily develop directly on Android devices connected by USB. I hope they retain the layout and most of the functionality.

It's a pattern to keep in mind. Develop your tools not just for users bot for developers as well, and you'll also have strong engineering ressources targeted at improving your tools and brand.

Firebug has plug ins that I live by and aren't offered in the other browser tools. Firepath is one.

Let me [not] cite Steve Ballmer...