Decker is normally sandboxed fairly strictly, but if you build Native-Decker from source you can opt into the Danger Zone, a supplementary interface for interacting with the local filesystem and spawning external processes. I've just introduced a counterpart for Web-Decker which allows Lil to interoperate with JavaScript, and thus access arbitrary browser capabilities:
danger.js["alert('hello from js')"]
This system automatically coerces data (numbers, strings, lists, dicts, and Array interfaces) between JS and Lil datatypes. It also wraps JS and Lil function values so they can be passed between languages and called directly:
danger.js["f=>f(f(47))" (on twice x do x,x end)]
# (47,47,47,47)
If you make use of these features, decks you create will not work properly on Native-Decker, and you'll have to worry about dealing with the behavior of different browsers on your own, so I don't recommend it for casual Lilateers. If you understand the risks and want to tinker with web APIs that aren't available in ordinary Decker, this is your escape hatch!
If you'd like to give danger.js[] a spin, check out the latest version of Decker from the source repo, build it with the DANGER_ZONE symbol defined, and then export an .html build of a deck from Native-Decker.