3 ms·

I think being CLI-first (and maybe API-first) is a really clever strategy. My gut feeling is that it’s much easier to get a CLI/API right than to get a GUI righ

by k_sze 6y ago

I think being CLI-first (and maybe API-first) is a really clever strategy. My gut feeling is that it’s much easier to get a CLI/API right than to get a GUI right. So you can just expose an API or a machine-parsable CLI, and let people who care enough to build their own wrapper GUIs the way they want.

Jtsummers 6y ago
Whenever I make a desktop application, this has been my strategy and it's usually been effective. Create a library for the core logic and various CLIs using the library to expose functionality (also helpful for creating automated tests of larger chunks of functionality). Then create a GUI that essentially wraps those same features in a pretty presentation and (hopefully) intuitive interface. Not everyone has liked my approach, though. And some managers have scrapped it even though the users (usually these are internal tools, so our teammates) liked it. Another advantage of this style is that, for me at least, I tend to get a better design out of the system which makes that "library" portion more reusable. In theory, that CLI tool can become a GUI or become a server application as well without having to change the core code. But many people (and I sometimes fall victim to this as well) when making a GUI integrate the business logic too tightly with the GUI code (the same with web services). Something about making a CLI makes it easier for me and many people I've worked with to make a clearer delineation between the core logic and the interface logic. Perhaps because we know the CLI isn't the final or only presentation.
- deleted 6y ago
  [deleted]
- BlueTemplar 6y ago
  And I suppose that this kind of approach should make it easy to make several wildly different UI's : - one desktop keyboard & mouse GUI - one small touchscreen GUI (- who knows, one day a Virtual Reality GUI ?) ?
  - deleted 6y ago
    [deleted]

by k_sze 6y ago

Jtsummers 6y ago

Whenever I make a desktop application, this has been my strategy and it's usually been effective. Create a library for the core logic and various CLIs using the library to expose functionality (also helpful for creating automated tests of larger chunks of functionality). Then create a GUI that essentially wraps those same features in a pretty presentation and (hopefully) intuitive interface. Not everyone has liked my approach, though. And some managers have scrapped it even though the users (usually these are internal tools, so our teammates) liked it. Another advantage of this style is that, for me at least, I tend to get a better design out of the system which makes that "library" portion more reusable. In theory, that CLI tool can become a GUI or become a server application as well without having to change the core code. But many people (and I sometimes fall victim to this as well) when making a GUI integrate the business logic too tightly with the GUI code (the same with web services). Something about making a CLI makes it easier for me and many people I've worked with to make a clearer delineation between the core logic and the interface logic. Perhaps because we know the CLI isn't the final or only presentation.

deleted 6y ago
[deleted]
BlueTemplar 6y ago
And I suppose that this kind of approach should make it easy to make several wildly different UI's : - one desktop keyboard & mouse GUI - one small touchscreen GUI (- who knows, one day a Virtual Reality GUI ?) ?
- deleted 6y ago
  [deleted]