Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham]

Hi Hermann,

First of all please don't take any offence at my email as none was 
intended.

I was mainly trying to explain that whilst there are many things the 
HTML5 engine does not do, which means many stacks will not work without 
changes/workarounds (indeed, somewhat significant ones) - there are 
increasing numbers of those which do work and this is set to continue 
and expand as we have more time to spend on the 'surface' features as 
opposed to the core.

On 2017-07-28 22:22, hh via use-livecode wrote:
> Probably the "one" (=checking if the mouse is "down") pledged and 
> bought a HTML5
> license, the "at least other 2" (=never using it) didn't pledge nor
> buy a license.

To be honest, this really is probably not true.

The thing is that 'the mouse' has long reported the event-asynchronous 
mouse state, which is almost never what you actually want on modern 
purely event-driven OSes - so over time its use has diminished as if you 
use it to do certain things (not all - admittedly), you will end up 
noticing 'interaction faults' which can be fixed by tracking mouseDown / 
mouseUp using the event loop. Also, it is generally used alongside 
'wait' - which of course does not currently work.

Obviously you do use it, as do others, so it isn't that it is not 
important, just that there are lots of other things that we have been 
working on in the HTML5 engine first which *are* used much more widely.

It isn't actually possible to get the async mouse state on HTML5, so it 
will not be 100% the same (although to be fair, the approximation we can 
use there is probably more correct anyway). It is just a matter of time 
before we get it to work, not if.

> I reported to quality center in Dec 2015/Jan 2016, that the state of 
> the mouse
> and modifier keys aren't recognized and that all menu buttons crash
> the standalone.

Similarly, the modifierKeys. Text entry and keyboard states for the 
LiveCode engine in HTML5 is another what is a seemingly 'simple' thing 
from the outside, but is actually not that simple at all under the hood.

We are still working on solving some issues with text entry - we will 
solve the problem in time, but again as with other facets of this 
endeavour some things are taking a lot longer than we had originally 
anticipated.

> Since the start of this *395 thousand dollars* project in July 2014 I 
> made at
> about 60 "successful tests" to show 'oh the HTML5 engine does this' and
> 'oh it does that'. This wasn't easy at all, needed a _lot_ of 
> workarounds ...

You've mentioned the amount of money raised several times; however, one 
thing which everyone has to appreciate is that every project we have 
crowd-funded has had the value raised matched at least by a factor of 2 
from other sources (in some cases significantly more). My point here is 
not to undervalue the contribution that a good number of you have made, 
but to illustrate that the scale of the projects we have crowd-funded 
have been significantly larger than the dollar value we went out to the 
community to raise would suggest.

Indeed, we have already spent far in excess of $400k on the HTML5 
project when taking into account all work that we have undertake to do 
it (it isn't just each line of code which is written, but also 
infrastructure, maintenance, systems and a huge variety of other factors 
almost all entirely not user/publicly visible).

There is no problem here (I assure you) - we expected it - we knew it 
was going to be a large, difficult project. However it is one which was, 
is, and remains a vital project to finish for our ecosystem as a whole 
and finish it will shall.

> So I'll better stop now and wait for the suitable percentage of 
> 'unchanged'
> LiveCode demos (although "wait" is not allowed in HTML5 deployment).

I would hope that you will continue to do as you have been - because it 
has been great to see many of the things you have achieved with the 
HTML5 engine despite its various obvious omissions in functionality. It 
also helps us, the engineering team, to see visible progress by users on 
a project which is large, long and complex (and somewhat frustrating at 
times!) - particularly when much of the work we are doing, and have been 
doing is entirely non-user visible!

> What the team made in HTML deployment until now is *very* good, 
> especially the
> "do as javascript" part is excellent. Just put more of the funds (and 
> by that
> 'bandwidth') into it, so that also basic things (e.g. typing UTF-8 into 
> a field)
> do work.

Getting two way communication working in the HTML5 engine has been a 
significant step forward. Particularly as it means we can now do the 
absolute minimum in JavaScript and much more in LiveCode Script (what's 
the point of engineering a language, if one does not use it oneself, 
after all!).

Indeed, I envisage a good deal of the engine functionality we need to 
still implement relative to JavaScript should start being able to be 
done in LiveCode Script - the networking stuff Michael has been working 
on, is an implementation of libUrl in LiveCode Script and uses the 
JavaScript interoperation features we have to provide its services.

> p.s. HTML5 standalones can talk to each other, several of them, in one 
> browser
> window. I just successfully tested that --- and trashed the demo.

This sounds very interesting in-and-of itself (perhaps not the trashing 
part - please file a bug report if you can / have time to isolate the 
issue!).

Warmest Regards,

Mark.

P.S. At some point I'll write at length about the 'wait' problem in 
HTML5. Whilst I try not to let myself be kept awake at night by 
engineering problems related to work - if ever there was one which did, 
it would be that one!

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps