I think the author has a great point and it’s shameful that only a handful of applications respect that philosophy.
The best example I can think of a program that for the most part follows the described approach is mpd (maybe even mopidy, haven’t used it yet though). It integrates so easily in applications, desktop environments, less known status bars, terminal interfaces… yet it’s not tightly-coupled, it just exposes and endpoint for commands.
While separating interface and application adds more work to the list of tasks an average joe has to accomplish, it has been proven to help a lot with the separation of concerns that in turns translates to tidier code and thus potentially less bugs in the program.
It’s true that it makes the programs a bit less efficient, but with the amount of raw calculation power we can harvest even from the smallest of computers, I’m honestly confused as to why we keep writing coupled UIs.
(Then of course there are exceptions, like games and other programs)
I think the author has a great point and it’s shameful that only a handful of applications respect that philosophy.
The best example I can think of a program that for the most part follows the described approach is mpd (maybe even mopidy, haven’t used it yet though). It integrates so easily in applications, desktop environments, less known status bars, terminal interfaces… yet it’s not tightly-coupled, it just exposes and endpoint for commands.
While separating interface and application adds more work to the list of tasks an average joe has to accomplish, it has been proven to help a lot with the separation of concerns that in turns translates to tidier code and thus potentially less bugs in the program.
It’s true that it makes the programs a bit less efficient, but with the amount of raw calculation power we can harvest even from the smallest of computers, I’m honestly confused as to why we keep writing coupled UIs.
(Then of course there are exceptions, like games and other programs)