Exploring the evolution of GUI toolkits
GUIs must be programmed like any other computer program, and just like libraries are created to provide standard components, a GUI toolkit exists to support building the graphical elements of an application. Many toolkits exist for different reasons—Wikipedia maintains a list of nearly 50 different projects, and growing, at https://en.wikipedia.org/wiki/List_of_widget_toolkits and https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries. To make sense of the huge number of options, we split them into categories, looking first at those built for specific operating systems.
Platform-specific toolkits
Each graphical operating system or desktop environment has a distinct look and programming style, therefore a graphical toolkit was traditionally created for each platform. Windows had the WinAPI (as well as WinForms and foundation classes), Atari was programmed using GEM, and BeOS used the Be API. Applications developed for Apple products have used various toolkits, but since macOS X it's called Cocoa (with desktops using AppKit and mobile devices using UIKit). Android devices are programmed with their own toolkit and other mobile platforms have explored other options.
The Unix and Linux operating systems have a more complicated story. Although the Motif toolkit was one of the first, the fact that its design offers multiple choices has meant there is no one true look or library. In the 1980s, before Motif was created, there was the OpenLook project that aimed to provide a standard interface look and feel for Unix systems. Although there were many different designs and toolkits to choose from, the main contributors to Unix decided that unification would help it compete with Windows and other desktop platforms. And so, in 1993, they chose Motif for future development.
One of the common features of desktop environment design is that it is frequently updated, as you could see in the screenshots of Microsoft Windows earlier in this chapter. Whether due to changes in fashion or advances in usability, these changes are expected and the Motif system did not adapt to them, and so new projects were created as alternatives. Later in the 90s, the GTK+ and Qt projects were started and provided a more modern, polished-looking user interface. Also, the Java platform launched with AWT (Abstract Widget Toolkit) in 1995, all of which were not platform-specific, opening a new world of cross-platform GUI libraries.
Cross-platform toolkits
The toolkits mentioned in the earlier subsection were all developed for a specific platform. They evolved along with the operating system design and are often developed using the manufacturer's preferred programming language. These challenges make it difficult (if not impossible) to create a single app that will work on all platforms. For that reason, the move to create a cross-platform toolkit requires taking a different approach and so developers started to design a library that could be written independently of platform specifics in a language that could be compiled for any of the operating systems it supports.
When GTK+ and Qt were created in the mid-1990s, they chose C and C++ (an object-based language derived from C), respectively. Both languages had wide adoption across most operating systems and were in use with some other toolkits already, keeping the barrier of learning low. The Java approach, however, was broader—to create a whole new language that would work across all of these platforms and deliver a graphical toolkit built on top.
Operating system and computer manufacturers have market power to sway technologies, and as new languages became available, they are able to force developers in the same new directions (such as Apple moving to Swift, Microsoft to C#, and Google moving their apps to Dart). However, the large open source communities built around cross-platform technologies are generally loyal to the language it is built with and so don't typically embrace such large changes. Therefore, these projects can be left behind in some senses and can encourage developers to look in new directions, such as web technologies.
Hybrid apps
As discussed earlier in the chapter, the WWW offered an attractive platform for delivering applications to users on multiple operating systems as well as providing a way to build apps once and run them on any computer. A web browser offers a highly customizable canvas so that, using Cascading Style Sheets (CSS), any HyperText Markup Language (HTML)-based application can be made to look like any design. This benefit brought a lot of popularity to web application development and even influenced some native toolkits to expand their theme capabilities to mimic this.
Websites, as described earlier in this chapter, were designed for information transfer—initially for read-only, and later for sending and editing data too. To get from this to a fully interactive application requires additional programming capabilities, and for this JavaScript is used. In the years since its creation, JavaScript has grown in popularity and complexity—there are now multiple package managers to handle the thousands of available packages that can be used in any JavaScript-powered app. Of these libraries, many are graphical toolkits for handling application interaction and layout, much like a traditional GUI toolkit. Of these, the most popular are currently React, Vue.js, and JQuery, though that list changes regularly.
When developing such JS based web-apps, the focus is on the user interface entirely (the frontend), whereas a full application may contain business logic and algorithms that may be part of the server infrastructure (the backend) of a web application. Historically, these separate parts of a complex application are created using different programming languages. This makes sense as there are different requirements for each area of a large infrastructure. However, for smaller applications, or to reduce technical complexity, it can be useful to use the same language for all parts—and so Node.js was created to support the JavaScript-based backend elements of an application as well.
Despite the benefits of distributing over the web, many companies still want to provide a traditional application that is downloaded and installed (the reasons are explored in the next section). To balance the speed of development and other benefits of web applications with the standard application package that developers are familiar with, a new breed of applications was created, nicknamed hybrid apps. These new apps are loaded in a standard container that loads the custom web application in a regular window like any other application on the system. Electron, Ionic, and React Native are all projects working in this space, offering a web-based app framework with varying levels of access to the system they are running on.
Alongside the evolution of graphical toolkits for cross-platform development, we cannot ignore the ubiquity of the web browser. Although it has the benefit of being present on most modern computers, it may not be the right solution for building your product – let's take a look at how these approaches differ.
