Why is XUL still relevant?

[moonbat]

I really wish XULRunner could be fixed and packaged separately, as of now it needs to be built I think. I have always preferred desktop applications to web based ones and this would be a shot in the arm for proper apps.

Also - consider that a XUL application can also have the same kind of extension and theming mechanism that Pale Moon has and Firefox used to have (as in extensions written for it). Same goes for updates - you can set up an update server for the app and deploy signed updates.

[soundmodel]

The widget toolkit is irrelevant for the development of XUL applications/extensions. That's the entire point.
XUL will translate its GUI definitions to whatever the underlying widget toolkit is; whether that be GTK, Windows, cocoa, raw X11, or something else! The developer of a XUL application or extension does not necessarily need to know, since it is abstracted to cross-platform elements/definitions in XUL. once again, look at the XUL documentation for a XUL technology overview and what it exactly entails.
With XUL you use an XML-based interface definition to build (and potentially localize through XML definitions) your UI, usually with javascript to "drive" the core of your application or extension and perform its tasks, making use of the various XPCOM interfaces or higher level APIs that are available in Goanna. You don't need to know anything about GTK or other widget toolkits for this as you are dealing with well-defined XUL elements.

Okay, why would Mozilla be the only inventor of such technology?

https://docs.wxwidgets.org/latest/overview_xrc.html

https://wiki.wxwidgets.org/WxWidgets_Co ... Mozilla.29

So XUL's contemporary appeal is based on JS vs C++?

Maybe XUL can be better contrasted with IUP? IUP does not use XML, but LED or LUA:
https://www.tecgraf.puc-rio.br/iup/

But, BTW, what is this:

https://sourceforge.net/projects/gluescript/

GLUEscript (Glueing Libraries Using EcmaScript) creates a JavaScript engine which can be used as a general purpose language. GLUEscript uses SpiderMonkey and is the successor of wxJavaScript.

Write GUI desktop programs in JavaScript.

Also:

https://docs.wxwidgets.org/stable/classwx_web_view.html

Yes, based on:

https://wiki.wxwidgets.org/WxWidgets_Co ... Mozilla.29

someone could feel like XPCOM is redundant for a general-purpose framework. OTOH, based on https://en.wikipedia.org/wiki/Component_Object_Model one could think it's not, but it's something that has just been missing so far (unless we consider e.g. wxWidgets' XRC to be essentially the same technology). Based on https://wiki.wxwidgets.org/Talk:Development:_wxTNG XPCOM is not redundant. Based on: https://wiki.wxwidgets.org/Development:_wxTNG#Back-ends wxWidgets has had interest towards a similar thing.

Also,

based on https://udn.realityripple.com/docs/Mozilla/js-ctypes we have:

Unlike binary XPCOM components, it allows developers to ship a single binary for use with multiple versions of Firefox

which could suggest that Firefox can also be treated as just a target. The contemporary version of this is: https://developer.mozilla.org/en-US/doc ... _messaging

Yes, TBH, from where I am coming from, I much more would appreciate a framework that allows me to "compile to JS/HTML/CSS". For this we only need a browser to render based on an input file.

I don't know about desktops, but for mobile platforms I think the added security measures make total sense. That is, that one doesn't want the browser to have access to native code.

[frostknight]

To be honest, I also consider it relevant for one other reason, Google is the developer and as such, they absolutely 100% cannot be trusted to do the job right. If Mozilla really wanted to make it more locked down the addon standard, they should have done it themselves and not trust dipshit google.

Also, that explains a lot, why mozilla really dropped XUL.

If they didnt want to vet the addons, they should have just found people to do the job for them.

Bunch of greedy narcissistic SOBs

SOBs = as in a three letter acronym...

[athenian200]

Okay, why would Mozilla be the only inventor of such technology?

https://docs.wxwidgets.org/latest/overview_xrc.html

https://wiki.wxwidgets.org/WxWidgets_Co ... Mozilla.29

We never said that it was? Yes, I'm aware that similar technologies like wxWidgets exist that can do some of the things XUL can do. In fact, I think that's a good analogy for the things XUL can do that that WebExtensions can't, but doesn't really capture everything.

So XUL's contemporary appeal is based on JS vs C++?

Well, actually XPCOM and XUL can be used with either JS or C++, though if you use it with C++ you have to compile the application.

Maybe XUL can be better contrasted with IUP? IUP does not use XML, but LED or LUA:
https://www.tecgraf.puc-rio.br/iup/

But, BTW, what is this:

https://sourceforge.net/projects/gluescript/

GLUEscript (Glueing Libraries Using EcmaScript) creates a JavaScript engine which can be used as a general purpose language. GLUEscript uses SpiderMonkey and is the successor of wxJavaScript.

Write GUI desktop programs in JavaScript.

Also:

https://docs.wxwidgets.org/stable/classwx_web_view.html

Yes, based on:

https://wiki.wxwidgets.org/WxWidgets_Co ... Mozilla.29

someone could feel like XPCOM is redundant for a general-purpose framework. OTOH, based on https://en.wikipedia.org/wiki/Component_Object_Model one could think it's not, but it's something that has just been missing so far (unless we consider e.g. wxWidgets' XRC to be essentially the same technology). Based on https://wiki.wxwidgets.org/Talk:Development:_wxTNG XPCOM is not redundant. Based on: https://wiki.wxwidgets.org/Development:_wxTNG#Back-ends wxWidgets has had interest towards a similar thing.

Well, GLUEscript, IUP, and wxWidgets are interesting projects that have some overlap with XUL, but would you mind telling why are you are linking them? Are you trying to understand what XUL is by analogy to other things, are you saying you'd like to see us take more inspiration from these projects in our design, or are you trying to convince that we shouldn't be working on XUL? I honestly don't understand your goal at this point. This is all interesting, but what exactly are you trying to say here?

Also,

based on https://udn.realityripple.com/docs/Mozilla/js-ctypes we have:

Unlike binary XPCOM components, it allows developers to ship a single binary for use with multiple versions of Firefox

which could suggest that Firefox can also be treated as just a target. The contemporary version of this is: https://developer.mozilla.org/en-US/doc ... _messaging

Once again, we're aware that WebExtensions can do some of the things that XUL was able to do. We explicitly chose not to support that technology in our platform, and in fact removed it when we forked off Mozilla. Obviously we know what it is and were not satisfied with it.

You are correct that the documentation there is obsolete, it's a copy of old Firefox documentation. Firefox is no longer a valid target for XUL.

Yes, TBH, from where I am coming from, I much more would appreciate a framework that allows me to "compile to JS/HTML/CSS". For this we only need a browser to render based on an input file.

I don't know about desktops, but for mobile platforms I think the added security measures make total sense. That is, that one doesn't want the browser to have access to native code.

Well, in that case I don't see how our goals align, because we absolutely do want the browser to have access to the native code and are not interested in something that just compiles to JS/HTML/CSS. There are plenty of things around that do that already. It sounds like you want what Mozilla and Google are already working towards, not what we're maintaining. And... you're free to try and create a modern alternative to XUL using some weird patchwork of wXWidgets, GLUEScript, and JNI stuff if you want, we're not stopping you. I just don't see what that has to do with us.

That said, I am going to keep your list of other projects in mind as stuff we could potentially take inspiration or possibly even code from in the future (with the obvious exception of WebExtensions which we really don't like). It's unlikely we'll ever have an occasion to pull in another similar project, but you never know, they might be good for code/ideas some day.

[soundmodel]

Maybe XUL can be better contrasted with IUP? IUP does not use XML, but LED or LUA:
https://www.tecgraf.puc-rio.br/iup/

But, BTW, what is this:

https://sourceforge.net/projects/gluescript/

GLUEscript (Glueing Libraries Using EcmaScript) creates a JavaScript engine which can be used as a general purpose language. GLUEscript uses SpiderMonkey and is the successor of wxJavaScript.

Write GUI desktop programs in JavaScript.

Also:

https://docs.wxwidgets.org/stable/classwx_web_view.html

Yes, based on:

https://wiki.wxwidgets.org/WxWidgets_Co ... Mozilla.29

someone could feel like XPCOM is redundant for a general-purpose framework. OTOH, based on https://en.wikipedia.org/wiki/Component_Object_Model one could think it's not, but it's something that has just been missing so far (unless we consider e.g. wxWidgets' XRC to be essentially the same technology). Based on https://wiki.wxwidgets.org/Talk:Development:_wxTNG XPCOM is not redundant. Based on: https://wiki.wxwidgets.org/Development:_wxTNG#Back-ends wxWidgets has had interest towards a similar thing.

Well, GLUEscript, IUP, and wxWidgets are interesting projects that have some overlap with XUL, but would you mind telling why are you are linking them? Are you trying to understand what XUL is by analogy to other things, are you saying you'd like to see us take more inspiration from these projects in our design, or are you trying to convince that we shouldn't be working on XUL? I honestly don't understand your goal at this point. This is all interesting, but what exactly are you trying to say here?

That based on what I've read I think I would use wxWidgets for native GUIs, because I found that XRC seems like XPCOM.

I would use JS/CS/HTML for possibly SPA-style apps that have the same value as XUL apps. https://www.laws-of-software.com/laws/atwood/

Both languages already have an "object model", I don't want a new one. I just wants things to connect between them.

I also think GLib comes really close to this, and it's already in GTK.

[athenian200]

That based on what I've read I think I would use wxWidgets for native GUIs, because I found that XRC seems like XPCOM.

Well? That's fair enough, wxWidgets is a solid choice for a native GUI if you don't need or want the underlying Goanna engine.

I would use JS/CS/HTML for possibly SPA-style apps that have the same value as XUL apps. https://www.laws-of-software.com/laws/atwood/

I don't agree that JS/CS/HTML has the same value as XUL apps, but I get that a lot of people would see it as "close enough."

Both languages already have an "object model", I don't want a new one. I just wants things to connect between them.

I also think GObject comes really close to this.

Yeah, there do seem to be a lot of independently developed object models that do similar things but aren't interoperable. XPCOM itself actually took inspiration from DCOM and CORBA, I believe. If you find that fact frustrating, I sympathize somewhat.

But yeah, from what I gather, I do not think XUL as provided by us will meet your needs. Like I said, this is a fairly niche project. And at the end of the day, it is what our users want, and what we are getting donations to keep alive, even if it isn't what average developers like you want. There does seem to be a sort of frustrating divide in software development... what developers want to work with is often different from what users want to use.

[Moonchild]

In the end it depends also on what any dev is willing to learn to use. We all make choices in what languages and environments we use, and we don't have to agree (unless we work together on one project).
Whether XUL is what you would choose or not is not an answer to the question whether XUL is still relevant as a whole. XUL is still relevant as a whole because we use it.

[soundmodel]

Here it claims that the contemporary use for XPCOM is as an intermediate language between C++ and JS mainly, and that the V8 has a similar thing:
https://news.ycombinator.com/item?id=23519618

Wonder what this similar thing in V8 is?

This:

https://news.ycombinator.com/item?id=23519575

suggests as if "writing in C++" and "writing in XPCOM" wouldn't have much difference.

---

Reply to below:

The thread is:

Why is XUL still relevant?

[athenian200]

Here it claims that the contemporary use for XPCOM is as an intermediate language between C++ and JS mainly, and that the V8 has a similar thing:
https://news.ycombinator.com/item?id=23519618

Wonder what this similar thing in V8 is?

This:

https://news.ycombinator.com/item?id=23519575

suggests as if "writing in C++" and "writing in XPCOM" wouldn't have much difference.

So, what is the point of all these analogies? I'm just going to be blunt now. I don't care about what you want. I feel as though you are picking apart our reasons for working on XUL, belittling us for thinking it has any value in the modern day, and trying to persuade us to work on something else that would be more valuable to you, simply because it's what you desire.

So, let me to clear. I'm not here to serve you. I don't care what you think, I don't care what you want. I want to keep working on XUL whether you think it's relevant or not. I have no more respect for your view than you do for mine.

I think you're trying to force a very particular kind of engineering pragmatism down my throat here by decreeing that only things that are "relevant" by your metric should be worked on, and using your topic as justification to keep pushing the idea that XUL is not relevant and putting us in the position of defending it and answering for criticism that I do not feel we should have to answer for. It's this sort of weird, condescending, false objectivity that I've grown accustomed to in programming/engineering circles that narrowly defines a parameter or topic, speaks very rationally and avoids emotion, and then continues pushing until the desired outcome is justified and no one can argue against it without seeming unreasonable.

You've already decided what the outcome of this thread should be and seem to be prepared to push your perspective down our throats, countering every possible justification and insisting we submit to your logic from exhaustion eventually.

[moonbat]

All I've seen in this thread is the OP totally ignoring everything athenian200 & Moonchild have (very patiently) explained and just jumping off on irrelevant tangents. Some random comment on HackerNews is what you'll refer to after all this time, really?

Just pick a language or framework of your choice and stick with it.

[athenian200]

All I've seen in this thread is the OP totally ignoring everything athenian200 & Moonchild have (very patiently) explained and just jumping off on irrelevant tangents. Some random comment on HackerNews is what you'll refer to after all this time, really?

I'm afraid the tangents aren't irrelevant. He's systematically going through and picking apart every possible reason anyone could use to justify continuing to use XUL and shown that other things exist that could do the same thing, and basically trying to leave us with no justifications left so we have to concede his original point.

Based on the stuff he's said, and the rules for the topic he seems to have laid out, I think his rule for things being relevant is that there can't be other, better-maintained ways of doing the same thing that are more popular. And since XUL fails to meet that metric, he therefore thinks it is irrelevant because it is not unique.

The problem is that... well, you could apply this reasoning to almost any software project. Why is X11 still relevant when we have Wayland? Why is Qt relevant when we have GTK? Why is C++ still relevant when we have Rust now? Why would anyone want OpenRC or SysVInit when systemd exists? Why Why is glibc still relevant when Google is working on bionic? Why is GCC still relevant when Clang exists? Why is Firefox still relevant when Chromium exists? You start pulling at that thread, and the only conclusion you can come to is that there's a lot of wasted effort in software engineering with people trying to reinvent the wheel, and is instead suggesting that everyone should work on improving one implementation rather than trying to do similar things in their own way.

And I mean... I don't totally disagree with that logic, but I also do not get why our project in particular has to be picked on for trying to preserve XUL, when there are plenty of other projects that are working on doing things that are very similar to other projects in only marginally different ways, and yes, some of them with varying levels of quality and maintenance. I don't think our project is so uniquely awful regarding pointless duplication of existing efforts as to deserve this level of scrutiny.

If our project isn't relevant, then quite a few software projects aren't relevant either. Maybe we could even ask why FreeBSD is relevant when Linux exists... you see what I mean, right? That rabbit hole never ends.

[soundmodel]

Because I thought XPCOM as a term carries more weight than just "a browser add-on object model" (the MS COM is huge and has significant use), and I am slightly misled by the direction and contemporary use case of XPCOM/XUL. Based on the earlier notions.

I was interested in it as a layer to generate any native object model like GObjects in GLib, wxWidgets objects, COM objects, ... Then it would be to those what HTML5 is to XUL/XPCOM.

So if there's a way to write XUL and have that generate the app on any such platform.

Given the current state of other browsers, one could potentially also read in a XUL file using Native messaging and generate the GUI (+ etc.) based on that in the browser. In fact, ATM I am not understanding why cannot Native messaging enable about the same features.

[athenian200]

So if there's a way to write XUL and have that generate the app on any such platform.

Well, XULRunner can technically do that, but it's in a state where I wouldn't recommend it for most new projects. With that, you can actually just write an entire application in JS and XUL, and never touch the platform code.

Given the current state of other browsers, one could potentially also read in a XUL file using Native messaging and generate the GUI (+ etc.) based on that in the browser.

Okay, I think I see where you're going with this now... you're talking about whether this codebase is the only way to implement XUL. You're wondering whether we could have an implementation of XUL as a language/concept that isn't tied to an old Firefox engine, but instead engineered on top of more modern stuff.

Well, honestly, if we really wanted to put all our engineering effort into that? Probably, but it would take a few years and it probably wouldn't be much more popular than what we have now. But the truth is, at this point Pale Moon is valuable to me for more than just XUL. I like a lot of the other ideas behind it, like eschewing Rust and preferring a single-process/multithreaded architecture.

In fact, ATM I am not understanding why cannot Native messaging enable about the same features.

Theoretically, yes, but I haven't seen an implementation of such a thing.

[soundmodel]

But the truth is, at this point Pale Moon is valuable to me for more than just XUL. I like a lot of the other ideas behind it, like eschewing Rust and preferring a single-process/multithreaded architecture.

What about the security issues? Isn't it evident that browser add-ons should not be allowed to execute foreign native code?

[athenian200]

What about the security issues? Isn't it evident that browser add-ons should not be allowed to execute foreign native code?

Well, as stated above, I don't agree with the means by which Google and Mozilla provided added security at the cost of user freedom, via mechanisms such as Google Safe Browsing, locking down and limiting extensions, and adding extensive telemetry.

I'm fully aware that Pale Moon is considered "less secure" than mainstream browsers. But I would argue that human existence has always been about choosing between freedom and security, and I would rather have freedom. Just because the majority of the computing world has chosen to concern itself with security over freedom, doesn't mean everyone has.

And as part of that, of course I am fine if people use that freedom to choose something other than Pale Moon or XUL.

As for it being evident, well... what environment are we talking about? Just because it's evident to you that it shouldn't be allowed in high-security, mission-critical environments, doesn't mean that everyone should have to accept the idea that it should never happen under any circumstances.

[soundmodel]

Why cannot one have security and freedom? I see that the main problem is not foreign native code per se, but when it's combined with a connection to the internet and the inputting of various sensitive data forms. Possibly, add-ons as such aren't that more insecure than normal native programs, but they are connected to the web. They are also near a program that is used to put in passwords etc. to banking systems etc.

And as I wrote, I am not sure whether Native messaging prohibits much of XUL/XPCOM's use case. It just breaks it so that the components cannot connect without limitations.

[athenian200]

Why cannot one have security and freedom? I see that the main problem is not foreign native code per se, but when it's combined with a connection to the internet. Possibly, add-ons as such aren't that more insecure than normal native programs, but they are connected to the web. They are also near a program that is used to put in passwords etc. to banking systems etc.

Well, let me put it like this... we tell the users to be careful which add-ons they install, and make it very clear that if anything happens negatively that results from the use of an add-on, we're not responsible. So yes, if a user installs a malicious add-on, then bad things could happen.

There is actually a strict separation of chrome and content. Websites can't arbitrarily execute native code, only user-installed extensions can. So, it is the user choosing to take that risk by installing the extension, if random websites could run foreign native code, that would be a totally different story.

While we do give the users the freedom to install XUL extensions, I personally would actually recommend running the browser without extensions for maximum security, but we still give them the choice to use them. Offering the choice doesn't mean we think that installing every extension you can get your hands on is a good idea, obviously.

And as I wrote, I am not sure whether Native messaging prohibits much of XUL/XPCOM's use case. It just breaks it so that the components cannot connect without limitations.

Hmm... so you're saying that you think XUL as a concept could be adapted to modern browser using native messaging? I mean, maybe it could be. I don't know enough about that to speculate one way or the other.

[soundmodel]

And as I wrote, I am not sure whether Native messaging prohibits much of XUL/XPCOM's use case. It just breaks it so that the components cannot connect without limitations.

Hmm... so you're saying that you think XUL as a concept could be adapted to modern browser using native messaging? I mean, maybe it could be. I don't know enough about that to speculate one way or the other.

Yes, just send the XUL file or whatever as a string or some form of binary using Native messaging and capture it on both sides.

[soundmodel]

I also noticed that single-threading in browsers and native code are a bit orthogonal.

Possibly, this is why WASM modules might be more appropriate for the near-browser part (as per Google).

Yes, it has started to feel to me like XPCOM/XUL is overkill for the browser's needs. But it could have made sense as a general framework between all the other object models so that one can compile for all the others from a single codebase.

[soundmodel]

I don't know if this has any relevance to Android, but I just thought that the architecture around Native messaging sounds quite a bit like JNI is for Java and Android NDK. There too people complain that the bridge is limited. But it's similar in architecture. There it's evident that NDK is overkill for most of Android apps though.