I got this question last week from a meeting. The title is a bit misleading because we do have a TokenScript JavaScript library in development. The actual question is "Why TokenScript is a framework and not purely a JavaScript library".
Presently TokenScript is an overlay of JavaScript with XML markup. It looks like the XML part which manages these JavaScript + data can be itself done in JavaScript.
Most specifically, an action card is launched either as a user action in the wallet or on the web. In the first cases, it can be called out with JavaScript; in the second case, it has to. So why don't you write Action Card as JavaScript function?
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.
One important aspect of it is that the piece of code that opens a card shouldn't be able to read what's in it. A card is given the privilege to read all token (or attestation) data. So, for example, a proof-of-age action card can read your age itself to generate a zk-proof of your age. The website, let's say liquor store, which opens the card should read and verify that proof; it should not be prevented to read your age. This requires them to be in separate VMs. In such a scenario, although the opening of a card is done through the JavaScript on the liquor store's website, it's not a direct call; TokenScript engine takes it over from there and deploys an environment to run the action card which has the needed JavaScript.
Even if there is no private information, the caller might modify the information in the action card. It's like early days of Paypal hack, where a web developer is able to modify a site's javascript code to do Paypal Checkout of 1 dollar and the website would take it as a successful order. In short, an engineless JavaScript implementation will not do.
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.
But in reality, the web needs to run much token logic at the back of it. Take the above liquor store example, the website needs to verify the proof of age at the backend. In another example, a hotel website might run a Weblogic specific to FIFA ticket holders. If you use a FIFA ticket token, the website needs to be able to access token data like membership tier. The same data layer is needed between the front and the backend, except that the backend might not be written in JavaScript.
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.
What if we just redo it in JavaScript?
I explained the choice of using an XML overlay with JavaScript in two sections, on setting up of cards, and on providing data layer. Both can be done in JavaScript. I don't think it feasible, but it's possible.
In the first case, the JavaScript will be "super JavaScript" managing JavaScript VMs and security/privacy - not impossible but certainly not as simple as creating an <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.