• ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
    link
    fedilink
    arrow-up
    7
    arrow-down
    2
    ·
    1 day ago

    In my opinion the whole notion of coupling the UI to the API was a step in the wrong direction. It makes it effectively impossible to compose apps the way you can compose command line utils with piping. Apps should be designed as client/server by default, and then you could always leverage the service API for the app any way you want, slap a custom UI, use it in automation scripts, etc. It’s just way more flexible that way.

    • utopiah@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      11 hours ago

      Some apps are still done this way, e.g. transmission the BitTorrent client, but also ALL self-hosted Web apps. Sure it might feel a bit much to install containers on your phone “just” for that, or having to go through REST API despite being on the same actual device, but still it provides a TON of app.

      Anyway, yes I agree that it is often a better model. Still a lot of apps, e.g. Blender, Inkscape, etc do provide a CLI interface. So one can both use them with a GUI or without. It’s not decoupled like transmission but arguably it covers most needs.

      • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        3 hours ago

        yeah there are a handful of apps that follow this model, it would be nice if it was the standard way to do things. In fact, this could even be handled by the GUI toolkit itself since native apps have to rely on it to build the user interface. The toolkit could just automatically generate a JSON API based on that for example.