3 ms·

WYSIWYG UI builders are very underrated. I don't even need it to be interactive: all I want is a UI-oriented DSL with live-preview. Which is why I personally t

WYSIWYG UI builders are very underrated. I don't even need it to be interactive: all I want is a UI-oriented DSL with live-preview. Which is why I personally think SlintUI is currently way ahead of the competition. The author basically suggests a DSL themselves despite this framework's UI being Rust constructs, as they note the importance of fast iteration and then say that because of Rust's slow compile times it's probably not the ideal language. A DSL provides more than fast iteration too. It also encourages good code quality by forcing you to separate the app's UI from the rest of the logic. And complete language control means that a true DSL with its own syntax will always be more readable than anything you can embed in Rust's.

PaulDavisThe1st 4y ago
> It also encourages good code quality by forcing you to separate the app's UI from the rest of the logic. This concept of separation is always interesting to me. In the 1990s, when MVC was first conceptualized, a GUI was (a) native (b) playing the dual role of both View and Controller. It is quite hard (not impossible, but hard) to separate the app's UI from "the rest of the logic". Consider trivial interactions (i.e. the Controller side of the UI element) like drags. What does a drag do? How do you conceptualize limits on the motion? How do you convey semantics between the Model and the Controller? How do you handle the differences between clicks (essentially drags with no movement) and actual drags? How does the Controller handle both axes? Gestures? etc. Remember: the UI is the thing that receives input events from <somewhere, and in its capacity as the Controller, alters the Model state, which in turn causes changes in the appearance of the UI (as the View). This then creates additional issues if changes to the Model state are expensive (i.e. the Model contains/controls heavyweight resources), and thus Controller interaction must first work on a "pseudo-model" which is also represented by the View aspect of the UI, until the interaction is complete, at which time, the Controller propagates the actual change(s) into the "real" Model. Yes, quite a bit of this has been revised/extended/expanded (e.g. Microsoft's View-Model concept), but the basic issues remain, and make the kind of separation you're thinking about hard to do in practice for all but basic data presentation applications.
- KRAKRISMOTT 4y ago
  We are back to two-way data bindings if you see frameworks like Svelte and Solid
  - PaulDavisThe1st 4y ago
    Most webdev stuff that I've seen completely fuzzes the distinction between View and Controller, or changes it into something quite different from the original concept in MVC.
    - lmm 4y ago
      The original concept was never very clear, or at least never very clearly communicated.
      - PaulDavisThe1st 4y ago
        I used to work downstairs from one of the UW CS&E faculty who helped push MVC, and I would disagree quite harshly. The problem, such as it is, is that the original examples they tended to use involved systems where the View and Controller were physically separate systems. Consider a medical scan data viewer with (a) a screen (b) a series of controllers to manipulate what appears on the screen. In this context, all 3 of MVC are clearly identifiable and easy to talk about and understand. But as it got applied to GUIs where there are no distinct physical controllers and all the interaction occurs intimately tied to the View (i.e. what's on the screen), it is harder to find the boundaries between the V and C parts (and to some extent even the M).
dcow 4y ago
Try xcode and swiftui.

PaulDavisThe1st 4y ago

> It also encourages good code quality by forcing you to separate the app's UI from the rest of the logic. This concept of separation is always interesting to me. In the 1990s, when MVC was first conceptualized, a GUI was (a) native (b) playing the dual role of both View and Controller. It is quite hard (not impossible, but hard) to separate the app's UI from "the rest of the logic". Consider trivial interactions (i.e. the Controller side of the UI element) like drags. What does a drag do? How do you conceptualize limits on the motion? How do you convey semantics between the Model and the Controller? How do you handle the differences between clicks (essentially drags with no movement) and actual drags? How does the Controller handle both axes? Gestures? etc. Remember: the UI is the thing that receives input events from <somewhere, and in its capacity as the Controller, alters the Model state, which in turn causes changes in the appearance of the UI (as the View). This then creates additional issues if changes to the Model state are expensive (i.e. the Model contains/controls heavyweight resources), and thus Controller interaction must first work on a "pseudo-model" which is also represented by the View aspect of the UI, until the interaction is complete, at which time, the Controller propagates the actual change(s) into the "real" Model. Yes, quite a bit of this has been revised/extended/expanded (e.g. Microsoft's View-Model concept), but the basic issues remain, and make the kind of separation you're thinking about hard to do in practice for all but basic data presentation applications.

KRAKRISMOTT 4y ago
We are back to two-way data bindings if you see frameworks like Svelte and Solid
- PaulDavisThe1st 4y ago
  Most webdev stuff that I've seen completely fuzzes the distinction between View and Controller, or changes it into something quite different from the original concept in MVC.
  - lmm 4y ago
    The original concept was never very clear, or at least never very clearly communicated.
    - PaulDavisThe1st 4y ago
      I used to work downstairs from one of the UW CS&E faculty who helped push MVC, and I would disagree quite harshly. The problem, such as it is, is that the original examples they tended to use involved systems where the View and Controller were physically separate systems. Consider a medical scan data viewer with (a) a screen (b) a series of controllers to manipulate what appears on the screen. In this context, all 3 of MVC are clearly identifiable and easy to talk about and understand. But as it got applied to GUIs where there are no distinct physical controllers and all the interaction occurs intimately tied to the View (i.e. what's on the screen), it is harder to find the boundaries between the V and C parts (and to some extent even the M).

dcow 4y ago

Try xcode and swiftui.