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

I would seriously recommend against XML. While I agree it won’t be going away for this stuff, it should. It’s easy to get XML wrong or to make it fit a particular cognitive bias for what data should look like. Or to pile on schemata and namespaces and make a beast so goofy it requires a manual to formulate a basic API request and parse the results.

JSON is nude Arrays, Hashes, Strings, Integers, and Booleans. It is what it is and it’s UTF-8. I would *never* use XML as the serialization or data layer in a project if I had the choice. And I resent the hoops through which I have to jump due to it being every Java hackers first choice.

Ajax was only XML at first, hence the “x.” Today hardly anyone is doing it in anything but JSON. It wasn’t a corporate agenda that did that, it was path of least resistance and fewest bugs.

More than KISS, I’d say use the abstractions that abound. There are a couple dozen *excellent* JS kits now that take away the pressure of having to deal with browser nonsense. There are as many nice CSS templates which will gracefully adjust to monitor size, be it a phone or a cinema display. The guts of a CMS can be written in Catalyst/REST or Mojo or Dancer or Amon2 or… in a week by anyone who has experience; mix in Oauth2 or something and you don’t even have to keep formal user accounts or manage password issues. A beginner might need three months…and that includes getting help when necessary, but it is worth it and doing it on your own means you become more employable should you choose to go that route.

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