Livecode Content Management System

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com