Explore direct DOM access via C++ API

[adamjs]

From a suggestion by derefr on Hacker News:

> > with most memory being allocated by the JavaScriptCore VM
If I'm writing a green-field HTML5 app, and I don't derive any benefit from Javascript, is the interface between Ultralight and JavaScriptCore clean enough to just rip out the JS support altogether, replacing it with something simpler?

I'm picturing:

1. I embed Ultralight into a process that exposes a simple script-loading API, ala the one in JSCore;

2. I write HTML with no <script> elements, just elements with onclick/ontouch/etc. handler attrs, where these handlers just contain a UUID;

3. Ultralight passes the "script code" (i.e. the UUID) to my trivial script-loading API, which simply looks up a native handler based on the provided UUID, and returns its function pointer;

4. Ultralight holds onto that function pointer and treats it just like a regular thunkable Javascript handler function pointer.

In other words, all the "dynamism" of the HTML would be handled by native, static code in my compiled binary, with the only thing being set up at runtime being the binding of DOM elements to those known-at-compile-time native handlers. The QML/XAML/NIB approach.

[s-ol]

I think it would be great to have this for high-performance applications that traditionally avoid HTML UIs because of the "heavy handedness" of the web stack or a C++/JS codebase split.

For API-Design purposes, maybe it is enough to write a glue library that breaks out relevant JS DOM functions into C++ and play around with that, then when the API itself starts making sense the individual functions could maybe be changed to manipulate the native DOM representations directly?