[FpUser]

>"the GUI always ends up being a ridiculous mess"

Well no. There are applications with nice well thought out GUIs.

>"Congratulations, a large amount of your effort will go towards resolving weird message bus problems as opposed to writing the business logic of your app"

Sorry but I do not resolve "weird message problems". I use my own publish-subscribe mostly asynchronous message bus for my GUI apps (actually I use it also for non GUI parts as well). Components (visible or not and including running threads) can subscribe to events. It does not exhibit any performance / memory problems and in combination with the global app state object makes programming interactions a piece of cake.

[nikisweeting]

Every codebase is clean and elegant when in the head of a single person. How big is your codebase and how many people work on it?

[FpUser]

>"Every codebase is clean and elegant when in the head of a single person."

Simply not true. I recently had to salvage business rules from a codebase written by single person over the course of many years. It was probably one of the messiest code I've ever seen.

>"How big is your codebase and how many people work on it"

Depends on a project. On some I work alone. Some had 2-3 persons. The biggest team I've ever had to lead was about 35 people (not all developers). Properly organizing and splitting work and using mostly experienced people the resulting code was very decent and quite possible to grasp. Also well documented.

[nikisweeting]

I don't mean objectively clean and elegant, I mean in the eye of the beholder it's easy for a tiny codebase to be clean.

But a system that may be clean and elegant for a 1-person gig may end up falling to bits if you attempt to have 100 people working on it.