3 ms·

> And it's not just Smalltalk that had those pitfalls. It's also Java Swing. Tcl/Tk. Also, to one extent or another, any number of cross platform tools and libr

by woah 8y ago

> And it's not just Smalltalk that had those pitfalls. It's also Java Swing. Tcl/Tk. Also, to one extent or another, any number of cross platform tools and libraries. Given we've been at it so long, and the same mistakes have happened so many times, the pitfalls for cross platform GUI must be quite severe and hard to see. My guess is that the platform creators tend to put a lot of money into look and feel for their native components. This is hard to match for a small open source project (or anyone, really). The web platform gets around this by being flexible enough for the application creator to create a polished look and feel themselves, and ubiquitous enough for many designers and developers to know how to use it. That's also part of what makes it so resource intensive.

stcredzero 8y ago
My guess is that the platform creators tend to put a lot of money into look and feel for their native components. This is hard to match for a small open source project (or anyone, really). It sounds like you have an unspoken assumption that only the web has that degree of flexibility. That's false, however. The web platform gets around this by being flexible enough for the application creator to create a polished look and feel themselves, and ubiquitous enough for many designers and developers to know how to use it. That's also part of what makes it so resource intensive. Smalltalk was flexible enough for anyone to create such a look and feel. Everything above the border of the VM itself was in the class library and was modifiable in Smalltalk, and most everything was in the class library. However, as a member of that community I can attest that many felt the need of this, but no one wanted to do it. Everyone who needed that level of polish was on a professional project and couldn't afford to devote that many resources to it, and everyone else was fine with the "developer" level UI. The Web after the "Web 2.0" period grew both a developer and user culture emphasizing good looking interfaces with great UX. This was also increased by the aesthetics of smartphones and tablets after the appearance of the iPhone. The tools on the web are a bit less flexible than what was available to many earlier environments. However, there were more people with more motivation to make things look good. It's not about flexibility and technical superiority. It's about numbers and motivation.
- scroot 8y ago
  Pharo's new graphics system, Bloc, is going to change some of this. Already the guys rewriting GToolkit are experimenting with much better looking and more interesting UIs. And one of the backends is the same framework mozilla uses in their browser.
MarkMc 8y ago
> My guess is that the platform creators tend to put a lot of money into look and feel for their native components. This is hard to match for a small open source project (or anyone, really). I wonder whether the problem for cross-platform GUI can be solved by brute force. Swing had a terrible reputation for being slow and ugly, yet today I find Intellij (which is based on Swing) fast and good looking.
- ptx 8y ago
  The brute-force work there is in IntelliJ, not in Swing – they've reimplemented the most broken Swing components, like the menu bar. Other Swing applications are still slow, ugly and buggy. (And despite all their work, IntelliJ still suffers from Swing bugs.)

by woah 8y ago

stcredzero 8y ago

My guess is that the platform creators tend to put a lot of money into look and feel for their native components. This is hard to match for a small open source project (or anyone, really). It sounds like you have an unspoken assumption that only the web has that degree of flexibility. That's false, however. The web platform gets around this by being flexible enough for the application creator to create a polished look and feel themselves, and ubiquitous enough for many designers and developers to know how to use it. That's also part of what makes it so resource intensive. Smalltalk was flexible enough for anyone to create such a look and feel. Everything above the border of the VM itself was in the class library and was modifiable in Smalltalk, and most everything was in the class library. However, as a member of that community I can attest that many felt the need of this, but no one wanted to do it. Everyone who needed that level of polish was on a professional project and couldn't afford to devote that many resources to it, and everyone else was fine with the "developer" level UI. The Web after the "Web 2.0" period grew both a developer and user culture emphasizing good looking interfaces with great UX. This was also increased by the aesthetics of smartphones and tablets after the appearance of the iPhone. The tools on the web are a bit less flexible than what was available to many earlier environments. However, there were more people with more motivation to make things look good. It's not about flexibility and technical superiority. It's about numbers and motivation.

scroot 8y ago
Pharo's new graphics system, Bloc, is going to change some of this. Already the guys rewriting GToolkit are experimenting with much better looking and more interesting UIs. And one of the backends is the same framework mozilla uses in their browser.

MarkMc 8y ago

> My guess is that the platform creators tend to put a lot of money into look and feel for their native components. This is hard to match for a small open source project (or anyone, really). I wonder whether the problem for cross-platform GUI can be solved by brute force. Swing had a terrible reputation for being slow and ugly, yet today I find Intellij (which is based on Swing) fast and good looking.

ptx 8y ago
The brute-force work there is in IntelliJ, not in Swing – they've reimplemented the most broken Swing components, like the menu bar. Other Swing applications are still slow, ugly and buggy. (And despite all their work, IntelliJ still suffers from Swing bugs.)