
Show HN: Ultralight – Lightweight, Pure-GPU HTML UI Renderer for C++ - adamjs
https://ultralig.ht
======
pritambarhate
>> 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...](https://softwareengineeringdaily.com/wp-
content/uploads/2018/06/SED625-Flutter.pdf)

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.

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

~~~
cheapsteak
How are their licensing terms?

~~~
ahartmetz
GPL, LGPLv3 or commercial.

------
fapjacks
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!

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

------
Sammi
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!

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

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

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

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

~~~
adamjs
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](https://github.com/ultralight-ux/ultralight/issues/4)

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

~~~
andrewprock
Slower release cycle is a con.

Slower deprecation cycle is a pro.

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

~~~
oldmanhorton
"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.

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

------
disqard
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!

~~~
adamjs
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...](https://github.com/ultralight-
ux/ultralight-0.9-api/tree/master/include/Ultralight/platform)

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

~~~
c-smile
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...](https://github.com/c-smile/sciter-
sdk/blob/master/include/behaviors/behavior_tabs.cpp)

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

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

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

------
srikz
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...](http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trai..). [2]:
[https://pastebin.com/8SUpcgWJ](https://pastebin.com/8SUpcgWJ)

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

~~~
adamjs
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/screen1.png)

\- [https://ultralig.ht/screen2.png](https://ultralig.ht/screen2.png)

\- [https://ultralig.ht/screen3.png](https://ultralig.ht/screen3.png)

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

~~~
woodrowbarlow
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/](http://www.acidtests.org/)

~~~
cormacrelf
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?

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

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

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

~~~
c-smile
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.

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

------
arciini
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/](https://cobalt.foo/)

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

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

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

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

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

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

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

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

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

Dogmatism all over again.

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

~~~
supermdguy
\- 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](https://github.com/zserge/webview)

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

~~~
rapsey
\- 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.

~~~
iffycan
> 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_...](https://docs.google.com/spreadsheets/d/1dTZIp6z2J1IL7YgBlHG_x68x0_zfecU0MTsjTXn1E3A/edit?usp=sharing)

~~~
pknopf
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](https://github.com/pauldotknopf/Qml.Net)

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

~~~
applecrazy
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...](https://discuss.ultralig.ht/d/6-ultralight-0-9-beta-now-available)

Edit: added source

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

~~~
applecrazy
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](https://www1.qt.io/faq/#_Toc_1_2)

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

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

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

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

------
thepumpkin1979
I downloaded it and launched the Browser sample Xcode project, take a look:
[https://vimeo.com/284388678](https://vimeo.com/284388678)

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

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

------
geoah
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?

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

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

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

~~~
floatboth
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/servo-embedding-example)
[https://github.com/paulrouget/servoshell](https://github.com/paulrouget/servoshell)
[https://github.com/antoyo/servo-gtk](https://github.com/antoyo/servo-gtk)

~~~
infogulch
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. :)

~~~
ricardobeat
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).

~~~
infogulch
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](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.

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

------
stoyannk
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...](https://cppcon2018.sched.com/event/FnKC/oop-is-dead-long-
live-data-oriented-design)). Also I would love to hear from people interested
trying Electron-based apps with our tech.

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

Which subset?

------
fit2rule
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. ;)

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

~~~
adamjs
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](https://github.com/ultralight-ux/ultralight-webcore)

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

------
speps
How does it compare with CoherentGT? [https://coherent-labs.com/coherent-gt-
or-hummingbird/](https://coherent-labs.com/coherent-gt-or-hummingbird/)

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

------
bmh
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?

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

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

~~~
adamjs
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](https://ultralig.ht/docs)

------
foadsf
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!

~~~
vernie
Performance be damned!

------
platform
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/...](http://docs.godotengine.org/en/3.0/getting_started/workflow/export/exporting_for_web.html)

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

~~~
pjmlp
macOS is supported via Metal.

------
xingped
Uh... Where is the documentation?

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

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

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

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

------
andrewmcwatters
Hi I'm Andrew McWatters, I author lcef, LuaJIT FFI bindings for Chromium
Embedded Framework at
[https://github.com/Planimeter/lcef](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.

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

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

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

