HTML Platform

[Richard Gaskin]

Pi Digital wrote:

 > Richard wrote:
 >> But most apps that might make good candidates for LC's HTML export
 >> have characteristics that lend themselves very well to not doing HTML
 >> at all, instead using a one-time download of an LC standalone which
 >> then downloads and runs stack files (a practice that, in the absence
 >> of a more common label, I like to call "streaming apps").
 >
 >
 > Two words, Richard.
 > IT Departments.
 > Of the 150+clients my client has, 150+ of them would emphatically
 > prefer a web based app than a desktop one. They don’t want stuff
 > ‘installed’ or ‘run’ on their machines that haven’t been thoroughly
 > tested before use. Each and every update. And they really don’t want
 > to have to keep testing each and every update. Using Chrome/Edge-
 > Chromium overcomes all of that.

I hear you loud and clear on that, Sean. I've run into that myself 
(humorous anecdote below).

In the subset of cases where IT is absolutely forcing the entire 
enterprise to ditch OS-native apps in favor of browser apps, there's 
little you can do to stop that.

And where the limitations inherent in any Emscripten-based solution pose 
no impediment to functionality, why not?  You'll still need to do 
significant rework of the stack to meet user expectations (e.g. more 
than half of all net traffic is on mobile devices so responsive design 
has become a common expectation for web apps), but where Emscripten does 
what you need by all means use it.

There is no one-size-fits-all for any of the work each of us does.  We 
evaluate the needs of our audience and make our deployment choices 
accordingly.


But the advent of the web hasn't killed OS-native apps.  The Mac app 
store is filled with them, and they remain a mainstay throughout 
organizations big and small.

Indeed, even the rise of the cloud hasn't killed off OS-native apps, but 
simply validated the "streaming app" model with the popularity of 
net-savvy apps like Adobe's Create Suite, Microsoft's Office 365, and 
Apple's iTunes.

An OS-native app allows a level of integration with common OS services 
and workflows difficult or impossible to achieve in the confines of a 
browser window.

Extra bonus points that it's also often a better overall user 
experience, and far cheaper to build and maintain in the LC we know and 
love.



 > And mySQL from LC in the browser is tonnes faster than on the desktop
 > - massively! Because they’re both on the same server. Even though the
 > message path is LC>JS>(AJAX)>PHP>JS>LC!

I suspect there's something going on there that can be remedied.  As you 
noted, compiled object code should be faster than interpreted 
JavaScript.  In every other respect the calls should be the same, so 
throughput should be faster in the OS-native implementation.  If it's 
not let's review that to bring it up to speed.



--
Aside: A Humorous Anecdote about working with Corporate IT

I was once a partner in a company that deployed a networked app which we 
delivered to institutions on CD-ROM.  As we told customer IT, we 
designed it for their convenience, so installation is simply copying a 
folder from the CD-ROM to a shared volume.  That's it.

IT at one facility didn't believe us.  They were up to their armpits in 
lesser tools than LiveCode, they were unable to conceive of a true 
standalone, accustomed to apps that spew DLLs all over the hard drive 
and then also require mods to their firewall.

They insisted we produce an Installation Guide.  We did.  It was one 
paragraph describing how to copy a folder from a CD to a shared drive, 
with the rest of the page being an illustration of doing that.  They 
were fully satisfied with that deliverable. :)


Years later we did migrate the consumer portion to a web-native 
implementation (using LC to generate it).  And since the original was 
built in LC, we easily moved a lot of the logic that had been in the 
client onto the server with minimal effort.  More on that in a moment.

We kept the authoring desktop-native, and expanded it into a streaming 
app where it was used by dozens of collaborating authors in offices 
around the world.

Authoring had originally been slated for migration into an existing 
Java-based system the org had built for similar products. The only 
reason for expanding our own authoring system to become multi-user was 
because the IT staff at an acquiring company was so busy with other 
tasks it became more cost-effective to build out ours than to wait for 
IT to catch up on the tasks the org relied on them for.  Great IT staff, 
just busy.  The authoring system written by a single LC dev eventually 
had more features than their similar system built in-house by an entire 
team of Java programmers, and for a much lower cost.


But on the consumer-facing web side, we have one more punchline:

One of the orgs that had insisted on a browser-based version did so for 
the usual reason, the one you noted, the concern for security.  As a 
regional hospital network (no, I'm absolutely not naming names) I could 
appreciate their need to take every opportunity to keep things as 
tightly contained as possible.

So you can imagine my surprise when they later came back to us insisting 
that we needed to "update" some features for compatibility with IE 6. 
This was about three years after none other than Microsoft themselves 
spent millions on a worldwide campaign to plead with their customers to 
stop using IE 6 and to upgrade to a supported version without that vast 
number of unaddressed vulnerabilities that remained in the older browser.

The rationale, their IT department explained, was that they had 
mission-critical web apps dependent on IE 6 which would not run in newer 
versions.

Think about it: Mission critical.  Dangerously-obsolete browser. 
Hospital network.

We did the extra work, but still didn't feel comfortable encouraging 
anyone to use a browser version its own vendor characterized as too 
dangerous to use.  So after we included the IE 6 workarounds we also 
added a disclaimer noting that we do not encourage use of EOL'd browsers.

As far as I know that hospital group continued to remain dependent on an 
increasingly-dangerous obsolete browser for at least another three years 
before they were finally required by top management to bring the legacy 
apps up to date.

I have a lot of respect for good IT staff.  I've done that job myself. 
But I've been in the biz long enough to feel comfortable noting that 
hiring practices for IT can be, we might politely say, spotty. :)

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