I'm not a big fan of using "fat" client-side Javascript to implement what would otherwise be static content.

For something more "app-like" (a weather information app), I had great success with using Perl to prepare the JSON and then Javascript to implement a Progressive Web App on the client side to render the JSON into something interactive.

I've given a presentation about this and the code is online as Weather::MOSMIX and https://github.com/Corion/PWA-WeatherClient for the client-side Javascript.

Thanks for the input, Corion.


As an Android user, who's a seasoned web systems developer, I'm sick and tired of being asked to download apps from whatever app store, to do things that are easily done by visiting a responsive web site.
There are times that an app is needed, as I have recently found out with a mini web app I wrote for tracking a mobile device using the browsers' geolocation api and feeding the positions to our server via AJAX and JSON.
Despite my attempts for power management and permissions to the mobiles' Firefox, my "tracker" web app kept going to sleep when the screen of the phone went off, or the browser went to running as a background app.
Apps seem to make better use of the device than a browser app does.
I am actually all for abolishing app stores and pushing users to apps developed in the browser, either with frameworks like React and AngularJS or by ensuring that web sites cater for every client, using well defined and corporation neutral technologies.

will the apps running on Android or iOS be expecting to communicate with the "hub" in JSON over RESTful URLs?

If JSON is a standard for REST I don't know, but both ends *can be made* to communicate with anything you want. JSON is convenient (except that you must url-encode it and you send binary data only as base64-et-al). Surely Perl backend can convert a JSON to a Perl data structure very easily. And vice versa. The client-app will coerce you to using a library for converting that JSON to objects (for example Gson) but you don't have to as you can have it converted to polymorphic hashtables. So, yes JSON is convenient on both sides. And an app, from personal experience, gains greatly by RESTing with JSON. I found Retrofit library useful for communicating with a server. If you are programming the app, your biggest problem will be placing all data requests using asynchronous logic. And that leads you to RxJava (for example). And that's some learning curve. Alternatively, you have a WebView component. Basically a browser inside your app, just a shortcut with lots of deadends.

Thanks, Bliako.


I don't much care about what will be used for handling the RESTful communication on the client side.
I am primarily concerned with adding "base class" functionality to my systems' packages, that will help all relevant web objects to be used by smartphone apps as easily as they are by web browsers. Regarding JSON and Perl, I have already implemented base class functionality that gives objects the ability to JSON serialize themselves using the Mojolicious JSON functions.

Do you see this "base class" functionality as exclusively producing JSON which is then either 1) sent straight to REST clients or 2) passed into an HTML-producing layer like: Templates+JSON=HTML to be sent to html clients (browser)?

JSON is usually a good choice for client/server communication. Just because the client is a mobile device makes little difference. It also has good support from Perl in the form of the core JSON module and also the faster JSON::XS. JSON has good support in other langauges too which will be needed at the client end.

JSON is not a core module, JSON::PP is. See also corelist/modules.

Nonetheless, JSON is a standard, and Perl has full support for it as do most other languages today. Hand it a string, get a data structure. Hand it a data structure, get a string. Treat the conversion process as a black box.