Markup vs Code for UI – Angled Brackets, yay or nay?

C#:

With such a simple layout, they’re not so different. Nonetheless I believe if I were to see them cold, in the middle of a file, it’d be almost immediately obvious for me what the first is describing, whereas it’d take me a few seconds to pin down the meaning of the second. The first has to be a hierarchical object declaration. The second could be anything – that’s the beauty of code! – but by that token it takes a moment longer to narrow down the vast possibility space of what it could be saying to what it is saying.

Markup is a domain-specific language

This point is really a generalization of the first: markup is a domain-specific language for UI declaration, with all the advantages (and drawbacks) that entails. The parser can do a lot of clever stuff that might not be appropriate in a general-purpose language, like context-sensitive implicit conversions, specialized syntax, implicitly understanding nested content, etc.

Inherent separation of concerns

Markup pushes you to keep your UI separate from other layers of your app because it can only do UI. I don’t find this point particularly compelling: we’re reliant on discipline and good dev culture to maintain separation of concerns in all the other layers of the app, so I don’t think artificially forcing that separation solely for UI makes much difference. But I guess it’s a minor point in markup’s favour.

Markup is tooling-friendly?

I include this one because it seems to’ve been an important argument historically for why markup is superior. The argument is that markup, with its inherent structure and reduced expressivity, would be more amenable to tooling support where you drag and drop UI elements into a WYSIWYG editor. The dream seems to’ve been that designers would author the bulk of an app in such a tool, a developer would come along and tweak the resulting markup output, and app development times would be slashed.

I don’t think that’s necessarily technically inaccurate – such tools do exist, like Blend and Xaml Designer. It just doesn’t seem to be particularly relevant. The dream never really panned out. WYSIWYG tools are great for static documents, but in an interactive application there are key aspects that in practice must be manually handled by an experienced front-end dev, like responsive layouts and virtualized lists to name a couple off the top of my head. And a tool and a human ‘collaborating’ on the same raw markup is not a pleasant experience for either, making it difficult to do further tool-aided edits after the markup has been hand-tweaked.

The trend in practice seems to be for designers to use designer-focused tools like Figma and Zeplin, and then to focus on improving the capabilities of such tools to export feedstock for front-end devs, like first-draft markup layouts, colour and text style resources, etc.

Meanwhile on the dev side, the increasing power of ‘hot reload’ capabilities in most modern UI frameworks is making build-time design tools increasingly redundant.

Performance optimizations

Just as the constrained structure of markup is beneficial for editing tools, it also potentially lends itself to pre-parsed intermediate formats which may offer particular performance benefits. UWP’s Xaml, for instance, supports the Xaml Binary Format (.xbf) which loads faster at runtime.

It’s probably more than that: I suspect the curtailed expressiveness of markup helps to steer UI authors away from performance-killing anti-patterns. It’s easy to shoot yourself in the foot, when it comes to UI and performance, and markup by no means makes it impossible; but the exposed API surface tries to guide authors towards the happy path. Virtualized ListViews in Xaml languages are a good example.

Benefits of code

Let’s turn to the advantages of declaring UI in code.

Code is Turing-complete

I don’t mean, like, you literally couldn’t implement a Turing machine in markup somehow. (Maybe you could, feel free to tell me how.) But what I mean is that code is capable of expressing arbitrary logical constructs, that’s basically code’s whole job, whereas markup struggles to do so.

Proponents of code show examples of UI snippets that are neatly expressed as code, but verbose and unwieldy in markup, often involving conditionally setting a property, or transforming a value. Proponents of markup usually concede that there are some things markup just can’t (or shouldn’t do); no one I’ve seen is really maintaining the position that a rich interactive application can be built only in markup. The pro-markup position is that the mechanisms for calling into code from markup, or vice versa, are adequate. The anti-markup position is that they aren’t worth the bother.

I would note that the interconnectivity between code and markup varies widely from one markup language to another. Xaml leans heavily into said interconnectivity, with the whole notion of ‘code-behind’ as well as mechanisms like value converters, template selectors, behaviours, etc.