Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

 > As for web app vs native app, @Richard Gaskin  You *can*, obviously,
 > build a "web app" (html5+js+css) and  package it in the app and run
 > it off line. another lad here on our team builds in ionic/React
 > /Angular. But his app is "native" to the phone, appears in stores.

Yes, OS-native apps can be made in many languages, including scripting 
languages like LiveCode and JavaScript.

My explorations here are less about the programming languages one might 
use to make them and more about the delivered result, whether the app is 
its own executable or lives within a web browser executable.


 > In your quest for understanding,  does your idea of "web app" cover
 > this? or are *only* think "delivered runtime from web servers."

More specifically, the distinction is that the app is delivered within a 
browser, since even OS-native apps can have most of their UI and code 
downloaded from a server just like web apps do.


 > At any rate, I would re-iterate Jonathan's earlier sentiment, that,
 > unless you are a super JS expert, once you get past the presentation
 > layer, doing a lot of work that requires manipulation of data, more
 > complex framework integration of many elements, Livecode would put
 > you far ahead in terms of productivity and transparency.
 >
 > And even if you *could* you could actually do all that with JS, it
 > would be such a horrible snake pit that you and only you could
 > possibly maintain it, scale it or refactor it.
 >
 > Hence oft-repeated prayer that we get the browser "widget" to become
 > a true member of the LC message hierarchy, they we can leverage the
 > web apps eye candy layer (easy to build, responsive, CSS is already
 > done for us…) with LC powerful framework, so that we don't have to
 > waste time using JS to get work done, but use it just for "clicking
 > here and there" while LC does the heavy lifting in the background.

If the web client technology stack (JavaScript/HTML/DOM/CSS) is a "snake 
pit", do we really want to increase dependency on snakes in LiveCode?

If I want an asynchronous progress indicator like a spinning wheel, 
should it be necessary to include and embed an entire other web 
application process just to get that?  Is that the story we want to tell 
new users?  I'd much rather have an async playback option for the LC 
engine's handling of GIFs, which already covers the other 95% of what we 
need very well.

Same for broader use-cases, like smooth transition effects of the sort 
CSS3 now does so well.  Those are also now so pervasively expected by 
users that it benefits the LC platform more to have as much of that as 
practical right in the engine, rather than limited to one specific 
widget that requires us to leave LiveCode and program it in JavaScript.

A sense of smooth liquid flow is the hallmark of modern UI.  If support 
for this were limited to one widget that requires JavaScript, we might 
as well use the other tools you mentioned above.

Fortunately it seems some of the work needed for the DG update will help 
with some of this.

Related, Jacque's request for swipe transitions was well received, but 
oddly its status was changed to "Hibernated":
http://quality.livecode.com/show_bug.cgi?id=20141

I hope that's only momentary.  Swipe transitions are no longer merely 
optional for mobile UIs, and the level of effort required to work around 
that with groups diminishes many of the advantages of choosing LiveCode, 
lowering LC's score when potential new users do a comparative 
evaluations of tools. I may be a dreamer, but I'd like to see LC match 
or exceed capabilities in such comparisons.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com