Well, much has to do with making tokens available to websites and getting websites to use tokens and the fact that TokenScript is language agnostic (presently, WASM support is planned which onboards a lot of languages).
Card is not just a code container; it's also a unit of trust
We must be aware that the cards are not written by the same group of people who already trust each other; instead, they are composed. A Tokenscript engine builds a wall around a card and considers it a basic unit of trust in the first place.
The XML overlay is shared between front and backend
The XML overlay does 2 things:
- setting up cards, like knowing what cards do, what are the inputs and outputs, what keys are accessible to the card's code, how to stack it with other cards). We just covered cards.
- providing data layer, like how to get token attributes, events, which events would update which attributes, what data objects are accepted or stored. Let's move on to talk about the data layer.
If you build a miniDapp, which is only a user interface for the smart contract, then you don't need a website backend. Your whole dapp might be written on a static web page.
This is more prominent in the case that the website a market. e.g. Booking.com (a hotel listing website). It needs to deal with tens of thousands of tokens, and its deployment will be a bit like a "supernode", where processed token data is hooked to the web backend. The XML overlay in TokenScript can enable such data processor in various language and frameworks.
<iframe> and writing a DOM tree into it.
In the latter case, well, you can at least service web backends that is written in node.js. Currently, websites are largely not written in node.js. So maybe you can solve it by having the data layer implemented in other languages too. But that would require you have a common data layer definition. What will that be? Maybe jason, but then you lose the composibility and reference capacity which is already built in in the current XML markup. These can be amended by adding references and composability in JSON, but I would imagine the result will look like XML anyway, and recall that composed XML can always generate JSON whenever needed by flatterning and dereferencing. It's easy to do so so I wonder if there are much to be gain by ditching markup.