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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
