Show HN: Ultralight – Lightweight, Pure-GPU HTML UI Renderer for C++ | Hacker News Reader

Show HN: Ultralight – Lightweight, Pure-GPU HTML UI Renderer for C++

ultralig.ht

527 pointsadamjs170 comments

>> We needed something in between a huge, all-in-one browser toolkit and a bare-bones HTML UI renderer that only supports a tiny subset of HTML/CSS spec.

>> We started over with WebKit, stripped it to the bare-minimum, then rebuilt it from scratch with an eye towards embedding.

This is very similar to the origin story of Flutter. [1] In the end Flutter team just abandoned the HTML based UI idea and went with their own component system. As per the podcast, the core team doesn't have any plans to bring Flutter to the desktop development. I wish they would do it, that way we can get a performant alternative to Electron.

[1] https://softwareengineeringdaily.com/wp-content/uploads/2018...

Edit: Found the actual quote from the podcast:

>> We allowed ourselves, I think it was a week or two and we just tore Chrome apart and see how fast we could move on our benchmarks. Allowing ourselves to break compatibility to the web. The end result was we were 20 times faster on some of the benchmarks that we cared about and obviously, the end product wasn’t the web, it didn’t render all web pages, but it taught us that there was a lot of potential to do things better, faster, if we worked on something that was beyond the web.

That's really interesting! Thanks for sharing.

There's actually been several HTML UI projects that "break compatibility with the web" in varying degrees, with some breaking almost completely (eg, Sciter and libRocket) for the sake of simplicity and performance.

The goal of Ultralight was to see if we could strike a balance between modern HTML5 compatibility (eg, actually being able to render the Alexa Top 50) and reducing size and complexity for use in an embedded use-case.

I think we've struck a good balance so far but can go much farther. We plan to support much more of the web platform while still remaining small by use of shared modules (eg, for WebAudio/Video) so users can pick and choose how big of a distributable they want based on feature support.

As an aside, I took 2 years off just to explore if this was possible, partly funded by my previous work on Awesomium. This project is the result of that research and development.

Do you support JavaScript? I always got the impression that that’s one of the most resource-heavy parts of the modern web, but at the same time it’s hard to render many modern webpages (webapps?) without it..

Yep! In fact we expose JavaScriptCore API directly to users so your native code can call directly into the VM. Check the samples in the SDK.

I hope you add https://codesandbox.io/ to the list of websites that you aim to explicitly support! They use VS Code's editor (Monaco) internally, which does not work in WKWebView on macOS.

> I wish they would do it, that way we can get a performant alternative to Electron.

Qt / QML is an existing performant alternative to Electron.

...and if you don't like C++

https://github.com/pauldotknopf/Qml.Net

How are their licensing terms?

GPL, LGPLv3 or commercial.

I love Flutter. It's super dumb that they are not pushing hard to every platform (you could render to the web and basically get the desktop for free!). I would love to use it for a desktop app, or maybe on the web.

I love Flutter, too.

There are other ways to get the same juice, though.

I love MOAI, for the same reasons as I love Flutter. Except MOAI has a better license .. even if the responsibilities for using it as a non-Game GUI are pretty high. You can do it, but you've gotta have Lua-foo.

In my case, I'm going to glom Ultralig.ht onto MOAI some day soon, and see if it makes the Flutter desktop problem irrelevant...

Someone else could do it. After all, Electron wasn't started by Google.

Not to dismiss work done by the Electron team but Electron essentially wraps Chromium via CEF, so, tangentially it was made possible by Google.

And Chromium came from -> WebKit (Apple) which came from -> Konqueror/KHTML (KDE)

Haha, I totally wrote that up but deleted it at the risk of sounding too fastidious.

You probably mean pedantic. 'Fastidious' concerns attention to detail, not level of detail.

no, pedantant is what you are doing: correcting above comms

We've reached peak Hacker News.

I wonder if there's a limit to thread depth.

homie electron doesn't use CEF in any way

Not only Flutter, that is how XAML and WPF came to be.

The team was lead by IE devs, which were trying to create a design how would it look like if the browser was actually designed for applications and not documents.

Also for those that aren't aware the initial design of CSS grid was based on how XAML grid layouts work.

https://github.com/google/flutter-desktop-embedding

My criticism of webkit is that it fails hard on separating concerns in code. The way JS is superglued into code base is prime example of it.

Netsurf is on other hand is an opposite:

Css parsing - separate lib

Html/xhtml parsing - separate libs

Network - fully based on external libs

Js execution - separate lib

Dom - separate lib

Layouting - separate lib

Final renderer - separate lib

It has a lot of promise

What? WebKit doesn't contain any JavaScript implementation, certainly not glued in. Apple uses JavaScriptCore (Nitro) which wasn't even open source; before Google forked Blink, they were using WebKit with their own JS engine, V8.

How spec compliant is Netsurf? JavaScript is "superglued" into the code base in all 3 major open source browser engines, mostly because it's also superglued into the specs.

I thought they were using Flutter in desktop development by way of the Fuchsia operating system.

WebKit is the only open source project I've ever needed to dig into which immediately signaled onerous complexity, and did not disappoint on that instinct until I gave up. You, too, can have this experience, if you really want. Take a weekend, if you've been programming for a couple decades -- more, way more, if you haven't -- and just try to build WebKit. Go to the repository, follow the instructions, and just try to build the project.

That anybody would -- or could -- dig in, tear it apart, and try to make something better... That is impressive and I salute you.

Edited to add: I am however only interested in using open source applications on Linux, so I'm out on this one, unfortunately. That's not strictly true -- for example, I use ST3 as my daily driver -- but I've got to see a substantial value proposition to weight my decision towards becoming a user. Still, impressive nonetheless, and best of luck to you in this endeavor!

Did you get deep enough into WebKit to see that the namespace for the utility functions is called WTF? :)

I also like how there are at least five string classes (to be fair, there are good reasons for most of them): String, AtomicString, StringImpl, CString, WebString.

Edit: If you're feeling particularly brave, look up some of the text-run and unicode bidi algorithm related code. I don't remember how old that code is, but some of the darker corners of WebKit go back literally decades.

Haha, at ease sergeant, thank you! Building WebKit from scratch was, shall I say, an exquisite learning experience. My first change was re-writing part of the CMake scripts to make it more elegant.

This part of the FAQ right here:

  Q: Who is behind Ultralight?
  A: Hi, I'm Adam Simmons...

YES that is what I am talking about! I hate it when people try to hide behind a company name. When they try to make it out like they're some big "proper" business. Just tell me who you are, and I'll trust you much more. Just like this. Thank you very much Adam!

Haha, you are welcome! I definitely don't hide, come join our Slack channel here: https://chat.ultralig.ht

Question: will there be a C API? (for using Ultralight from languages other than C++)

Yep! We plan to expose a C API to make bindings easier to generate.

A few questions

- What does it do to be better (smaller, more memory-efficient) than a browser engine? Which features does one lose?

- When will Linux support ship? (Edit: I see it's planned, this was just an assumption before)

- There could be bindings to other languages in the future, right? (Edit: I see .NET compatibility is planned)

Edit: - Where's the source? Yes, this is a rethorical question; What is the motivation to keep it closed? This will probably hinder adoption (unless support is damn good).

- Could you upload the files to GitHub (or some other, similar place)? It's probably less intimidating than "Get SDK" and a lot nicer to browse through samples on my phone (Chrome doesn't seem to forward zips to apps at all, I don't really have a good text/code viewer installed etc).

Hi there:

Pros (Ultralight is...)

- Smaller distributable (25% the size of Electron/CEF or smaller).

- Simpler and easier to build (fewer dependencies and smaller codebase).

- More configurable (users can do custom handling of file system, fonts, GPU rendering, clipboard, and more).

- Potentially more performant (all rendering is done via GPU command buffers).

- First-class support from an actual company.

Cons:

- No support for MathML, Geolocation, WebGL, IndexedDB, WebAudio/Video (for now)

- Less mature and unstable.

- Slower release cycle (might be a pro).

Linux support is planned and will ship when it's ready, you can track its progress here: [1]

Yes, we have plans to publish a C API interface to simplify bindings for other languages.

The WebCore source is available here [2]. The rest of the source is kept closed for now to keep our licensing/support options open. There's a chance we will find a better funding model and will open-source the entire repo in the future.

Yes, I agree the SDK packages should belong on GitHub, and will also be BSD'ing the framework/sample code so users can fork and hack on it at will.

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

- [2]: https://github.com/ultralight-ux/ultralight-webcore

Slower release cycle is a con.

Slower deprecation cycle is a pro.

> Chromium is awesome, it really is. But not for embedders.

> the API is currently available for C++ only and requires Direct3D 11 on Windows and Metal on macOS.

“Embedders” here seems to mean “people who want to embed a web UI in a desktop application.” This confused me at first because I wondered why an embedded systems UI framework only supported Windows and macOS instead of Windows and small Unixes.

"Embedding" is often the term used to describe using a scripting language runtime within a larger app, for example embedding a Lua runtime in a game or a Javascript engine in a database. I'd imagine that was the context for using that term here.

Thanks for the tip, will update the language to clarify.

Hi, I was a former Awesomium user (.NET bindings) and i think you did a good job, then told everyone to wait for the next version (2 years?) and.. there comes Ultralight which is a completely different beast. It can be impressive for people who need an embedded html front-end, but who wants to embed a real browser is left with CEF.. which is really cumbersome.

I think you should open source Awesomium also, allowing contributors to maintain it.

This looks like a useful framework.

To the creator: Could you help me understand how lightweight this is, in terms of memory usage? For instance, how much memory is used to render the Wikipedia sample page, when using Ultralight, vs. using a single Chrome browser tab to do the same?

Thanks!

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.

Just in case, here is Sciter rendering HTML 3.2 specification document using Direct2D/DirectX backend on 3840x2160 screen:

https://sciter.com/sciter-fps/

Real FPS is shown in window's caption (490 FPS).

Sciter Engine (HTML/CSS/script) is fully contained in sciter.dll (4.9 Mb) (https://github.com/c-smile/sciter-sdk/tree/master/bin/32) without external dependencies. It works on all Windows versions starting from Windows XP and provides choice of four backends to use: Direct2D (GPU and WARP), Skia (OpenGL and CPU) and GDI+ (just in case someone is still interested in mammoth's shit).

On MacOS it uses Skia/OpenGL or CoreGraphics. On Linux it uses by default Cairo (good enough) and Skia/OpenGL as an option.

Skia is not a small dependency, FWIW.

I mean binary dependency here - external DLLs.

But in any case I am building sciter.dll as with Skia (sdk/bin/skia32/) as without it (sdk/bin/32/)

I second this. Some real world comparisons would be indeed great, to see how much lighter it really is. I would also add some heavy page to compare in context of CPU and memory usage between chromium and this framework.

Where can I find the canonical list of how efficiently each tool renders that wiki page, I'd really like to see it?

Using HTML/CSS for UI design on the web[0] makes sense in that you don't really have an alternative besides embeds like Flash, Java, etc.

But surely it's non-optimal for native applications that have direct access to the native renderer and GUI systems, or at least to limit them to HTML and CSS and not some more optimal domain specific subset of XML?

[0]assuming one accepts the premise that "web apps" should even be a thing, which I know is controversial on HN to say the least...

Pure HTML for UI is pretty shit, with Vue/Angular/React it's bearable to develop in (though now huge), but:

Everyone knows how to produce "fuck it, it works" results with it.

Everything (almost) supports it.

It already runs on the web.

That's a valid excuse for the web, but there's no reason we can't take what works about the HTML/CSS as UI model and make it work better for native applications. Just sticking to the web model because it's familiar is laziness.

There's a balance to be found by each app developer between roll-your-own and just-use-a-web-browser.

There's room in there for Ultralight, Awesomium, Chromium, Dear Imgui, SDL, Cairo, WPF, even GDI+.

That's basically because (I think) there's still a lot of effort being put into recreating UIs - especially for apps, games, and embedded.

(In embedded, as in, embedded systems running linux or VxWorks or something, the story is less well known, but it's the exact same balance and set of choices.)

I imagine the intent of something like this is so you can embed things in your app that you've already published online (e.g., support documentation, news posts, etc).

In addition to the other responses, when I was developing a game / game engine we chose Awesomium to render the UI to improve modding capabilities. A lot more people are willing to manipulate a website than some other scripting language. Planetary Annihilation had the same thought as well, if you want to see results on a published title.

This got me excited as I will soon start working on a visualiser / developer tool for a niche industry. I am looking for desktop gui frameworks to build performant desktop apps with lot of visuals on the screen. Will give Ultralight a try along with some other suggestions in the comments.

In my app there will be lot of trees and mind-map style diagrams with traced signals. These will react to user input and as there is a change in state.

There is a need to support huge monitors or a multi screen setup so, I have currently ruled out Electron and looking at building a native tool as cross platform is not a priority.

Any suggestions are welcome.

I recently came across this excellent article comparing GUI frameworks [1]. It is definitely worth a read for anyone looking at building a serious desktop app. I have put my particular requirement in a longer format here if anyone is curious and has some suggestions [2]. [1]: http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trai.... [2]: https://pastebin.com/8SUpcgWJ

Is there a video or screenshot anywhere, I wonder? I'd like to see it in action. Rendering HTML could mean a lot of things.

It's not clear how much of a browser they are reimplementing. Features include XSLT and local storage, scroll bars, "text selection and dragging"? While on the to-do list is "full GIF support" and "CSS shadows." It's such a mixture of things that doesn't sound based on what you'd minimally need for a game UI.

"We've stripped WebKit to the bare essentials" - Sounds like maybe they took the non-rendering part of WebKit (eg layout) and wrote their own renderer(s)?

Fascinating.

It renders most major websites fine, it's similar to WebKit with a few rendering quirks. Here are a few screenshots:

- https://ultralig.ht/screen1.png

- https://ultralig.ht/screen2.png

- https://ultralig.ht/screen3.png

And yes, the renderer is completely new, this project has been in development for 4+ years.

i recommend putting screenshots of your acid test results right on your website. it's the first test people will run when evaluating your SDK anyway.

http://www.acidtests.org/

What? No major browsers pass Acid3 these days, AFAIK. Chrome and FF on my mac only get 97/100. Who are these people still running acid tests?

Great idea! Thanks.

I would really like to replace Electron. It's way too heavy for the types of things we want to use it for.

But two things make it extremely valuable:

1. Ability to render css and js, so that web devs can build our app

2. Easily cross platform. This is so valuable to us.

To add some weight on 2 - with Electron, you rarely have to even think about platform differences, and just about everything you'll need to handle for a typical app (including installers, code signing, automatic updates, app linking, notifications, etc. et al) can be taken care of easily, either through core libraries or community libraries.

Electron isn't just Chrome in a box. It's a whole ecosystem of libraries that dramatically accelerate and simplify cross-platform desktop development.

Just because you can get another project running on all platforms, that doesn't mean the experience is going to be a smooth one. There are so many potential boondoggles lurking here. Do you really want to bet your company on something that uses less RAM or CPU but could easily confront you with problems like, hmmm, suddenly 43% of your Windows users can no longer update their apps and you have no clue why and the maintainers aren't responding on Github?

Electron has its faults, but if we want to build something better, we should also understand its strengths. Despite its performance drawbacks, it's an impressive technology that gets many important things right.

QML from Qt Quick is actually much better suited for creating UIs. It still shows that HTML is a document markup language...

Just a shameless plug, we're working on https://github.com/ndsol/VolcanoSamples to integrate imgui and skia across all major platforms.

It's still very early stages, but maybe interesting to you?

Another shameless plug: https://github.com/pauldotknopf/Qml.Net

It has everything you mentioned, except HTML/CSS, but I'd argue QML is better than HTML/CSS for desktop.

This is pretty cool. If you told me 20 years ago that the future of UI rendering would be GPU-accelerated HTML... I would have laughed. Heartily.

Why such a surprise?

20 years ago Windows had .dlg resources that define layout and content of dialog windows. .dlg is just a binary representation of serialized window DOM.

16 years ago Visual Basic had .frm files that are close to what now known as QML.

Et cetera.

So there is nothing new with markup defining UI structure. What is new and quite valuable is CSS with its declarativeness and cascading.

And all of those were/are easier to work with than picking a div and turn it into a component.

One gets to write a bit of CSS soup and then ensuring it works as expected across all target browsers.

The next generation pf applications will be made with quantum computer accelerated excel spreadsheets.

One interesting Google project which I think shares a similar goal (but is not quite so easy to port yet) is Cobalt.

It strips down a subset of HTML that can then be used to render UI across different base platforms. I feel like it could be a good starting point as well

https://cobalt.foo/

I believe it's currently used by Youtube to render its HTML5 app on many set-top box devices

This is proprietary, so it's a non-starter.

Care to elaborate why? I'm not affiliated with the project in any way. But if it works well and the documentation/support are there, why is it as completely unusable as you seem to claim? Your comment sounds like you're just fighting the holy FOSS war.

Because I see every piece of software like this as something I will inevitably have to dig deep into the internals of to fix bugs and send patches for if I were to adopt it. So should you.

By being so religious about the open source aspect only, you are blind to the many potential other benefits a project may have. But to each their own.

I don't think that's true. I've long worked with software both proprietary and not, and I find myself digging deep all the time. I shouldn't have to reverse engineer my dependencies to find out why they're broken. When I do figure it out, I should be able to send a patch so everyone benefits. Without these basic things in place, I simply cannot get work done.

The other advantages are not really important. If an open source offering is lacking something, I can just add it myself. If the proprietary version is lacking something, I cannot.

And what if what you're doing is just a quick, one month project? Is it likely you must absolutely dig into the sources then? I would say no. The fact is, your original comment completely fails to address or take into account the context of the individual project. You think you're being reasonable, and of course there are great advantages to open source. I too would prefer this library to be. But the dogmatism and fanaticism is not just offensive to the author who claims elsewhere in the thread that he spent 4 years on this, it's also irrational and leads to suboptimal results.

>And what if what you're doing is just a quick, one month project? Is it likely you must absolutely dig into the sources then? I would say no.

You would be surprised. I can't even count on one hand the number of times I've send a patch upstream within the first 2 hours of using a new dependency.

I don't really care how long he spent on it. It was a waste of 4 years if it's just going to be proprietary.

> It was a waste of 4 years if it's just going to be proprietary.

Dogmatism all over again.

Sir_Cmpwn, i too find myself sending drive-by patches after trying out a new package.

Don't bother with this hateful guy, you rock!

Wanting to debug/maintain libraries you depend on isn't what I would call "religious".

> you are blind to the many potential other benefits a project may have

What makes you think we aren't paying attention?

Because the comment

> This is proprietary, so it's a non-starter.

did not go into _any_ of the other details or aspects of the project.

For me, I work on embedded systems, and every binary that goes on my devices have to be compiled with very specific toolchains/libs.

Now someone please explain why this isn't the electron-killer to save us all.

It's "just" a renderer for a subset of HTML/CSS. Things like this existed for a long time, and even smaller (e.g. https://github.com/libRocket/libRocket).

Electron on the other hand is a full browser runtime, for better or worse. It probably would make more sense to create a cross-platform application packager which embeds the operating system's web-renderer into a window. But I think one of the main selling points of Electron is that you're guaranteed a specific version of the browser runtime, so your app suddenly won't stop working with a browser update.

It's not a subset, it's the full WebKit layout engine underneath and supports most modern HTML5/CSS/JS.

Ultralight can render full websites just fine and is also a full browser runtime, the SDK ships with a Browser sample on macOS and Windows.

With that said, Ultralight is indeed somewhere between libRocket and Electron in terms of size and support. We won't support things that are unrelated to HTML UI (for example WebGL) and are able to reduce our dependencies/size/complexity by limiting said support.

> engine ... supports most

That's what subset means.

I'm sure what adamjs meant is "it's not just a renderer."

License.

Electron is MIT. Ultralight is proprietary. Electron always free to use even on comercial, ultralight only for small projects.

Openness. Electron succeeds because of dev friendliness.

- This sort of thing has existed for a while, and people still use electron [0], [1]

- It doesn't come with a DOM implementation, so most existing js libraries won't work. EDIT: actually it does have a DOM implementation, which is awesome

- Its API is in C++

- People are lazy

[0]: https://github.com/zserge/webview

[1]: https://bitbucket.org/chromiumembedded/cef

This thing HAS existed for a while (CEF/Electron, Awesomium, QtWebKit, GTKWebKit, etc.) but the size, memory usage, and flexibility has always been prohibitive.

Ultralight addresses all of those through a new, lightweight WebKit fork geared specifically for embedding in other apps. This is a major rewrite and has taken 4+ years to complete. I am the former creator of Awesomium and decided to tackle this issue myself.

Also, the library does come with a DOM implementation and most existing JS libraries work just fine.

Wow, that's awesome that it supports DOM.

> - This sort of thing has existed for a while, and people still use electron [0], [1]

For reference, CEF is not much more lightweight than Electron. It still inherits Chrome's bloat and multiprocess weight. Also, webview only supports IE on Windows which is missing a lot of features.

- Being a fresh C++ codebase, god knows what security vulnerabilities and stability issues it has.

- D3D 11 and metal required. Most likely huge compatibility/stability/rendering issues across different graphic cards and driver versions.

- Barrier to entry is one of the most important factors in a framework/library's success. You can't beat the Electron ecosystem where any idiot can make a cross platform app. This is really only useful for C++ developers.

> You can't beat the Electron ecosystem where any idiot can make a cross platform app.

As an idiot, I can attest to this. I'm constantly looking for lighter weight alternatives, but nothing so far has been nearly as simple as Electron. Here's the list of options I maintain: https://docs.google.com/spreadsheets/d/1dTZIp6z2J1IL7YgBlHG_...

Qml.Net [0] (I'm the author) is a pretty simple way to make a cross platform app. I think it's worth checking out.

[0] https://github.com/pauldotknopf/Qml.Net

I should mention that my current favorite (still exploring) is Haxe/OpenFL

- The beta is definitely not rock-solid stable yet but reasonably runs a majority of major websites. The current branch of Ultralight is based off of a stable branch of Safari/WebKit.

- The Ultralight library itself has no dependencies on D3D11 or Metal. The renderer emits virtual GPU driver commands that are consumed by the user (see GPUDriver.h). We ship a few stock implementations of GPUDriver for major platforms but users can undoubtedly write their own.

Could this run on OpenGL ES? I know of a few projects running chromium on embedded devices... Something like this could be handy!

The OpenGL driver is almost complete, it shouldn't be too difficult to port to OpenGL ES. We're definitely interested in targeting embedded devices with this.

After that you need to take it full circle and get it to run on WebGL!

Electron is bloated indeed, but it's open source.

Tell that to the users who have to wait ages for "Electron" to start, and then gives their system resources the hug of death. Life is way more nuanced than "FOSS is good, everything else is bad".

Maybe, but for projects like this, it's as simple as "FOSS is a prerequisite", for me at least.

Sometimes you wish copyleft licenses were still popular...

Suit yourself. It's just a shame for the users who have to suffer a worse product because of your dogmatism.

The WebCore module of Ultralight is open-source: https://github.com/ultralight-ux/ultralight-webcore

And support linux

Sure, it's not open source, but their licensing terms are quite generous. It's free for noncommercial use and for independent development (<$100k per year)[1].

Compare this to something like Qt, which is open source. But (as I understand it) it's LGPL licensed, meaning it can't be used commercially without paying the developer for a commercial license or releasing all the source code.

Of course, take this advice with a grain of salt. I've not really worked with Qt or Ultralight before, but I've been exploring my options for a project for a school club.

[1]: https://discuss.ultralig.ht/d/6-ultralight-0-9-beta-now-avai...

Edit: added source

> Sure, it's not open source, but their licensing terms are quite generous.

That's nice, but not being open source means it will never have the breadth of players who both use it and contribute back that Electron does, which is why it won't beat Electron on the long term, even if it had some intriguing advantages.

That's not what LGPL means, no. It's not GPL.

Interesting. I thought Qt was dual-licensed using the (L)GPL and a commercial use license[1].

[1]: https://www1.qt.io/faq/#_Toc_1_2

What they meant was that the LGPL is perfectly fine to use for commercial use, but you have to a) provide the source for just the library when requested (easy enough: provide a link), and b) allow for the program to run using a different or modified version of the LGPL library that's used.

That means you can dynamically link QT, and your program doesn't have to be (L)GPL. No commercial license required.

It is, but LGPL does not mean what you said it did. It doesn't force you to open your code if you allow users to replace the LGPL components. If you don't want to do that or run in an environment where you can't do it, then you have the option to buy a commercial license to free you from these restrictions.

Correct. The LGPL does not mean it can't be used without releasing all the source code AFAIK.

Funny you didn't mention sciter. Sciter is also free for noncommecial use. In terms of memory usage, binary size, sciter is good enough. The downside of sciter is its script engine isn't javascript, and it's closed source too.

Edit: When I say open source, I didn't mean it has to be free of charge.

Having worked with embedded WebKit in games before, this looks interesting. However, even more than binary size or runtime memory usage, I hope Ultralight optimizes for responsiveness. In games we’re usually dealing with frame times on the order of 16 ms (or less for MR applications); any sluggishness in the UI immediately stands out. Often the UI masks more delayed gameplay feedback and for html/js to be viable as an embedded framework for games, it needs to be as fast as native implementations.

To minimize latency, Ultralight runs on the main thread, single-process, and outputs to raw virtual GPU command buffers for consumption by the user. I worked in game engines before so I'm familiar first hand with responsiveness as a design goal.

What does "The new standard in UI." mean? As far as I know it's not really a standard until either many people are using it and/or it's ratified as a standard of some kind. Or is it saying that html is a standard? Is the implementation a standard implementation? If so how standard is it?

That's the largest text in the landing page and it's really confusing.

I downloaded it and launched the Browser sample Xcode project, take a look: https://vimeo.com/284388678

Tip: you can hold down cmd while clicking to interact with windows in the background.

Out of curiosity, why did Qt Quick not accomplish your objectives? I think it has a quazi-CSS/HTML/Javascript engine in the QML language

I take it this allows applications to (safely) render simple html inside of their apps without having to include the whole webkit/chromium engines? Or is there something else more that I'm missing?

What is the advantage of this compare to Sciter [1], which on the surface is very similar and lighter.

[1] https://sciter.com

I'd like to see one of these based on servo.

Servo is "one of these based on servo" :) Of course the embedding stuff is WIP just like Servo itself, but here's a few examples:

https://github.com/paulrouget/servo-embedding-example https://github.com/paulrouget/servoshell https://github.com/antoyo/servo-gtk

Having servo wrapped up with a nice api and sdk with a good up to date default example project is exactly what I mean. Just like electron/ultralight/sciter. These projects are great but they haven't been updated for over 6 months and they aren't designed for mass (developer) consumption. Not to disparage, even servo is still WIP so I understand that a ultralight-equivalent isn't possible right now, I'm just excited for when it does happen for servo. Don't downplay the value of packaging and documentation. :)

Last time I looked at Servo for the same purpose, the build was clocking at ~40MB. Unless something changes drastically, it's not gonna be any better than Chromium for Electron-type apps (except better performance).

I don't know if your figure of 40MB includes support for javascript, but if Servo offers native DOM apis that would let you omit all js-related dependencies. (I don't know if it will, hence "if".) Even at 40MB, with static assets like html templates, css, and images, and a compiled binary, you could probably package a full-featured app up at ~60MB, less if compressed.

I wanted to know how that stacked up against some of my favorite and most used apps on windows, so I made a list: https://pastebin.com/KnkFcJXh (sorry, it's a bit long for HN).

I'll be honest, if I could publish a native app that's blazing fast, is cross platform, and whose size sits between Paint.NET (40) and VLC (130), and is even a fraction as useful as those two I would be downright ecstatic. I know for some people the final build size is a very important metric for native apps, and to those people I'm sorry. But if it's under 100MB and it uses about the same amount of ram I'm actually pretty ok with it, and I think a lot of others would agree with me.

> but if Servo offers native DOM apis that would let you omit all js-related dependencies.

Nope. JS engine is deeply integrated in Servo. Thus it can not be much better than Electron.

For a period of time there were CEF interfaces for Servo. Unfortunately, when Firefox added their GPU webrender stuff, it broke and there was no effort to go back and fix it.

I looked into using this for a project and discovered this unfortunate result.

Yeah, we have a bit too much WebKit around.

I work at a company that has been doing a webkit-based GPU accelerated renderer for more than 4 years and we have great results powering many games with <1ms render times for many cases. Webkit however has a lot of intrinsic architectural limitations that we spent a lot of time trying to overcome. Now we are writing a new HTML renderer from scratch and our results are promising: 5x-12x faster than anything WebKit/Blink based. You can hear more about how that was done at CppCon 2018 (https://cppcon2018.sched.com/event/FnKC/oop-is-dead-long-liv...). Also I would love to hear from people interested trying Electron-based apps with our tech.

>…that only supports a tiny subset of HTML/CSS spec.

Which subset?

If this is based off of Chromium it may be required to be Open-Source. Unless the LGPL parts are dynamically linked, you must share the statically linked source just like with the GPL.

Regardless, I'm only interested if it is Open-Sourced.

It's WebKit-based, not Chromium-based. The only LGPL component of WebKit is WebCore and we have open-sourced our WebCore module here: https://github.com/ultralight-ux/ultralight-webcore

Glad to hear it. Too bad it's not all Open-Source. Otherwise, it's just another one of several preexisting closed source solutions.

From the FAQ: "WebCore has LGPL code, how can you be closed-source?

To satisfy the licensing requirements of the LGPL license we have published our source code modifications [here] and made sure all WebCore code stays linked in a separate shared module."

How does it compare with CoherentGT? https://coherent-labs.com/coherent-gt-or-hummingbird/

Hi, this looks cool! What's your ETA for Linux? Thanks!

You say this is a hard fork, so how do you intend to maintain feature parity with new HTML rendering concepts. eg imagine CSS Grid had not been invented yet?

We will be pulling upstream WebKit changes from the Safari stable branch into WebCore, so it's not a "hard hard" fork.

Is there any documentation here? How does styling work? Is there DOM manipulation? How is this useful at all?

There was actual documentation for 0.8 [1] but the source for it was wiped by an erroneous rm -rf and I couldn't update it for 0.9 in time. Full documentation and tutorials will be published soon.

With that said, the SDKs include full samples and framework code and all the API headers are documented so you can get up to speed fast.

- [1] https://ultralig.ht/docs

Yeah. I think the creator could have benefited from posting more documentation, videos, and examples of what this thing really looks like in practice.

When the documentation is so sparse it begins to feel a little like vaporware.

I don't believe it is. Check out the files you get when you download the "SDK".

it is really disappointing when I see open source projects refuse to use cross platform and vendor neutral APIs like Open0CL and go for Metal, direct3D or CUDA. please don't. you are defeating the purpose of free software!

Performance be damned!

very interesting. Would it be able to support games exported by Godot ? (they require webassembly and webGL) ?

http://docs.godotengine.org/en/3.0/getting_started/workflow/...

Couldn’t find any documentation for OpenGL but it says macOS is supported - anyone know? I’d like to use this with SFML or GLUT.

macOS is supported via Metal.

Uh... Where is the documentation?

I want to ask a dumb question: can Ultralight integrate with WebAssembly ?

When it comes to Linux, will it utilize Vulkan or OpenGL?

Definitely yes on an OpenGL GPUDriver implementation (it's done), Vulkan is still being explored.

+1 for Vulkan. Tell the exploration team to come back, Vulkan's here to stay.

Not sure what I said that elicited a negative reaction but it's worth noting I didn't imply they were porting to Linux, they explicitly mention it on the page.

Hi I'm [redacted], I author lcef, LuaJIT FFI bindings for Chromium Embedded Framework at https://github.com/Planimeter/lcef. I also work on Planimeter's Grid Engine, the largest 2D Lua game engine on GitHub. So, I'm fully invested in both exposing libraries to languages like Lua, and directly integrating those offerings with software.

So, while people are in here talking about Electron, which is most likely not your target audience and might be confused as a result, I am your target audience. I am looking for ways to move away from my engine's imperative UI system and to migrate to web-based UIs in an OpenGL setting, and I have been for years.

Adam, this looks great, and I've been waiting to see new solutions like this in the game development space for quite some time now. However, the only truly viable solution at the moment in my opinion is still CEF. The proprietary aspect is significant, and while some using Unity and Unreal might be interested based on existing license restrictions, for these reasons, I am not.

Can you explain how Ultralight is fundamentally different than projects like Awesomium and libRocket? It seems very similar to your previous work and not enough of a differentiator for someone like myself. Could you tell me why I wouldn't use EAWebKit instead of this?

I spent years as a Source Engine developer and avoided both projects because of their proprietary nature, and because of lack of updates to their underlying web browser libraries.

I fear this is a repeat of Awesomium, with a similar proprietary nature, and operating in a space where we will not see frequent updates to the underlying web libraries, regardless of using a subset of web technologies that UI developers would care about.

Hi Andrew, thanks for the comment!

Trust me, no one is more familiar with the issues of Awesomium (cumbersome licensing, slow update schedule, bloat, etc.) than myself and it was this reason that I decided to start over from the beginning.

Awesomium was similar in scope to CEF (and actually predates it by many months), it's goal was to wrap Chromium and make it accessible via a pixel buffer instead of a platform window.

Chromium in its initial stages was very tight and focused in its scope and only supported a subset of the current web platform we see today, I think the first Awesomium DLLs were something like 18MB or less.

Over the years Chromium grew larger and accumulated more complexity to a point where it was no longer a web renderer but something closer to an OS platform. Many of the features added were somewhat irrelevant for users looking to render HTML as a frontend but downstream developers like Awesomium and CEF had no choice but to integrate their updates as a whole since we were de-facto wrappers.

Ultralight is different. It's a hard fork of WebKit and has a considerable number of differences tuned specifically for embedders (such as the Platform API and virtual GPUDriver). We have much more control over the project and will continue making design decisions that benefit embedding as a first-class use-case.

Reasons to use Ultralight over EAWebKit are ease of use, pure GPU rendering and performance (EAWebKit, last I checked, depends on Cairo for all its rendering), and the backing of an actual commercial company that will support and maintain the product for years to come.

Sorry this took me all day to get back to you, but thank you for the response! The work you're doing is excellent, and it's fascinating to see the evolution of it.

I appreciate the informative breakdown. It gives me a much better understanding of the value proposition. You have a particularly unique understanding of the challenges embedders have and it's great that we have another option in the industry. Thanks for your time!

Does Ultralight provide a pixel buffer or just on-screen rendering?

Ultralight renders to a virtual GPU command buffer for later consumption by a user-space GPUDriver. We ship implementations of GPUDriver for D3D11 and Metal.

I'm of similar ilk (MOAI) to you, but at far lesser magnitude of relevance .. I wanna just say that I'll probably spend a few days next week putting Ultralig.ht into the MOAI engine where I can, and take it for a drive .. To me this represents the best of both worlds, Lua finally driving the HTML ship.

Gonna be an interesting year for us Lua frameworks with this thing around. One of the principle 'reasons' for not using Lua for everything, is poor HTML support - welp, "lua_remove(that) -- and all the things..."

This is awesome. I'm definitely going to use it for a project in the near future.

My personal favourite environment to solve the 'one codebase for all platforms' problem, has been .. MOAI. The reason is, it gives you everything you need from the browser/server relationship, with none of the bullshit; i.e. you use Lua for everything, and do nothing in HTML/CSS/javascript, etc.

Well, its been a nice ride. For my projects, MOAI has been very useful.

But with Ultralig.ht, the question is .. which part gets embedded in what. Naturally, it'll be a sinch to stitch UL->MOAI .. and with a nice result: can finally do business apps. ;)

Reply on news.ycombinator.com