Most modern class browsers owe their origins to Smalltalk, one of the earliest object-oriented languages and development environments. The typical Smalltalk "five-pane" browser is a series of horizontally-abutting selection panes positioned above an editing pane, the selection panes allow the user to specify first a category and then a class, and further to refine the selection to indicate a specific class- or instance-method the implementation of which is presented in the editing pane for inspection or modification. Most succeeding object-oriented languages differed from Smalltalk in that they were compiled and executed in a discrete runtime environment, rather than being dynamically integrated into a monolithic system like the early Smalltalk environments. Nevertheless, the concept of a table-like or graphic browser to navigate a class hierarchy caught on. With the popularity of C++ starting in the late-1980s, modern IDEs added class browsers, at first to simply navigate class hierarchies, and later to aid in the creation of new classes. With the introduction of Java in the mid-1990s class browsers became an expected part of any graphic development environment.
In modern IDEs
All major development environments supply some manner of class browser, including
Modern class browsers fall into three general categories: the columnar browsers, the outline browsers, and the diagram browsers.
Columnar browsers
Continuing the Smalltalk tradition, columnar browsers display the class hierarchy from left to right in a series of columns. Often the rightmost column is reserved for the instance methods or variables of the leaf class.
Outline browsers
Systems with roots in Microsoft Windows tend to use an outline-form browser, often with colorful icons to denote classes and their attributes.
Diagram browsers
In the early years of the 21st century class browsers began to morph into modeling tools, where programmers could not only visualize their class hierarchy as a diagram, but also add classes to their code by adding them to the diagram. Most of these visualization systems have been based on some form of the Unified Modeling Language.
Refactoring class browsers
As development environments add refactoring features, many of these features have been implemented in the class browser as well as in text editors. A refactoring browser can allow a programmer to move an instance variable from one class to another simply by dragging it in the graphic user interface, or to combine or separate classes using mouse gestures rather than a large number of text editor commands.
Logic browsers
An early add-on for Digitalk Smalltalk was a logic browser for Prolog rules encapsulated as clauses within classes. More recent logic browsers have appeared as and for Squeak and VisualWorks Smalltalk. A logic browser provides an interface to Prolog implemented in Smalltalk. A comparable browser can be found in ILog rules and some OPS production systems. Visual Prolog and XPCE provide comparable rule browsing. In the case of SOUL, VisualWorks is provided with both a query browser and a clause browser; Backtalk provides a constraints browser. The comments of Alan Kay on the parallel of Smalltalk and Prolog emerged in the same timeframe but with very little cross-fertilization. The interest in XSB prolog for XUL and the migration of AMZI! prolog to the Eclipse IDE are current paths in logic browser evolution. Rules encapsulated in classes can be found in Logtalk and several OOP Prolog variants such as , and as well as mainstream SICStus.
Web-based versions
One variant of the Seaside web framework in Smalltalk permits a class browser to be opened at runtime in the running web browser: an edit to a method then takes immediate effect in the running web application. In the case of Vistascript for Microsoft IE7, a right-click on the background opens a ClassHierarchyBrowser. This is somewhat like editing JavaScript prototypes in a web browser or Ruby, Groovy or Jython classes in an IDE running in a JVM.
