Wondering about LC and HTML5

[Terry Vogelaar]

Hi Chipp,

This sheds some other light upon this topic. I think the reason why it is such a torture to work with HTML5 is the lack of a good RAD tool. The guy who figures out how to do that, is a soon to be rich guy. A development environment with the ease of use LiveCode offers, that makes behind the curtains all it's HTML and CSS and PHP and JS that just works, so there is almost no temptation to take a look under the hood, is the dream of a few million web developers, including me. Sounds a whole lot better than what I currently need to do to make a web page, which mainly involves inspecting elements in Safari a few 100 times.

Michael Kann wrote that Livecoders will never be able to compete with the people writing and maintaining the popular javascript libraries. I kind of agree, except that they lack ease of use. It really is a pain to learn how to use jQuery etc.

I thought you meant HTML5 as one of the distributions to export a stack to. That is not going to happen. But if you mean a Rapid Application Development tool to make Rich Internet Applications, with the ease of use and the stability LC offers, I'm cheering. 

Terry

Op 21 jun. 2011, om 18:28 heeft use-livecode-request at lists.runrev.com het volgende geschreven:

> 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.