Wondering about LC and HTML5

[Chipp Walters]

Terry,

Thank you for your thoughtful reply. A couple of thoughts crossed my mind
while reading it.

Years ago, in a former life, I used to attend various CEO conferences. At
one of them, I had a chance to visit with Eric Schmidt, now of Google, but
then he was with Sun. We got to talking about Java, the topic of the day. My
comment to him was, as a multimedia company, we had evaluated Java and
determined it was too slow and too abstracted to do any meaningful
development with. He remarked, yes, he already knew this. But more important
than the reality of what Java currently was, is the expectation and
perception of what it will be. His point to me was the perception is more
important the the nuts and bolts of reality.

I think the same is true for HTML5.

When a client says they want an HTML5 application, most don't really know
what it is they want, nor do they know the trade-offs which may be necessary
to provide a lowest common denominator application. But they do know they
need it to run on the web, and on browsers connected to iPads and Androids
and Macs and PCs. As a strategy component for the client, and even more
importantly for us developers, we MUST have a RAD tool for HTML5 apps-- or
if not HTML5, then AJAXy "look like application and not websites" apps. Most
clients don't know the difference. If we don't heed this, my guess is we
will run out of clients and projects as they end up moving to the web or
isolated platforms.

The other key point is perhaps a lesson learned from Jerry and Sarah. Here
in Austin, I see Jerry often. In fact I'm having lunch with him tomorrow.
One thing Jerry always understood when he developed applications, is to
start simple. His RodeoApps did just that. I'm saying we do the same. Start
by creating a card and a button with a home icon...and go from there.

That said, RodeoApps is not what I'm talking about. I'm not talking about a
subscription based model where all code lives on a server. HTML5 allows for
caching. I actually suggesting the opposite approach, where you start on the
client and load an HTML5 app there and do simple things. Just like Rev.
Early on, it only did simple things-- even now you can't code Photoshop or
MS Word in it. I'm thinking the same with an HTML5 plugin approach.

I get it there will be some hurdles, and one of them will have to be a
compile (translate) first approach-- not unlike many other IDE's including
our own LC iOS plugin. Still, the time is now, not AFTER all HTML5 problems
are worked out-- or pushed out to HTML6. Sorta like the guy who never bought
a TV because he was waiting for the new and better one to come out in just a
few months.

Just my 2 cents.