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.
Good spot regarding the non-Free licence. Instant deal-breaker. It forbids distribution of the source-code, forbids reverse-engineering, and forbids commercial use.
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.
"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?"
It really is not that simple. Rendering a modern webpage or webapp requires a lot of components. You can't just take webkit and call it a day. For example in the chromium engine Blink which is the Webkit fork doesn't event render pages. It consumes HTML and CSS and produces "display lists" i.e lists of drawing commands. Those are fed to a rasterizer engine that must maintain a whole stack of trandormable layers which are managed in various render trees. Finally pages are radterized in tiles and then composited together for the final image that is show in the viewport. All of this covers millions of lines of code on top of Blink! And we're not even talking about things such as executing JS or syncing JS input handlers with the rendering or doing the actual page loads over HTTP/S or handling windowing and platform APIs and user input etc. All of which are really more or less essential in order to make anything that is actually useful.
Hi there, lead dev of UL here (seems HN found our beta :)):
1. That Section (5) is left intentionally reserved (empty) since the commercial version of the contract provides commercial license grants. This is typical when offering multiple versions of a contract.
2. Contracts are typically governed by laws of a certain government (this is called venue). You can indeed enter into an agreement with another party using a venue in another country. (FWIW I agree the Free License is a bit too unwieldly-- I'm going to switch to an slimmer alternative that's more grokkable)
3. You would use UL for lower-level control over the embedding itself-- the library allows you to override file system loaders, font loading, drawing/rasterization, clipboard integration, and drawing itself (via GPU display lists). You can think of it like a smaller, lighter, cross-platform WebKit that's way more "hackable" and is designed to display HTML in an existing app rather than function as a standalone browser (right now, we're primarily used in games).
4. ARM64 support is on the way, there'll be an Apple Silicon port later this year.
For your other questions:
- [Is it thread safe?] This is in our docs, the API is not currently thread safe but you can run the whole thing on another thread. (an upcoming multi-process RPC layer is being built around the core API, and that will be thread-safe/async)
- [Can it fall back to software?] Latest build of UL can fully render on CPU, so yes.
- [Will it be contentious for GPU?] The overhead is minimal. Views are painted on an as-needed basis to GPU display lists, you can see the full GPUDriver interface here [1].
- [Only the C & C++ bindings are official] Several users of our community maintain open-source bindings for other languages, we will move into supporting them directly as the project grows.
- [Why couldn't a dev team just embed WebKit?] As one who has worked on exactly that for 11 years, it's really not that simple. The API of WebKit itself is not designed for embedding inside an existing application, and also much of the design decisions of the engine itself is designed to build a browser, not render HTML. Furthermore, most WebKit ports are tied to a specific windowing-system which is a big deal breaker if you're embedding HTML inside exotic, cross-platform environments likes games and headless server apps.
- [What about CPU cycles? GPU cycles? Latency?] Sure I can put up more benchmarks to that effect, the website is undergoing a refresh for the 1.2-stable release so it's out of date.
- [What about Unreal, Unity, Godot?] Several users have already used the API to integrate into Unreal and Unity, we will make an official plugin for all three later.
Hope this helps clear things up! I'm usually available in Discord [2] if you have more questions.
This seems like it’s based on WebKit, parts of which are LGPL. Did they not modify it at all? (If so, why should I use this?) If they did, where is the code?
Hi there, lead dev of UL here (we didn't post the link, HN just found our beta :)).
That top-level repo is just our packager/samples, 90% of our code is open-source and available on GitHub (released under LGPL), see our WebCore [1] and AppCore [2] modules.
The product as a whole contains two proprietary modules which are indeed non-free but allow free use in non-commercial and commercial projects up to $100K in gross revenue.
The website https://ultralig.ht/ says "No source code for proprietary modules." for the free version. So it's technically not an open source project and therefore not a suitable candidate for my projects.
Anyway the sole core benefit proposition compared to chrome seems to be less memory use.
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.
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.
Is there an Electron alternative that uses the OS's rendering engine (Webkit on macOS, Edge on Windows), for developers who think that bundling a whole browser with their app is not the right tradeoff?
I've found two that are promising. wails [1] for Go and pywebview [2] for Python. Oddly enough, I haven't found a decent node package that is maintained and documented.
Here is a list of lightweight alternatives for Electron: electrino, neutralino, Quark, Ultralight, Miniblink, Deskgap, WebWindow, litehtml, cztomsik/graffiti, yue, nodegui.
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.
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.
In the realm of lightweight html renderers I've taken a liking to litehtml ( https://github.com/litehtml/litehtml ) - though it isn't quite as fully featured as this.
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.
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.
I had a brief look at the github repositories and don't think that all source code is available. At least I'm missing the source code of the core renderer. Maybe I didn't look close enough yet though.
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.
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
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.
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.
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.
[+] [-] antonyh|5 years ago|reply
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.
[+] [-] MaxBarraclough|5 years ago|reply
[+] [-] KenanSulayman|5 years ago|reply
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
[+] [-] ensiferum|5 years ago|reply
It really is not that simple. Rendering a modern webpage or webapp requires a lot of components. You can't just take webkit and call it a day. For example in the chromium engine Blink which is the Webkit fork doesn't event render pages. It consumes HTML and CSS and produces "display lists" i.e lists of drawing commands. Those are fed to a rasterizer engine that must maintain a whole stack of trandormable layers which are managed in various render trees. Finally pages are radterized in tiles and then composited together for the final image that is show in the viewport. All of this covers millions of lines of code on top of Blink! And we're not even talking about things such as executing JS or syncing JS input handlers with the rendering or doing the actual page loads over HTTP/S or handling windowing and platform APIs and user input etc. All of which are really more or less essential in order to make anything that is actually useful.
[+] [-] adamjs|5 years ago|reply
1. That Section (5) is left intentionally reserved (empty) since the commercial version of the contract provides commercial license grants. This is typical when offering multiple versions of a contract.
2. Contracts are typically governed by laws of a certain government (this is called venue). You can indeed enter into an agreement with another party using a venue in another country. (FWIW I agree the Free License is a bit too unwieldly-- I'm going to switch to an slimmer alternative that's more grokkable)
3. You would use UL for lower-level control over the embedding itself-- the library allows you to override file system loaders, font loading, drawing/rasterization, clipboard integration, and drawing itself (via GPU display lists). You can think of it like a smaller, lighter, cross-platform WebKit that's way more "hackable" and is designed to display HTML in an existing app rather than function as a standalone browser (right now, we're primarily used in games).
4. ARM64 support is on the way, there'll be an Apple Silicon port later this year.
For your other questions:
- [Is it thread safe?] This is in our docs, the API is not currently thread safe but you can run the whole thing on another thread. (an upcoming multi-process RPC layer is being built around the core API, and that will be thread-safe/async)
- [Can it fall back to software?] Latest build of UL can fully render on CPU, so yes.
- [Will it be contentious for GPU?] The overhead is minimal. Views are painted on an as-needed basis to GPU display lists, you can see the full GPUDriver interface here [1].
- [Only the C & C++ bindings are official] Several users of our community maintain open-source bindings for other languages, we will move into supporting them directly as the project grows.
- [Why couldn't a dev team just embed WebKit?] As one who has worked on exactly that for 11 years, it's really not that simple. The API of WebKit itself is not designed for embedding inside an existing application, and also much of the design decisions of the engine itself is designed to build a browser, not render HTML. Furthermore, most WebKit ports are tied to a specific windowing-system which is a big deal breaker if you're embedding HTML inside exotic, cross-platform environments likes games and headless server apps.
- [What about CPU cycles? GPU cycles? Latency?] Sure I can put up more benchmarks to that effect, the website is undergoing a refresh for the 1.2-stable release so it's out of date.
- [What about Unreal, Unity, Godot?] Several users have already used the API to integrate into Unreal and Unity, we will make an official plugin for all three later.
Hope this helps clear things up! I'm usually available in Discord [2] if you have more questions.
* [1] <https://github.com/ultralight-ux/Ultralight-API/blob/master/...
* [2] <https://chat.ultralig.ht>
[+] [-] zelly|5 years ago|reply
[+] [-] saagarjha|5 years ago|reply
Edit: I think it’s at https://github.com/ultralight-ux/WebCore.
[+] [-] adamjs|5 years ago|reply
That top-level repo is just our packager/samples, 90% of our code is open-source and available on GitHub (released under LGPL), see our WebCore [1] and AppCore [2] modules.
The product as a whole contains two proprietary modules which are indeed non-free but allow free use in non-commercial and commercial projects up to $100K in gross revenue.
* [1] https://github.com/ultralight-ux/WebCore
* [2] https://github.com/ultralight-ux/AppCore
[+] [-] Rochus|5 years ago|reply
Anyway the sole core benefit proposition compared to chrome seems to be less memory use.
[+] [-] michannne|5 years ago|reply
[+] [-] bioipbiop|5 years ago|reply
[+] [-] minus7|5 years ago|reply
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|5 years ago|reply
[+] [-] codegladiator|5 years ago|reply
> 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:
Let me know if I’m missing any and I’ll add it to this sticky!```[+] [-] rcarmo|5 years ago|reply
[+] [-] ilkkao|5 years ago|reply
[+] [-] MikusR|5 years ago|reply
[+] [-] kartickv|5 years ago|reply
[+] [-] mmgutz|5 years ago|reply
[1] https://wails.app [2] https://pywebview.flowrl.com/
[+] [-] pjmlp|5 years ago|reply
Anything else is just the laziness of not caring about Web standards and shipping an whole browser instead.
Every day ChromeOS is one step closer to overtaking all desktops.
[+] [-] niutech|5 years ago|reply
[+] [-] sunflowerdeath|5 years ago|reply
[+] [-] formerly_proven|5 years ago|reply
[+] [-] jamesu|5 years ago|reply
[+] [-] pornel|5 years ago|reply
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|5 years ago|reply
[+] [-] rsp1984|5 years ago|reply
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|5 years ago|reply
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.
[+] [-] Tarq0n|5 years ago|reply
[+] [-] Rochus|5 years ago|reply
[+] [-] nodefourtytwo|5 years ago|reply
[1] https://www.outrunlabs.com/revery/
[2] https://v2.onivim.io/
[+] [-] sunflowerdeath|5 years ago|reply
[+] [-] jakearmitage|5 years ago|reply
https://github.com/mikke89/RmlUi/
or for apps:
https://sciter.com/
[+] [-] c-smile|5 years ago|reply
Here it runs in Unreal Engine: https://sciter.com/see-sciter-lite-unreal-engine-in-theaters... - HTML/CSS primitives are rendered directly into DirectX surface controlled by Unreal.
[+] [-] sradman|5 years ago|reply
> 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
[2] https://ultralig.ht/#pricing
[+] [-] shubham_sinha|5 years ago|reply
[+] [-] nkozyra|5 years ago|reply
[+] [-] rawoke083600|5 years ago|reply
[+] [-] miki123211|5 years ago|reply
[+] [-] fwsgonzo|5 years ago|reply
[+] [-] pjmlp|5 years ago|reply
[+] [-] adamjs|5 years ago|reply
[+] [-] niutech|5 years ago|reply
[+] [-] dusted|5 years ago|reply
[+] [-] gridlockd|5 years ago|reply
[+] [-] newsbinator|5 years ago|reply
It doesn't make sense to charge $2000/yr for an app that makes $1 of revenue.
[+] [-] jashmatthews|5 years ago|reply
[+] [-] qppo|5 years ago|reply
[+] [-] genocidicbunny|5 years ago|reply