Nope. â Security, backwards compatibility and JS feature parity.
Even if TWX is not compatible with TW5.x.y, it will start its own backwards compatibility-chain.
The elephant in the room: Security. If we would allow users to directly use JavaScript like wikitext, we would need to parse and sanitise it, to avoid misuse. Thatâs slow and super complex.
JS feature parity: The JS language specification advances every year. So in 2025 there is a specification ES2025, which defines the new features, allowed in JS. Browsers implement these specs in their own pace. Thatâs why we need pages like caniuse.com to see whatâs possible, to be used.
For the TW v5.4.0 core we defined our target to be ES2017. So if users would want to use newer features, which they will, we would need to implement a transpiler, to make their code compatible. â We will not want to do that. ** no â never ever - eiks **
So what you suggest is:
-
- procedures
-
- sanitised (for security reasons) and transpiled JS
-
- JS
Where no. 2 is a 1000 times more complex than handling widgets / wikitext.
You are right TW widgets are an abstraction. Widgets look very similar to HTML elements. So if someone knows HTML they should be somewhat familiar with the syntax.
TW wikitext, which contains plain text, HTML elements and widgets, is a so-called DSL (Domain specific language) â If you insert text or HTML code into your tiddler, we parse, sanitise and then prepare it for the browser, so it can âdrawâ it.
â The only purpose of TW wikitext is to allow ordinary users, to create interactive hypertexts, without the need to know HTML, CSS and JS. If they do know it, thatâs a plus but it is no requirement to start.
It can become a necessity if the users want to modify the appearance of TW. âŚ
Is an extremely simplified view.
Procedures and widgets are TW wikitext. To transform TW wikitext into html-code, that the browser can handle there are many more steps. All of them are some kind of âabstractionsâ for different usecases.
eg: This is ''bold'' text
A) For the user looks like this:
B) For the browser it looks like this
To be able to create the code for the browser we need:
C) A Parser - 1st step it looks like this:
We call it: âparse-treeâ. The parse tree is mainly needed for performance optimisations. Since parsing wikitext is the most time consuming operation, the parse-tree is cached. It is only recreated, if a tiddler is changed. It is used to find âback-linksâ, âback-transclusionsâ and some other stuff.
It âdescribesâ the âstructureâ of the text in a unified syntax, that we can use for the next step D)
D) parse-tree is converted to the widget-tree
If you have a closer look at the widget-tree, you can see, that it mainly is a description of HTML elements to be used, so the browser can make sense of our text.
E) Renderer
The widgets render() functions converts the widget-tree into HTML elements, so the browser can make sense of it.
How does all of this correlate with JavaScript. â Javascript it the general purpose language the browser understands. It is used to manipulate and manage our TiddlyWikiâs.
And here is the point, where the core JavaScript journey starts.
More precisely:
Looks simple - right
â But thatâs a completely different story.