Warranted Genuine Snarks
RIP: Longhorn - Here's a thought for you: Why pay lets say US$200 for Longhorn when you can get a Linux Desktop for free? Note that you can also build rich UIs using XML for the Linux Desktop. Chck t th Lxr XL Tlkt fr strt nln @ http://lxr-xl.srcfrg.nt [Spam disenvowelled by moderator.]
Gerald Bauer (gerald@vamphq.com) (http://luxor-xul.sourceforge.net) -- Tue Oct 28 14:01:24 2003
I don't really buy it.
After all, you've been pretty much able to do this with Java for years. That was the whole original idea, right[1]? Rather than these dumb pages, we'll write little client applications that run in the browser. More efficient, better UI, etc. Except that it didn't end up working out that way.
I don't doubt that this will be a nice, slick, polished effort, but I don't think it'll take over the world.
[1] Okay, so I don't think that was the original original idea, but it was the first thing it got famous for.
Mike Bruce (bruce@jhereg.net) (http://log.ibruce.org) -- Tue Oct 28 15:29:26 2003
You're ignoring the details, which are important. Java applets failed, because: 1) they didn't have a good way to communicate back to the server, 2) the UI was terrible, 3) writing interfaces in Java was (and still kind of is) difficult, and 4) Java applets were too big to download on 14.4 modems.
Compare Web-deployed Longhorn apps to Flash (which has been fairly successful), and you've got something closer. Except Flash never had much of an enterprise story, and .NET does.
Like I say, on the broad net, I think HTML is still going to be the lingua franca, but especially for intranets, rich clients are going to make a big comeback.
Mike Kozlowski (web@klio.org) (http://www.klio.org/marks/) -- Tue Oct 28 15:38:36 2003
XUL bears mentioning, somewhere. No marketing there, though.
I'm aware of the difficulties of Java, but I still don't find it all that compelling. 14.4 modems are a non-sequitur in this case, since we're talking about intranets. And the other problems could be solved by the application of some libraries. If regular web apps were really so bad, you'd imagine that someone would have gone to the effort, after all this time.
What we're really looking as is a more polished, better thought out implementation of the same vision. And it still seems kind of tepid and uncompelling.
I'm sure some IT departments will sign on, because I have no expectation of taste or good sense from IT departments. I just don't see it as an all-conquering type of thing.
Mike Bruce (bruce@jhereg.net) (http://log.ibruce.org) -- Tue Oct 28 15:54:01 2003
XUL is an implementation detail of Mozilla. There's very little documentation for it, no commitment to developing it as an API, and very little feasible way of doing so. Again, details matter.
As to "better implementation of the same vision," HTTP is a better implementation of the failed Gopher vision, Java is a better implementation of the failed Smalltalk vision, and XML is a better implementation of the failed SGML vision. The lesson of tech history is that when people keep coming back to an idea, eventually someone's going to do it right.
My main point is that if I were working, in 2008, for a company that had standardized on Longhorn desktops, and I was asked to create an application for internal use, there's not a single reason that I could give in favor of a browser interface, and many that I could give in favor of an Avalon one.
Mike Kozlowski (web@klio.org) (http://www.klio.org/marks/) -- Tue Oct 28 16:00:25 2003
xulplanet.com.
The obvious advantage to a browser interface is that it doesn't lock you into your current client platform. Sure, you're standardized on Longhorn today, but what about tomorrow? Locking yourself in to a platform controlled by a known-hostile vendor doesn't seem terribly prudent.
(Of course, that's probably the whole point behind Microsoft's effort anyway.)
I think there are lots of other advantages to a regular browser interface, of course, but I don't have a lot to back them up with. For example, I think that the extremely limited UI available to the web programmer is a good thing.
Mike Bruce (bruce@jhereg.net) (http://log.ibruce.org) -- Tue Oct 28 16:41:18 2003
Yes, it locks you into the desktop; but most large businesses will view it as a fait accompli, no matter how they roll out a new app.
As for the non-rich interface of browsers, yes, there's something to that limited set of controls (the Avalon demo for Amazon looked like a nightmare, and we can all point to horrid Flash). But after you've banged your head against simple, common master-detail stuff; after you've wished like hell you could use right-button context menus; after you've ripped out your hair trying to make an interface halfway-usable because you can't use half the widgets in the toolbox... well.
And, as you note yourself, your arguments aren't particularly compelling when presented to your non-technical boss who wonders why you're sacrificing functionality and ease of development for a Web interface.
Mike Kozlowski (web@klio.org) (http://www.klio.org/marks/) -- Tue Oct 28 16:51:57 2003
I find many of the opinions expressed here to not be consistent with the experience nexaweb http://www.nexaweb.com has had with deployment of declarative applications at several Enterprises and ISVs. They have a markup of XUL/SVG+ backed by at the present Java that runs server and client side using a tiny java based engine on the client sdie.. You can read about how trivial it is to rewrite apps like the Java Petstore a blueprint J2EE application trivially ripping out HTML for The markup yielding 90% reduction in bandwidth for a mere 3% change in the presentation layer of the code. http://www.nexaweb.com/ Microsoft is really making a huge step forward in validating the mixture of XUL/SVG/etc as a tenable and the way to write apps backed by compiled code. Time will tell but the nexaweb implementation deployed in the field provides clear evidence TODAY that enterprises and ISVs can derive HUGE benefits using an approach that allows one to leverage the huge investments allready made in web applications today can be leveraged by real application in a very incremental way. I have 0 doubt in my mind if you continue to develop ASP.Net code or JSP that the Declarative model of programing will require trivial updates to your web application as shown in the petstore example we wrote over a year ago. Declarative Programming as Petzold long realized awhile ago is the way to write apps both today and the future. Another point worth noting is that enterprises in many cases realize that today if they write more then HTML code its very expensive because the browser is not something they control. In most cases this makes you lose most of the productive functionality. So to think that you can "control" the rendering platform is naive. The bottom line is that web applications are expensive to maintain if you do things specific to the browser.
Rajeev Surati (raj@photo.net) (http://www-swiss.ai.mit.edu/~raj) -- Wed Oct 29 13:44:28 2003
Mike, I wrote an example remote spreadsheet application somewhat like your example in 1995 using Java and CORBA (which is a long way from dead - see http://www.adtmag.com/article.asp?id=8137 and http://www.corba.org/success.htm). Back then, Java/CORBA already did what MS is trying to do with Avalon and Indigo. Since then, Java has added lots of easy GUI components. The OMG has added a lot of functionality and APIs, including the Model Driven Architecture. Microsoft is re-inventing the wheel and doesn't even realize the complexity of their task. The OMG already has specifications (which means at least one working implementation) for things like on-the-fly software upgrades, how to handle moving wireless clients, and a host of other subjects. I just spent some time reading some of the documentation you point to on MSDN and I'm not impressed. Most of it seems like fluff without any basis. There seems to be a lot of "A uses B uses D uses A" circularity in the descriptions which begs the question "Which thing in this chain actually works?". They haven't even started to think about the issues that CORBA worked out ages ago. The Java/ORB model is far more interoperable both in terms of platform and languages than .NET and the Avalon/Indigo duo. What's more, it doesn't require learning a version of C so mangled it's like learning a new language. I will admit there's no equivalent of Visual Basic in the Java/ORB world but since VB has never been useful for real, high-volume applications that is no loss. Some folks argue that CORBA and Java are expensive and difficult to implement, but I've not found that to be true. Between the Java security model and CORBASec, the duo of Java/ORB beats heck out of .NET's insecurity model. For god's sake, Microsoft is stuffing and rerunning Authenticode and expecting applications to 'fess up when they aren't secure.
Ray Parks -- Fri Oct 31 19:33:32 2003