I was able to face the comparison between cash points created with Apps or on browsers back in 2014 in aKite – Cloud POS: App vs. Browser but I return to it because in the meantime both fields have evolved and I still hear people saying that “a cash register on a browser is light”. That may be true, but only in extreme cases, as I’ll try to explain. First let’s clear the field of consumer applications focused mainly on smartphones. WhatsApp, Facebook, Linkedin and others are Apps for the best performance and “User Experience” and also for offline operation. The less frequently used applications are instead based on Browsers because the operations of accessing a “store”, downloading and installing a new App require an application and several minutes. The new Progressive Web Apps (PWAs) try to combine the immediacy of a web page with the performance that only a little local intelligence can provide, by downloading code in the background that gradually installs itself inside the browser. Let’s now move on to the professional world, where a device is used continuously for years and where the few minutes to initially install an App with a click from a web page seem like a dream compared to the intervention, even of hours, of a specialist for installation of a traditional program. What matters are performance even with cheap devices, safety and resilience in the event of failures, needs that also involve architectural choices.

The paradigm shift of the Cloud

Before the Cloud, the cash points were part of the “departmental” system of the shop, capable of functioning autonomously and periodically exchanging data with the center of the chain. With the Internet, “centralized” systems, also known as “hosting”, have spread, where data and intelligence are exclusively at the centre. The risk of total blockage of activities is often mitigated by a backup database in each POS, with additional costs and complications. Even a redundant line can become null in case of blockage of the central server. True Cloud Computing has introduced real paradigm shifts, such as PaaS (Platform as a Service), multi-tenant Microservices orchestrated by SW such as Kubernetes and “distributed” architectures, so as to give birth to open technologies such as DAPR (Distributed App Portable Runtime). The browser was born as a multiplatform viewer of centrally managed content, but the computing power and memory of any device present in the POS (smartphones, terminals, tablets and PCs) allows you to perform many local operations without additional costs, just like the Apps do Redesigning a form on a central server and sending the instruction to the device’s browser to change a few pixels, when it could do everything by itself, is the reason why intelligence is brought to the periphery. In Apps, execution is direct and optimized while inside browsers, languages ​​such as JavaScript are used that access device resources only indirectly. I remind you that even bits are subject to the laws of physics: they require energy to travel and cannot exceed the speed of light. Everything that can be done locally avoids delays for forwards and backwards of data and work on central servers, with an improvement in performance and environmental sustainability. By “distributing” even a copy of the most frequently used and least subject to change data to the periphery (in a cash point: products, prices, customers and promotions), you further reduce time and energy in data exchange and, more importantly, the normal sales operations take place quickly and undisturbed even in the event of a connection failure or problems with central services. Sales data is automatically queued and transmitted as soon as normality returns. Local data synchronization (also necessary in a “centralized with local back-up” system) must be reliable and efficient. The “cloud-native” mode is based on asynchronous messages generated by events. In this way the update is immediate and limited without resorting to periodic replications of entire databases, sometimes completely useless and sometimes late.

The Comparison

In this diagram I try to represent the memory occupation and interactions with the cloud, with the relative pros and cons. The data are averages obtained from personal observations and are intended to give a relative order of magnitude. Assuming a centralized architecture, local code in the browser is reduced and data exchange with the cloud is elevated. A distributed architecture implemented on the browser would further increase the memory footprint, where smaller = more efficient. In addition to the lower memory usage of the Apps, the main advantage lies in being optimized for the O.S. chosen and not to require additional processing by the browser. Pros and Cons mirror each other.
The Browser is an intermediate layer of software that “translates” the commands towards the different O.S. necessarily imposing less freedom of development, less responsiveness and greater memory occupation compared to an application of similar complexity developed directly for the O.S. The Browser is the cost to pay to get multi-platform with a single version of the application program. A rather steep price if Mark Zuckerberg said years ago that one of his biggest mistakes was to betting too much on HTML5 and neglecting Apps Facebook’s Mark Zuckerberg knocks HTML5 in favor of native apps | ZDNET .


For a browser-based till station to be lighter, it has to deal with an old and inefficient “departmental” solution that performs any operation locally, even the least frequent and most complex, and periodically exchanges data with the centre. The one on the browser becomes lighter only if the other takes up at least 0.5 GB of RAM but it can never be lighter than an App with the same level of local intelligence. Given the undisputed superiority of Apps, technologies have always been developed to reduce the effort required to derive specific versions for each OS. One of the best known is Xamarin. With MAUI (Multi-platform App User Interface) Microsoft is making Xamarin evolve both in terms of performance, ease of development and also towards the Desktop, by introducing, for example, multiple windows. MAUI is open-source and was officially made available in May 2022. It is the technology that aKITE has been working on since last year for the next multi-platform version of its Cloud-native service for the Front and Back Store of chains and independents.
Via del Progresso 2/a
35010 Vigonza (PD)
P.IVA/C.F: 02110950264
REA 458897 Cap.soc. 50.000€


© Copyright 2023 aKite srl – Privacy policy | Cookie policy