<p>In C to create a UI one must use a 3rd party toolkit such as GTK. However I read about Swing and AWT in Java which appears to be different implementations of UI toolkits built-in to the Java language. This is a cool feature in Java to be able to have cross platform, basic UI applications.</p>
<p>I am aware that a UI toolkit may be a big deal, and is clearly not an option for systems without graphical interfaces at all. I am not very familiar with systems other than Linux or Mac, but as far as I can tell, the idea is the same: Providing users with an API to programmatically create windows and populate them with other widgets.</p>
<p>What are the implications of including an (optional) UI toolkit in a the standard library of a language, and why don't more languages do so?</p>

<standard-library>
What are the implications of including a UI toolkit in a standard library?
CC BY-SA 4.0
2023-06-30T01:31:52.277Z
Another relevant point for answers that may have some discussion and information available: Java added a *third* pack-in UI library in Java 8 (why?), and then removed it a few versions later (also why?).
Michael Homer
CC BY-SA 4.0
2023-06-30T01:42:35.040Z
Cynical answer: the main implication is that you'll need a process for deprecating and removing it later. Best practices in UI design change too quickly compared to the stability normally expected of a standard library module.
kaya3
CC BY-SA 4.0
2023-06-30T01:43:54.860Z
Writing a library or toolkit that behaves like a good first-class citizen on all GUI platforms (e.g. interacting with third-party disability access tools like screen readers), including mobile platforms, is a huge task. Obeying the user interface guidelines is especially tricky. Famous example: On XBox, you "press" a controller button, but on PlayStation, you "push" it. Get this verb wrong and they won't let you ship.
Pseudonym
CC BY-SA 4.0
2023-06-30T10:30:55.807Z
On the other hand, having an easy-to-use builtin UI toolkit can be a major selling point for a language. See [Rebol](http://www.rebol.com/)/[Red](https://www.red-lang.org/), [TCL](https://en.wikipedia.org/wiki/Tcl), [Visual Basic](https://learn.microsoft.com/en-us/visualstudio/ide/create-a-visual-basic-winform-in-visual-studio), and [Pascal](https://en.wikipedia.org/wiki/Pascal_(programming_language)). I'd even put Javascript in this list due to web/Electron. You'll also note that most of these languages are on the older side, because desktop GUIs aren't so popular anymore (unfortunately).
BoppreH
CC BY-SA 4.0
2023-06-30T21:37:06.510Z
"to create a UI one must use a 3rd party toolkit" -- you seem to be assuming UI == GUI. The standard library of practically every language provides everything you need for a simple text UI.
Barmar
<p>Creating a good, cross-platform user interface toolkit is extraordinarily challenging, and what constitutes a good user interface is a moving target, so most GUI libraries go through significant evolution over their lifetimes. This remains true even for relatively mature GUI toolkits like GTK. In contrast, standard libraries tend to have exceptionally strong backwards compatibility constraints, which is likely to produce tension. Java itself is a decent illustration of this, as AWT, Swing, and JavaFX all coexist, littering the library with legacy cruft and fragmenting the ecosystem.</p>
<p>Still, in earlier decades, shipping an GUI framework in your standard library might have been considered worthwhile given the sheer utility of building GUI applications. But these days, native desktop applications are somewhat out of style: how often do you find yourself installing a new application with a traditional, WinForms/AWT/GTK-style user interface? I certainly don’t! Most of the desktop applications I use either come with my operating system, are professional-grade tools that roll their own GUI frameworks, or are Electron-style applications that are effectively an embedded web browser.</p>
<p>For that reason, it’s probably pretty difficult to justify going to the trouble to ship a native GUI toolkit with your programming language. There’s little downside to distributing the GUI library separately (which you can even give some sort of “official, language-endorsed blessing” if you like), and it avoids significant maintenance headaches.</p>

CC BY-SA 4.0
2023-06-30T04:54:12.227Z
2023-06-30T04:54:12.227Z
Alexis King
CC BY-SA 4.0
2023-06-30T15:30:58.890Z
I would argue that the proliferation of electron apps is at least partly *because* of the lack of native GUI support in many modern languages. My preferred language is Go. I have skipped adding a GUI to several internal tools, and switched to nw.js for stuff that does need a GUI, because there isn't a great way to do GUIs in Go.
9072997
CC BY-SA 4.0
2023-06-30T18:42:59.540Z
Of course, if Java didn't have its fragmented ecosystem of standard GUI libraries, it would probably have a fragmented ecosystem of third-party GUI libraries.
dan04
<blockquote>
<p>What are the implications of including an (optional) UI toolkit in a the standard library of a language,</p>
</blockquote>
<p>It can be a lot of design, implementation, maintenance, and evolution work.</p>
<p>For users that don't want/need to use that part of the language, it can be bloat in their development tooling installation, and depending on how application deployment works in the language and in the user's context, it may in some cases result in unnecessary bloat to users as well. This may be solvable by component-izing things.</p>
<p>And with deployment, you have to deal with things like how much reuse you want to normalize: Are you going to make each application bundle a standalone copy of everything needed for the runtime? Or try to take a more &quot;system package&quot; approach with more reuse? Or do you want to support both kinds of approaches? The more reuse you try to get, the more you probably have to commit to stability (like avoiding breaking changes to... avoid dealing with the headache of deployment and ecosystem implications of breaking changes), or deal with stability related issues. The more you drop reuse to not deal with that, the more you may find your ecosystem's applications &quot;bloating&quot; end users' machines. (Though I suppose with the &quot;system packaging&quot; approach, you could just have multiple versions of the language runtime side-by-side on the same machine, which is kind of like what the Visual C++ redistributables do I think)</p>
<p>That's not even getting into how much you want to try to fit into the look at feel of &quot;native&quot; applications on various device platforms, or specific platform versions of those device targets, or make use of &quot;native&quot; components (and all of the versioning things that happen in that space).</p>
<blockquote>
<p>Why don't more languages do so?</p>
</blockquote>
<p>If you want to make something that people will actually want to use, it has to solve some real problem(s) in the space of UI toolkits to some satisfactory  degree- Ex. writability, readability, performance, flexibility/&quot;power&quot;, platform support, etc. That's a non-trivial thing to do well (or to do at all).</p>
<p>The most important thing is the goals of the language. For many languages, this isn't even on the radar for standard support. Perhaps the reason being that the language's goal is to be flexible enough to support people in the ecosystem to build their own UI toolkits, perhaps because UI tookits aren't even remotely within the target application/problem domain of the language, perhaps because the language wants to instead enable users to use other existing UI toolkits through some sort of bindings, etc.</p>
<p>But there are languages where UI toolkits are a core part of the somewhat &quot;standard&quot; set of things. You already listed Java, which has Swing, and more recently, JavaFX (last I checked, that's not part of the standard library), Dart has Flutter, Kotlin has some ties to Android development, there's Tcl/Tk, in a way, I suppose one could consider HTML+CSS+JS part of that list too, I think Delphi?, etc. For many of those that I listed (maybe not so much Java and Kotlin?), building graphical frontends is very much part of their core- a problem space that they set out to tackle as a goal (to varying degrees). (This is the <a href="https://youtu.be/QyJZzq0v7Z4?t=113" rel="nofollow noreferrer">&quot;killer app&quot;</a> &quot;design strategy&quot;).</p>

CC BY-SA 4.0
2023-06-30T02:25:24.317Z
2023-06-30T20:03:32.020Z
2023-06-30T20:03:32.020Z
starball
CC BY-SA 4.0
2023-06-30T15:59:18.277Z
Kotlin is not *solely* Android. Java is often used for Android too. In fact, Kotlin is more often used for application rather than Android development.
Seggan
# What are the implications of including a UI toolkit in a standard library?
Posted by: username_0 on 2023-06-30
In C to create a UI one must use a 3rd party toolkit such as GTK. However I read about Swing and AWT in Java which appears to be different implementations of UI toolkits built-in to the Java language. This is a cool feature in Java to be able to have cross platform, basic UI applications.

I am aware that a UI toolkit may be a big deal, and is clearly not an option for systems without graphical interfaces at all. I am not very familiar with systems other than Linux or Mac, but as far as I can tell, the idea is the same: Providing users with an API to programmatically create windows and populate them with other widgets.

What are the implications of including an (optional) UI toolkit in a the standard library of a language, and why don't more languages do so?
**Tags:** standard-library
> **Comments:**
> **username_1**: Another relevant point for answers that may have some discussion and information available: Java added a *third* pack-in UI library in Java 8 (why?), and then removed it a few versions later (also why?).  
> **username_2**: Cynical answer: the main implication is that you'll need a process for deprecating and removing it later. Best practices in UI design change too quickly compared to the stability normally expected of a standard library module.  
> **username_3**: Writing a library or toolkit that behaves like a good first-class citizen on all GUI platforms (e.g. interacting with third-party disability access tools like screen readers), including mobile platforms, is a huge task. Obeying the user interface guidelines is especially tricky. Famous example: On XBox, you "press" a controller button, but on PlayStation, you "push" it. Get this verb wrong and they won't let you ship.  
> **username_4**: On the other hand, having an easy-to-use builtin UI toolkit can be a major selling point for a language. See [Rebol](http://www.rebol.com/)/[Red](https://www.red-lang.org/), [TCL](https://en.wikipedia.org/wiki/Tcl), [Visual Basic](https://learn.microsoft.com/en-us/visualstudio/ide/create-a-visual-basic-winform-in-visual-studio), and [Pascal](https://en.wikipedia.org/wiki/Pascal_(programming_language)). I'd even put Javascript in this list due to web/Electron. You'll also note that most of these languages are on the older side, because desktop GUIs aren't so popular anymore (unfortunately).  
> **username_5**: "to create a UI one must use a 3rd party toolkit" -- you seem to be assuming UI == GUI. The standard library of practically every language provides everything you need for a simple text UI.  
---
## 2 answers
### Answer by username_9 on 2023-06-30. Score: 4 | Accepted answer
> What are the implications of including an (optional) UI toolkit in a the standard library of a language,

It can be a lot of design, implementation, maintenance, and evolution work.

For users that don't want/need to use that part of the language, it can be bloat in their development tooling installation, and depending on how application deployment works in the language and in the user's context, it may in some cases result in unnecessary bloat to users as well. This may be solvable by component-izing things.

And with deployment, you have to deal with things like how much reuse you want to normalize: Are you going to make each application bundle a standalone copy of everything needed for the runtime? Or try to take a more "system package" approach with more reuse? Or do you want to support both kinds of approaches? The more reuse you try to get, the more you probably have to commit to stability (like avoiding breaking changes to... avoid dealing with the headache of deployment and ecosystem implications of breaking changes), or deal with stability related issues. The more you drop reuse to not deal with that, the more you may find your ecosystem's applications "bloating" end users' machines. (Though I suppose with the "system packaging" approach, you could just have multiple versions of the language runtime side-by-side on the same machine, which is kind of like what the Visual C++ redistributables do I think)

That's not even getting into how much you want to try to fit into the look at feel of "native" applications on various device platforms, or specific platform versions of those device targets, or make use of "native" components (and all of the versioning things that happen in that space).

> Why don't more languages do so?

If you want to make something that people will actually want to use, it has to solve some real problem(s) in the space of UI toolkits to some satisfactory degree- Ex. writability, readability, performance, flexibility/"power", platform support, etc. That's a non-trivial thing to do well (or to do at all).

The most important thing is the goals of the language. For many languages, this isn't even on the radar for standard support. Perhaps the reason being that the language's goal is to be flexible enough to support people in the ecosystem to build their own UI toolkits, perhaps because UI tookits aren't even remotely within the target application/problem domain of the language, perhaps because the language wants to instead enable users to use other existing UI toolkits through some sort of bindings, etc.

But there are languages where UI toolkits are a core part of the somewhat "standard" set of things. You already listed Java, which has Swing, and more recently, JavaFX (last I checked, that's not part of the standard library), Dart has Flutter, Kotlin has some ties to Android development, there's Tcl/Tk, in a way, I suppose one could consider HTML+CSS+JS part of that list too, I think Delphi?, etc. For many of those that I listed (maybe not so much Java and Kotlin?), building graphical frontends is very much part of their core- a problem space that they set out to tackle as a goal (to varying degrees). (This is the ["killer app"](https://youtu.be/QyJZzq0v7Z4?t=113) "design strategy").
> **Comments:**
> **username_10** (2023-06-30): Kotlin is not *solely* Android. Java is often used for Android too. In fact, Kotlin is more often used for application rather than Android development.  
---
### Answer by username_6 on 2023-06-30. Score: 11
Creating a good, cross-platform user interface toolkit is extraordinarily challenging, and what constitutes a good user interface is a moving target, so most GUI libraries go through significant evolution over their lifetimes. This remains true even for relatively mature GUI toolkits like GTK. In contrast, standard libraries tend to have exceptionally strong backwards compatibility constraints, which is likely to produce tension. Java itself is a decent illustration of this, as AWT, Swing, and JavaFX all coexist, littering the library with legacy cruft and fragmenting the ecosystem.

Still, in earlier decades, shipping an GUI framework in your standard library might have been considered worthwhile given the sheer utility of building GUI applications. But these days, native desktop applications are somewhat out of style: how often do you find yourself installing a new application with a traditional, WinForms/AWT/GTK-style user interface? I certainly don’t! Most of the desktop applications I use either come with my operating system, are professional-grade tools that roll their own GUI frameworks, or are Electron-style applications that are effectively an embedded web browser.

For that reason, it’s probably pretty difficult to justify going to the trouble to ship a native GUI toolkit with your programming language. There’s little downside to distributing the GUI library separately (which you can even give some sort of “official, language-endorsed blessing” if you like), and it avoids significant maintenance headaches.
> **Comments:**
> **username_7** (2023-06-30): I would argue that the proliferation of electron apps is at least partly *because* of the lack of native GUI support in many modern languages. My preferred language is Go. I have skipped adding a GUI to several internal tools, and switched to nw.js for stuff that does need a GUI, because there isn't a great way to do GUIs in Go.  
> **username_8** (2023-06-30): Of course, if Java didn't have its fragmented ecosystem of standard GUI libraries, it would probably have a fragmented ecosystem of third-party GUI libraries.  
---
