List and Tree
Learn it once
A file manager shows a collection two ways. One is a list: a row per file, with the name, the date and the size lined up in columns under headers you can click to sort. The other is a tree: the folders, with a small control beside each that opens it in place to show what is inside. Every operating system has drawn these two views for thirty years, and every program that shows files has either borrowed the system's or built its own. This page is the history of that choice, and then how Fuji makes it.
The argument for borrowing is older than the mouse on your desk. In December 1968 Douglas Engelbart demonstrated NLS, a system that kept a document as a hierarchy of numbered statements and let the operator fold it to a chosen depth or show only the first line of each statement, which is the collapse and the summary row of a tree control fourteen years before anybody sold one. The principle that such a control should work the same way everywhere was written down for the Xerox Star in Designing the Star User Interface, in BYTE for April 1982: "Consistency asserts that mechanisms should be used in the same way wherever they occur." Apple made the principle unavoidable by putting the mechanisms in ROM, and Inside Macintosh, Volume I, 1985, opens its account of the Toolbox with the bargain, and with the exception every guideline since has kept:
The Macintosh User Interface Toolbox provides a simple means of constructing application programs that conform to the standard Macintosh user interface. By offering a common set of routines that every application calls to implement the user interface, the Toolbox not only ensures familiarity and consistency for the user but also helps reduce the application's code size and development time. At the same time, it allows a great deal of flexibility: An application can use its own code instead of a Toolbox call wherever appropriate, and can define its own types of windows, menus, controls, and desk accessories.
IBM's 1987 Systems Application Architecture put the same two benefits as money saved by the user and the programmer alike. That is the bargain. The person at the keyboard learns the list once, and the person writing the program takes it off a shelf. The history since is a history of who keeps the shelf.
The vendors
The Macintosh had no standard list in 1984 and no standard tree in its whole classic life. The original Toolbox drew windows, menus, buttons and text, and the only list on the machine was the one inside the Open dialog. The List Manager came in 1986 as a package in the System file, and it was flat: cells of one size, text only unless you wrote your own drawing code, and a ceiling of 32 KB on the whole list. When System 7 gave the Finder its list view in 1991, with the triangle that turns to open a folder in place, the triangle belonged to the Finder alone. Apple's own 1992 Macintosh Human Interface Guidelines file the triangle under a heading of its own, Controls Not Supported by the Macintosh Toolbox:
This section describes the appearance and behavior of some common controls that are not supported by the Macintosh Toolbox. These controls include sliders, little arrows, and the outline triangle. You can implement these controls in your application where necessary according to the descriptions presented here.
The Mac's tree came in with NeXT. NSOutlineView, an outline built on top of the table view, appears in the AppKit release notes for 1997, Apple's first year of owning the company, and it is the Mac's outline view to this day.
IBM had a standard tree first. OS/2 2.0 shipped a container control in 1992 with a tree view among its modes, while Windows 3.0's File Manager was still painting its directory tree into an ordinary list box, drawing the connecting lines and the plus boxes by hand in a file called treectl.c that Microsoft published in 2018. Apple had sued Microsoft in 1988 over the look of Windows, and in September 1994, eleven months before Windows 95, the Ninth Circuit closed Apple v. Microsoft with the finding that "No copyright protection inheres in these ideas." Windows, icons and menus belonged to nobody, and a shared shelf was legal.
Windows 95 is where the list view and the tree view became system controls with those names, in a window that put a tree of folders on the left and a list of files on the right. The shell team wrote the two controls for Explorer and then, as Raymond Chen tells it, published them in comctl32.dll for every program on the machine. Microsoft's tree view patent states the bargain in its first line: "A tree view control is provided as a system resource that may be used by application programs." A shared library brings version trouble. New versions of comctl32 arrived with Internet Explorer rather than with Windows, so that Microsoft Systems Journal could tell developers in 1996, "Just install IE 3.0 to get the IE 4.0 Common Controls DLL-yes, you read that right." In Windows 7, Explorer itself left the control it had been built from for a private one called Items View, and Windows 11's File Explorer is a Win32 program with the newer WinUI framework hosted inside it, says the Windows Insider blog. Office never used the shared toolbar at all. Visual C++ and Office each drew their own, Microsoft Systems Journal noted in 1999, while Internet Explorer used the system's. The vendor that built the shelf kept its biggest program off it.
The toolkits
A program sold for more than one operating system needed a shelf of its own, and the first fight over whose look it should wear was on Unix. Sun's OPEN LOOK of 1988 described itself as the Star's consistency joined to the Macintosh's simplicity, and it ran on a SPARCstation 1 that cost between $8,995 and $15,400. In 1993 the Unix vendors chose Motif for the Common Desktop Environment and OPEN LOOK was over. Motif, by its own programming manual, was modeled on IBM's Common User Access, so the look that won Unix was a desktop vendor's look after all.
Java gave each side of the argument a company. Sun's Swing, part of Java 2 in December 1998, drew every component itself in Java and made its own look, Metal, the default. Sun's case for Metal, in The Java Look and Feel, was a program that looks and behaves the same on every operating system. Swing could also imitate Windows, but Microsoft licensed that look only on Windows, InfoWorld reported in 1998, so a Swing program that did nothing special looked like Java and nothing else. O'Reilly's Java Swing, from the same year, is the book that taught a generation to write them. IBM's answer, in Eclipse in 2001, was SWT, which its designer Steve Northover introduced as Swing with one difference, the operating system's own widgets underneath, so that an Eclipse program on Windows showed the same list and tree as Explorer because they were Explorer's, with a thin Java wrapper around them. His article closes on the method:
All of the natives in SWT are implemented using this simple and consistent strategy. There is no C code to hide the low level details of the operating system such as the event loop, callbacks or the thread model. No code reaches back into Java from C to get a field or invoke a method. Nothing is magic - everything is coded in Java using the terminology and documentation of the operating system.
Even SWT had to draw a tree of its own on Motif, where none existed, as its makers say in Creating Your Own Widgets. The two companies argued about it for years. James Gosling called SWT a Windows toolkit that happened to run elsewhere, on an Eclipse mailing list in 2006; IBM's Lee Nackman told Computerworld in 2004, "We didn't do it because we thought it would be fun to fracture Java."
Neither choice decided who lived. Qt drew its own widgets from 1995 and prospered because KDE adopted it in 1996 as the look of a whole desktop, so that on KDE a Qt program was the native program; Nokia paid about €105 million for the company behind it in 2008, The Register reported, to put it on phones. Borland's Delphi wrapped the Windows controls in 1995 and still ships that way, while its drawn twin, built on Qt, was dropped. What every survivor shares is a decision about where the data lives. The first tree controls were handed every row and kept a copy; the ones that lasted ask for a row when they need to draw it. Swing's JTree, by Oracle's own tutorial, holds no data of its own and only shows what a model hands it; GtkTreeView arrived in GTK+ 2.0 in 2002 built the same way; Qt 4 rebuilt its own around the idea in 2005 and called it the Interview framework. The tree every toolkit arrived at is a view over data it does not own, which is the shape a tree needs before it can show a drive with a hundred thousand files on it.
The web and the phone
Before React there was a decade of toolkits that carried the desktop's grid and tree into the browser whole. Yahoo's YUI had a tree view and a data table in 2006. Dojo 1.0 shipped in 2007 with a grid that handled a hundred thousand rows by creating elements only for the rows on screen, the trick every fast list on the web has used since. Ext JS sold a grid and a tree from 2007. Facebook's React, open-sourced in May 2013, proposed something smaller and stranger: no widgets at all, only components, small functions that describe what a piece of the page looks like for a given state. Its first post sold it as a way to compose a user interface rather than assemble one. Pete Hunt, presenting it that fall, said the first audience had been shocked. It finished the big toolkits anyway. Yahoo closed YUI in 2014 with a note explaining that developers had come to see large libraries as "walled gardens they don't want to be locked into." React has never had a list component. Its guide to rendering lists teaches a loop and a key, its advice on performance sends anyone with thousands of rows to a separate windowing library, and Vue gives the same advice. Evan You wrote Vue in 2014 as the part of Angular he liked, lightened, as he told freeCodeCamp; Rich Harris wrote Svelte in 2016 so that a phone would not pay for the framework, in Frameworks without the framework.
The phone did not thin the idea out. It narrowed it to one component and engineered that one harder than anything before it. The iPhone's UITableView, in the 2008 SDK, keeps only a screen's worth of row views alive and hands the ones that scroll off the top back to the ones arriving at the bottom, as Apple's Table View Programming Guide explains, so a list of ten thousand songs costs the memory of a dozen. Android's RecyclerView of 2014 is named for the same trick, and React Native's FlatList of 2017 brought it to the web's components. What the phone lost was the tree and the many-column table. No phone had an outline control until SwiftUI's OutlineGroup at WWDC 2020, and Apple's guidelines still mark outline views as a Mac thing, not supported on iOS. The two old camps formed again on the phone. React Native wraps the platform's own views, "learn once, write anywhere," and Flutter draws every pixel itself and uses none of the device's widgets, by its 2018 FAQ, which is Swing's choice twenty years on with nobody mentioning Swing.
Then the web's components came back to the desktop. Electron put a browser inside the application in 2013, and Visual Studio Code's file tree is a list. Its makers' notes on lists and trees describe that list as a virtual rendering engine that keeps only the visible rows in the DOM, which is how, in their words, "you can easily add 100k elements to it without breaking a sweat," and then say what a tree is:
A tree UI widget should be able to represent tree-like data, eg. a file explorer. A rendered tree can always be rendered as a list; it is each row's indentation level and twistie indicators which give the user the perception of tree structure. By leveraging the virtual rendering functionalities of the list we can use composition to create a tree widget.
The browser's own attempt to build a virtual scroller into the platform was archived in 2021, because its authors found the problem harder than a standard could hold. Tauri 1.0 in 2022 kept the page and dropped the bundled browser.
So the shelf is npm now, and nobody owns it. Apple has said the same sentence since 1992, when its guidelines asked developers to use the standard elements so that what a person learned in one program would hold in the next, and its components page today asks for the same familiar and consistent experience. Fuji draws its own list and tree in the page, as Swing did and Visual Studio Code does, and the rest of this page is how.