Comment by ben_w
2 years ago
I've had a weirdly large fraction of my career spent on making UI rather than business logic.
That said, the business logic in apps is, half the time, a needlessly complex shim on what is ultimately "here's a REST API you can do in one or two lines via `Codable` etc. except we're anticipating needing to support several API providers… oh no the money ran out".
> I've had a weirdly large fraction of my career spent on making UI rather than business logic.
Same here. None of my employers could go more than 2 years or so, before the head of UX would declare "Our app is no longer 'fresh' enough, and our competitors are adding 'pop' and 'zing' to their apps! We must stop what we are doing and totally redesign our app, create custom controls, and flex our brand onto the user!" Too much of my career has been turning a designer's Photoshop graphic pixel-for-pixel into an application, without regard to the OS's standard controls or conventions.
Yup, which is where I suspect most of the "visual UI builders are not the right tools to express dynamic constraints" objections come from: people are over-constraining the problem space with irrelevant nonsense. Half of the problems stem from abandoning OS standard controls, many of the rest are managing complexity of a large and complex UI codebase that didn't need to exist in the first place.
It's not like most webapp UIs are particularly well-aligned or consistent anyway, nor they are easy to visually overhaul on marketing teams' whim - so, what's the point? Why use tools that make important and impactful things between difficult and impossible?
(A possibly legitimate argument against RAD tools is that they encourage mixing business logic with UI code (static and dynamic). I used to be receptive to that, but I long come into conclusion that "separation of content and presentation" is bullshit both conceptually and in practice. And guess what, with React & all, we're all back to mixing UI and business logic - or adding extra layers of complexity to pretend we're not.)
Not mixing business logic kind of stops being possible when the UI needs to follow your business logic. We used to do much less complex, less specialized apps. And on the other hand - building an universal business rule engine just because you needed a wizard with three business process steps seems excessive.