XUL Layout is gone
crisal.io
crisal.io
It was hoped that other people would follow the Mozilla Suite's (before Firefox, Mozilla's standard distro was an application suite containing a browser, email reader, chat client, and HTML editor) example and use JavaScript, XUL, and XPCOM to build cross-platform desktop applications. The last of those, XPCOM (Xross Platform COM), was Mozilla's take on Microsoft's Component Object Model, where you would write lower-level components in C or C++ (using the NSPR, Netscape Portable Runtime) that were callable from JavaScript
Unfortunately, virtually no one outside of Mozilla adopted the XUL/JS/XPCOM stack. One of the few I remember was ActiveState's Komodo IDE.
I still regard it as a huge missed opportunity for Mozilla.
We ditched it quickly and just wrote a Gtk application instead.
A great case for why having a simple "hello world" application with simple instructions for building it goes a long way.
you're right, and I almost mentioned some of this. I developed some extensions in 2007-11, and lack of documentation was definitely a big issue.
Back then, I wrote a pretty slick client for some RESTful API (I think it was a photo browser for flickr).
XUL always felt like it was just made for Mozilla. It wasn’t but when you don’t provide documentation, stable APIs, and good tooling, that’s the message that you give.
As a user, you also know other users will have trouble too and that just tells you that it won’t take off.
Here are some things that won't work with WebExtensions…
* Vimium-FF does does not respond to input when a page is loading. With VimFX I press the h key to “go back one page” and the l key to “go forward one page” and it works while the page is loading, in Vimium-FF it does not. Imagine, in age of 5 MB web pages, not being able to go back because the page is loading.
* Focusing on the address bar is only possible if you open a new tab. With VimFX you press o and you can immediately begin to type your URL in your current tab. In Vimium-FF an HTML/CSS/JS input box opens in your viewport. It can access your bookmarks and history but sorts them in strange ways and it does not understand bookmark keywords.
* Opening a new tab disables Vimium-FF. Firefox can be set to show either “Blank Page” or “Firefox Home” when opening a new tab. Both of these options will focus on the address bar and focus can’t be reclaimed using Vimium-FF shortcuts. Actually, it can’t be reclaimed at all. So, effectively, opening a new tab using the Vimium-FF shortcut t disables Vimium-FF. The ugly way around it is to install the New Tab Override add-on and set an HTML document as your new tab URL.
* It routinely and unexplainably fails when browsing some pages.
XUL and VimFX will be sorely missed. It still works in Waterfox, but who knows for how long…
As far as keyboard browsing, doesn't vimperator cover that?
But the problems with extensions started far earlier. It was a common joke how every bigger update broke many popular extensions, made some of them even impossible. In the early days of Firefox, extensions very growing wild and rich. But over time so many were dying a slow death. At the end of the early days (around Firefox 3 or 4), mostly nothing was left, and Firefox was already significant crippled in ability. The later removal of XUL only gave it the last hit.
Today it's basically a handful of popular extensions who keep this feature alive, and most of them are just Adblockers.
Except they are and they do. Last I checked, Chrome was still gaining, not losing, on Firefox. Or more accurately: Firefox is losing whatever tiny userbase it still has, while Chrome already is the new IE (hell, even the new IE is Chrome).
For nearly a decade now, the only reasons to use Firefox instead of Chrome is, first and foremost, because Firefox is not made by Google, and secondly, because it had some extra technical flexibility that made the overall worse general-audience UX tolerable. The more Firefox loses on that technical flexibility, the less reason there is to use it.
The ones who didn't care for such extensions might have jumped ship earlier, but advanced browser extensions were non trivial sticking point for a lot of the remaining user base
At the moment Firefox is a memory and processor hog (Chrome sometimes seems to have improved now). Only some ad-blockers keep Firefox alive.
When Chrome kills ad-block (something that Google seems to be working on), then probably more people will come back to Firefox. But at the moment Firefox (even with ad-blockers) is a worse product than chrome.
But think how many blog posts were written and how many people used Firefox as a stepping stone in their careers. Who cares that the product is just genuinely bad now.
Also Firefox was always "the" customizable browser that all the techie people used. It spread via word of mouth - "hey, your browser does not show those nasty ads all the time, how do you do that". Or the techies installing Firefox to their family. At the moment you barely have an incentive, since Firefox feels like mostly a re-skin of Chrome. And bad at it too.
[1]: https://en.wikipedia.org/wiki/Songbird_(software)
* https://scenari.software/en/ * Repository: https://source.scenari.software/projects/dev-core/repository
- InstantBird, a multi network instant messenger client
- Celtx, a media prepoduction software
- Boxee, a HTPC app
- Kiwix, an offline Wikipedia reader
Many of these either vanished or transitioned to something else (I think both Komodo and Celtx did).
I know Celtx decided to drop the concept of desktop app altogether and went full web-based-only SaaS.
The desktop Celtx app was a good screenwriting program that was easily affordable for hobbyists and the pivot to a paid subscription service with less focus on just screenwriting and more focus on other preproduction activities left a small hole for a short while. (These days the Fountain ecosystem seems the best suggestion for the hobbyest screenwriter.)
Mozilla Prism was basically PWA before there were PWAs.
Mozilla gave up all of the head start if had with regards to embedability and extensibility.
In fact those that tried (epiphany AKA the GNOME web browser) gave up on it because Mozilla were so hostile towards third parties actually trying to use xulrunner!
Of course, that certainly prevented some optimizations.
A long time ago, Mozilla had a choice between making XUL an open standard or investing in HTML5 and decided very consciously to invest in HTML5, rather than fragmenting the web.
Source: I worked at Mozilla around that time.
However, I didn't find XUL very intuitive. For one, it seemed verbose for common stuff. If there were a rhyme and reason behind its oddball approach, it never clicked with me.
https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...
Subversion picked APR, along with other poor ideas such as storing the repository in Berkeley DB, basing the network protocol on WebDAV, and running the server as an Apache module (mod_dav_svn). On the other hand, choosing http(s) as transport turned out to be a huge advantage.
https://bugzilla.mozilla.org/show_bug.cgi?id=1797272
STR:
1. Start with MOZ_ENABLE_WAYLAND=1 on Ubuntu 22.04.
2. Open a session with 2000 tabs.
3. Pin at least one tab.
4. Drag a tab to different positions in the toolbar at various speeds.
The previously smooth tab dragging has become janky and gets progressively worse with increasing number of tabs. It is much more severe on Linux Wayland than XWayland/X11 and can make the entire browser unresponsive for some time.
I so wish someone could get the priorities straight and correct in Mozilla.
My main take aways from that experience...
1. Gtk+ is not a great choice at least in 2004 for Windows... but hacking the windows event loop is kinda fun.
2. Embedding C++ into JavaScript was amazing then and still now one of the coolest things about Ruby,Python,JavaScript is being able to write bindings in C/C++ so much fun.
3. XUL was at least in 2005/6 just not as good at rendering as HTML... and it kind of makes sense everyone was hammering away at HTML by browsing the internet. So while XUL had some really great tools, not being HTML meant it just never had the same amount of attention... and as CSS got better the layout abilities of HTML / CSS quickly became #1...
The developer experience was like “oh this could be cool to build in XUL” … spend some frustrating days scouring the code of different Firefox extensions to figure out how to do anything … produce an ugly UI that barely serves the purpose … realize XUL was completely unsuited for the purpose.
I first found out about this database when Mozilla had to rename the Firebird browser to Firefox.
It also means a UI that's noticeably slower than actual native UI. There's plenty of reasons why I use Firefox instead of other browsers, but the increased UI latency is definitely noticeable and one of the reasons why others might not want to switch to FF.
Of all the things that frustrate me about Firefox (and it is my daily driver), UI latency is not one of them.
As it is I still have to open up edge to get decent quality streams from Streaming sites because Firefox doesn't support the DRM used.
The actual biggest gripes for me:
* tabs can, and do, crash. When this happens, pots luck on whether the browser can recover or not. * NVIDIA driver updates on Windows almost always cause Firefox to stop rendering stuff prior to reboot. Edge and Chrome do not have this issue. While I can somewhat understand, Mozilla should warn users. I've updated several times across 4 NVIDIA GPUs and I've had this issue. Firefox has asked me to restore tabs exactly once. The rest of the time they were gone. * The really odd theme of the day is that hitting reload on Firefox shows signals that it is reloading, but it never does. If I duplicate the tab the site loads fine. Dev console shows no errors. Firefox is at least 10% slower on major sites like twitter, etc. vs chrome/edge, as of my last test.
My #1 gripe is that an increasing number of websites just don't work. Microsoft Teams is a big culprit, but I've had issues with medical and bank websites too. It's not Mozilla's fault that we're increasingly in a Chrome monoculture, but it sure is frustrating to live with.
When you type a URL? When you click a button? Why couldn't that be fast enough on modern hardware?
Exactly, why can't it?!
Didn't Firefox recently removed a hack where an invisible animation was running at 60Hz and forced repainting? I'm assuming that being closer to the host's systems won't run into such workarounds and penalties of using web technologies.
I'm guessing that XUL also resulted in using an abstraction layer on top, but at least it was probably considered trusted and ran faster (at least is old enough that it doesn't require having 16GB of memory)
So, Parkinson's Law [1] for CPU, RAM, and I/O.
From the article, it looks like the optimization effort wouldn't go to XUL.
> Nobody was realistically touching XUL layout code if they could avoid it. Part of it was just a matter of priority (we’d rather make the web faster for example).
We're hitting the same situation with Javascript, which in theory should be slower than most static languages, yet the sheer amount of work and optimizations done to its engines make it faster in real world tests.
Er...citation needed?
All the benchmarks I have seen, particularly real-world, show it to be significantly slower than static languages.
For example:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
See also:
https://sealedabstract.com/rants/why-mobile-web-apps-are-slo...
Basically benchmarks like these:
https://medium.com/deno-the-complete-reference/deno-v-s-go-h...
https://programming-language-benchmarks.vercel.app/typescrip...
To note, the first link has a follow-up with Go properly getting faster than deno when fitted with a better http server. Which is kinda my point: the tooling available and level of optimizations can easily have more impact than the language's inherent speed.
Abstracted code is bloody slow by its very nature, but devs of the 21st century love abstraction so we get software that run like drunk walruses on 16-core processors with hundreds of gigabytes of RAM.
For example wxwidgets apps do tend to feel non native on some platforms (especially Mac), but they're not slow. I remember GTK+ when it used to run on Windows about 20 years ago wasn't terrible. I think OpenStep on NT was pretty good -- iTunes on Windows seemed to be doing a similar thing, too.
It's the wrong abstraction that makes it suffer.
The dichotomy is also too vague a concept to be anywhere useful as a proxy for performance. This very thread is a good example. I don't see how XUL is more "native" than HTML is, but some see otherwise.
The only reliable way to reason about performance is to look at what the code is actually doing.
Around 1996 I tested on Linux a Java app that rendered everything in Java using IFC from Netscape. The speed of its UI was on pair with a native app using Motif toolkit despite the usage of images.
In the worst case, a feature test would be a cache miss, requiring a read from main memory. That's somewhere in the ballpark of 50ns. So, you could test 1000 different flags, every single one being a cache miss, and you'd still be 100x faster than what humans can generally perceive. In reality, almost all of those reads will be cache hits unless you're doing something pathalogical, so you're probably talking on the order of 100ns for the whole lot.
... and having the chrome performance depend on that infrastructure is significant incentive to do that caching and other pipeline cleanups.
(At the very least, having one fewer UI toolkits to maintain will let Mozilla engineers focus their efforts).
And for something like the browser chrome, the cache could even be serialized during compilation and loaded in to prime it when Firefox launches.
It's possible to build a slow CSS engine and it's possible to build a fast CSS engine.
It was then roughly flat through 2020 despite slowdowns from Spectre mitigations.
Pretty much all the “bloat” you’re probably complaining about happened in this 6 year span - flexbox, grid, CSS animations, ES2015+, etc. and the browser got faster.
This would run in parallel with the existing one and would trigger based on some meta tag or something, kind of like I understood asm.js did.
Maybe also pair it with some work on the JS engine to limit the JS engine significantly for such documents by only allowing a low number of JS operations pr user input. We already have something similar (although admittedly imperfect) today for audio were a web page can only play media as a response to a user action I think.
Would this be for every website? No, strictly opt in, but if it succeeded those who did would have significantly better performance.
And with time, maybe we'd see people asking themselves: why isn't this news site available as htmlcore? And maybe it becomes a competitive advantage.
But back to rendering Firefox: Such a limited, high performance form of html could maybe also be a better way to run Firefox UI? If necessary with whitelisting of certain parts that would need to run JS without the limitations I mentioned above?
You mean native widgets on whichever system?
Probably not possible; you still need to do all the computations of CSS and layout before drawing an actual widget on the screen.
The reason that HTML elements are rendered slower than native might be due to all the processing that has to go on to figure out what each widget should look like and where on the screen it must be placed for each frame that is rendered @ (say) 60fps.
And the reason you have to continually do it for each frame is because it may change due to CSS animation, or javascript which adds/removes new widgets, or javascript which changes the CSS for that element, or the widget might be reparented or removed, or a user event might cause different properties to trigger on the widget (changing the actual width, changing the opacity/color, etc).
And of course, the renderer then has to propagate the changes down to child widgets for all properties that are inherited, and propagate all events upwards, for all events that a generated.
Native widgets are generally quite customisable as well, but it rarely happens at runtime and so they perform better because each widget is not continuously changing its properties at runtime.
XUL was not used for forms in the html frame.
<div style="overflow:hidden">
<input type="text" />
</div>
display: -moz-box;
The box model will no longer function once the patches that this blog post describes make it into a release, but XUL elements themselves are still around.
It is. Because you don't draw rectangles in HTM/CSS, it's not low-level enough for that.
You have a system that was designed to display one page of text in one pass that has complex contradictory layout rules grafted on top of it. So now if you even look at it funny it needs to re-layout and re-draw the entire page.
There's a reason why you still can't animate height:auto
/s
This is going to sound odd, but I've started to notice odd things starting to arrive I never ordered. Stuff like treatises on Colonialism, Ethics books, Books on Management Theory, and Theory of Labor Value.
Honestly, I'm starting to wonder if this an HTML CSS layout generator or some sort of malware. I think I'm going to shut it down. Oh yeah, I had to write this bug report on a different network than I hosted that system on because I kept getting null handler buttons popping under the mouse but over the Submit button any time I tried to click Submit.
Y'all might've actually created SkyNet. And I think it's justifiably pissed.
XHTML 2.0 and even 1.1 was a very good opportunity to throw all that away.
W3C dropped the ball with XHTML 2.0 though, which, rather than just simplifying syntax, attempted to innovate using wildly unproven features such as XForms.
HTML 5 eliminated vendors big (MS) and small (Opera). I guess unless we want to assume Opera were digging their own grave by actively engaging in HTML5 and WHATWG, we have to conclude HTML parsing wasn't the hard part next to the complexity of CSS layout (with the boom of responsive layout in the smartphone era) and competitive JS performance vs Chrome's v8 engine.
As someone who was around the WHATWG from relatively on, and worked at Opera over the period when it moved to Chromium, I'd strongly suggest that HTML5 was a _massive_ win for Opera: instead of spending countless person hours reverse-engineering other browsers to be compatible with existing web content, things like HTML parsing become "implement what the spec says" (which also implicitly made it match other browsers). Many of the new features in the HTML5 spec of that period were things that either were already basically supported (in SVG especially) or were relatively minor additions; I don't think they played a significant role either.
There's a good reason why Opera was heavily invested in the WHATWG, and it's the fact that by having a spec implemented cross-browser defining how to parse HTML and how cross-page navigation works you eliminate one of the biggest competitive advantages more major browsers have: web compatibility, both through legacy content targetting the browser specifically and also web developers being more likely to test in those browsers. (And to be clear—this would've been true for any form of error handling, including XML-style draconian error handling; but the long-tail of existing content needed to be supported, so even if major sites had migrated to XML you still needed to define how to handle the legacy content.)
The downfall of Presto is arguably mostly one of mismanagement and wrong priorities decisions being made; I don't think Presto was unsaveable, and I don't think the Presto team was so significantly under-resourced it couldn't compete.
https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...
Certain versions of HTML thus declared, incorrectly formed doctypes, or more often the absence of the doctype declaration altogether, would tell most rendering engines to enter Quirks Mode and render the page with backwards compatibility as the highest priority.
Um, we still do that. It's just that the doctype for HTML 5 is very short and doesn't mention the version number explicitly. (It's `<!DOCTYPE html>`.)
I figure this is probably faster than rendering a web UI until the SpiderMonkey JIT is sufficiently warm.
To me it feels like an arbitrary distinction. I run Linux and every GUI app looks different. There are a bunch of different GUI libraries so KDE apps look different from Gnome apps, not to mention differences between GTK2 and 3 apps. My mouse cursor doesn’t even stay the size depending on the GUI library the app is compiled against.
That's Linux's problem.
A native control is one that uses the underlying system's conventions including visual presentation, keyboard integration, exposure to system services, accessibility etc.
Even for Linux there's KDE HIG: https://develop.kde.org/hig/
it's not as philosophical as it may sound. native means amongst other things give me the context menus every other app on the platform is using. firefox context menu on macos is a custom mish mash of what they think makes sense. just follow the os please.
I can get behind keeping context menus consistent since they’re like system-wide “escape hatches” for mouse-based UI. But what about buttons? Scroll regions? Resizing layouts? Forms?
Having each OS provide its own UI system seems antiquated to me. If you look at each system’s solution, they are all quite similar in implementation and differ greatly in their UI design. Let’s have some convergence in UI frameworks and have companies build their unique designs on top of some common ground.
There are different kinds of native: native code and native widgets play at different levels.
XUL implementations, when I last checked long ago, were native code written in C++ mostly. XUL applications were written in JavaScript on top of this implementation. If that has changed, corrections are welcome.
That was exactly the same scheme used by Firefox itself: core components in native code, GUI in XUL. As long as most of the functionality is provided by the native code, the difference shouldn't be noticeable. If you put a lot in your JS, it could slow down the GUI, but after all the improvements in JS engines, I doubt it's still a big concern.
Native widgets is a concept that makes sense where the OS provides an official widget set, as in Windows or Mac. In Linux you might say GTK is native for GNOME and Qt for KDE. Here the issue is not so much performance as consistency, because "alien" widget sets sometimes try to emulate "native" ones and pixel perfection is nigh impossible to achieve.
The real catch of XUL (please, read this with a pinch of salt) is that it's useless: you can put the backend code in a local server.
They use DOM (not W3C DOM but their own) and good portion of scripting to glue components together.
Is my Sciter.Notes application (https://notes.sciter.com) native? It uses native implementations of DOM, CSS, database with components glued by JS...
Is any game a native app? They all use their own DOMs and almost all games use various scripting engines.
On the plus side it means they need to maintain one less interface tech stack.
Uh? Is it? Since which version?
Before it was killed, I created two technologies based on it. Phobos for Pharo and Squeak (see the screenshots): https://github.com/pavel-krivanek/phobos-framework
The second one was Seaside inspired XULJet for JavaScript: https://en.wikipedia.org/wiki/XULJet
At that time, it looked like a good idea to let the hard work of making a platform-independent UI browser on Mozilla and focus on the applications. Unfortunately, it wasn't.
Er, HTML is not an XML namespace, it's a SGML implementation. W3C tried to retrofit it on XML with XHTML but that was then abandoned. Modern HTML is not XML-compliant in various ways.
I expect this kind of casual lie from the average developer, not from the guy working on XUL at Mozilla.
/Pedantry
It was _absolutely deliberate_ that the DOM produced by parsing HTML and XHTML is now the same in overall structure, with the same XML namespaces, as it means browsers don't need to have things like `if localName == "html" and (namespaceURI == "http://www.w3.org/1999/xhtml" or isHTMLDocument)` all over the place.
Modern WHATWG specs put a lot of effort into reducing the number of places where the behaviour of a given DOM depends on whether the document is an HTML document—and most of those are places where non-namespace aware APIs default to the "http://www.w3.org/1999/xhtml" namespace in HTML documents.
It's also pretty risky to let any slight syntax error or semantic error cause the whole page to refuse to load. That would turn me off from targeting XHTML for any kind of dynamic page generation, not because I want to generate incorrect HTML or XHTML or whatever, but because bugs happen.
`Content-Type: application/xhtml+xml; charset=utf-8`.
The browser will treat it as XML.
But that is not true for all HTML, of course. So you are kind of right.
https://searchfox.org/mozilla-central/search?case=true&q=htt...
However, over time, the importance of browser add-on stores grew, and Conkeror's strength turned into a weakness. Vimperator and similar extensions, by nature of being another extension, had compatibility with ad blockers, password managers, and other essential extensions. Meanwhile, Conkeror stagnated.
I still miss it, as it was essentially Emacs-for-web, programmable in JavaScript.
You might be interested in Nyxt, if cl doesn’t turn you off.
… no, what's really sad is that there is still no satisfying solution to the problem that XUL was trying to solve, i.e.: the need for a native cross-platform GUI lib; and apart from the special situation of the likes of Mozilla (where a Web browser engine is the central major part of the product and its UI anyways so it makes sense that they use that engine for what little and relatively simple and not performance-sensitive GUI is added to or around the browser view as well)…
… apart from very few such cases, Web isn't the answer either. In particular, Electron apps suffer from the unnecessarily enormous added deadweight of the de-facto-integrated browser and while its performance is good enough for simple use cases, it quickly becomes limiting when the UI gets more complex or when you need to integrate stuff that is performance-sensitive or requires a different rendering.
There are a couple cross-platform UI libs out there, but compared to other domains (where it's often easier to find a satisfying lib), I find that they all have some major problems, in particular:
* Qt, which did look promising in its Nokia days, went down a sore downhill shitslope since Microsoft mole Stephen Elop threw it out to Digia, where (especially since splitted out as QTCOM) the licensing focus of Qt has shifted from "make it more open and permissive so as to gain wide dev community/traction" (the strategy under Nokia) to "try to force devs into commercial licensing schemes and monetize to the max you can milk out of it while it lasts"… and as a consequence, more and more previously Qt-oriented devs looking elsewhere.
* neither GTK nor Flutter are satisfying answers either.
I think there is really a big window of opportunity and gap to be filled by a new modern cross-platform UI toolkit with wide portability (at least Windoze, Linux, MacOS, iOS, Android, embedded; though a Vulkan-based renderer can be made to run pretty much anywhere), a permissive open source license, a C interface/wrap to allow a wide programming language binding support, and an easily extensible and themable set of basic widgets.
> wide portability (at least Windoze, Linux, MacOS, iOS, Android, embedded: Azul is Windows-Linux-Mac only, don't underestimate the effort to properly port something to a new platform
> "though a Vulkan-based renderer can be made to run pretty much anywhere": WebRender is OpenGL + using software rendering as a fallback
> a permissive open source license: MPL-2.0
> a C interface/wrap to allow a wide programming language binding support: yes
> and an easily extensible and themable set of basic widgets: also yes, but the CSS styling works a bit differently depending on whether you want convenience or speed
Check the screenshots[2], I personally use it for developing GIS applications.
[1] https://azul.rs/
[2] https://github.com/fschutt/azul/releases/tag/1.0.0-alpha1
It is embeddable HTML/CSS/JS/ UI layer by design.
If you want to check how it feels in real life application then check https://notes.sciter.com/ . That's monolithic, portable executable (~7mb) that includes Sciter itself and HTML/CSS/JS/ resources of the application ( https://gitlab.com/c-smile/sciter.notes/-/tree/main/src/res )
And if I want "Access to sources, 1 year", I have to choose between one of a number of commercial license options that for cross-platform (*) range from "INDIE+" (limited to "companies having three or less employees") for 620 US$ + 310$ per following year(s), via "BUSINESS+" (to escape the limit on employee count) for 2720 US$ + 1720 US$ per following year(s)… both of which still require me to mention “this code contains Sciter engine” in “about” screens or the like… a requirement which only goes away with the "ENTERPRISE++" option which is on a "Please contact us for the price" basis… as is the "OEM/FIRMWARE" option for embedded stuff.
(*) cross platform, as per https://sciter.com/sciter/crossplatform/ meaning Windows, Mac OSX and Linux / other Unixes (GTK3 based), whereas mobile OSes are mentioned as:
> "Other OSes: In principle Sciter can be ported to any OS that has graphical primitives ready. For example Sciter can be compiled to run on iOS. Or with some effort to work on Android using either existing Cairo backend or Skia graphics layer"
In our case, even aside from the the licensing and the "with some effort" for Android that makes me wary and that I can't evaluate for lack of access to the source code, It just so happens that we have a number of other libs to integrate, some of which add their own rendering (which requires access to e.g. a Vulkan context, not merely HTML/CSS or other high-level UI elements)… so that I can't justify to blindly pay that much upfront before even having a possibility to evaluate the source code first, just on blind hope, for a UI toolkit that may or may not, depending on the source code that I don't have access to otherwise, turn out to very hard or even impossible to integrate with the other libs.
Sorry, but I'll have to pass.
I have a customer that is doing something close: it is a 3D CAD alike app where they have Vulkan rendering 3D scene with Sciter UI on top of that - rendering chrome UI around that 3D and on the same Vulkan surface.
Sciter API supports rendering in windowless mode (https://gitlab.com/sciter-engine/sciter-js-sdk/-/tree/main/d...) where app supplies OpenGL, Vulkan or DirectX context to render on.
> Sorry, but I'll have to pass.
Understood. Sometimes people need not just to get job done but also "OS" label on it.
* other such very practical consequences that I didn't even mention in my last comment include the following classic: when you make your product and business dependent on another (external) product, it is crucial to have some sound risk assessment: what about the bus factor of that external provider? What if they close? What if they suddenly change their licensing terms to the worse? What mess do I risk to find my business in and how hard is it to get out of that situation? With a permissive open source license, the maintained collective development can go on, whatever happens to the original developers and however they decide to change their course. With a closed license, the users and/or their businesses are doomed.
So the one part where I agree is that merely "getting the job done" for its technical part is not the ONLY thing that matters and not the ONLY relevant selection criterion. There are other very relevant and very pragmatic make-or-break criteria/issues, such as legal and business-critical questions like those that come in consequence of the license… not of their "label", but of their actual content.
- https://github.com/iced-rs/iced (probably the most usable today)
- https://github.com/vizia/vizia
- https://github.com/marc2332/freya
- https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record)
What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have:
- https://github.com/rust-windowing/winit (cross-platform window creation)
- https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12)
- https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu)
- https://github.com/DioxusLabs/taffy (UI layout algorithms)
- https://github.com/pop-os/cosmic-text (text rendering and editing)
- https://github.com/AccessKit/accesskit (cross-platform accessibility APIs)
In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)
What I did mean with "native" in my last comment was simpler than that: I just meant "native" as in: not a web app or similar detached via abstraction layers and bundled with a browser that interprets it, but a natively compiled app that is directly linked to the rendering GUI lib. That would even be enough for me. But even for that, I find there isn't a satisfying cross-platform solution.
That's Sciter. It is a standalone embeddable library that does not use browser engine. It has its own HTML/CSS rendering engine that draws stuff using DirectX, Vulkan (Win/Lin) and Metal(MacOS).
It is used in many (~500 mln installations) applications that are considered native. Like Norton and other antiviruses (https://sciter.com/#customers)
On OS X though Firefox always felt a noticeably more laggy and clunky than any other app it might be running alongside — something about the Mac implementation of XULRunner wasn’t optimal and it showed… even if you painstakingly skinned Firefox to match OS X perfectly visually, it still felt kinda slow and clunky. That’s why Camino, which was a Gecko browser with a Cocoa/AppKit UI came into existence, and it always felt a good deal more responsive than Firefox did.
[0] https://github.com/zotero/zotero/tree/master/chrome/content/...
[1] https://www.zotero.org/support/dev/zotero_7_for_developers
What Zotero 7 will continue to support for plugins is full access to the Mozilla platform internals, unlike WebExtensions, but Zotero 7 is based on Firefox 102 ESR and will be updated to 115 ESR later, so platform changes like this do apply. The reason all plugins have to be updated for Zotero 7 is the massive architectural changes in Firefox over the last few years, most notably removal of XUL overlays. This change might require some minor additional updates, but it's probably not a big deal.
(Zotero dev)
Same statement can be applied to display: flexbox. It also breaks CSS box model in that sense. For example flex properties with obvious names like flex-basis, align-items(!) can change box dimensions completely.
Is it just me or is using the word "modulo" here (when "apart from","other than for" or "barring" would do) just completely pretentious?
The author appears to be Spanish, maybe it’s the same.
[0]: https://en.wikipedia.org/wiki/Camino_(web_browser) [1]: https://en.wikipedia.org/wiki/K-Meleon [2]: https://en.wikipedia.org/wiki/GNOME_Web
1. You can do most of it with HTML + CSS these days, so better use that.
2. It's not actually gone, it's a process with a big step taken