[goofballlogic]

I have to agree with @rado on this one. The article presents this as a "code" vs "UI" debate when really it's a "web" vs "app" debate.

Although we use the web as an application platform, it was designed for information interchange, and evolved to support "an Internet-scale distributed hypermedia system." Those are often two quite different things. An application platform focuses on "component semantics" whereas the concept of an "Internet-scale" application focuses on "connector semantics".

"Not only is the set of input controls really small, but these controls have almost no functionality associated with them." - yes and that's a useful attribute if you are architecting "internet-scale" applications (think hypermedia, rest, hateoas et al.) because the intent is that each component is dumb enough to be seamlessly switched out with another. In this mindset, a page in a web application does one thing and does it well. It doesn't coincidentally provide retina scanning and 3d imagery (yes, i know...)

Neither the code nor the UI of the web are "solved" problems if you are trying to use it as a traditional application programming platform. You need frameworks and tooling to accomplish that.

I'm not arguing here that it should be this way (although I happen to love the web concept), but the real debate here is about "web" vs "app" - not "code" vs "UI". HTML is designed to facilitate web applications and that will continue to evolve very slowly and deliberately. The alternative is to reimagine web technologies as a traditional application platform from the ground up.