Andre Garzia work:
> So far, most of our web efforts have been "PHP-inspired", as in our
> server engine behaves like PHP and our frameworks look and feel like
> PHP frameworks.
Thank you for bringing that up. There are a great many design decisions
with the LC Server CGI that do mirror the PHP model very specifically.
We don't see that devotion to PHP in the ways people use Ruby, Lua,
Python, or others on servers. Those languages are used in ways that
emphasize their own flavor. But with LC, the preoccupation with
mirroring the PHP model has given us a system that is in some ways
incompatible with the core language: You cannot run LC Server scripts
with the LC desktop engine.
There are workarounds for that, but I miss the original CGI solution
which let us use native LC script without requiring us to comingle it
within HTML. The current LC Server engine has been enhanced to allow
that, but in a way that unfortunately maintains its incompatibility with
the desktop engine: the original CGI solution was handler-based, and
used "on startup" as the entry point; the newer LC Server engine allows
you to have lines of code outside of HTML, but expects those outside of
any handler declaration. Odd, and unfortunate as it not only prevents
us from using that in the desktop engine but also introduces yet another
"sometimes" rule in a language otherwise consistent with its handler
declarations.
For these and other reasons I tend to use standalones for CGI work
instead of LC Server. Oh, the joys of emulating server behavior so
easily right on the desktop where I have all my tools and debuggers!
I've been tempted to refine and document the standalone method for
others, but it's still unclear to me whether there's enough growth in
using LC CGIs to warrant what would then be a niche of a niche, or
instead focus on tools to migrate LC systems to Node.js or others where
the ecosystem makes them an easy sell for stakeholders.
> ...PHP is not on the bleeding edge of web development anymore.
That is of course true, but I would caution against discarding ecosystem
for fashion. Being bleeding edge may be exciting for devs, but delivery
of a working system is the goal for stakeholders.
PHP may be old, but it's also competent, designed for a job it often
handles reasonably well. As #8 on the TIOBE Index, I don't see it going
away any time soon. When it does what you need, it can be a good
choice. And most needs are pretty modest.
> Any tool built today, in any language, with aspirations to be webby
> should be generating a PWA. Generating a simple barebones progressive
> web app (this is not your old progressive enhancement) boilerplate is
> quite easy.
> The new features such as WASM (which is implemented in all major
> browsers already), Service/Shared/Web Workers, and all the other APIs
> from the web platform are all awesome....
The browser is a very capable, flexible platform. The features you
outline there are wonderful enhancements that will move app development
forward very powerfully.
But not everything on the web is an app per se. Much of it is content.
Indeed, content is the focus of a CMS.
The distinction between a "web page" and a "web app" is subtle and not
universally agreed on, so I won't bother to attempt to define it here.
Suffice to assume that we at least all agree that there is a difference.
For a "web app", of course that will be driven by JavaScript; as the
only language included in all browsers, there is not choice in the
matter. We may translate from other things to JavaScript, and package
the JavaScript in different ways, and ultimately with interaction in a
browser it's JavaScript just the same.
For a "web page", I feel it's important to deliver content that can
render without JS dependency. In this era of rampant malware it's
becoming increasingly common for savvy users to keep JS blockers active,
turning them off only as needed on specific pages, and only specific
scripts. Tedious, but less so than restoring from backup after ransomware.
And tragically, many (most?) ad networks do little if any filtering for
malware in the code they deliver into your computer. They may complain
about JS blockers, but until they begin to take practical measures for
protecting recipients of their code, their networks are, in effect,
potential malware delivery systems. I look forward to the day when they
prove me wrong on that.
There are other reasons why JS blockers are increasingly popular, but
the result is something that's become important to me, and others who
have a vested interest in content delivery: we build content pages in
which JS is optional if used at all, so that the content which the user
came to read is always available, not dependent on JS.
So as much as I value APIs to deliver data without HTML formatting, when
the request comes from a browser I prefer to wrap the HTML before delivery.
There are tradeoffs either way, but for me the tradeoff that favors
security and quick rendering is a higher priority for content pages than
saving a few k in delivery time over modern fast networks.
The TL;DR relevant here:
We have many options available, and many different needs. Whatever Alex
finds as the best fit for the specific CMS he's aiming to build will
hopefully reflect less any fashion or trends or technologies among the
nearly infinite range at his disposal as it will reflect an
understanding of what constitutes an excellent UX for visitors of the
sorts of sites he's looking to build.
--
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
