4 ms·

> 1. GUI vs. CLI - I want to support both. But should it be a CLI first application that's then wrapped with GUI? Or perhaps it's better to build it as a GUI fi

> 1. GUI vs. CLI - I want to support both. But should it be a CLI first application that's then wrapped with GUI? Or perhaps it's better to build it as a GUI first application, and add a CLI interface to it? Or just have a core library, and use it in independent CLI and GUI tools? I never wrote a cross-platform tool, so I am not sure what's the best approach. Don’t be GUI-first or CLI-first; be API-first. You can get started by writing a test target. As soon as you need more than “edit tests, recompile, run, examine debug prints”, you can start on both the GUI and the CLI together. Focusing on keeping a solid API makes things much simpler. And if you ever regret choosing Electron over Qt or vice-versa, having all the juicy parts behind an API makes it much easier to switch. For examples, look at Git, the TypeScript compiler, and Everything [0] (closed source unfortunately). There was a quick-search app for macOS that used V8-to-Rust asynchronous procedure calls as the API. It would make a great example, but I can’t remember it’s name. (Love the app idea btw! I look forward to trying it on my mess of files for my small business.) [0] https://www.voidtools.com/support/everything/sdk/ https://www.voidtools.com/support/everything/sdk/

goostavos 5y ago
>But should it be a CLI first application that's then wrapped with GUI? If you build it as a CLI, you can get the GUI for free via Gooey[0] (shameless plug)! [0] https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey
- Nicksil 5y ago
  >If you build it as a CLI, you can get the GUI for free via Gooey But then you've just added a dependency and, unless you vendor that thing, or don't update it in the future, you've no way to ensure it doesn't screw up your application at some point down the road. Design the API, write the code, then have your front end(s) (cli, GUI, etc) call into it. Best of all worlds, no additional dependency.
aliasEli 5y ago
> Don’t be GUI-first or CLI-first; be API-first. This is very good advice for all systems. First try to describe the domain before implementing the user interface.

goostavos 5y ago

>But should it be a CLI first application that's then wrapped with GUI? If you build it as a CLI, you can get the GUI for free via Gooey[0] (shameless plug)! [0] https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey

Nicksil 5y ago
>If you build it as a CLI, you can get the GUI for free via Gooey But then you've just added a dependency and, unless you vendor that thing, or don't update it in the future, you've no way to ensure it doesn't screw up your application at some point down the road. Design the API, write the code, then have your front end(s) (cli, GUI, etc) call into it. Best of all worlds, no additional dependency.

aliasEli 5y ago

> Don’t be GUI-first or CLI-first; be API-first. This is very good advice for all systems. First try to describe the domain before implementing the user interface.