5 ms·

> You can create a GUI using something like Qt, but the code to make it is messy and unorganized. Having made a very large GUI myself, it gets very cumbersome

> You can create a GUI using something like Qt, but the code to make it is messy and unorganized. Having made a very large GUI myself, it gets very cumbersome to manage all of that. Haven't we moved past writing UIs in code about twenty years ago? I see your code samples, and all they look like is an improved version of the code UI creation we had in OWL, MFC, and other UI frameworks on other platforms. Starting about 1995 we had a better way: form designers that streamed objects (note: not even auto-generated versions of code, which is not much better, but object streaming.) Your UI is then designed and manipulated largely as a graphical UI -- that's what it is -- and manually written code is reduced to tweaks or state changes. For example: Delphi (the prototype of all modern UI frameworks); C++Builder; others. WPF may count although the generated text is ugly as :) - but it carries the concept. A NIB file on macOS. You get the idea.

flukus 9y ago
Form designers produce their own issues like compatibility between versions, poor interactions with source control and poor responsiveness. I don't see an issue with creating UI's in code, with a decent API like Qt and Gtk provide it's quite straightforward. Why should UI code be treated differently to other code?
- pjmlp 9y ago
  Because of productivity, and UI/UX workflows while prototyping. Why should I spend 30 coding something away that is doable in a few seconds with a couple of mouse clicks? It is not good to generalize, but most coders I have meant without any sense of UI design never used graphical tooling for doing UIs.
  - flukus 9y ago
    > Why should I spend 30 coding something away that is doable in a few seconds with a couple of mouse clicks? Because maintainability is more important than instant gratification. If you can do both then great, but IME visual designers are a maintenance headache.
    - pjmlp 9y ago
      I have exactly the opposite experience regarding visual designers versus code. Changing a couple of properties in layout files is more maintainable than hundreds of code lines just to change a visual effect.
      - dahauns 9y ago
        >Changing [..] hundreds of code lines just to change a visual effect. If you need to do that, your codebase has a serious problem.
        pjmlp 9y ago
        Basic example, WPF storyboard animation defined in Microsoft Blend versus coding the full animation by hand in C#.
robterrell 9y ago
30 years for NIB, right? From 1988 or so? I remember using GUI codegen tools in the 1990-ish era that would blow away your code changes with every GUI tweak. Interface Builder and delegates were a great solution to that problem. I just didn’t get to use them for a really long time.
zengid 9y ago
These are interesting points (although I don't quite follow some of your explanations). I've been trying to learn more about the history of GUI development, so I appreciate hearing about how it's been done. Here's an interesting discussion of Delphi (2013): https://news.ycombinator.com/item?id=7613543 https://news.ycombinator.com/item?id=7613543
- vintagedave 9y ago
  Sure - it was quick! Here's a short overview of how Delphi's UI design works. First, you have a visual form designer: drop a button, resize it, edit the caption, etc. All objects like buttons, edit boxes etc are classes with properties. They live on a form, another class. The key is object streaming. The form has instance variables: a private MyButton : TButton, for example, where TButton is the type. This list of fields is autogenerated by the IDE. However, those are created and values set not in code or managed by the IDE, but by loading from a human-readable text stream at runtime (stored as a separate file at designtime, and linked as a resource at compiletime), something like, from memory: Form : TForm Button : TButton Left = 100 Top = 50 Width = 70 // etc Caption = 'Hello' OnClick = MyClickHandlerMethod end; end; When the form loads, the object instances and their properties are created and set on the fly. A form will self-initialise it and its owned objects from that stream: it will create a TButton instance, assign it to its own Button field, set the Left and Caption properties for the button etc. That includes hooking up methods to events, which are just properties of a method pointer type. So effectively, you have a human-readable, easily editable format that is a streamed version of a class and instance/property hierarchy, which the class can recreate itself from. That is generated by a visual editor, and of course you can edit it manually. It is a very simple and clean format; as little as possible is stored. It is also very diff-able. Your code then is reduced to things like state changes or events - user clicks a button, you write code to do something. UIs are visual. Writing a complex UI in code is inefficient (manually doing stuff you should not have to do) and with a long modification turnaround time - you can't preview what it looks like, so changes take a long time. The important leap was to design visual elements visually; to stream, so it is OO, diffable, and still human editable if you need to; and to load from a stream via reflection/RTTI. Delphi did all that in 1995. C++Builder does all that too, in C++! It's beautiful compared even to Qt, and certainly compared to code like the original post, which reads like early nineties techniques to someone used to the above.
matchbok 9y ago
NIBs in macOS/iOS are horrible for development and code review. Using a UI to build UI is slow and clunky. There is no "moving past" it. That's a bad way to develop stuff. We don't do it with HTML, do we? No.
- pjmlp 9y ago
  > We don't do it with HTML, do we? No. How could we? There is hardly any design tooling that matches the capabilities of native ones. So we just give up and pretend we don't need them.
- dilap 9y ago
  Agreed that NIBs are terrible, but I've found prefabs in unity to be quite pleasant.
- woolvalley 9y ago
  I think that is a uniquely iOS thing since they insist on using computer generated IDs to link objects together, while %100 human editable UI formats like HTML or Android's UI XML formats don't do that. It's the same issue that project.pbxproj has in Xcode.
  - matchbok 9y ago
    Oof. I've had nightmares about the project.pbxproj file. Such a weird design decision on Apple's part.
- tenaciousDaniel 9y ago
  Exactly. I feel like the design experience of HTML/CSS is the best of both worlds. You're designing in code, but it's not imperative code, which is what you have to do in iOS if you want to escape the NIB. Using declarative code to define your interface just...makes sense.
  - matchbok 9y ago
    A few libraries have tried to build declarative UIs for iOS, with varying degrees of success. This is what I love RN so much - I can build UI in 20% of the time and effort.
polskibus 9y ago
You always need the capability to generate UI in code, because static forms sometimes don't suffice. For example the layout and contents of your form depend on the data that is sent to it, like render a choice as checkbox if it is binary, use dropdown otherwise. I used delphi, etc., MFC was really bad forcing too much inheritance.
- Fins 9y ago
  Ah, generating dynamic UI in Delphi. It worked surprisingly well, much better than many modern solutions do.
heedlessly3 9y ago
>Haven't we moved past writing UIs in code about twenty years ago? WYSIWYG editors suck for source control on teams. There's a reason why iOS development of the UI elements is still done thru code.
jpochtar 9y ago
It turns out it's really hard to get a UI Builder right with HTML/CSS. In particular, layout is tricky because DOM trees imply both bottom-up and top-down constraints. For example, text getting longer pushes down content beneath it, while at the same time, the text might be 50% of it's parent node's width. The first constraint is bottom-up: the text node influences it's parent and sibling DOM node's geometry, while the second constraint is top-down. I'm working at Pagedraw (https://pagedraw.io/ https://pagedraw.io/) which attempts to solve this problem. We make a UI builder for web. It pretty much works like all the UI builders of the past, but translates constraints into divs, flexbox, and other web standard html/css. We don't have the benefit other UI builders in the past have had of compiling into our own layout system, because we refuse to force our users to use a js-based layout library or take extra dependencies which could increase bundle size. It's only available for React Web for now, but we look forward to supporting React Native, and maybe even Proton Native in the future! Lastly to matchbok's point: > NIBs in macOS/iOS are horrible for development and code review. We hope that this is a problem with NIBs, and not with UI builders in general. We believe that it's because there are no NIB diff/merge tools, so we're building branch/diff/merge into Pagedraw as a first-class feature.
- misterdata 9y ago
  > In particular, layout is tricky because DOM trees imply both bottom-up and top-down constraints. Well you can always choose to roll your own layout algorithm and position everything in the DOM using absolute coordinates - e.g. https://diasli.de https://diasli.de implements an 'auto layout' mechanism disregarding DOM layout.
- city41 9y ago
  PageDraw is really interesting. I started the tutorial and when I click on the "Next ->" button, I get redirected to Google OAuth. Why is that? What am I logging into?

flukus 9y ago

Form designers produce their own issues like compatibility between versions, poor interactions with source control and poor responsiveness. I don't see an issue with creating UI's in code, with a decent API like Qt and Gtk provide it's quite straightforward. Why should UI code be treated differently to other code?

pjmlp 9y ago
Because of productivity, and UI/UX workflows while prototyping. Why should I spend 30 coding something away that is doable in a few seconds with a couple of mouse clicks? It is not good to generalize, but most coders I have meant without any sense of UI design never used graphical tooling for doing UIs.
- flukus 9y ago
  > Why should I spend 30 coding something away that is doable in a few seconds with a couple of mouse clicks? Because maintainability is more important than instant gratification. If you can do both then great, but IME visual designers are a maintenance headache.
  - pjmlp 9y ago
    I have exactly the opposite experience regarding visual designers versus code. Changing a couple of properties in layout files is more maintainable than hundreds of code lines just to change a visual effect.
    - dahauns 9y ago
      >Changing [..] hundreds of code lines just to change a visual effect. If you need to do that, your codebase has a serious problem.
      - pjmlp 9y ago
        Basic example, WPF storyboard animation defined in Microsoft Blend versus coding the full animation by hand in C#.

robterrell 9y ago

30 years for NIB, right? From 1988 or so? I remember using GUI codegen tools in the 1990-ish era that would blow away your code changes with every GUI tweak. Interface Builder and delegates were a great solution to that problem. I just didn’t get to use them for a really long time.

zengid 9y ago

These are interesting points (although I don't quite follow some of your explanations). I've been trying to learn more about the history of GUI development, so I appreciate hearing about how it's been done. Here's an interesting discussion of Delphi (2013): https://news.ycombinator.com/item?id=7613543 https://news.ycombinator.com/item?id=7613543

vintagedave 9y ago
Sure - it was quick! Here's a short overview of how Delphi's UI design works. First, you have a visual form designer: drop a button, resize it, edit the caption, etc. All objects like buttons, edit boxes etc are classes with properties. They live on a form, another class. The key is object streaming. The form has instance variables: a private MyButton : TButton, for example, where TButton is the type. This list of fields is autogenerated by the IDE. However, those are created and values set not in code or managed by the IDE, but by loading from a human-readable text stream at runtime (stored as a separate file at designtime, and linked as a resource at compiletime), something like, from memory: Form : TForm Button : TButton Left = 100 Top = 50 Width = 70 // etc Caption = 'Hello' OnClick = MyClickHandlerMethod end; end; When the form loads, the object instances and their properties are created and set on the fly. A form will self-initialise it and its owned objects from that stream: it will create a TButton instance, assign it to its own Button field, set the Left and Caption properties for the button etc. That includes hooking up methods to events, which are just properties of a method pointer type. So effectively, you have a human-readable, easily editable format that is a streamed version of a class and instance/property hierarchy, which the class can recreate itself from. That is generated by a visual editor, and of course you can edit it manually. It is a very simple and clean format; as little as possible is stored. It is also very diff-able. Your code then is reduced to things like state changes or events - user clicks a button, you write code to do something. UIs are visual. Writing a complex UI in code is inefficient (manually doing stuff you should not have to do) and with a long modification turnaround time - you can't preview what it looks like, so changes take a long time. The important leap was to design visual elements visually; to stream, so it is OO, diffable, and still human editable if you need to; and to load from a stream via reflection/RTTI. Delphi did all that in 1995. C++Builder does all that too, in C++! It's beautiful compared even to Qt, and certainly compared to code like the original post, which reads like early nineties techniques to someone used to the above.

matchbok 9y ago

NIBs in macOS/iOS are horrible for development and code review. Using a UI to build UI is slow and clunky. There is no "moving past" it. That's a bad way to develop stuff. We don't do it with HTML, do we? No.

pjmlp 9y ago
> We don't do it with HTML, do we? No. How could we? There is hardly any design tooling that matches the capabilities of native ones. So we just give up and pretend we don't need them.
dilap 9y ago
Agreed that NIBs are terrible, but I've found prefabs in unity to be quite pleasant.
woolvalley 9y ago
I think that is a uniquely iOS thing since they insist on using computer generated IDs to link objects together, while %100 human editable UI formats like HTML or Android's UI XML formats don't do that. It's the same issue that project.pbxproj has in Xcode.
- matchbok 9y ago
  Oof. I've had nightmares about the project.pbxproj file. Such a weird design decision on Apple's part.
tenaciousDaniel 9y ago
Exactly. I feel like the design experience of HTML/CSS is the best of both worlds. You're designing in code, but it's not imperative code, which is what you have to do in iOS if you want to escape the NIB. Using declarative code to define your interface just...makes sense.
- matchbok 9y ago
  A few libraries have tried to build declarative UIs for iOS, with varying degrees of success. This is what I love RN so much - I can build UI in 20% of the time and effort.

polskibus 9y ago

You always need the capability to generate UI in code, because static forms sometimes don't suffice. For example the layout and contents of your form depend on the data that is sent to it, like render a choice as checkbox if it is binary, use dropdown otherwise. I used delphi, etc., MFC was really bad forcing too much inheritance.

Fins 9y ago
Ah, generating dynamic UI in Delphi. It worked surprisingly well, much better than many modern solutions do.

heedlessly3 9y ago

>Haven't we moved past writing UIs in code about twenty years ago? WYSIWYG editors suck for source control on teams. There's a reason why iOS development of the UI elements is still done thru code.

jpochtar 9y ago

It turns out it's really hard to get a UI Builder right with HTML/CSS. In particular, layout is tricky because DOM trees imply both bottom-up and top-down constraints. For example, text getting longer pushes down content beneath it, while at the same time, the text might be 50% of it's parent node's width. The first constraint is bottom-up: the text node influences it's parent and sibling DOM node's geometry, while the second constraint is top-down. I'm working at Pagedraw (https://pagedraw.io/ https://pagedraw.io/) which attempts to solve this problem. We make a UI builder for web. It pretty much works like all the UI builders of the past, but translates constraints into divs, flexbox, and other web standard html/css. We don't have the benefit other UI builders in the past have had of compiling into our own layout system, because we refuse to force our users to use a js-based layout library or take extra dependencies which could increase bundle size. It's only available for React Web for now, but we look forward to supporting React Native, and maybe even Proton Native in the future! Lastly to matchbok's point: > NIBs in macOS/iOS are horrible for development and code review. We hope that this is a problem with NIBs, and not with UI builders in general. We believe that it's because there are no NIB diff/merge tools, so we're building branch/diff/merge into Pagedraw as a first-class feature.

misterdata 9y ago
> In particular, layout is tricky because DOM trees imply both bottom-up and top-down constraints. Well you can always choose to roll your own layout algorithm and position everything in the DOM using absolute coordinates - e.g. https://diasli.de https://diasli.de implements an 'auto layout' mechanism disregarding DOM layout.
city41 9y ago
PageDraw is really interesting. I started the tutorial and when I click on the "Next ->" button, I get redirected to Google OAuth. Why is that? What am I logging into?