- server load: your user's browser is handling one request at a time—you're handling many, and the extra processing adds up
- updates to site design don't require redeploying your application
- reduced code-bloat from hard-coding complicated HTML trees
- less work-flow dependency between back-end developer and front-end developer/designer
Most (all?) complaints of JSON web applications fall to poor front-end decisions: using enormous
violations, and really just plain shitty code.
In this short document, I'll sketch out how to set up your BCHS environment for JSON applications.
For a full working system using this method, see dblg.
Begin with the actual web application source. I use kcgi(3) and use pledge(2) (so it requires OpenBSD, of course) to safeguard our operating system. In this example, I just emit a simple greeting in a JSON container.
In most large systems, seperate people work the front-end (HTML5, CSS, JS, etc.) and the back-end (BCHS). We can document the interface between this by using Swagger, which hooks into JSON Schema to document the input and output of each resource.
Front-end work! In this incredibly simple example, we use AJAX to asynchronously invoke our web application and put the result into an identified element. We use vanilla JS and pay deference to CSP by processing fully in the script. You'll obviously need to put your own application URL in the loader.