Always separate where possible. In my experience things can end up a tangled mess really easily.
I'm a big fan of mvvm. Keeps everything separate and simple.
A general programming discussion community.
Always separate where possible. In my experience things can end up a tangled mess really easily.
I'm a big fan of mvvm. Keeps everything separate and simple.
I did both, separated is my way to go. Having both separated makes things easier and cleaner IMHO. You can have a designer to create these seperated layouts, which is pretty cool when you're a UI/UX designer. The ability to reuse the same code with a different UI layout. And of course generates less conflicts on Git when someone worked on the code while you where on the UI.
I prefer to define the UI in application code, because separation introduces a lot of overhead for bindings.
Nevertheless, I think it is important separate UI code from business logic.
Separating them allows you to add additional interfaces, such as command-line interfaces, APIs and web pages
depends what you mean by application code.. I'd say if your business logic is exclusively used by a ui feature the best is to keep them together. but you probably want to abstract away things like data access. I found working with a nx monorepo helps reasoning about how to structure your code.