Replace LiveCode Script with JavaScript, forever

[FourthWorld]

I just happened to have been on my bank's website at the moment I was reading this. They're one of the biggest banks in the world. I told them two years ago their banking application doesn't work on Safari on OSX. Two years later and it still doesn't work. And I'm on a different version of OSX with a different version of Safari, so that's multiple versions where it doesn't work.

Obviously that huge international bank made the decision that Safari/OSX isn't worth the engineering effort.

Is the issue with the site or Safari?

The web is standards-based. Code written for the standards that works in one browser should work in all.

There was a surprisingly long period in which Safari on iOS didn't handle iframe tags. iframe. Been around for years. Many sites depend on it. Millions. None of them rendered on an iPad or iPhone.

Maybe Apple has the clout to unilaterally declare global standards obsolete. But not in this case: though a good many of us were forced to undertake the expense to replace those with divs filled via XHR, eventually Apple got around to supporting that widely-used part of the HTML standard.

In your case with your bank, until we learn the details it's not possible to know whether the underlying issue is a lack of standards-compliance from the bank's web devs or Apple's Safari team.

But whenever we encounter code that works in all contexts but one, we can't rule out the context as the source of the issue without further investigation.

And even if it turns out your bank has sloppy devs, as long as there are millions of examples of web apps that work wonderfully in Safari I'm unclear what case can be made that the issue is somehow the tech and not the team misusing it.

[richmond62]

sloppy devs

This seems to be a universal problem, and it is probably unfair to blame LiveCode for
the short-comings of one's bank.

Recently I have had a problem trying to send SVG files through to a laser cutter from an 2006 iMac running macOS 10.6.8
and it turns out that, while the laser cutter is set up to recognise SVG files there is something in the firmware that checks
what OS is sending the signal, and if it is not Windows 8 or 10 it won't accept the signal.

So, for the sake of argument; it will accept my SVG file from Inkscape running on a Windows 8 box, while it will NOT
accept the same SVG file running from Inkscape running in a Mac box (even my one running macOS 12).

This nothing but sloppy devs: I flashed the laser cutter's firmware to reset it to factory default, and the thing worked: but the
people who had set the machine up in China before shipping it to Belgium for my next-door-neighbour to drive it out to the
Bulgarian mountains (Yes, I do live a mental life) screwed it up so badly for no reason than that they assumed that
eveyone uses Windows.

[Bernard]

And even if it turns out your bank has sloppy devs, as long as there are millions of examples of web apps that work wonderfully in Safari I'm unclear what case can be made that the issue is somehow the tech and not the team misusing it.

If the world wild web was standards-compliant an app that worked in one browser would work in another. I went to check what happens in Microsoft Edge. Same errors listed in the Javascript console as with Safari, but the banking app is still working on Edge. Checked with Firefox on OSX - same errors, but the app still works. Why do these browsers work if they are standards-compliant? Seems to me they ignore standards by working when the console is full of errors.

If the web is standards-based, can you point me to the tool produced by the standard committees which will show where a site has deviated from these standards? If this tool exists then the question becomes "why aren't global corporations using this tool to see where their web apps are broken"?

What is the standards-compliant rule for variable naming in Javascript? Try switching off Javascript and see how much of "the web" works. Even JSON is not really a standard (it's just most people don't notice that there are many parts of the spec which are ambiguous and therefore interpreted and implemented differently by different tools/platforms). The web is one massive hack. If the errors weren't hidden away in a Javascript console, most people would stop using the web when they saw all the errors flying by. Microsoft Edge raises Javascript errors on loading its default home page. Seems Microsoft developers can't even get their own Javascript right.

My point is that it is unreasonable to expect that a small team in Scotland to be able to easily produce a version of LC that runs as Javascript inside a browser, as evidenced by the failure of a major international bank to be able to have their own web app work in the default browser of a Mac. The world of browsers is full of inconsistencies. As the Microsoft Edge example proves.

Furthermore I had cause yesterday to contact this bank about a non-IT problem. Their response was to tell me to move to using their mobile app not a browser, as in future they plan to get rid of the browser access. So whilst people are expecting LC Ltd to produce LC that runs inside a browser, at least some global corporations are moving from web apps back to fat client apps. Try accessing Twitter.com through a browser without being logged in. It's clear they are going the route of Fakebook and limiting access. They are building the walls of their walled gardens ever higher. They want to control not only what people say but what people can see within the walled garden. And their best form of control is to get rid of browser access and make everyone use a fat client app. It seems likely that most users of Twitter and Fakebook are already accessing the content through fat clients, not browsers (I've seen reports that 98.5% of Fakebook users access the site on a mobile device). If I try to access imdb.com on a mobile browser, they make the site impossible to use without a hack, telling me to access it via their fat client app.

I'm looking forward to a day when LC will run acceptably as a web assembly deployment. But I don't expect it to work as well as a fat client. And I don't want LC Ltd to over-emphasize the resources they put into making it work. And I am one of those who paid extra to have them develop a HTML5 deployment.

[richmond62]

All this stuff about standards makes me think about USB connectors.

[FourthWorld]

I'm looking forward to a day when LC will run acceptably as a web assembly deployment. But I don't expect it to work as well as a fat client. And I don't want LC Ltd to over-emphasize the resources they put into making it work.

Bingo.

Maybe the key question we're not asking is:

Why do LC users have the expectation that a tool for making native apps is also a web page authoring tool?

We don't see XCode users demanding that, or those using Visual Studio, or Qt, or B4X, or...

If folks got the idea from Xojo, that "solution" is technically relatively easy to implement, but unscalable and rarely used (it's essentially a form of screen sharing).

It's not just that LC Script is so different from JavaScript. It's also the object model, layout flow, sandboxing, messaging, and a hundred other things.

Of all the platforms LC has taken on, I'd guess attempting browser export is the most expensive by far.

And given the vast inherent differences between desktop and web, even if it were finished today I'm not sure how many LC apps would make sense in a browser. It's not even limited to technical concerns, but use cases. The web is a fundamentally different platform than native apps.

Super expensive + unlikely satisfying = low ROI.

I love LC, and I love web dev. But I don't see a profitable bridge between the two.

[richmond62]

Why do LC users have the expectation that a tool for making native apps is also a web page authoring tool?

An extremely pointed question.

Possibly the answer may lie at LiveCode's door as they have raised this point, and attempted it, twice.

Had they not, it certainly would not have crossed my pea-like brain.
-

[FourthWorld]

Why do LC users have the expectation that a tool for making native apps is also a web page authoring tool?

An extremely pointed question.

Possibly the answer may lie at LiveCode's door as they have raised this point, and attempted it, twice.

Had they not, it certainly would not have crossed my pea-like brain.

I've seen folks asking for this since at least 2003.

I didn't understand it then. I don't understand it now.

The only thing I understand is that the question comes from people who don't do web dev, and those who do web dev aren't asking that question.

[richmond62]

Somewhere, historically at least, there was an idea being cast around that at one time sooner or later
"things" would happen in such a way that almost everyone would connect to an internet using nothing
but a thin client (ie. a minimal OS running only a browser, possibly off a chip), and "applications"
as we now know them, as conglomerations of code "sitting" on storage media in our computers,
would cease to exist, and that all services that applications had previously supplied would be
delivered by web-based front-ends connected up to something like applications somewhere quite
different from our thin clients.

I often use this sort of web service for batch conversion of image files: so not entirely daft.

Obviously this sort of idea has given people the idea that the "stuff" for writing a computer-based app
is somehow rather more similar to a web-based front-end than it actually is.

[richmond62]

I think that the quicker LiveCode "swallow" the HTML thing and get on
with consolidating their existing strengths the better it will be for all
concerned.