Complete apps in Javascript

Historic view

The separation of systems into front and backend emerged in development because it made it easier to build rich websites leaving the server to provide data, with a front-end that provides views and controls on that data.

Notanant is a bit older than this (we started it in 2002 and had elements of a Javascript front-end in 2005), so a typical Notanant site still uses server-side rendering, but since we separated out content and form, and have been using component-based design since forever, this doesn't restrict the flexibility of Notanant as a platform.

More particularly, Notanant is designed to be output neutral, so can be used as a 'JSON-server' if required (in addition to HTML4, HTML5, RSS or even WAP). Importantly, the server still needs to process permission-based access rules before deciding what data to send, and what data wrapper to use.

This means it is as easy to serve components wrapped as HTML components as it is to serve them as JSON components that then need to be wrapped and processing in by a Javascript framework. All the Notanant components can be accessed as JSON or HTML snippets as required.

The increased use of Javascript through tools like JQuery, eventually led to the need for a full framework approach so the front-end design team could work separately from the backend database team.

Consequently, over time, the JQuery snippets started to amalgamate into a more unified and uniform front-end, particularly as many developers started to build single-page-applications (SPAs) to eliminate page-hopping (personally I think there is still a place for page-hopping, while also adopting SPA approaches for things like profile management). These SPAs linked elements together and essentially became a front-end application on their own, linking in and out to the backend when needed - hence a 'Progressive Web Application' - sort of front-end plus - what used to be called 'Thin Apps'.

In some cases those services might be delivered in a 'serverless' mode - static resources called up as required from files, rather than databases. However, for the most part these applications still rely on backend services.

Where we are is that we've moved to developing full apps in Javascript that run regardless of the backend. They are more like traditional software applications or apps running client-side, but that only link to the server when the user wants to. This gives great privacy to users, while still allowing for all the augmentation of the application with backend data and processes.

Client-based javascript apps

These type of client-based javascript apps can be created because they use browser-side storage (eg IndexedDB or localStorage) providing a full immersive environment on the browser, combined with features such as saving and loading files to and from the local file system, the user can operate entirely in client-side mode without server-side connections, up until the point that they need to upload or interact with online services.

Our Cxoice Survey Editor is Cxoice Questionnaire Editor is one example where the whole application is built in Javascript, data is stored locally and it can even spawn fully functional HTML apps, all without touching the server.

This then provides a rich-editor interface for document creation, or allows building of rich exploration tools (eg the dobney.com Space Mapping data visualisation package) that only connect to the server when they have to, rather than all the time.

This then unburdens the server end as the server only has to deal with selected writes and edits, instead of a continual stream of client interaction with every possible client.

What's more is that in creating the whole app client side, we can dismantle some of the need for frameworks. When we started in the 2000s, frameworks were necessary to standardise Javascript and DOM access by hiding browser-quirks, or by adding pre-coded widgets. Modern Javascript has removed the browser-compatibility issue, and with client-side code, widgets become embedded elements within the larger application which allows for them to be written more cleanly, without the need for framework hooks, purely focusing the application approach itself. The front-end developer becomes and application coder, rather than being a UX specialist limited to widgets and HTML.

The challenge is that if the app is instantly available, how do you charge? But the answer is that there is always a gate - a need to take what is done client-side into a shared online-side. Do anything you like locally, but going through the gate requires a subscription.