
C++ Lightweight, cross-platform, HTML rendering engine for desktop apps - plp12
https://github.com/ultralight-ux/Ultralight
======
antonyh
A few things strike me immediately here:

1\. Whole sections of the license are missing, such as section 5 - it's just
not possible to agree to something in this state.

2\. It's governed by the laws of Texas, so internationally that's not going to
work - I'd have to hire a lawyer just to figure out what this means

3\. Most importantly, I've no idea why I'd want to use this over embedding
Chrome or Servo.

4\. There's no ARM support. So no use on RPi, and potentially no use on Mac OS
on Apple Silicon, depending on the secret sauce used.

That's before I even start to dig deeper - is it thread safe? Can it fall back
to software renderer if needed? Will it be contentious for the GPU with other
code that wants to use it?

Only the C & C++ bindings are official, the others are 'community maintained'.
Whatever that means.

What I don't get, is why couldn't a dev team just embed WebKit directly - what
does this really give? Can it put a browser in game in 3D, or is it a 2D
overlay? Will it work with VR / AR?

The website makes a big deal over memory usage, which might be important in
some cases, but what about CPU cycles? GPU cycles? Latency? Impact on
framerate? Compatibility with Unreal, Unity, Godot, other engines?

I think it's a good project, but there's a lot of considerations before I'd
even download for experiments.

~~~
KenanSulayman
1\. Valid point.

2\. ?

3\. Chrome (or more specifically CEF -- Chromium Embedded Framework, the one
used by Spotify et al.) is significantly more heavy than UL. Memory use is
massive. Google doesn't care about API stability and ABI breakage is so common
you'll have to keep up with all API changes (the ones published and documented
anyway...) to get anything done. Good luck embedding Servo!

4\. ARM support is coming.

\---

> the others are 'community maintained'. Whatever that means.

I maintain the Rust binding to Ultralight [0] via the CAPI to provide an
ergonomic way for people to work with it. Adam is busy improving Ultralight
itself, so I find it worthwhile to maintain it. That's what it means.

[0] [https://github.com/psychonautwiki/rust-
ul](https://github.com/psychonautwiki/rust-ul)

~~~
OskarS
> Good luck embedding Servo!

You know, it doesn't really seem that hard to embed Servo in a Rust
application [0]. It's a pretty interesting read.

Anyone know how stable Servo is for this kind of thing? It's not uninteresting
as a cross-platform GUI solution or as more lightweight alternative to CEF
(assuming it is more lightweight, I haven't done the science on it or
anything). Given that you have total control over everything it renders, it's
not massively important if it's not 100% HTML compliant or whatever.

Interesting space to watch for the future. Hopefully the Mozilla layoffs don't
doom Servo.

[0]: [https://github.com/paulrouget/servo-embedding-
example](https://github.com/paulrouget/servo-embedding-example)

~~~
KenanSulayman
That's a great repository, thanks.

However, Servo just isn't ready yet. There are just so many rendering issues
that it's worth waiting for it to become more mature. (If you don't believe
me, open [https://psychonautwiki.org](https://psychonautwiki.org) with
Servo..)

------
zelly
Seems kind of misleading to post a github link that contains no code and it's
actually nonfree software

~~~
viach
The code is there, but not all of it, as I understood - except the
"Proprietary GPU Renderer". And yes - "Ultralight is free for non-commercial
use and free for commercial use by companies with less than $100K gross annual
revenue"

~~~
Rochus
Not all code is there. The website
[https://ultralig.ht/](https://ultralig.ht/) says "No source code for
proprietary modules" for the free version. If you want to use the technology
in your free application then you tnerefore have to depend on a proprietary
closed-source library. And as it seems only to save a bit of RAM. Better use
Qt.

~~~
genocidicbunny
To be fair, Ultralight supports the console platforms, which it cannot do with
open source code (not allowed by the developer agreements.) As such, it would
already have to have a way to deal with non-public binaries or sources in the
tree. In addition, a GPU renderer that plays nice as an embedded library, and
is performant and can properly render html is not a small feat of engineering.
I cannot entirely blame the author(s) for keeping that part proprietary. I
just question the wisdom of it in the face of free competition like WebKit,
CEF, Sciter or Qt.

~~~
Rochus
> Ultralight supports the console platforms

I don't understand that. The readme says "Ultralight is a lightweight, cross-
platform, HTML rendering engine for desktop apps and games." How does this fit
with your argument?

> which it cannot do with open source code (not allowed by the developer
> agreements.)

Why not?

~~~
genocidicbunny
Consoles, as in PS4, XB1, soon PS5..etc. Elsewhere in the thread the author
said that some of these are already supported, and others are coming soon.
Access to the SDKs for those, which you would need to run something like UL,
is governed by contracts that you as a developer sign with the platform owner
-- Sony, Microsoft, Nintendo, etc.

These agreements very rarely (read: never) allow publishing of the SDK sources
in any fashion. Even simply exposing code that calls into SDK functions would
be in violation.

You don't get access to the SDK unless you sign the contract, and if you sign
the contract and breach it, they have legal cause against you. Usually if you
want to use third-rdparty software for these closed platforms, the third-party
and you must both have developer agreements with the platform owner. This of
course excludes software that you as a developer ported to the platform on
your own.

~~~
Rochus
Ok, I see, you're talking about home video game consoles, not command-line
interfaces. I'm not home console developer (nor user); one reason is that it
ties one too closely to the proprietary technology of individual
manufacturers. But I see your point. Your arguments do not contradict my
statements. I only stated that not all source code are available in the free
version and therefore it is not an open source product.

------
minus7
Proprietary renderer (not even source-available; Linux binaries linked against
god knows what version of libc, libstdc++, etc) ontop of WebKit? No thanks.

Edit: I mean, sure, you could use it in your proprietary Electron app to make
it more lightweight. At least on Windows, macOS and some Linuxes, the rest of
users is left out then, but those free software enthusiasts are unlikely to
use your software anyway.

~~~
swiley
A lot of people really don’t seem to get that users rejecting Linux binaries
isn’t _just_ them being idealist, it’s also a big usability thing.

------
codegladiator
Wow this is great.

> [https://forum.ultralig.ht/t/community-language-
> bindings/20](https://forum.ultralig.ht/t/community-language-bindings/20)

``` Several awesome members of our community have created bindings for other
languages!

Check them out below:

    
    
        C# – https://github.com/ImpromptuNinjas/UltralightSharp 104
        Rust (High Level) – https://github.com/psychonautwiki/rust-ul 21
        Rust (Low Level) – https://github.com/psychonautwiki/rust-ul-sys 7
        Java – https://github.com/Janrupf/ultralight-java 10
        Go (High Level, Framework) – https://github.com/ImVexed/muon 22
        Go (Low Level)-- https://github.com/raff/ultralight-go 19
    

Let me know if I’m missing any and I’ll add it to this sticky!```

------
rcarmo
There should be a list of Electron alternatives somewhere. This looks like a
promising start, at least.

~~~
ilkkao
This lead me to think that there are huge amount of legacy HTML functionality
that Electron could potentially drop if it was possible. Electron doesn't
really need to care about breaking the web. So there's definitely room for
alternatives.

~~~
michaelchisari
A strict subset, chosen for the greatest intersection of flexibility for
developers, simplicity and performance with good documentation on how to write
directly for it might go over well.

The hardest part for maintainers would be saying no when everyone inevitably
asks to expand the feature-set.

~~~
diegoperini
If we choose a year as a checkpoint to start deprecating old web technology
without sacrificing functionality, which one would be the reasonable pick?

------
sunflowerdeath
It looks strange to me that it tries to use HTML, because then it should be
compatible with Web APIs and should render the same. Then it would be
basically a browser, not very different from what is used today in Electron.
But if it will differ from Web platform, why not to just make lightweight
alternative DOM-like API.

~~~
formerly_proven
Been there, done that. Qt has had a renderer for a reasonable subset of HTML4
and CSS2 since the Qt 3(?) days. If you see a Qt app and there's colored text
or bold/italics inside a label or editor, that's all done using that flavor of
HTML. It gets rendered through the standard QPainter engine.

------
jamesu
In the realm of lightweight html renderers I've taken a liking to litehtml (
[https://github.com/litehtml/litehtml](https://github.com/litehtml/litehtml) )
- though it isn't quite as fully featured as this.

------
pornel
I hoped Servo would fill that niche.

It's nearly impossible to write a new browser engine that is compatible with
all the legacy mess on the wild web, but for packaged webapps a modern minimal
engine is exactly what they need.

~~~
Tarq0n
Servo isn't necessarily dead, though it is ambitious for a community-run
project. There's still activity on the repo.

------
rsp1984
_Ultralight is free for non-commercial use and free for commercial use by
companies with less than $100K gross annual revenue._

Something that I have always asked myself is: If the code is open source, how
would it ever be possible to enforce such a licensing model?

~~~
gridlockd
It isn't open-source in the "FOSS" sense. You can't have such terms in a FOSS
license.

However, you can have _parts_ of a codebase be FOSS licensed, if the license
is compatible with non-FOSS code. BSD, MIT and Apache licenses allow this,
copyleft licenses like the GPL don't.

~~~
johannes1234321
GPL (and others) allow such a model as well. There is nothing in the GPL
preventing me from selling for as much as I like. The buyer however has to
receive the source code (upon request) and can share it for free (as in beer)
if they like.

~~~
gridlockd
I'm taking about using a _license_ that has provisions such as "can only be
used for free by entities with less than $100,000 in revenue" (this case) or
"must not be used for evil" (jslint). Such a license would not be considered a
free software license, because it restricts the use:

[https://opensource.org/osd.html](https://opensource.org/osd.html)

As a result, the license would be incompatible with copyleft licenses.

Of course, you could kindly ask your "customers" to please pay for a license
in case they're using the software for some purpose. Good Luck with that.

------
nodefourtytwo
How does it compare to Revery[1]? Onivim2[2] is built with it and it seems
great.

[1] [https://www.outrunlabs.com/revery/](https://www.outrunlabs.com/revery/)

[2] [https://v2.onivim.io/](https://v2.onivim.io/)

~~~
sunflowerdeath
Revery is fully native and doesn't use parts of web platform. It uses
ReasonML, that is dialect of OCaml and has its own implementation of platform
and renderer.

------
jakearmitage
If you are considering something like this for games, try:

[https://github.com/mikke89/RmlUi/](https://github.com/mikke89/RmlUi/)

or for apps:

[https://sciter.com/](https://sciter.com/)

~~~
c-smile
Sciter works just fine in games. Sciter.Lite (windowless engine) was designed
exactly for that.

Here it runs in Unreal Engine: [https://sciter.com/see-sciter-lite-unreal-
engine-in-theaters...](https://sciter.com/see-sciter-lite-unreal-engine-in-
theaters-near-you/) \- HTML/CSS primitives are rendered directly into DirectX
surface controlled by Unreal.

------
sradman
According to the Architecture section of the GitHub page [1]:

> Ultralight is a new port of WebKit combined with a new [proprietary]
> lightweight renderer intended specifically for embedding in apps and games.

And the Licensing section:

> Ultralight is free for non-commercial use and free for commercial use by
> companies with less than $100K gross annual revenue. For more info see
> LICENSE.txt

Pricing [2] is available from the main web site.

[1] [https://github.com/ultralight-
ux/Ultralight#architecture](https://github.com/ultralight-
ux/Ultralight#architecture)

[2] [https://ultralig.ht/#pricing](https://ultralig.ht/#pricing)

------
shubham_sinha
[https://github.com/vlang/ui](https://github.com/vlang/ui) also seems
promising and more targeted to devs who're more comfortable with go lang

~~~
nkozyra
"pre-alpha" and it seems excessively declarative

~~~
1f60c
That's the trend du jour :-) (see also Flutter, Jetpack Compose, SwiftUI, …)

------
rawoke083600
For once I want to see "heavyweight" in the sales line... Just to see how it
compares to all these "lightweight" offerings. Once you add in all the corner
cases and bug fixes it seldom stays "lightweight". Good job on releasing it
though.

------
miki123211
How does the accessibility story look like? If there's no accesibility, the
usual disclaimers apply, get legal advice before building anything
professional with it. Be aware of not just current laws, but future ones,
especially those we definitely know are coming.

~~~
nlitened
Honest question — do I really get into jail or get sued for high penalties if
a small tools I make for my clients are not "accessible" by any measure?

~~~
badsectoracula
No developer is going to be sued for their application having no accessibility
features. The one who might be sued is an employer _forcing_ some employee to
use the software to perform their task without any other alternative,
essentially making it impossible for that task to be performed by that
employee. Unless you are in a position to cause this, you are not going to be
affected (and even then, you getting sued is very unlikely unless you are said
employer).

In practice the worst that can happen to you is people with accessibility
needs not using your software.

------
fwsgonzo
This looks very promising. Will there be PS4/PS5 support, or is that not under
consideration?

~~~
pjmlp
PS already supports WebWidgets, the menu selection was done in WebGL.

------
niutech
Previous thread:
[https://news.ycombinator.com/item?id=17733515](https://news.ycombinator.com/item?id=17733515)

------
dusted
9 MiB is lightweight?

~~~
gridlockd
That's RAM usage. Not sure what this measures, but a single Full-HD backbuffer
at 32bpp is already 8MiB.

------
newsbinator
Their pricing model could be adjusted.

It doesn't make sense to charge $2000/yr for an app that makes $1 of revenue.

~~~
jashmatthews
$1 revenue startups pay $0. $100k+ revenue startups have to pay $2k for the
commercial license. Seems fair to me.

~~~
newsbinator
Ah under Single Title license it says:

> $0K - $500K : $2000

But under Free License it says:

> Free for non-commercial use.

> Free* for use by companies with less than $100K annual gross revenue

Got confused.

~~~
ecmascript
I think that is if you want the additional stuff like support. You can still
have $5 in revenue and purchase a license, that will make you fall into the
first category and have to pay $2000.

You don't have to purchase a license, but you can if you want.

~~~
adamjs
Yep, this is correct! I'll update website pricing to make this more clear.

------
qppo
What ever happened to Awesomium? Wasn't that more or less the same project by
the same author?

~~~
genocidicbunny
I'm pretty sure this is what Awesomium became. When I last looked into
Awesomium (like 8 years ago now) its development seemed to have stagnated and
the developer was trying to find a way to monetize it.

~~~
qppo
IIRC he shutdown the website and abandoned twitter leaving paying customers
high and dry. There was some talk of it last time this project made the forum
rounds.

~~~
adamjs
Hi there, author of UL and Awesomium here.

We didn't abandon anything, we announced to the community that we were
stopping development of Awesomium (our previous Chromium fork), are going to
build something new (which turned out to be UL, I wrote the rationale
elsewhere in this thread), and continued to support our paid customers for
years after (all licenses came with a 1 year annual support contract with
option to renew, we would be in contract violation if we didn't).

We did stop maintaining the free online support community which I think is
where this sentiment came form. Users were upset that there were no new
versions of Awesomium and there was a 4 year gap before the first alpha of
Ultralight was released which left a number of users rightfully annoyed.

I personally couldn't promise that were _would_ be a successor project since
Ultralight was so experimental (the GPU renderer alone took about 4 years to
get working on all platforms). That lack of communication and subsequent gap
in updates is what led users to believe the project was abandonware (luckily,
I'm here to say it isn't and we're still alive!).

FWIW, Ultralight was actually built in tandem using internal feedback from our
existing customers. Many of our current users are ex-Awesomium users.

~~~
qppo
Thanks for the clarification!

------
twoslide
If you're writing desktop apps using an HTML/CSS interface, I wonder if
"lightweight" is really a concern? I don't work on any such projects, but I'd
probably prefer something established with a community (electron) if the only
advantage is size (they mention memory usage too, but no specifics).

~~~
adamjs
It's definitely still a concern! And our community is growing (come check out
our Discord [1]).

Our advantages are much more than memory usage-- it's also distributable size,
low-level integration, single-process mode (no external renderer processes),
GPU rasterization (and integration into custom GPU drivers), and custom
modification of the library itself (most of the library is open-source and on
GitHub-- it's much more amenable to "hacking" on than Chromium so it's a
better fit if you need a custom HTML rendering solution than Electron).

We're still building out our desktop app runtime (AppCore) to match the API of
Electron, but the low-level renderer is already finding a solid foothold
inside of games (PC, macOS, and consoles) and headless server renderers.

* [1] [https://chat.ultralig.ht](https://chat.ultralig.ht)

------
unnouinceput
Isn't that called a browser and already exists? How is this one different?

~~~
cromulent
My understanding: It's common to use Electron to build cross-platform desktop
apps, but that basically ships a browser and a web server inside every app, so
it takes a lot of resources.

This is a lightweight alternative.

~~~
unnouinceput
If I am to locally run some HTML + CSS + Javascript app, isn't it better to
just give my clients exactly some HTML + CSS + Javascript files and let them
use their preferred browser to use it?

As for Electron, each time I see those types of applications, they are
uninstalled faster then light. One reason why I stopped used Skype in 2014,
they made it Electron app. Never looked back.

------
gigel82
Why is this thing on GitHub if it's not an open source project? Seems very
misleading.

