SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    Anonymous
    SitePoint Community Guest

    Discussion thread for Introducing XUL - The 'Net's Biggest Secret: Part 3

    This is a dedicated thread for discussing the SitePoint article 'Introducing XUL - The 'Net's Biggest Secret: Part 3'

  2. #2
    SitePoint Member aCastaņeda's Avatar
    Join Date
    Jun 2003
    Location
    Peru
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    spam

    is veru good
    Last edited by freakysid; Jun 12, 2003 at 21:00.

  3. #3
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ** BUMP ** And why not folks eh ?

  4. #4
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One thing I should correct while I'm about it. The rant about documentation / information in particular;

    For security reasons, using the XPCom SOAP API from a JavaScript that has been loaded directly from a Website requires the visitor to give their explicit permission before it can run in their browser. This is a good thing, but it requires developers to digitally sign the JavaScript, so that anyone who's loading your application can check your credentials before executing it. Fair enough...

    Unfortunately, the official explanations of how you must sign your JavaScript read like beer mat doodles and are scattered across multiple sites, some of which look as if they were knocked up in half an hour. And don't get me started on the README file in the signing tool they recommend, which directs you to this up to date URL.
    This is being addressed thankfully in the latest releases to make web services easy to use from a JavaScript client in the new security model.

    There's more information here: http://devedge.netscape.com/viewsource/2003/wsdl/01/

  5. #5
    Anonymous
    SitePoint Community Guest
    Good article, but let's be honest about why you use XUL - it's for techie fun, so let's not wrap it in business reasons. I'm not convinced using XUL would impress a potential client given that times are hard - most clients would surely rather their money was spent on features that work with 98% of the browsing community not the 2% who use Mozilla! (no way 20% Mozilla penetraton).

  6. #6
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Good article,
    Thanks

    but let's be honest about why you use XUL - it's for techie fun, so let's not wrap it in business reasons.
    Very true. I've done nothing but keep myself amused in understanding a technology which is currently largely experimental.

    I'm not convinced using XUL would impress a potential client given that times are hard - most clients would surely rather their money was spent on features that work with 98% of the browsing community not the 2% who use Mozilla! (no way 20% Mozilla penetraton).
    Certainly for business where budgets are tight and risk must be avoided, XUL is a bad choice. But here's how I look at it;

    XUL is something to use when you can reasonable require users to run a Gecko based browser. For example the backend admin interface to a website or on an Intranet/Extranet where there's a demand for an app where HTML isn't enough. In other words where the users aren't the general public.

    I've seen one app in progress (which sadly I can't talk about until it's released - commercial - except to say it's impressive) which puts a new spin on a commonly used corporate Intranet / Extranet app and I could imagine could a become very successful product as the web based nature of XUL solves many of the problems companies usually have with this type of app.

    From the point of which developers might consider XUL, I reckon it's enthusiasts (guess that's me), students and those (lucky enough to be) paid to experiment with new technologies.

    Otherwise, comparing XUL to equivalent "rich client" technologies today, really think XUL has the edge in everything except maturity (which it isn't);

    DHTML - too clunky for complex GUIs
    ActiveX - (basically) one platform only and also fairly clunky for real GUIs
    Java Applets - slow to load and requires Java skills (cf. XML + CSS)
    Flash - slow to download (or expensive on BW) and not well suited for complex GUIs (although it can be done)

    My guess is Microsoft have XUL on the radar and with Longhorn / .NET they'll be launching an alternative (but you'll have to wait 2 years).

    The bottom line, IMO, is we're doing a bunch of stuff in HTML today which if XUL had been available 5 years ago, we would have done with XUL. Count, for example, the number of page views you make opening your inbox and replying to a message with a typical webmail app - could be drastically reduced with XUL as well as offering users a much friendlier interface.

    Also XUL has potential to compete with traditional desktop based apps which so far have failed to be well migrated to the web, allowing them to gain the ease of access / maintence etc that online deployment provides. Today companies pay $xxx,xxx for technologies like Citrix to deploy such apps over a pan-regional Intranet. That means potential business opportunities for XUL...


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •