- 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
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.
- 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.
- 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.
The OpenGL driver is almost complete, it shouldn't be too difficult to port to OpenGL ES. We're definitely interested in targeting embedded devices with this.
> - This sort of thing has existed for a while, and people still use electron [0], [1]
For reference, CEF is not much more lightweight than Electron. It still inherits Chrome's bloat and multiprocess weight. Also, webview only supports IE on Windows which is missing a lot of features.
It's "just" a renderer for a subset of HTML/CSS. Things like this existed for a long time, and even smaller (e.g. https://github.com/libRocket/libRocket).
Electron on the other hand is a full browser runtime, for better or worse. It probably would make more sense to create a cross-platform application packager which embeds the operating system's web-renderer into a window. But I think one of the main selling points of Electron is that you're guaranteed a specific version of the browser runtime, so your app suddenly won't stop working with a browser update.
It's not a subset, it's the full WebKit layout engine underneath and supports most modern HTML5/CSS/JS.
Ultralight can render full websites just fine and is also a full browser runtime, the SDK ships with a Browser sample on macOS and Windows.
With that said, Ultralight is indeed somewhere between libRocket and Electron in terms of size and support. We won't support things that are unrelated to HTML UI (for example WebGL) and are able to reduce our dependencies/size/complexity by limiting said support.
> Chromium is awesome, it really is. But not for embedders.
> the API is currently available for C++ only and requires Direct3D 11 on Windows and Metal on macOS.
“Embedders” here seems to mean “people who want to embed a web UI in a desktop application.” This confused me at first because I wondered why an embedded systems UI framework only supported Windows and macOS instead of Windows and small Unixes.
"Embedding" is often the term used to describe using a scripting language runtime within a larger app, for example embedding a Lua runtime in a game or a Javascript engine in a database. I'd imagine that was the context for using that term here.
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)?
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?
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.
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.
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.
What they meant was that the LGPL is perfectly fine to use for commercial use, but you have to a) provide the source for just the library when requested (easy enough: provide a link), and b) allow for the program to run using a different or modified version of the LGPL library that's used.
That means you can dynamically link QT, and your program doesn't have to be (L)GPL. No commercial license required.
> Sure, it's not open source, but their licensing terms are quite generous.
That's nice, but not being open source means it will never have the breadth of players who both use it and contribute back that Electron does, which is why it won't beat Electron on the long term, even if it had some intriguing advantages.
Funny you didn't mention sciter. Sciter is also free for noncommecial use. In terms of memory usage, binary size, sciter is good enough. The downside of sciter is its script engine isn't javascript, and it's closed source too.
Edit: When I say open source, I didn't mean it has to be free of charge.
Tell that to the users who have to wait ages for "Electron" to start, and then gives their system resources the hug of death. Life is way more nuanced than "FOSS is good, everything else is bad".
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?
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.
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.
> with most memory being allocated by the JavaScriptCore VM
If I'm writing a green-field HTML5 app, and I don't derive any benefit from Javascript, is the interface between Ultralight and JavaScriptCore clean enough to just rip out the JS support altogether, replacing it with something simpler?
I'm picturing:
1. I embed Ultralight into a process that exposes a simple script-loading API, ala the one in JSCore;
2. I write HTML with no <script> elements, just elements with onclick/ontouch/etc. handler attrs, where these handlers just contain a UUID;
3. Ultralight passes the "script code" (i.e. the UUID) to my trivial script-loading API, which simply looks up a native handler based on the provided UUID, and returns its function pointer;
4. Ultralight holds onto that function pointer and treats it just like a regular thunkable Javascript handler function pointer.
In other words, all the "dynamism" of the HTML would be handled by native, static code in my compiled binary, with the only thing being set up at runtime being the binding of DOM elements to those known-at-compile-time native handlers. The QML/XAML/NIB approach.
While loading HTML that contains <div class="my"> you will get SC_ATTACH_BEHAVIOR callback with the DOM event handler reference. By handling SC_ATTACH_BEHAVIOR you will return DOM event handler (a.k.a. behavior) - just a native function pointer that receives all DOM events on that element: mouse, keyboard, etc.
That's the same mechanism as HWND and WndProc but with lightweight DOM elements instead of Windows.
Interesting, it's not too farfetched of an idea since there is a C++ API for accessing the DOM in WebCore and we have the ability to disable JS completely. I've added this to the issue tracker as an idea to explore. [1]
I'm sorry to hear that it's not multi-process. Ticked all of our boxes right up until that point. We have a use case to render our own UI, which from a threat modelling perspective can run in-proc, but also have another use case of running untrusted web content which absolutely needs to be out of proc. Do you have any plans to consider making it optional? I take it you've probably made architectural decisions that would make that extremely difficult?
Sciter Engine (HTML/CSS/script) is fully contained in sciter.dll (4.9 Mb) (https://github.com/c-smile/sciter-sdk/tree/master/bin/32) without external dependencies.
It works on all Windows versions starting from Windows XP and provides choice of four backends to use: Direct2D (GPU and WARP), Skia (OpenGL and CPU) and GDI+ (just in case someone is still interested in mammoth's shit).
On MacOS it uses Skia/OpenGL or CoreGraphics.
On Linux it uses by default Cairo (good enough) and Skia/OpenGL as an option.
>> 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.
>> 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.
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.
There are other ways to get the same juice, though.
I love MOAI, for the same reasons as I love Flutter. Except MOAI has a better license .. even if the responsibilities for using it as a non-Game GUI are pretty high. You can do it, but you've gotta have Lua-foo.
In my case, I'm going to glom Ultralig.ht onto MOAI some day soon, and see if it makes the Flutter desktop problem irrelevant...
There's actually been several HTML UI projects that "break compatibility with the web" in varying degrees, with some breaking almost completely (eg, Sciter and libRocket) for the sake of simplicity and performance.
The goal of Ultralight was to see if we could strike a balance between modern HTML5 compatibility (eg, actually being able to render the Alexa Top 50) and reducing size and complexity for use in an embedded use-case.
I think we've struck a good balance so far but can go much farther. We plan to support much more of the web platform while still remaining small by use of shared modules (eg, for WebAudio/Video) so users can pick and choose how big of a distributable they want based on feature support.
As an aside, I took 2 years off just to explore if this was possible, partly funded by my previous work on Awesomium. This project is the result of that research and development.
Do you support JavaScript? I always got the impression that that’s one of the most resource-heavy parts of the modern web, but at the same time it’s hard to render many modern webpages (webapps?) without it..
I hope you add https://codesandbox.io/ to the list of websites that you aim to explicitly support! They use VS Code's editor (Monaco) internally, which does not work in WKWebView on macOS.
How spec compliant is Netsurf? JavaScript is "superglued" into the code base in all 3 major open source browser engines, mostly because it's also superglued into the specs.
What? WebKit doesn't contain any JavaScript implementation, certainly not glued in. Apple uses JavaScriptCore (Nitro) which wasn't even open source; before Google forked Blink, they were using WebKit with their own JS engine, V8.
Not only Flutter, that is how XAML and WPF came to be.
The team was lead by IE devs, which were trying to create a design how would it look like if the browser was actually designed for applications and not documents.
Also for those that aren't aware the initial design of CSS grid was based on how XAML grid layouts work.
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.
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.
- 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).
- 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.
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...
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.
I imagine the intent of something like this is so you can embed things in your app that you've already published online (e.g., support documentation, news posts, etc).
In addition to the other responses, when I was developing a game / game engine we chose Awesomium to render the UI to improve modding capabilities. A lot more people are willing to manipulate a website than some other scripting language. Planetary Annihilation had the same thought as well, if you want to see results on a published title.
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.)
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.
Having servo wrapped up with a nice api and sdk with a good up to date default example project is exactly what I mean. Just like electron/ultralight/sciter. These projects are great but they haven't been updated for over 6 months and they aren't designed for mass (developer) consumption. Not to disparage, even servo is still WIP so I understand that a ultralight-equivalent isn't possible right now, I'm just excited for when it does happen for servo. Don't downplay the value of packaging and documentation. :)
Last time I looked at Servo for the same purpose, the build was clocking at ~40MB. Unless something changes drastically, it's not gonna be any better than Chromium for Electron-type apps (except better performance).
I don't know if your figure of 40MB includes support for javascript, but if Servo offers native DOM apis that would let you omit all js-related dependencies. (I don't know if it will, hence "if".) Even at 40MB, with static assets like html templates, css, and images, and a compiled binary, you could probably package a full-featured app up at ~60MB, less if compressed.
I wanted to know how that stacked up against some of my favorite and most used apps on windows, so I made a list: https://pastebin.com/KnkFcJXh (sorry, it's a bit long for HN).
I'll be honest, if I could publish a native app that's blazing fast, is cross platform, and whose size sits between Paint.NET (40) and VLC (130), and is even a fraction as useful as those two I would be downright ecstatic. I know for some people the final build size is a very important metric for native apps, and to those people I'm sorry. But if it's under 100MB and it uses about the same amount of ram I'm actually pretty ok with it, and I think a lot of others would agree with me.
For a period of time there were CEF interfaces for Servo. Unfortunately, when Firefox added their GPU webrender stuff, it broke and there was no effort to go back and fix it.
I looked into using this for a project and discovered this unfortunate result.
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.
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.
Having worked with embedded WebKit in games before, this looks interesting. However, even more than binary size or runtime memory usage, I hope Ultralight optimizes for responsiveness. In games we’re usually dealing with frame times on the order of 16 ms (or less for MR applications); any sluggishness in the UI immediately stands out. Often the UI masks more delayed gameplay feedback and for html/js to be viable as an embedded framework for games, it needs to be as fast as native implementations.
To minimize latency, Ultralight runs on the main thread, single-process, and outputs to raw virtual GPU command buffers for consumption by the user. I worked in game engines before so I'm familiar first hand with responsiveness as a design goal.
Care to elaborate why? I'm not affiliated with the project in any way. But if it works well and the documentation/support are there, why is it as completely unusable as you seem to claim? Your comment sounds like you're just fighting the holy FOSS war.
Because I see every piece of software like this as something I will inevitably have to dig deep into the internals of to fix bugs and send patches for if I were to adopt it. So should you.
I don't think that's true. I've long worked with software both proprietary and not, and I find myself digging deep all the time. I shouldn't have to reverse engineer my dependencies to find out why they're broken. When I do figure it out, I should be able to send a patch so everyone benefits. Without these basic things in place, I simply cannot get work done.
The other advantages are not really important. If an open source offering is lacking something, I can just add it myself. If the proprietary version is lacking something, I cannot.
And what if what you're doing is just a quick, one month project? Is it likely you must absolutely dig into the sources then? I would say no. The fact is, your original comment completely fails to address or take into account the context of the individual project. You think you're being reasonable, and of course there are great advantages to open source. I too would prefer this library to be. But the dogmatism and fanaticism is not just offensive to the author who claims elsewhere in the thread that he spent 4 years on this, it's also irrational and leads to suboptimal results.
>And what if what you're doing is just a quick, one month project? Is it likely you must absolutely dig into the sources then? I would say no.
You would be surprised. I can't even count on one hand the number of times I've send a patch upstream within the first 2 hours of using a new dependency.
I don't really care how long he spent on it. It was a waste of 4 years if it's just going to be proprietary.
176 comments
[ 4.8 ms ] story [ 182 ms ] thread- It doesn't come with a DOM implementation, so most existing js libraries won't work. EDIT: actually it does have a DOM implementation, which is awesome
- Its API is in C++
- People are lazy
[0]: https://github.com/zserge/webview
[1]: https://bitbucket.org/chromiumembedded/cef
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.
- 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.
- 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.
As an idiot, I can attest to this. I'm constantly looking for lighter weight alternatives, but nothing so far has been nearly as simple as Electron. Here's the list of options I maintain: https://docs.google.com/spreadsheets/d/1dTZIp6z2J1IL7YgBlHG_...
[0] https://github.com/pauldotknopf/Qml.Net
For reference, CEF is not much more lightweight than Electron. It still inherits Chrome's bloat and multiprocess weight. Also, webview only supports IE on Windows which is missing a lot of features.
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.
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.
That's what subset means.
Electron is MIT. Ultralight is proprietary. Electron always free to use even on comercial, ultralight only for small projects.
> 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.
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.
- https://ultralig.ht/screen1.png
- https://ultralig.ht/screen2.png
- https://ultralig.ht/screen3.png
And yes, the renderer is completely new, this project has been in development for 4+ years.
http://www.acidtests.org/
Compare this to something like Qt, which is open source. But (as I understand it) it's LGPL licensed, meaning it can't be used commercially without paying the developer for a commercial license or releasing all the source code.
Of course, take this advice with a grain of salt. I've not really worked with Qt or Ultralight before, but I've been exploring my options for a project for a school club.
[1]: https://discuss.ultralig.ht/d/6-ultralight-0-9-beta-now-avai...
Edit: added source
[1]: https://www1.qt.io/faq/#_Toc_1_2
That means you can dynamically link QT, and your program doesn't have to be (L)GPL. No commercial license required.
That's nice, but not being open source means it will never have the breadth of players who both use it and contribute back that Electron does, which is why it won't beat Electron on the long term, even if it had some intriguing advantages.
Edit: When I say open source, I didn't mean it has to be free of charge.
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!
Currently, the memory usage is similar or less than that of Chrome/Safari, with most memory being allocated by the JavaScriptCore VM, render geometry pools, and some by the GPU texture atlas.
So far, we've managed to reduce the total binary size to about 25% of a similar Electron-based app by reducing dependencies to the bare minimum and punting platform features to be handled by the embedder instead. See our Platform API [1].
As far as runtime memory usage goes, a lot of that memory is being allocated by pools and cache structures to improve performance (the same is true in most browsers). We will be implementing a memory management API soon so that this behavior can be configured (offering users the ability to strike a balance between memory usage and performance).
Additionally, Ultralight is NOT multi-process. The overhead of tens to nearly a hundred renderer processes makes sense for sandboxing in a browser situation but not for HTML UI where the assets are controlled by the user and security is less of a concern.
- [1] https://github.com/ultralight-ux/ultralight-0.9-api/tree/mas...
Real life HTML UI requires a bit more than standard HTML/CSS.
At some point you will discover that you will need something like this:
to show arbitrary DOM elements as popup elements (DOM-element-in-its-own-window) like here https://terrainformatica.com/w3/sciter-tooltip.pngYet pure HTML desktop windows: https://sciter.com/html-window/ with support of Acrylic/Vibrancy: https://sciter.com/sciter-4-2-support-of-acrylic-theming/
And at some point you may discover that by adding this to CSS:
and extending DOM Element by simple you will have the whole ReactJs thing obsolete/not-needed.All that ...
If you want you can contact me so we can discuss all these in details.
If I'm writing a green-field HTML5 app, and I don't derive any benefit from Javascript, is the interface between Ultralight and JavaScriptCore clean enough to just rip out the JS support altogether, replacing it with something simpler?
I'm picturing:
1. I embed Ultralight into a process that exposes a simple script-loading API, ala the one in JSCore;
2. I write HTML with no <script> elements, just elements with onclick/ontouch/etc. handler attrs, where these handlers just contain a UUID;
3. Ultralight passes the "script code" (i.e. the UUID) to my trivial script-loading API, which simply looks up a native handler based on the provided UUID, and returns its function pointer;
4. Ultralight holds onto that function pointer and treats it just like a regular thunkable Javascript handler function pointer.
In other words, all the "dynamism" of the HTML would be handled by native, static code in my compiled binary, with the only thing being set up at runtime being the binding of DOM elements to those known-at-compile-time native handlers. The QML/XAML/NIB approach.
In your CSS to define
While loading HTML that contains <div class="my"> you will get SC_ATTACH_BEHAVIOR callback with the DOM event handler reference. By handling SC_ATTACH_BEHAVIOR you will return DOM event handler (a.k.a. behavior) - just a native function pointer that receives all DOM events on that element: mouse, keyboard, etc.That's the same mechanism as HWND and WndProc but with lightweight DOM elements instead of Windows.
Example of such behavior that implements panels with tabs container: https://github.com/c-smile/sciter-sdk/blob/master/include/be...
[1] - https://github.com/ultralight-ux/ultralight/issues/14
https://sciter.com/sciter-fps/
Real FPS is shown in window's caption (490 FPS).
Sciter Engine (HTML/CSS/script) is fully contained in sciter.dll (4.9 Mb) (https://github.com/c-smile/sciter-sdk/tree/master/bin/32) without external dependencies. It works on all Windows versions starting from Windows XP and provides choice of four backends to use: Direct2D (GPU and WARP), Skia (OpenGL and CPU) and GDI+ (just in case someone is still interested in mammoth's shit).
On MacOS it uses Skia/OpenGL or CoreGraphics. On Linux it uses by default Cairo (good enough) and Skia/OpenGL as an option.
But in any case I am building sciter.dll as with Skia (sdk/bin/skia32/) as without it (sdk/bin/32/)
Which subset?
[1] https://sciter.com
>> We started over with WebKit, stripped it to the bare-minimum, then rebuilt it from scratch with an eye towards embedding.
This is very similar to the origin story of Flutter. [1] In the end Flutter team just abandoned the HTML based UI idea and went with their own component system. As per the podcast, the core team doesn't have any plans to bring Flutter to the desktop development. I wish they would do it, that way we can get a performant alternative to Electron.
[1] https://softwareengineeringdaily.com/wp-content/uploads/2018...
Edit: Found the actual quote from the podcast:
>> We allowed ourselves, I think it was a week or two and we just tore Chrome apart and see how fast we could move on our benchmarks. Allowing ourselves to break compatibility to the web. The end result was we were 20 times faster on some of the benchmarks that we cared about and obviously, the end product wasn’t the web, it didn’t render all web pages, but it taught us that there was a lot of potential to do things better, faster, if we worked on something that was beyond the web.
There are other ways to get the same juice, though.
I love MOAI, for the same reasons as I love Flutter. Except MOAI has a better license .. even if the responsibilities for using it as a non-Game GUI are pretty high. You can do it, but you've gotta have Lua-foo.
In my case, I'm going to glom Ultralig.ht onto MOAI some day soon, and see if it makes the Flutter desktop problem irrelevant...
There's actually been several HTML UI projects that "break compatibility with the web" in varying degrees, with some breaking almost completely (eg, Sciter and libRocket) for the sake of simplicity and performance.
The goal of Ultralight was to see if we could strike a balance between modern HTML5 compatibility (eg, actually being able to render the Alexa Top 50) and reducing size and complexity for use in an embedded use-case.
I think we've struck a good balance so far but can go much farther. We plan to support much more of the web platform while still remaining small by use of shared modules (eg, for WebAudio/Video) so users can pick and choose how big of a distributable they want based on feature support.
As an aside, I took 2 years off just to explore if this was possible, partly funded by my previous work on Awesomium. This project is the result of that research and development.
Netsurf is on other hand is an opposite:
Css parsing - separate lib
Html/xhtml parsing - separate libs
Network - fully based on external libs
Js execution - separate lib
Dom - separate lib
Layouting - separate lib
Final renderer - separate lib
It has a lot of promise
Qt / QML is an existing performant alternative to Electron.
https://github.com/pauldotknopf/Qml.Net
The team was lead by IE devs, which were trying to create a design how would it look like if the browser was actually designed for applications and not documents.
Also for those that aren't aware the initial design of CSS grid was based on how XAML grid layouts work.
That's the largest text in the landing page and it's really confusing.
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.
One gets to write a bit of CSS soup and then ensuring it works as expected across all target browsers.
http://docs.godotengine.org/en/3.0/getting_started/workflow/...
- 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).
Pros (Ultralight is...)
- Smaller distributable (25% the size of Electron/CEF or smaller).
- Simpler and easier to build (fewer dependencies and smaller codebase).
- More configurable (users can do custom handling of file system, fonts, GPU rendering, clipboard, and more).
- Potentially more performant (all rendering is done via GPU command buffers).
- First-class support from an actual company.
Cons:
- No support for MathML, Geolocation, WebGL, IndexedDB, WebAudio/Video (for now)
- Less mature and unstable.
- Slower release cycle (might be a pro).
Linux support is planned and will ship when it's ready, you can track its progress here: [1]
Yes, we have plans to publish a C API interface to simplify bindings for other languages.
The WebCore source is available here [2]. The rest of the source is kept closed for now to keep our licensing/support options open. There's a chance we will find a better funding model and will open-source the entire repo in the future.
Yes, I agree the SDK packages should belong on GitHub, and will also be BSD'ing the framework/sample code so users can fork and hack on it at will.
- [1]: https://github.com/ultralight-ux/ultralight/issues/4
- [2]: https://github.com/ultralight-ux/ultralight-webcore
Slower deprecation cycle is a pro.
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...
Everyone knows how to produce "fuck it, it works" results with it.
Everything (almost) supports it.
It already runs on the web.
There's room in there for Ultralight, Awesomium, Chromium, Dear Imgui, SDL, Cairo, WPF, even GDI+.
That's basically because (I think) there's still a lot of effort being put into recreating UIs - especially for apps, games, and embedded.
(In embedded, as in, embedded systems running linux or VxWorks or something, the story is less well known, but it's the exact same balance and set of choices.)
I think you should open source Awesomium also, allowing contributors to maintain it.
https://github.com/paulrouget/servo-embedding-example https://github.com/paulrouget/servoshell https://github.com/antoyo/servo-gtk
I wanted to know how that stacked up against some of my favorite and most used apps on windows, so I made a list: https://pastebin.com/KnkFcJXh (sorry, it's a bit long for HN).
I'll be honest, if I could publish a native app that's blazing fast, is cross platform, and whose size sits between Paint.NET (40) and VLC (130), and is even a fraction as useful as those two I would be downright ecstatic. I know for some people the final build size is a very important metric for native apps, and to those people I'm sorry. But if it's under 100MB and it uses about the same amount of ram I'm actually pretty ok with it, and I think a lot of others would agree with me.
Nope. JS engine is deeply integrated in Servo. Thus it can not be much better than Electron.
I looked into using this for a project and discovered this unfortunate result.
When the documentation is so sparse it begins to feel a little like vaporware.
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
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.
It's still very early stages, but maybe interesting to you?
It has everything you mentioned, except HTML/CSS, but I'd argue QML is better than HTML/CSS for desktop.
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.
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.
You would be surprised. I can't even count on one hand the number of times I've send a patch upstream within the first 2 hours of using a new dependency.
I don't really care how long he spent on it. It was a waste of 4 years if it's just going to be proprietary.
Dogmatism all over again.
Don't bother with this hateful guy, you rock!
> you are blind to the many potential other benefits a project may have
What makes you think we aren't paying attention?
> This is proprietary, so it's a non-starter.
did not go into _any_ of the other details or aspects of the project.