Despite all the trends, I still really like HTML for structure, CSS for styling, and JavaScript for logic.

The boundaries aren’t perfectly clean, and that’s fine. But the separation gives you a useful way to think: structure this first, style it later, add behaviour where needed.

My experience with Compose—though I suspect SwiftUI people will recognise the feeling—is that I have to think about everything, everywhere, all the time.

Then we add some MVVM/UDF flavour. The "ViewModel" knows nothing about the view, despite usually serving exactly one screen. Add some "MutableStateFlow"s, combine them into "ScreenUiState", expose it as a "StateFlow", collect it with lifecycle awareness.

Beautifully decoupled. Extremely testable.

Then the organisation writes no unit tests and relies entirely on two-hour nightly screen tests.

A welcome-page refactor breaks the profile page.

“Didn’t you check the nightly build?”

No. It runs at night.

“Well, that’s your responsibility.”

But you broke it.

“Yes, but it’s your code.”

Then why did we ship it?

Fine. Schedule the postmortem with my mother.

And I’m not blaming mobile developers here. I’m frontend, backend, full-stack, I think AI engineer now. I have personally helped make simple things complicated across the entire stack.

What I like about the web is that one simple screen can be vanilla JavaScript. Another can use Vue. Another can use some specialised spreadsheet component.

People react to that with horror: what if components are duplicated, behave or look slightly different?

Fair concern. But that is real coupling with visible consequences and trade-offs. Somehow we have started treating coupling as something abstract that only exists inside code, rather than something that should produce an actual benefit when removed.

HTML. CSS. JavaScript. Or something close to it.

Maybe I’m getting old.