Comment by adamjs | Hacker News Reader

Comment by adamjs | Hacker News Reader

Parent Full thread

That's a great suggestion and I will make a better comparision with real numbers in the next release.

Currently, the memory usage is similar or less than that of Chrome/Safari, with most memory being allocated by the JavaScriptCore VM, render geometry pools, and some by the GPU texture atlas.

So far, we've managed to reduce the total binary size to about 25% of a similar Electron-based app by reducing dependencies to the bare minimum and punting platform features to be handled by the embedder instead. See our Platform API [1].

As far as runtime memory usage goes, a lot of that memory is being allocated by pools and cache structures to improve performance (the same is true in most browsers). We will be implementing a memory management API soon so that this behavior can be configured (offering users the ability to strike a balance between memory usage and performance).

Additionally, Ultralight is NOT multi-process. The overhead of tens to nearly a hundred renderer processes makes sense for sandboxing in a browser situation but not for HTML UI where the assets are controlled by the user and security is less of a concern.

- [1] https://github.com/ultralight-ux/ultralight-0.9-api/tree/mas...

> … HTML UI where the assets are controlled …

Real life HTML UI requires a bit more than standard HTML/CSS.

At some point you will discover that you will need something like this:

    elem.popup(popupElem, at)

to show arbitrary DOM elements as popup elements (DOM-element-in-its-own-window) like here https://terrainformatica.com/w3/sciter-tooltip.png

Yet pure HTML desktop windows: https://sciter.com/html-window/ with support of Acrylic/Vibrancy: https://sciter.com/sciter-4-2-support-of-acrylic-theming/

And at some point you may discover that by adding this to CSS:

   div.widget {
      prototype: MyWidget url(/js/widgets.js);
   }

and extending DOM Element by simple

   elem.merge(newHtml[, callback])

you will have the whole ReactJs thing obsolete/not-needed.

All that ...

If you want you can contact me so we can discuss all these in details.

> 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.

Just in case you can do that with Sciter already.

In your CSS to define

    div.my { behavior:my-widget; }

While loading HTML that contains <div class="my"> you will get SC_ATTACH_BEHAVIOR callback with the DOM event handler reference. By handling SC_ATTACH_BEHAVIOR you will return DOM event handler (a.k.a. behavior) - just a native function pointer that receives all DOM events on that element: mouse, keyboard, etc.

That's the same mechanism as HWND and WndProc but with lightweight DOM elements instead of Windows.

Example of such behavior that implements panels with tabs container: https://github.com/c-smile/sciter-sdk/blob/master/include/be...

Interesting, it's not too farfetched of an idea since there is a C++ API for accessing the DOM in WebCore and we have the ability to disable JS completely. I've added this to the issue tracker as an idea to explore. [1]

[1] - https://github.com/ultralight-ux/ultralight/issues/14

I'm sorry to hear that it's not multi-process. Ticked all of our boxes right up until that point. We have a use case to render our own UI, which from a threat modelling perspective can run in-proc, but also have another use case of running untrusted web content which absolutely needs to be out of proc. Do you have any plans to consider making it optional? I take it you've probably made architectural decisions that would make that extremely difficult?

Out of curiosity, who is "we"? How big is your team?

The team is currently me :). Will be hiring soon.

Reply on news.ycombinator.com