Archives

So what are the big boys doing? Are they using Dojo, Prototype, etc.? After another disappointing stroll through the top 100 sites (a few more uses of Scriptaculous, yawn), I discovered that Monster.com is in Beta with a spiffy new OpenLaszlo Job Search app. Unfortunately it uses Flash, not the new Ajax runtime, but I’m guessing they started development well before the release of 4.0. I’d be curious to know if they are considering a flashless version for the future.

Technorati : ajax, flash, monster.com, openlaszlo

It’s already been reported elsewhere, but Adobe has just contributed source code for their AVM2 — basically a virtual machine for executing ECMAScript — to the Mozilla Foundation. The project is code named Tamarin, and there are already a number of misconceptions about it. First, it is not an open sourcing of Flash. Rather, it is just the piece that executes the Javascript. Firefox already has a piece that does this, code named SpiderMonkey. The idea is that Firefox and the other Mozilla products that make use of SpiderMonkey will have the goodness of Tamarin swapped or folded in. (See Brendan Eich’s post on Tamarin for more details.)

Why is this good news? Well, having the Mozilla and Adobe folks collaborate on a core technology frees them up for doing other, more interesting work. Also, sharing an implementation between two big players strengthens the standard. And let’s not forget that that there are lots of cool features in the AVM2 (Actionscript Virtual Machine). SpiderMonkey is an interpreter of Javascript. Tamarin compiles to byte code for a virtual machine which can then take advantage of Just in time compilation (JIT) ala the JVM. The performance of Javascript in Firefox 3 (I hope) will blow the doors off of the current version. Hopefully the improvements will also find their way into Rhino, the Java version of SpiderMonkey (or is SpiderMonkey the C version of Rhino?).

Technorati : actionscript, adobe, ajax, javascript

Jim Grandy, the director of OpenLaszlo from Laszlo Systems, took the time to respond to my post from yesterday on the criticisms of OpenLaszlo from Flash/Flex developers. He also took me to task for publishing claims about failed OpenLaszlo projects:

I think you did yourself a disservice by picking an inflammatory and attention-seeking title and then posting anonymous allegations. Frankly, I could come up with any number of “failed project” anecdotes about every significant technology I have ever worked with, so it’s not that impressive or useful to make a claim like this. How many times did folks fail to deploy Flex-based apps? How many Flex2-based apps have been abandoned? Why would you call in a Flash developer to rescue an OL project? Were those rescue missions successful?

I will take his criticisms to heart. No matter whether I trust my contacts, a claim that cannot be verified and critiqued by either myself or the reader is not worth publishing. Here then are Jim’s comments.

Hey Dietrich,

If you’d like to talk to some *OpenLaszlo* developers, drop me a line and I’d be glad to get you in touch. Flash development is really a very different beast than OpenLaszlo development, and in my experience not too many people are fully informed with both, so you might want to collect some OpenLaszlo data points so your comments are more interpolation than extrapolation.

One factual correction:

+ OpenLaszlo’s scripting language is ECMAScript Edition 3, aka JavaScript 1.5, aka JScript 5.6. It’s correct that there are (minor) differences between ActionScript and OpenLaszlo’s scripting language, but in my opinion ActionScript is the outlier — you can port DHTML/Ajax code libraries to OpenLaszlo much more easily than to Flash.

And some responses:

It’s arguably a good thing that OL is a version behind Flash. First of all, high market penetration of new Flash players is not immediate, and we try to have OL releases available before penetration tops 80%, which is where most Internet (not intranet/kiosk) project cycles are initiated.

And second, OpenLaszlo is compatible with Flash 6, 7, 8, and (in emulation) 9. Flex 2 is only compatible with Flash 9 native. If you want to develop in Flex against the 95% penetration player, Flash8, you have to use Flex 1; Flex 2 only works in Flash 9 native. So developers with previous investment in Flex 1 apps need costly retooling to run in Flash 9 native, whereas OpenLaszlo’s cross-runtime architecture means you will be able to run the same app across multiple current *and future* runtimes as they are supported. As a datapoint, we brought our Calendar demo, a 3700 line app, into DHTML by changing fewer than 1% of the code.

In fact, the “Flash is proprietary” argument is one of the big reasons OpenLaszlo is expanding to include DHTML and JME runtimes. Would you want to deploy a multi-million dollar app against Flex 2 when Adobe’s strategic interests for the Flash platform may not be in alignment with your own over the long term? With OpenLaszlo, not only are we not aligned with Adobe, we’re not captive to Adobe either — and since the project is open source, you don’t have to be in alignment with us either.

Furthermore, if you’ve seen our Calendar demo running in DHTML in FireFox 1.5, you’ll know that there’s no Flash monopoly on clean, animation-rich user interfaces — DHTML is as capable a Flash in that regard. So the “Flash advantage” may not be so much after all. (I should say we are enthusiastic about being hosted on Flash 9 native — it appears to be significantly faster then Flash 8 or 9 in emulation mode.)

And finally, with regard to your unsubstantiated claims of “failed projects”, all I’ll say is that there’s a word for this rhetorical technique in usenet: it’s called being a “troll”. I almost didn’t reply to this posting because I didn’t want to give you more traffic, but we’re a small company and don’t have the PR reach of Adobe so we have to be clear about our advantages whenever we can.

Technorati : ajax, flash, openlaszlo

Yesterday was the good, tomorrow will be the good again, and in general I will have more good things to say about OpenLaszlo than bad, but today I have some bad things to say nonetheless, from my conversations with some Flash developers. I’ve picked an appropriately inflamatory title to go with it, but before you leave flame comments, understand the origins of the title (see below).

I picked the brains of a number of full time Flash developers of my acquaintance, so — from my notes — they had the following things to say about OpenLaszlo:

• When Flex was $20K per processor, there was a cost justification.
• Now that Flex is free, there is much less reason – and if you can use Eclipse, you don’t need to buy flexbuilder.
• If folks already know actionscript, they don’t need to learn a new scripting language.
• In their experience, development in Flex is twice as fast as in Lazlo – built by a more robust, experienced software firm.
• Also moving data around in Lazlo – some issues, and internationalization is squirly at best.
• Likely always a version behind in flash support. If you were investing over five years, you should be wary, because Adobe owns flash, no standards board, etc., so they can do whatever they want with it.
• They all had horror stories of coming in on troubled projects where OpenLaszlo was used and they had a great deal of difficulty saving the application.

That last point has me a little worried. I didn’t get a consistent answer as to why these projects were troubled or which version of OpenLaszlo was used. It could be they were all just Flex biggots and didn’t like how OpenLaszlo worked. It could also be that the professionalism of OpenLaszlo developers was not that high back then.

Does anyone else have project experience with OpenLaszlo that they would like to share?

—

Back in March of 1968, the great Computer Scientist Edsger W. Dijkstra published his now classic essay “Go To Statement Considered Harmful.” His well thought out argument, on why the Go To Statement made it hard to undestand and support programs, has made it to the top of the list of best practices in software development — don’t use gotos. His contentious title caught the interest of computer scientists and made them read it in the first place. So take the title as the tongue in cheek, discusion inspiring reference it is meant to be.

Technorati : ajax, flash, openlaszlo

I hope to have a number of things to say about OpenLaszlo this week, both good and bad. First, let me say that when I first experimented with OpenLaszlo, it struck me as nice presentation layer scaffolding for a more substantial server-side framework. I didn’t expect that framework to be Ruby on Rails, however. Nonetheless, in my travels around the web I came accross ROpenLaszlo and the OpenLaszlo Rails Plugin. From the ROpenLaszlo web site:

ROpenLaszo is a Ruby interface to the OpenLaszlo compiler. It allows you to compile OpenLaszlo programs from within Ruby, in order to integrate OpenLaszlo development into Rake or Rails applications.

Combine it with the Rails Plugin:

The OpenLaszlo Rails plugin makes it easy to use OpenLaszlo client-side applications with Rails. It includes generators and scaffolding for creating OpenLaszlo applications, connecting them to Rails REST controllers, and displaying them within Rails views.

and you can generate interfaces on the fly and hook them up with a REST-based RoR backend. Throw in the fact that Laszlo will do DHTML before too long, and you can see the possibilities. Some rough edges on all of these tools, but other framework designers should take a lesson on how to integrate OpenLazlo as a presentation layer.

Technorati : ajax, flash, openlaszlo, ror, ruby

I feel a little sorry for all of those guys who come up with their own elegant solution to a problem only to have technology or standards make their work irrelevant. I had my own little IFrame-based library that I was proud of and that allowed me to build RIA webapps with wild abandon. I haven’t used that library in quite some time, it having been surpassed in quality and expressive power by any number of Ajax frameworks. Altogether, I am a little sad that it’s been consigned to the bitbucket of history.

I get a little bit of that same feeling regard FJax, a Javascript Flash integration that simplifies some of the cross-browser XML and Ajax operations. (See the Webmonkey Interview with its creators).

Fjax is a simple technique that hacks through all of the complicated code often associated with this type of development by encapsulating the XML handling into a tiny Flash engine that stays behind the scenes and just shuttles data between the server and the browser window. Working in Fjax is simple, and developers can customize and extend the technique with little effort by writing their own Flash engine to suit their needs

I did say just a little bit of that feeling, mostly from the uninspiring demos on the site that might have been cook 18 months ago. Because of the cross-browser problems that it solves, however, FJax is still interesting, though probably as a transport and XML processing component for a larger Ajax framework.

Technorati : ajax, flash

Apollo was announced by Adobe back in March of 2006. What is Apollo? From the Adobe Apollo official FAQ:

Apollo is the code name for a cross-operating system runtime being developed by Adobe that allows developers to leverage their existing web development skills (Flash, Flex, HTML, JavaScript, Ajax) to build and deploy Rich Internet Applications (RIAs) to the desktop.

[snip]

While a number of more traditional desktop applications can be built and targeted at the Apollo runtime, Apollo is targeted at making it easy to develop and deploy Rich Internet Applications to the desktop.

So, Flash without the browser? Actually, its a little more than that. It’s supposed to have a full featured API that allows you to interact with the underlying OS (Windows XP and OS X at this point). It also appears that some fairly low level programming is possible:

Apollo 1.0 will not have built in support for communicating directly with databases. However, it will be possible to write Database drivers in ActionScript (leveraging binary or XML sockets), which would allow Apollo applications to communicate directly with a database (both local and remote).

It seems like this is the “browser without the browser” in a JVM like package that users install on their PC’s and Mac’s. Developers can distribute Apollo based apps much like Java applications are distributed today, depending on the presence of the previously installed runtime. The runtime is a natural continuation of the development of the flash platform, which started out in Flash 2 with simple commands and has evolved into a second generation byte code VM with JIT compilation. Apollo looks to extend that platform and allow a tighter integration between the HTML/Javascript part of the runtime and the technologies that keep the lights on at the Adobe headquarters in San Jose — Flash and PDF. No more need for a Flex/Javascript bridge.

What’s in the API? From a presentation by Adobe:

• Offline / Occasionally Connected
• Applications can run in background
• Network
• • HTTP
  • XML-RPC / SOAP / Rest based web services
  • Binary and XML sockets
• File I/O
• Local storage / Settings API
• Custom Chrome

Still a little nebulous, I know. I find the offline/occasionally connected support very intriguing, but right now its just a tease.

Apollo may well be successful where Flash has struggle to gain acceptance in the past. As Ajax drives acceptance of rich interaction web applications, it is helping Flash along. If Apollo is seen as a better or cleaner way of deploying Ajax applications, or even as just another viable target for existing Ajax frameworks, that should drive it’s adoption. Still, Ajax prompts me to ask lots of stupid questions: how is this different from client-server; why not just use Java/Swing; why run desktop style apps in a browser; what’s wrong with Flash?

There are a few open questions for Apollo. For example, ActionScript 3 eliminated eval(), i.e. you can no longer include dynamically generated ActionScript. Since some Ajax frameworks and techniques load Javascript at runtime (JSON, etc.), the lack of a ECMAScript eval() is going to be a problem. According to the above presentation, ActionScript and Javascript will coexist within the environment, so maybe there will be an eval() in the one but not the other.

Apollo is slated for prerelease in the second half of 2006 (any day now) so we’ll have an answer to some of our questions soon.

Technorati : adobe, apollo, flash, runtime

Yes, it’s Flash and not AJAX, but this Visio-like Flash application demonstrates two things:

1. As AJAX is driving acceptance of desktop-like functionality in the browser, Flash is also benefiting from that same changing mindset. The same decisionmakers who used to wrinkle their nose at the mention of Flash are now weighing it as a legitimate option for providing RIA’s in the browser.
2. The march of desktop applications to the browser continues. This app is good enough for 90% of the network diagrams people produce. Why do I need a $200+ piece of software for that? The answer? I don’t.

My suspicion is that we will end up seeing a melding between Flash and AJAX, where most Rich Interaction Web Applications (RIWA) end up using both technologies. We’re already seeing this happening in small increments, whether it’s the use of Flash for cross domain cummunication or wrapping the Flash sound object to play mp3′s in your AJAX app.

Perhaps the best know example of a melding of AJAX and Flash is Google Analytics (the former Urchin), where many of the graphs are rendered in Flash.

A number of readers have noted that XMLHttpRequest can only communicate back to the same host that served up a page. This is true. We’ve all played around with XMLHttpRequest to see if we could make it break. Barring browser bugs, even with iframe and document.domain hacks there isn’t much you can do. You can use the super twin powers of Flash to do cross domain scripting in some cases, but even that has its limitations. So we’re safe, right?

As I pointed out last week, sites that allow for the persistence of executable artifacts — Javascript scripts and Flash files — can provide a leading wedge for AJAX worms and viruses. Many of these same sites have various forms of messaging, such as email. If you can push the buttons on these apps, you don’t have to make cross domain XHR calls at all. So, is an application like Yahoo or Google mail “scriptable” enough to allow this sort of subversion?

I know that reading through code like this

may make you feel confident that no one could decipher the inner workings of Gmail, but remember the old cracker war cry: “Security through obscurity is no security at all.” What man has compiled, man will also decompile — the Google Web Toolkit will give up its secrets.

With this in mind, I would be much more at ease if all of the various google applications I use — maps.google.com, spreadsheets.google.com, mail.google.com, and the various apps under www.google.com — didn’t all have single sign-on and the same google.com domain. It makes for a better experience, to be sure, but I’m pretty certain I don’t want someone mailing my spreadsheets to a compromised mailbox.

In the olden days, a popup browser window that started behaving strangely was a dead giveaway that foul play was involved. These days there is no window or status bar message and email may be going out in your name that you don’t even know about.

Over at Simple Thoughts, they disect a Flash/AJAX worm that has been laying waste to MySpace.

The unnamed worm isn’t malicious but the Shockwave Flash (.swf) file containing the payload embeds JavaScript into the profile of any MySpace user who views the .swf file. This can easily replicate Samy is my friend worm without breaking a sweat.

This javascript code would then be interpreted by any user who visited the site, allowing sensitive data to be stolen, such as a hash value required to carry out operations as a user, and performing operations on behalf of that users (without consent obviously). Currently, that access is being used only to spread the JavaScript code to other profiles on the popular social network site.

They go on to describe how this worm, if malicious, could be used to compromise MySpace security and a user’s Office applications. Defanged (commented) Javascript is included.

It’s fair to say that this is just the beginning of these worms/viruses. The fundamental security situation in the browser hasn’t really changed — the same sort of mischief that could be done in 2004 or 2002 can be done today. So what has changed? At least three things as I see it.

1. Web 2.0 sites now persist Javascript and other executable online artifacts. We all know that a Word or Excel file from a buddy must be treated with caution. We have no such expectations when it comes to their MySpace profiles or plain text emails. It’s this persistence of executable artifacts that turns a malware into a worm, flowing from one user to another with Web 2.0 haste.
2. Our guard is down. If in 1989 anyone outside of a University campus had found a piece of software contacting all manner of remote computers and transfering data, they would have shut it down immediately. Now we don’t even blink when our browser secretly accesses other web sites via XMLHttpRequest. How to identify malicious activity when it doesn’t look all that different from normal AJAX activity? That’s sort of like the old Mac virus detection tools complaining about a compiler because it tried to modify a resource fork of a file. It’s about context.
3. Although Flash, XMLHttpRequest, browser extensions and rich Web 2.0 apps haven’t really changed the basic security picture for browsers, in combination they can lead to unforseen vulnerabilities. This latest worm simply demonstrates how inching the security door open in Flash and Web 2.0 at the same time can lead to trouble. When you design webapps for security, don’t assume a pristine client environment. Assume the worst and design accordingly.

I don’t have any solutions to these problems other than “don’t use flash or AJAX.” I’d be interested to hear your thoughts on this topic. Comment away.