Miguel nails the key threats in XAML/Avalon/whatever: fancy graphics, widgets, and layout; easier XML-based authoring; better “managed code” model for when you have to hack; and a web-like deployment model with sandboxing for security.
The deployment model is a huge advantage over conventional app development. Web browsers and FlashPlayer have benefited from it, even as they’ve been held back by HTML and plugin stagnation. You can see Macromedia trying to escape the “plugin prison” now, and they’ve got a good chance of succeeding, thanks to FlashPlayer’s ubiquity.
The challenge for Mozilla and other open source projects is not to “react to Microsoft”, any more than it is to “react to Macromedia”. MS and MM are reacting to the same fields of force that govern everybody. The prize we seek is a better way to develop common kinds of networked, graphical applications.
People are using web standards to build web apps, and running into limitations in the deployed standards, and speedbumps in the standardization process. Other people are developing desktop apps using, e.g. Glade and GTK+, but wanting web-style deployment and even cross-platform portability. We should make it easy to do advanced, native-looking UI and fancy graphics in a web-like way, and portably.
This doesn’t require building an IDE, although who could object? The best case success story for any open source advanced layout/rendering/GUI-app platform would use the same network effects and low entry cost structure that helped the web explode to 5 billion or so public pages (but without the tag soup this time, please). People should be able to copy and mutate cool content. You should be able to edit by hand, even if the IDE generated the content, and have everything work (maybe your pretty formatting might even be preserved, what a concept!).
To make a difference on the web requires distribution, ideally in the form of support for new standards in all browsers including IE. That’s not going to happen with Mozilla code unless someone makes an Active X plugin out of Gecko, and distributes it widely. Fortunately, we have such a plugin. Distribution will be the hard part. But even without Mozilla, IE6’s behaviors (HTCs) allow a lot of extensibility. What if the minority browsers started incrementally improving HTML, DOM, etc. — and the emulation layer for modern IE were thin enough to download, if necessary?
Another requirement for web-like deployment of rich apps: a sandbox security model that allows trust to be delegated only to critical sections in the app. You shouldn’t trust a big pile of compiled C++ *or* compiled/interpreted JS/JScript/C#. Object signing is not enough — what’s need is a way to minimize the “trusted computing base” extensions, the critical sections in the app that actually need privilege. Also, those sections should automatically downgrade on exit (return from privilege-enabling method, e.g.).
I hope to blog more on these and related topics, as time allows.
To worry MS, it is vital to make it easy for a “developer” to create programs; and to make it easy for a “developer” to create programs that are easy to use.
The reason why HTML, etc. was and is so successful is because a hello world “program” can look like this:
<html><body>Hello, world!</html></body>
and there is a smooth continuum between that and the useful programs that html/js/css is capable of. (Actually, I was thinking that if you could save and load the js+dom state of *any* page, html would be capable of even more. You could write useful html “Object Apps” — e.g. document and spreadsheet files that provide the tools to edit themselves).
If dabbling with a XAML etc. alternative is any more difficult for a “developer” than the current html way, then MS’s defacto distribution capability will kill the alternative before longhorn’s 3 month birthday. The current XUL/XBL/js is waay too difficult to start developing with. It is also very difficult to keep code organised — and organised idiosyncratically (which is actually quite important).
This is not an easy task for open source to achieve: open source projects tend to present powerful but badly organised interfaces to their users (whether those Interfaces are prefaced with U or AP). But there isn’t really any other source from which an alternative to XAML could spring.
I am assuming (and hoping) this vital need for ease is already well understood. I have followed far too many closed/open source projects that forgot to make things easy for the users, devs _and_ the devs’ users because they, being frightened by MS, were too busy increasing their software’s power.
I disagree that XUL is hard. It’s certainly less “familiar” than XHTML, but it just uses the same XML syntax with new tag names. It’s just a jargon problem, not a very large leap.
If you compare laying out a GUI in XUL to Swing for instance, XUL wins hands down for ease. The problems come when you try to bind the JavaScript to lower layers (ie. XPCOM). Good solid and SEAMLESS support to Java on lower layers (there are third parties working on this?) would help a lot, and would get “web app people”, who already know Java, making these rich internet application frontends. “Smart clients” as some people call them.
You should talk to the Eclipse guys about some sort of XUL/SWT combination/collaboration — they were looking into making SWT easier to use, and having an XML layout language was one of the options. They have the luxury of not being associated to tightly with Sun and are exploring options as far as I can tell. They also have no graphical WYSIWYG editor, though several are in third party development and a framework (GEF) is provided. An interesting idea one of them had was making an XML layout language for SWT and them being able to XSL transform to and from XUL.
Extending DHTML and DOM past its usefulness is dangerous and it’s already been stretched too much, IMO. HTML is for documents, not end user applications. That document paradigm is strained enough as it is. A better option would be to make a new markup language or extend XUL (2.0), differentiate it from XHTML and continue to support both natively in Mozilla/Gecko.
I wish you the best of luck and I’d be glad to help in any way I can. Good to see you blogging!
I should clarify that XUL is easy to learn and develop with. Also, XUL will always be easier than Swing for GUI layout, since its declarative while Swing is procedural.
But XUL (partly by virtue of being written in XML) is harder than it *could* be, and the competition is XAML, not Swing. It has to be *much* easier than XAML to succeed.
I also disagree with the idea that HTML must stick to the paper-document metaphor. That would mean there is a clear distinction between docs and apps that almost no website today obeys. And a new application-file format would suit MS just fine, since they are the ones with the most power to distribute a new format.
What bothers me is that there doesn’t exist a dedicated XUL section on mozilla.org yet and even more that no “pure” XUL runtime has been released so far. Everybody is talking about XUL as an alternative platform to XAML but I don’t see it that way. XUL right now is just a part of the browser known as Firefox/Mozilla. Why do I have to install a browser to run a XUL-based application even if I have no interest in using that browser? I know that this is more a case of how this platform is perceived but unless you can give developers a reason to think of XUL as more than just a Firefox “add-on” I just don’t see how you want to compete with XAML (which *will* become a huge standard simply because of MSs sheer deployment power resulting from it’s broad base).
Even the XUL tutorial doesn’t seem to be up to date with current developments as I had to follow some of the user comments to make my first XUL app work and that tutorial seems to be the only source of good documentation right now. XUL really needs to stand on it’s own legs if it is supposed to become relevant in any way.
I don’t want to get too off track here, but I think this is an important point: the Mozilla team needs to do a better job contrasting XAML and XUL, they are really not that similiar. Public perception is that they are.
It took a month of blogging on behalf of Microsoft’s employees to get this straight after Longhorn’s technology was announced and now Mozilla will have to do it all over again. The comparisons don’t help Mozilla target the right technologies, so it would probably be in the best interests of the community if this was straightened out as soon as possible.
I think this discussion is exactly on topic for this blog (e.g. para 4 in Brendan’s entry).
The only differences between XUL and XAML that I’m aware of are the following: XAML is meant primarily to be compiled; XAML hooks into windows APIs, while XUL hooks into mozilla APIs. If the two formats aren’t in direct competition, then XAML is clearly a superset of XUL, and XUL will become an unused format (isn’t this implied in Miguel’s entry?).
@dennisj: I agree with you, this is very important. I think they are working on this, though. See: https://www.mozilla.org/projects/xul/xre.html
(although it’s a little stale). I wonder if someone knows if its possible to build some kind of XRE from the source today?
Miguel isn’t really clear about what XAML is either in that post, he just talks about it in the context of Avalon. XAML is just a general tool that *happens* to be used by Microsoft to specify user interfaces in Longhorn. It is not solely a user interface markup language like XUL is, and could easily be used in other areas.
The idea of XAML is this: you write some XAML XML markup, and that markup is turned into objects. Those objects and their properties are then combined with source code objects (ie. C#) and their properties to create the full definition of the objects. Half of the object may be specified in XAML while the other half of the same object may be specified in C#. This has nothing to do with GUIs at all.
What this lets you do, for example, is completely seperate presentation from handler method attachments. You can say what it “looks like” in XAML and “how it works” in C#. With XUL, it’s all together with XUL and JavaScript calls to handler methods in one file (ie. onClick=”method()”).
So comparing XUL and XAML is apples and oranges. XAML isn’t just a superset of XUL in the GUI context, it’s a completely different tool altogether. The “tags” that it uses to specify user interfaces are just classes that are some part of the Avalon API, which make Avalon objects. Thes objects are combined with code (C#) objects and then drawn by the window “renderer” (it’s safe to assume there is such a thing, given it’s hardware accelerated 3D graphics).
The XAML tool has the advantage that it only has to “compile” against one object model: .NET. Open source has no such advantage, and so it would be more difficult to duplicate XAML itself in all of the different languages of open source, though not impossible. It’s a neat idea but I don’t see XAML (THE TOOL) being useful for Mozilla, really.
What Miguel talks about is: should the open source community create a new user interface markup language or just implement Avalon’s API? He’s probably going to just implement Avalon anyway to give cross platform benefits to Mono. Coincidentally, he also has only the .NET object model to worry about, so it’s easy for him to support a direct port (rewrite) of all of XAML. Most open source software does not have this luxury.
He’s just wondering if he can use existing tools to do it. I don’t think he benefits at all from creating a new markup language to support, other than loosening ties/coupling with Microsoft technology that hasn’t been released/standardized (as far as I know). Mozilla could provide this markup language — XUL is a good start, but right now it’s only a subset of what Avalon can do.
What would be more interesting is if the Mono team did Avalon support, Mozilla did XUL support and they both used the same renderer and “browser” security stack (sandbox) — no sense reinventing the wheel there. The problem comes when connecting all of the open source languages to this renderer: bindings.
A “universal VM” that worked like the .NET runtime would be nice, wouldn’t it? It would have to support C++ and Java at the very least. Open source should have had this 5 years ago anyway. Talk to IBM (and search for UVM in Google), they know a bit about this.
But what do I know? 🙂 I just graduated, I’m unemployed and I’ve only been reading blogs. Miguel was at the PDC. Personally I trust his judgement, but I see a lot of duplication here that could be taken advantage of.
Sorry, you’re quite right. The markup languages XAML and XUL aren’t comparable. I mean XAML and all related technologies like Avalon, Indigo, .NET (let’s label it all XAML+), and XUL and all its related technologies such as js, XBL, dom, XPCOM(+necko) (let’s label it all XUL+).
XAML+ provides a development system comparable to that provided by XUL+. e.g. Imagine that something like XAML+ had existed universally before mozilla started development. There would have been no point in developing XUL or having any of the other XUL+ technologies available within XUL. If XUL+ isn’t competitive with XAML+ when longhorn is released, XUL+ will become irrelevant, and a huge opportunity to trip-up MS would have been wasted, both on the desktop and in embedded devices. (Of course, if MS doesn’t bother you, then there isn’t really any issue at all.)
However, I think we roughly agree on what would be desirable, just not how to achieve it. IMO (which ain’t worth much 🙂 ), it is vital to get an XRE working now, ASAP, that allows people to run programs from a command prompt/console like this: ‘xre myapp.xul’ or ‘xre myapp/’ (the latter kind of app would mimic the chrome dirs in mozilla apps). This can almost be done now with ‘mozilla -chrome’, but it needs to be marketed properly as a separate product with its own security model: as an XRE.
This needs to be done to create awareness amongst developers that XUL+ can be used to write standalone programs and can be a useful technology for them *today*. It also needs to be done so that mozilla developers working on XUL+ can get early feedback for the next iteration of XUL+ — the one that is likely to compete with XAML+.
After the XRE, would come SVG and XTF. Then, focus should shift to XUL+ 2.0 (whatever it is). The primary XUL+ 2.0 language should be kept simple and lightweight: tags for objects, css-like rules for adjectives (which would equal ordinary attributes), xbl/xslt-like rules for object composition (and pattern matching), xbl-like inheritance, scripts for actions. Syntax should be made simple, quick, roughly consistent and _perhaps_ non-standard in some cases (e.g. php style tags for scripts or perl- or tex-like shortcuts). Also, scripts should natively interact with every non-script element within the same scope: no document.getElementById or document.createElement methods, or anobj.style.width accesses. Just objid, objid = new obj and objid.width, respectively (there’d be a heap more shortcuts that could be made). Also, no backwards compatibility (but definately build on top of existing code).
Quick summary of what I think the priorities are:
1. XRE with a decent/good security model
2. SVG
3. XTF
4. Enhancements to necko
– competitive with XAML+ –
5. XUL+ 2.0
I also believe that what should happen on the linux side is merely to provide well-integrated support for all of this (unless they want to help hack). By well-integrated, I mean optimisation of the libs and the XRE being a native environment. Perhaps we might even get an OS+apps with well-designed, consistent UIs.
I don’t think a UVM (or even basic multi-language support) ought to be an aim *atm* (it would not attract enough developers to compensate for implementation costs). But it would certainly be great eventually.
But (to shamelessly mimic your own closing humility), I’m just a programmer who probably hasn’t the ability or time to make a difference, but likes to think about how things could be made better anyway. I spose even if we did suggest something useful, these things don’t get read anyway, do they 😉
(getting late, must sleep . . .)
XUL & javascript are easier than XAML
However adding objects/components to .NET is far more easy than in mozilla/firefox e.g. database access via odbc or serial line or file access.
See https://www.myxaml.com/ for an open source XAML parser
Great comments here.
Yes, XAML is “just” another CLR source language, so you can mix and match implementations, partial classes, etc. among C#, XAML, etc. It’s hard to match this flexibility without Mono — which is not to say we should try to reverse-engineer MS APIs. I think Mozilla should join Mono and promulgate our own easy-to-use stack of APIs sooner.
We’re thinking of a xulrunner/libxul.so pair (Unix speak; xulrunner.exe/libxul.dll, etc.) for Mozilla 2.0. The libxul is a consolidated library with minimal dependencies and minimal and frozen API only exports, so most of it is fast, static-linked non-PIC-entry point code. The xulrunner program can take a .xul file, or a .jar, and not only run an app, but do things such as pick up desktop icons from the .jar.
I’ll post more on this later in the week.
/be
Excellent! That sounds very promising. I have high hopes that a xulrunner and xul lib (and moz2) will catch on quite quickly with devs, both new and experienced. I’m looking forward to seeing how successful it is (that’s possibly the first time I’ve said that when MS is the competition).
Personally, I can’t bring myself to use XUL until the Java bindings are done and pretty much seamless. The Mozilla team would be well served to make this a priority and turn all of the server-side J2EE monkeys into rich client application coders as well. That would make my day, for sure. It would also accelerate the adoption of XUL.
Of course, there’s the 3rd party blackconnect work on accessing java via xpcom (and hence xul) as you pointed out earlier. But, more interestingly, you might also get java in xul with mono — though the effort to support the java lang in mono seems a bit stagnant and I don’t know how seamless or cross-platform it would be. Nevertheless, I don’t think java bindings should be done directly from xul — at least, not with the default package — it would be better done in mono. No point in building multi-lang support that requires maintenance and may impact performance, when you already have hooks into a CLR.
Actually, it seems java in mono is further along than I thought, with IKVM.
I was referring to direct JavaScript to Java communication in a XUL file instead of through XPCOM.
Some people will resist using Mono, rationally or not, because of its affiliation with Microsoft. It might be a mistake to depend on it too much.
One of my first thoughts when reading this was: What about mozrunner? I’m looking forward to reading your upcoming blog about xulrunner since it seems like a logical, incremental way of making xul (xre) a platform.
Voracity: great post about priorities regarding Mozilla. I agree with you 100%.
Brendan: Don’t let us down: you promised to write about xulrunner/XRE soon… 🙂 This is truly interesting stuff.
Thanks Brendan, Ryan and Voracity for your excellent opinions. Picking from where Ryan left, I was wondering whether the Mozilla folks would be willing to try for a better inter-op with the Mono folks. The concept of a runtime already exists in Mono, wouldn’t it reduce effort if the XRE were Mono-aware (or even the other way round). Do you think that would be possible. I have written(https://chaos.weblogs.us/archives/011847.html) more on my blog. Can we expect something like this. And if yes, I think XRE would be a wonderful project to work on.
I don’t know if this will get read but…
The goal of new products should be to create collaboration, not competition. The downside is that some products by their nature thwart collaboration (e.g. IE). Firefox is an excellent example of a collaborative prduct with it’s focus on etensions etc.
Great article!
————-
Tax Man
Excellent!
———————
Ad Specialty King