If you've built more than one SAPUI5 app, you've hit this decision: write the view in XML or in JavaScript. Both compile to the same controls at runtime. The difference is in how fast you write it, how easy it is to maintain, and how well your team can work with it. Here's the honest breakdown for 2026.
Why XML views are the default
XML views are declarative. You describe the UI, the framework builds it. For the vast majority of apps — master-detail pages, forms, tables — that is exactly what you want.
<mvc:View controllerName="my.app.controller.Main"
xmlns:mvc="sap.ui.core.mvc"
xmlns="sap.m">
<Page title="{i18n>appTitle}">
<content>
<Input id="nameInput" placeholder="{i18n>enterName}"/>
<Button text="{i18n>submit}" press=".onSubmit"/>
</content>
</Page>
</mvc:View>XML views are compact and readable. They also get strong tooling support: XML validation in SAP Business Application Studio, templates and fragments that snap in cleanly, and better separation of concerns — layout lives in the view, logic lives in the controller.
When JavaScript views make sense
JS views build the control tree imperatively in createContent(). That gives you full programmatic power: loops, conditionals, dynamic control creation — anything you can express in code.
createContent: function () {
const oPage = new Page({ title: "Dashboard" });
this.getTileConfigs().forEach((cfg) => {
oPage.addContent(new GenericTile({
header: cfg.title,
press: this.onTilePress.bind(this, cfg.id)
}));
});
return oPage;
}This shines when the UI structure is genuinely dynamic — say you have a dashboard whose tiles are driven by a configuration service. Generating ten tiles in a loop beats writing ten XML blocks. JS views are also handy for highly programmatic wizard steps or view composition logic.
Rule of thumb: if you can describe the layout statically, use XML. Reach for a JS view only when the control tree is truly data-driven and dynamic.
The trade-offs that actually matter
Readability wins in XML. A new team member can open an XML view and understand the screen in minutes. A JS view requires mentally executing the code to picture the UI.
Performance is essentially a non-issue. XML views are parsed once at load; the overhead is negligible for real apps. Don't let micro-benchmarks drive this decision.
Fragments tip the scale further toward XML. A dialog or reusable toolbar fragment is trivial in XML and plugs into any view type. Reuse patterns across the app stay consistent when everything is XML.
- XML: static layouts, forms, lists, pages — the 90% case.
- JS: dynamic, config-driven UIs where the tree can't be known upfront.
- Mixing: fine when justified — an XML view embedding a JS-built control works.
The 2026 verdict
SAP's own Fiori Elements tooling, templates, and documentation are XML-first, and that's not changing. In 2026, start with XML for every view. Switch to JavaScript only for the specific screens where the UI is genuinely dynamic.
XML for layout, JavaScript for logic, fragments for reuse. Stick to that division and your codebase stays clean no matter how big the app gets.
Got a view you built in JS that could have been XML — or the reverse? Drop your take in the comments.