The Old Joel on Software Forum: Part 4 (of 5) - Flash: the new client platform? Why / why not?

Flash: the new client platform? Why / why not?

I've been investigating Flash and Flex a lot in the last month or so, and I have to say I'm imipressed. The latest version of the Flash IDE (2004 MX Pro) can be configured to be used in a way very similar to visual basic (i.e. without any "animation" constructs like player head, timelines, layers, etc). XML parsing, web services, and integration with RDBMS systems are built in. And Actionscript 2 is completely object oriented, with intuitive (i.e. very similar to java) support for inheritance, interfaces, polymorphism, yada yada yada. And a standard collection of very plain, normal-looking UI widgets now ship with the product (as opposed to the "flash trash" so often pushed by designer types).

In terms of market penetration, Flash player 6 is at 92%, which is pretty good.
http://www.macromedia.com/software/player_census/flashplayer/version_penetration.html

There are still problems, of course. The largest one I can think of is that flash code is persisted as a ".fla" file, a proprietary binary format. Even if you externalize your actionscript code to text ".as" files, this still leaves a substantial amount of your work (i.e. all the graphical layout work) in a binary format, which means you can't diff versions to see what has been changing in your source control system.

The Flash player also apparantly has a memory leak in the Web Services parsing code: http://www.flashorb.com/articles/soap_vs_flash_remoting_benchmark.shtml

What else is stopping flash from becoming the new platform for web UI?
* There doesn't seem to be a good actionscript 2 book out yet (oreilly book comes out next month and should solve that problem).
* Flash has the "designer" taint that makes developers not take it seriously.
*Macromedia hasn't done a very good marketing job: I've only discovered these capabilities because I've made an effort to find out about this stuff.

Any other reasons I've missed? What potential does flash have to do what java originally promised and failed to do (write once, run everywhere, distribute via the browser)?

mystified
Sunday, April 11, 2004

Flash has traditionally had a poor accessibility story, although I hear that they've tackled that with the latest version.

John Topley (www.johntopley.com)
Sunday, April 11, 2004

"Flash has traditionally had a poor accessibility story,"

Can you elaborate or give some examples of that?

Are you saying that it's got a poor history for supporting features for the vision impaired or hearing impaired.

Mr. Analogy
Sunday, April 11, 2004

It all comes down to Macromedia's marketing.

Most people probably equate Flash with gaudy web site intros, stupid web sites that they can't navigate without animations and sounds flying all over the place, and advertisements.

I haven't seen tons of ads or PR (write ups by journalists in major geek outlets) touting flash as a great programmer tool.

But maybe Macromedia is waiting until these new features are more mature (read: stable) before they dump a ton of money into marketing them.

...

Another thing that I think holds it back is developer mindshare about price and learning curve. You have to either buy the Flash Authoring Environment ($700) or the Flex server (just came out) for $12,000. You also have learn how to use the Flash product! Not everyone knows about the developer centric configuration. (I didn't think it was that great, it still has a Designer feel IMO, but I didn't use it for too long. Just played with it.)

.... I wish I could pick up all these new technologies in the palm of my hand and just slam them into my head. Learning through osmosis would be so much faster. I'm still learning JSP/J2EE/Java. And quite frankly I don't have time to learn the Flash stuff....

michael sica (michaelsica.com)
Sunday, April 11, 2004

Maybe I should have said, "lack of marketing".

michael sica (michaelsica.com)
Sunday, April 11, 2004

$12,000? Ill be darned.

Anyway, I think Macromedia have recognized that flash sites is a bad idea and are now trying to evolve the concept out of that area.
I think we will see more of the streaming media part of flash. Its the most widespread, lightweight streaming client after all.

Tell me, can you connect a flash app directly to a DB server?

Eric Debois
Sunday, April 11, 2004

Eric, I could be wrong. But I don't think the Flash player or the server side ActionScript can connect directly to a DB. You'd have to talk to objects on the server through Flash Remoting or Web Services. (As mentioned above the Flash player can consume Web Services.)

michael sica (michaelsica.com)
Sunday, April 11, 2004

Well, thats a kinda major drawback then if they are going for the VB market. As long as you are bound by HTTP statelessness you might as well use regular web stuff, and maybe spice it up with XUL or applets if you want to get that "it looks like a real app" thing going.

VBs strenght was (in my opinion) always the gui stuff, combined with painless ODBC connectivity.

Eric Debois
Sunday, April 11, 2004

<<Eric, I could be wrong. But I don't think the Flash player <<or the server side ActionScript can connect directly to a <<DB.
You are correct. Upon inspection, it seems to send XML documents with the queries. It doesn't actually connect to the database remotely. (google RDBMS resolver for the documentation)

>>Well, thats a kinda major drawback then if they are >>going for the VB market. As long as you are bound by >>HTTP statelessness you might as well use regular web >>stuff, and maybe spice it up with XUL or applets if you >>want to get that "it looks like a real app" thing going.
How are you bound by http statelessness? You can download all the data you need to run your application at application startup (the whole database, in xml, please!). Or you can go back to the server every time the user does anything. Or, you can take the middle path, and connect to the server when it is appropriate for your application.

The fact that http (a stateless protocol) is the way you connect to the database seems pretty irrelevent to me: it's just a communication protocol.

mystified
Sunday, April 11, 2004

"Are you saying that it's got a poor history for supporting features for the vision impaired or hearing impaired."

Yes, exactly that.

John Topley (www.johntopley.com)
Sunday, April 11, 2004

mystified >>

Well, Im no protcoll expert, but as far as I can tell it means that the server can not initiate a transfer to a client even thought they are "in session". So, in order to get live data the client needs to continually poll the server which can potentially create a serious bottleneck.
Also, can you lock data retreived for editing and stuff like that?

Eric Debois
Sunday, April 11, 2004

re: XUL, it doesn't work on IE, right (correct me if I'm wrong, I haven't worked with it)? If so it's a non-starter.

re: applets, the fact that swing is the slowest, crappiest UI toolkit ever (and that java is not ubiquitously installed on browsers, and is a big-ass download compared to flash) is the reason we're having this conversation. I'm a java bigot, but even I have given up on SUN ever solving these problems.

mystified
Sunday, April 11, 2004

http://www.metasphere.net/web_tools/18.html
Look Mom, no FCS. An interactive chat room built off of Flash XMLSockets and Perl. Server side perl script mimics Flash Communication Server to update all users of the shared event.

>>Also, can you lock data retreived for editing and stuff like that?
Good question. My impression is that one would have to implement that on the server, not in the flash client.

mystified
Sunday, April 11, 2004

Yes, well, thats kind of my point. You cant make a self contained flash app that operates directly against the DB server. I dont really know how VB is used in general, but back when I was still interested, vb apps were often made to work directly with the backend via ODBC. So, I figure that if they want to win over some of that crowd they will need that kind of functionality.

Eric Debois
Sunday, April 11, 2004

Flash will make an interesting example for a marketing course one day.

Macromedia wants to expand the market by turning it into a developer too, but Flash's designer background will always handicap it in that market.

Developer tools have to provide power and control to the developer, whereas designer tools treat the user as an idiot. Flash has not entirely escaped from that attitude.

.
Sunday, April 11, 2004

Dot

We agree that this will be a great case study.

I disagree with your statement that designer UIs "treat the user like an idiot". They're in fact pretty hard to use and far from idiot-proof. They're just oriented towards controlling the look rather than the behaviour of a system.

mystified
Sunday, April 11, 2004

Plain old HTML and a web server is still compelling for most web applications. The user has a much greater control over a normal web page than flash. The user can go backwards or forwards at will, they can bookmark pages, email links to friends, open different links in different tabs or pages, easy printing and previewing etc.

The other reason is that no search engine can index flash movies, so no one will be able to find them, unless they are embedded in a web page.

Matthew Lock
Sunday, April 11, 2004

>>Plain old HTML and a web server is still compelling for >>most web applications.

OK, Plain old HTML is fine for web _sites_. We're talking about web _applications_.

Whe you try to really do something via the web (e.g. filing your taxes) it's a royal pain, and that's because of the latency induced by going all the way back to the server and sending the UI back to the client every time the user does anything. It's impossible to get "flow", even with a fast internet connection because of that latency. It seems to me that you have to push _significant_ power onto the client to solve this problem, and your options are

1)dhtml (non-starter due to browser incompatability issues in my experience)
2)java (ugly, slow, big download)
3)the microsoft way (seems fine as long as you don't care about supporting alternate browsers)
4)flash (see issues that have been brought up on this thread).

I agree re: control issues: flash does make you feel like you're "trapped" in a way that you don't feel when you're looking at an html document (although apparantly there are clever ways to _not_ break the back button, it takes extra work and flash developers don't tend to use them).

mystified
Monday, April 12, 2004

Diffs for flash format... aren't there tools which convert certain flash binaries to descriptive XML text? I'd unit test it with converting to/from this format and ensure that convert-from(convert-to(x)) = x. I remember using such a tool once.

Tayssir John Gabbour
Monday, April 12, 2004

> Whe you try to really do something via the web (e.g. filing
> your taxes) it's a royal pain, and that's because of the
> latency induced by going all the way back to the server and
> sending the UI back to the client every time the user does
> anything. It's impossible to get "flow", even with a fast
> internet connection because of that latency. It seems to me
> that you have to push _significant_ power onto the client to
> solve this problem, and your options are

I think this latency problem is a red herring. If you file your taxes online you will be presented with a series of forms, wizzard style. Filling out a form online is no different in speed to filling on out in flash. The only difference is the time it takes when you press the submit button to move to the next form, which typically takes what? A second at most.

No one complains about that latency when buying a book from Amazon, or selling things on ebay.

Matthew Lock
Monday, April 12, 2004

At least HTML gives you a standard user interface. Why would you like to write something from scratch with no standard widgets? Sounds like a step backwards to me. It's not like any basic web platform has all the rdbms-connectors and buzzword compliance you want. (Then there's also the fat client approach -- flash is something in between giving you the drawbacks of both.)

Jonas B.
Monday, April 12, 2004

re:Jonas. Flash ships with a standard UI toolkit now ... normal (albiet a little "macintosh-looking" buttons, menu bars, tree views, etc).

re:Matthew. I guess we'll have to agree to disagree. I can think of several applications I've used on the web where latency drove me batty (I agree that for an ecommerce transaction, html works fine). For more complex tasks the latency definitely hurts. Maybe you just have a longer attention span than me. ;->

mystified
Monday, April 12, 2004

Flash UI components have are far from equivalent to HTML form objects. Performance and bugs have plaqued them since inception.

anon-y-mous cow-ard
Monday, April 12, 2004

"have plaqued them since inception"

Plaqued? Is this something that can be corrected with regular flossing?

... couldn't resist.

Mr. Analogy
Monday, April 12, 2004

I've been considering FLASH for a while now. Tried it briefly last night.

My concerns:

1. Code editor is (as far as I can tell) merely a text editor. Not intellsense or autocompletion. Why buy a $1,000 editor when I can use notepad?

2. Seems that you can't edit local text files.

Honestly, unless you need cross platform support, wouldn't Delphi be a better way to go? It's easier to write code (better IDE) and compiles nice small EXEs.

Limited to Windows and (using Kylix) Linux. But (for me) the Mac market is too small to be worth the effort. It's MAYBE 2% of our customers and I think it's getting smaller.

Mr. Analogy
Monday, April 12, 2004

Flash suffers being the product developed by the company the produces Director.

VB - Widgets - *Animation* - Desktop => Director

Java/HTML - Widgets - *GIF* - Web => Flash

The emphasis is (still?) on interactive animation. Of course, it is to be expected, no doubt. Therefore changing core language bases means either a completely new product or at least a very difficult to use product.

KayJay
Wednesday, April 14, 2004