Both Tiger users and Leopard users will be automatically getting Flash Player 9 Update 3 along with the latest Security Updates via Mac OS X’s Software Update.

Nice to get Flash Player updates this way, they have come this way before. This should happen for every release really.

Google’s new Android mobile platform chose Java for it’s application development language. But what’s lacking in developing a Java GUI app? Oh, but of course, something that Mozilla and Adobe have implemented already as part of their platforms, an XML based user interface language!

I made up the name of course, since I couldn’t find a name for it: AXUL.
The format looks a little like SWIXML without the Swing.

This reinforces the whole strategy of using a markup language to layout interfaces and custom widgets, taking advantage of a nice box layout mechanism. But one thing I don’t see is the ability to create new AXUL components by simply composing other AXUL components. (without a hosting Java class)

But why didn’t they choose HTML 5? Ha.

Just read the NYTimes write-up on Prism.

Interesting comments by Mark Finkle:

if the Web can’t do it, Prism can’t do it

and

We’re not asking Web apps to change at all.

So thats the big thing really. It’s an incremental nicety to classic web browsing. This is really not in competition to Adobe AIR at all.

It’s more in line with something like Mac OS X’s new Safari Web Clips. Yank an app out of the browser and run it by itself.

As a real-world example, imagine Google Analytics without browser chrome, and then look at the Google Analytics AIR app. Designing an experience more with the user in mind, than browser limitations. And this is using Open Internet protocols and APIs. Maybe that’s not as good as the Open Web though, not sure?

Wow, a lot of writing and discussion over Prism lately! And to think, all from a new name, logo, and a Labs post. (And I guess some weight from being an officially sanctioned experiment too.)

Of course, I’ll follow suit. Partly because I am interested in the technology, and partly because I am interested in how this relates to Adobe AIR, and Mozilla’s own technologies, like XUL. How is it integrated? How can some important features and functionality be integrated with HTML/JavaScript only?

I thought I would start by comparing the installation story with Adobe AIR. A lot has been made of how easy it is (or will be?) to make a web app into a desktop app. (A simple menu command from Firefox, and voila!) But that’s not the whole story. How does Prism get installed in the first place?

With Adobe AIR (which runs web apps as well on the desktop, built with HTML/CSS and JavaScript), there is a really cool installation story. You can create a special badge that a user can install your app (with permission of course) from a web page. The cool part though, is if they don’t have the Adobe AIR runtime, it will be installed auto-magically (with permission of course) along with your app! No need to direct them to a different website, instruct them to download something, then come back and get your app.

So how will Prism get installed? Sure, after it’s installed it’s somewhat smooth sailing. But getting software installed is a hurdle which should not be ignored. Adobe has excellent experience with this. Heck, installs of Firefox are dwarfed by Flash Player. So what’s Prism’s installation story?

I was waiting for this to happen. Didn’t think it would happen this soon though.
The very first Prism app built with Flex.

Speaks to the pervasiveness of the Flash Player, since in the first batch of Prism apps out of the gate, one is built with Flex. It also speaks to the flexibility and strength of the Prism idea, especially since it’s already wooing prime Adobe AIR candidates: Flex developers.

A Flex app as a Prism app?! This doesn’t fall in lock step with the shining goal of the “open web” as defined by some folks.

But, man wouldn’t that be cool if Mozilla had their own user interface markup language? Oh, wait they do, XUL. Does something like this, and that Mozilla doesn’t even mention XUL with Prism mean that it’s pretty much lost the fight to Flex/MXML?

Daniel has posted his unpleasant surprise about eBay using Adobe AIR for their internet desktop application instead of XULRunner.

Here are two lists attempting to document the application landscapes with each technology:
Mozpad’s Mozilla App List
AIRApps Adobe AIR App List

I make use of XSLTProcessor quite a bit in XULRunner, so I was hoping to see this happen. Looks like Mike Chambers spilled the beans in the comment thread on this post. (Thanks Mike!)

Dave Johnson had been chafing over this too.

BTW, here is info on the different XSLT engines used in Mozilla and WebKit browsers:
Mozilla: TransforMiiX
WebKit: libxslt

I’ve been trying my best to try and figure out the current landscape of technology offerings for RIA and IDA development. So forgive me for this rant-ish post, and correct me or help me where I’m just dead wrong.

I believe in choosing the right technology for a project’s or product’s requirements. Some of the projects I work on are obviously web applications, so I target the browser and either use HTML/JavaScript for simple interfaces, or Flex/ActionScript for advanced interfaces or rich media integration.

But we’ve frequently found ourselves in the position of needing to create relatively light-weight desktop applications with advanced UI requirements, that can easily work with web technologies.

Building these IDAs with client technologies like Flash/Flex/XUL/ECMAScript has been awesome in developing fast and good, and not having to code Swing layouts. This idea has pretty much been hackish at best in the past until XULRunner came along. But now AIR is here, and I’m trying to evaluate both. So this is the type of target I’m referring to with this post, Internet Desktop Applications with advanced interface requirements.

This post and chat transcript posted by Matt of AllPeers really kind of set off some alarm bells. Not gonna summarize it, so you may have to read it. But I’m replying to some thoughts presented in it.

HTML? Hyper-text Markup Language: Formatting text documents.

XUL? XML User Interface Language: Creating user interfaces

Merge XUL into HTML, gradually over time? Why? Use the best tool for the job! Leave HTML for what it does best, for documents. And talking about some future idea that may be cool (or the worst thing ever done), is not NOW. There are excellent tools and technologies available NOW that do these things (Flex, ActionScript 3, AIR)

What is WebRunner’s or Firefox 3’s interface developed in? XUL, not HTML. Maybe once we see Firefox shipping with an all HTML interface then I’ll be able to see HTML as some sort of capable user interface language.

If Mozilla’s own evangelists are encouraging HTML over XUL, then it would be downright foolish to champion it, and makes me uneasy choosing it to develop with.

So who is putting their weight behind a modern, advanced, rich, and internet friendly programming language and user interface markup language? Adobe, with Flex and ActionScript 3.

In more than one spot I have seen this evangelism of using HTML over XUL for developing rich applications, and wonder what is at it’s core. Maybe it is because the Mozilla Foundation/Corporation is unsure of the future API or compatibility and stability of using XUL and its companions. And they figure HTML is the safe way to go for the “masses”.

Again, who has the awesome history of distributing a runtime far and fast, proven backwards compatibility in a runtime, and is at the same time making great advancements with innovation for rich media, RIA, and internet desktop application developers? Adobe. With the Flash Player, and no doubt soon to come AIR.

I’m trying my best to find something to keep me hackin’ on XUL and JavaScript, but I keep seeing these confusing mixed signals as to the future of a capable RIA/IDA platform or runtime using Mozilla technologies. (Or no signals at all)

Don’t get me wrong, I love working with XUL, JavaScript, and XULRunner, and I have a number of projects using the technology. So I’ll be continuing to develop with it. But for new and future projects I’m gonna have give it some serious thought.

There are a couple great posts spawned by a post by Simon Morris on java.net. He talks about three flavors of RIA “religions”, Browserism, Neo-Desktopism, and Pragmatic Neo-Desktopism.

Shaking the gratuitous buzzwords and fictional religious names off, I think there is a lot of relevant material here for Mozpad.

Caught all this by way of Ryan’s post. Ryan makes an excellent point:

The browser is not going to replace desktop applications, it just won’t happen. So instead of focusing so much energy on trying to pull that off, the “Browserists” should engage with the “Neo-Desktopists” and come up with a very web-centric solution for deploying desktop applications.

This idea is what was behind my idea to merge the deployment, distribution, and update mechanisms that exist with Firefox Add-Ons, with XULRunner apps.

So is Mozilla a Browserist, and Mozpad a Neo-Desktopist? You decide, here are the definitions:

Browserism is the belief that the web browser (or comparable page-centric markup-orientated HTTP-bound middleware platform) is the future of end user facing software; a belief solely based on observation that the web is currently the predominant tool for accessing the internet. The goal of Browserism is to slowly evolve a common web platform to include the functionality traditional desktop applications have supported since the rise of the Micro Computer in the early Eighties. Browserists get very excited by user interfaces approximating desktop applications circa 1984 (”wow, you can drag the map!”) or functionality which reminds them of a Commodore 64 (”gee whiz, I can save data onto the computer’s disk itself!”)

Neo-Desktopism is the belief that the web browser as an end user facing application platform is ultimately an evolutionary cul-de-sac. The goal of Neo-Desktopism is to evolve traditional desktop application technologies (for Java, this would be Swing and AWT primarily, although also includes the JRE itself) to a point where they can float free of a physical local client installation, deploying on demand just like web pages. Neo-Desktopities get very excited when their Java WebStart applications actually start on a friend’s laptop first time, without having to spend ten minutes fiddling with their Java installation while gawking at an impossibly long stack trace.

Pragmatic Neo-Desktopism is the belief that the web browser as an end user facing application platform is ultimately an evolutionary cul-de-sac, but we’d all get fired if we admitted that to our bosses. Pragmatic Neo-Desktopities desperately want to write proper Neo-Dekstop software, but are conscious of the fact that the fashion amongst Dilbert-esque managers is for all software to launch from a URL. So they simply embed heavyweight technologies inside a web page, which, while acting totally without sympathy to the host environment, at least keeps the Dilbert-esque managers happy.

Interesting to see reactions from Adobe and Mozilla to the Google Gears project.

Even though both companies have a platform that has been working on similar functionality, Adobe has welcomed it with open arms by announcing work to align APIs, while Mozilla is keeping it at arms length.

Also, I wonder if all those anti-plug-in purists that hate the Flash Player will take on a double-standard and adopt the Gears plug-in.