10 ms·

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

527 points by adamjs 8y ago

jchw 8y ago
When it comes to Linux, will it utilize Vulkan or OpenGL?
- adamjs 8y ago
  Definitely yes on an OpenGL GPUDriver implementation (it's done), Vulkan is still being explored.
  - _arvin 8y ago
    +1 for Vulkan. Tell the exploration team to come back, Vulkan's here to stay.
- jchw 8y ago
  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.
lx3459683 8y ago
Now someone please explain why this isn't the electron-killer to save us all.
- supermdguy 8y ago
  - 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
  - adamjs 8y ago
    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.
    - supermdguy 8y ago
      Wow, that's awesome that it supports DOM.
  - rapsey 8y ago
    - 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.
    - adamjs 8y ago
      - 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.
      - elcritch 8y ago
        Could this run on OpenGL ES? I know of a few projects running chromium on embedded devices... Something like this could be handy!
- flohofwoe 8y ago
  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 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.
  - adamjs 8y ago
    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.
    - infogulch 8y ago
      > engine ... supports most That's what subset means.
      - FPGAhacker 8y ago
        I'm sure what adamjs meant is "it's not just a renderer."
- kodablah 8y ago
  Openness. Electron succeeds because of dev friendliness.
- dmoreno 8y ago
  License. Electron is MIT. Ultralight is proprietary. Electron always free to use even on comercial, ultralight only for small projects.
watermans 8y ago
> 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.
- adamjs 8y ago
  Thanks for the tip, will update the language to clarify.
- oldmanhorton 8y ago
  "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.
dgreensp 8y ago
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 8y ago
  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 8y ago
    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/
    - adamjs 8y ago
      Great idea! Thanks.
    - cormacrelf 8y ago
      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?
geoah 8y ago
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?
deleted 8y ago
[deleted]
4684499 8y ago
Electron is bloated indeed, but it's open source.
- adamjs 8y ago
  The WebCore module of Ultralight is open-source: https://github.com/ultralight-ux/ultralight-webcore https://github.com/ultralight-ux/ultralight-webcore
- applecrazy 8y ago
  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-available https://discuss.ultralig.ht/d/6-ultralight-0-9-beta-now-avai... Edit: added source
  - detaro 8y ago
    That's not what LGPL means, no. It's not GPL.
    - applecrazy 8y ago
      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
      - detaro 8y ago
        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.
disqard 8y ago
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!
- lossolo 8y ago
  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.
- samstave 8y ago
  Where can I find the canonical list of how efficiently each tool renders that wiki page, I'd really like to see it?
- adamjs 8y ago
  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/master/include/Ultralight/platform https://github.com/ultralight-ux/ultralight-0.9-api/tree/mas...
  - 8y ago
tambourine_man 8y ago
>…that only supports a tiny subset of HTML/CSS spec. Which subset?
ksec 8y ago
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
- deleted 8y ago
  [deleted]
pritambarhate 8y ago
>> 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/06/SED625-Flutter.pdf 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.
- solarkraft 8y ago
  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.
  - skybrian 8y ago
    Someone else could do it. After all, Electron wasn't started by Google.
    - adamjs 8y ago
      Not to dismiss work done by the Electron team but Electron essentially wraps Chromium via CEF, so, tangentially it was made possible by Google.
      - 8y ago
barkingcat 8y ago
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.
jpm_sd 8y ago
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.
- solarkraft 8y ago
  The next generation pf applications will be made with quantum computer accelerated excel spreadsheets.
- c-smile 8y ago
  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 8y ago
    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.
platform 8y ago
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/export/exporting_for_web.html http://docs.godotengine.org/en/3.0/getting_started/workflow/...
solarkraft 8y ago
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 8y ago
  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 8y ago
    Slower release cycle is a con. Slower deprecation cycle is a pro.
krapp 8y ago
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 8y ago
  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 8y ago
    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.
- panopticon 8y ago
  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).
- Pxl_Buzzard 8y ago
  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.
- sounds 8y ago
  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.)
thepumpkin1979 8y ago
I downloaded it and launched the Browser sample Xcode project, take a look: https://vimeo.com/284388678 https://vimeo.com/284388678
- cookiecat12 8y ago
  Tip: you can hold down cmd while clicking to interact with windows in the background.
tabulatouch 8y ago
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.
infogulch 8y ago
I'd like to see one of these based on servo.
- solarkraft 8y ago
  Yeah, we have a bit too much WebKit around.
- floatboth 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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.
aphextron 8y ago
Is there any documentation here? How does styling work? Is there DOM manipulation? How is this useful at all?
- chairmanwow 8y ago
  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.
  - solarkraft 8y ago
    I don't believe it is. Check out the files you get when you download the "SDK".
- adamjs 8y ago
  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
  - deleted 8y ago
    [deleted]
deleted 8y ago
[deleted]
speps 8y ago
How does it compare with CoherentGT? https://coherent-labs.com/coherent-gt-or-hummingbird/ https://coherent-labs.com/coherent-gt-or-hummingbird/
tfha 8y ago
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.
- throwaway86x64 8y ago
  Just a shameless plug, we're working on https://github.com/ndsol/VolcanoSamples 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?
- pknopf 8y ago
  Another shameless plug: https://github.com/pauldotknopf/Qml.Net 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.
- ahartmetz 8y ago
  QML from Qt Quick is actually much better suited for creating UIs. It still shows that HTML is a document markup language...
- danenania 8y ago
  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.
SeanBoocock 8y ago
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 8y ago
  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.
Sir_Cmpwn 8y ago
This is proprietary, so it's a non-starter.
- mherrmann 8y ago
  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.
  - ddevault 8y ago
    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 8y ago
      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 8y ago
        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 8y ago
        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.
xingped 8y ago
Uh... Where is the documentation?
andrewmcwatters 8y ago
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 8y ago
  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.
jcoffland 8y ago
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 8y ago
  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 8y ago
    Glad to hear it. Too bad it's not all Open-Source. Otherwise, it's just another one of several preexisting closed source solutions.
- EmilStenstrom 8y ago
  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."
Sammi 8y ago
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 8y ago
  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 8y ago
    Question: will there be a C API? (for using Ultralight from languages other than C++)
    - adamjs 8y ago
      Yep! We plan to expose a C API to make bindings easier to generate.
cjhanks 8y ago
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
arciini 8y ago
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
bmh 8y ago
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 8y ago
  We will be pulling upstream WebKit changes from the Safari stable branch into WebCore, so it's not a "hard hard" fork.
osrec 8y ago
Hi, this looks cool! What's your ETA for Linux? Thanks!
fapjacks 8y ago
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!
- adamjs 8y ago
  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.
- missblit 8y ago
  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.
aetherspawn 8y ago
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 8y ago
  macOS is supported via Metal.
srikz 8y ago
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
foadsf 8y ago
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 8y ago
  Performance be damned!
stoyannk 8y ago
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-live-data-oriented-design 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.
roadbeats 8y ago
I want to ask a dumb question: can Ultralight integrate with WebAssembly ?
fit2rule 8y ago
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. ;)

527 points by adamjs 8y ago

jchw 8y ago

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

adamjs 8y ago
Definitely yes on an OpenGL GPUDriver implementation (it's done), Vulkan is still being explored.
- _arvin 8y ago
  +1 for Vulkan. Tell the exploration team to come back, Vulkan's here to stay.
jchw 8y ago
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.

lx3459683 8y ago

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

supermdguy 8y ago
- 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
- adamjs 8y ago
  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.
  - supermdguy 8y ago
    Wow, that's awesome that it supports DOM.
- rapsey 8y ago
  - 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.
  - adamjs 8y ago
    - 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.
    - elcritch 8y ago
      Could this run on OpenGL ES? I know of a few projects running chromium on embedded devices... Something like this could be handy!
flohofwoe 8y ago
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 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.
- adamjs 8y ago
  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.
  - infogulch 8y ago
    > engine ... supports most That's what subset means.
    - FPGAhacker 8y ago
      I'm sure what adamjs meant is "it's not just a renderer."
kodablah 8y ago
Openness. Electron succeeds because of dev friendliness.
dmoreno 8y ago
License. Electron is MIT. Ultralight is proprietary. Electron always free to use even on comercial, ultralight only for small projects.

watermans 8y ago

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

adamjs 8y ago
Thanks for the tip, will update the language to clarify.
oldmanhorton 8y ago
"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.

dgreensp 8y ago

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 8y ago
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 8y ago
  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/
  - adamjs 8y ago
    Great idea! Thanks.
  - cormacrelf 8y ago
    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?

geoah 8y ago

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?

deleted 8y ago

[deleted]

4684499 8y ago

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

adamjs 8y ago
The WebCore module of Ultralight is open-source: https://github.com/ultralight-ux/ultralight-webcore https://github.com/ultralight-ux/ultralight-webcore
applecrazy 8y ago
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-available https://discuss.ultralig.ht/d/6-ultralight-0-9-beta-now-avai... Edit: added source
- detaro 8y ago
  That's not what LGPL means, no. It's not GPL.
  - applecrazy 8y ago
    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
    - detaro 8y ago
      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.

disqard 8y ago

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!

lossolo 8y ago
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.
samstave 8y ago
Where can I find the canonical list of how efficiently each tool renders that wiki page, I'd really like to see it?
adamjs 8y ago
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/master/include/Ultralight/platform https://github.com/ultralight-ux/ultralight-0.9-api/tree/mas...
- 8y ago

tambourine_man 8y ago

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

ksec 8y ago

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

deleted 8y ago
[deleted]

pritambarhate 8y ago

>> 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/06/SED625-Flutter.pdf 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.

solarkraft 8y ago
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.
- skybrian 8y ago
  Someone else could do it. After all, Electron wasn't started by Google.
  - adamjs 8y ago
    Not to dismiss work done by the Electron team but Electron essentially wraps Chromium via CEF, so, tangentially it was made possible by Google.
    - 8y ago

barkingcat 8y ago

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.

jpm_sd 8y ago

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.

solarkraft 8y ago
The next generation pf applications will be made with quantum computer accelerated excel spreadsheets.
c-smile 8y ago
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 8y ago
  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.

platform 8y ago

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

solarkraft 8y ago

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 8y ago
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 8y ago
  Slower release cycle is a con. Slower deprecation cycle is a pro.

krapp 8y ago

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 8y ago
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 8y ago
  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.
panopticon 8y ago
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).
Pxl_Buzzard 8y ago
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.
sounds 8y ago
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.)

thepumpkin1979 8y ago

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

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

tabulatouch 8y ago

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.

infogulch 8y ago

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

solarkraft 8y ago
Yeah, we have a bit too much WebKit around.
floatboth 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.

aphextron 8y ago

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

chairmanwow 8y ago
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.
- solarkraft 8y ago
  I don't believe it is. Check out the files you get when you download the "SDK".
adamjs 8y ago
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
- deleted 8y ago
  [deleted]

deleted 8y ago

[deleted]

speps 8y ago

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

tfha 8y ago

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.

throwaway86x64 8y ago
Just a shameless plug, we're working on https://github.com/ndsol/VolcanoSamples 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?
pknopf 8y ago
Another shameless plug: https://github.com/pauldotknopf/Qml.Net 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.
ahartmetz 8y ago
QML from Qt Quick is actually much better suited for creating UIs. It still shows that HTML is a document markup language...
danenania 8y ago
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.

SeanBoocock 8y ago

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 8y ago
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.

Sir_Cmpwn 8y ago

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

mherrmann 8y ago
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.
- ddevault 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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.

xingped 8y ago

Uh... Where is the documentation?

andrewmcwatters 8y ago

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 8y ago
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.

jcoffland 8y ago

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 8y ago
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 8y ago
  Glad to hear it. Too bad it's not all Open-Source. Otherwise, it's just another one of several preexisting closed source solutions.
EmilStenstrom 8y ago
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."

Sammi 8y ago

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 8y ago
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 8y ago
  Question: will there be a C API? (for using Ultralight from languages other than C++)
  - adamjs 8y ago
    Yep! We plan to expose a C API to make bindings easier to generate.

cjhanks 8y ago

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

arciini 8y ago

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

bmh 8y ago

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 8y ago
We will be pulling upstream WebKit changes from the Safari stable branch into WebCore, so it's not a "hard hard" fork.

osrec 8y ago

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

fapjacks 8y ago

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!

adamjs 8y ago
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.
missblit 8y ago
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.

aetherspawn 8y ago

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 8y ago
macOS is supported via Metal.

srikz 8y ago

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

foadsf 8y ago

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 8y ago
Performance be damned!

stoyannk 8y ago

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-live-data-oriented-design 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.

roadbeats 8y ago

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

fit2rule 8y ago

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