Honestly, I (where JavaScript is concerned) want to keep it simple. As noted previously, and elsewhare. I'm not keen on the addition of JS, anyway.

Main points of contention, are that JS is fragile, in the sense it's easily disabled (within browser). This leads to [potential] failure of any aspect [depending] on JavaScript. Other point; Don't at all care for those "BloatWare" libraries floating around -- I'm uncomfortable going to sites that use them, mostly, because I think the're easily abus(ed|ive). I have no idea what's in them, and could easily be a big fat security risk. Further (as my CPU meter indicates) that even with 3 cores, running @3.2Ghz w/128Gb RAM the meter shyrockets, when subjected to these libraries. Can you say inefficient, poorly designed, spaghetti code? Sure, I knew you could.

So, for me. I think those are reasons enough for anyone to feel compelled to reject such option(s). Sure, you could always examine the JS library, and make any changes/corrections you felt necessary. But in the end, wouldn't just be adding yet another big JS library to the pile?

In the end, and as you note so wisely, forethought is required, in order to make the correct choice the first time. Lest one squander precious time needlessly. :)

As I'm already using XML (XML::Parser). I'm feeling inclined to travel down that road. In fact, I'm also looking at possibly replacing XML::Parser with one, or perhaps both Modules created by Jenda -- XML::Rules, and XML::DTDParser. By going (sticking to) the XML path. I think I keep the current path of the CMS, both narrower, and more direct. I can then be more easily focused. Not having to keep changing hats, while working with/on it.

I'd like to close by thanking you again, sundialsvc4. For both your time, and perhaps more importantly; your patience. Given my bone headed initial conception, where JSON is concernecd.

--Chris

Search for “graceful degradation” and “progressive enhancement” to learn more about considerations and strategies. If you’re committed to a perfectly atomic app you’ll have to look in other places though. The magic of the web is its deep, if sloppy and choppy, interoperability. Web pages from the early 90s load fine on Chrome or a PSP. Many, though obviously not all, web pages from this year would load “ok” on Mosaic or Navigator.

What you gain from committing to iOS or something, you lose by committing to iOS. :P A unified app has to be specially built/compiled for every platform, sometimes in proprietary languages, and sometimes recompiled for every platform upgrade, firmware change, etc. A Perl/JS app can be run with just a little forethought on nearly limitless combinations of platforms, agents, and their manifold versions and is somewhat future proof by default just because of the nature of the web.

Always a pleasure, Your Mother. Thanks for chiming in.

As I read your reply. I ultimately hear you say; Keep It Simple Stupid (KISS).

Frankly, hard for anyone to resist. After all. Aren't we all inclined to the Least Line Of Resistance? Hell, some might even say "lazy". But seriously. I'm trying to balance the 2 areas I believe you refer to. 1) keeping it simple, and based on standards with a long history, and good "legacy" support. Will surely be considered a safe route to take. But OTOH, I'd like to think I could also add to my application(s) (FutureFul). I believe the direction I've chosen caters to both. HTTP hasn't changed [significantly] for some 20yrs. Perl? OK this one will likely receive contrasting opinions; but suffice to say, where P5 is concerned, it's LegacyProof. XML, has been around for quite some time now, and shows little sign of 1) going away, anytime soon. 2) will likely get additional features for the foreseeable future.

In the end I think the route I've chosen makes it relatively FutureProof. I think it is also simple enough to not become completely derailed, as standards, and technologies change.

I'm not suggesting you're attempting to argue against my chosen direction (altho perhaps that's true). I also get the impression that you may be suggesting that JS is a better approach. My personal observation is XML delivers nearly on-par w/JS. So unless I require Mosaic. I think I'm covered -- and XML is less fragile too. :)

Thanks again, Your Mother, for taking the time to reply!

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

P.S.

Just had a look at haxe. Seems [at least] a bit like Clang && LLVM.

How well would it work on my Timex Sinclair? ;)

I think [where my CMS is concerned], it's a bit more than my needs require. But could easily see where it'd fit in where using some [compiled] form of JavaScript, was concerned.

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH