What is the difference between an app and a web app?

The software creates applications. Some of these apps are “apps” that we download from an app store or marketplace on the Internet, but some are provided as part of an enterprise software suite. A few of us remember when those same applications came on a CD-ROM or floppy disk. But that’s not a history lesson, so let’s move on.

Other apps are never downloaded (at least in full) as such, because those apps are web apps. These applications basically exist as services that run over HTTP or HTTPS, which are of course the transfer protocols the Internet uses for application layer data communication.

Considering these two main sides of the app coin, can we ask what is the real difference between an app and a web app?

All and nothing

The answer, somewhat paradoxically perhaps, is all and nothing.

That’s all, because most of the components, software code structures, operating system connections, data services, and interconnectivity channels that exist in an application could (and usually should) also exist in a Web application.

It’s also nothing, because a web application is an essentially ephemeral piece of web ether that can potentially be affected by all of the intergalactic traffic that traverses the web and connects to various interplanetary docking points, often through the use of application programming interfaces (APIs). .

To say that web applications are inherently different because they can be affected by more vulnerabilities from malicious actors and the more nasty parts of the dark web is an overstatement, i.e. many applications and services “ground” databases can be compromised from the inside due to unpatched exploited sections of the network, for example via a content management system (CMS) or other central enterprise computing engine.

“Compared to ‘land’ apps, which are often designed for specific operating systems and devices, web apps are accessed through web browser ‘interfaces’ on any device, from anywhere. In a typical Software-as-a-Service (SaaS) cloud computing deployment, the web application back-end is designed as a collection of cloud services accessed through an API. Using web technologies, it is also possible to build a web application without a backend – the ultimate ‘thick client’ application that can work without a network or internet connection,” said Doron Sherman, VP of Relationships with developers at Cloud-based image and video management. cloudinary company.

Beyond their obvious economic and portability benefits, Sherman says web applications are also becoming popular because of their versatility in use cases. Data can be passed to web applications in a distributed (and even decentralized) way, both on the server and increasingly on the client side.

“For example, modern applications often acquire data from a camera, microphone, and other sensors. It’s too slow to ship all that data to be processed on the cloud/server, so “Web browsers have evolved to process data at high speeds (for example, using WebAssembly code). These advancements mean that the capabilities of web applications running on user devices are rapidly catching up with those of native applications,” he said. he adds.

What is true is that web applications as they currently exist on cloud services can be under greater strain due to cloud misconfiguration. This occurs when a cloud instance is not properly provisioned, planned, architected, and deployed for the use case it is intended to serve. But even this next-level truth doesn’t quite answer the question, what’s really the difference between an app and a web app?

Finding the Basic Application Difference

The co-founder and chief technology officer (CTO) at cloud connectivity specialist Kong is Marco Palladino. With experience working with enterprises on deeply connected web application technologies like microservices and service mesh (configurable software designed to streamline IT system infrastructures that use APIs), Palladino has a lot to say about this. topic.

“A web application is essentially a client application [i.e. one that resides on your PC] – decoupled from its back-end components – which requires API communication with a back-end server to work. Previously, traditional applications integrated both client interface and back-end functionality into a single component that we used to install and use locally, on a physical computer,” Palladino explained.

APIs power our modern digital world

As we know then, modern web applications use underlying APIs on the internet (or local network) to provide the intended functionality. This brings us to a point where we can position APIs to essentially power the services that run our modern world… from banking to mobile to IoT to all modern consumer applications.

“From a technical perspective – when we look at web apps that run in a browser – that’s not the only difference. The traditional customer interface [pre-web] apps used to be completely self-contained and self-contained, whereas web apps require a third-party dependency – which we didn’t need before – to load the interface: the web browser. Web browser work (Chrome, Firefox, etc.) is needed to load the interface of a web application that otherwise doesn’t know how to render (very different from traditional applications that might run completely locally even when rendering of the interface itself),” Palladino said.

Where this takes us into the “new” world of web application development and deployment is a kind of decoupled application reality. It may or may not be obvious, but the net benefit of these decouplings is that we reduce the portion of our software that we need to run and load on our computers or devices, making it lighter and faster to download.

Kong’s Palladino points out the pros and cons (perhaps the cons are too negative) that arise at this point.

Gain of the web application: continuous improvement

“The decoupling process we have here comes at the cost of needing an internet connection (or an offline browser for some offline-capable apps) to provide the underlying API communication to make them Additionally, by decoupling the client from the server, developers can continually improve the software without always forcing the end user to download the latest and greatest, thus making new backend features and fixes accessible from day one to their base. of users,” an optimistic Palladino explained, suggesting that the gain here is significant and one we should all be grateful for.

As this analysis unfolds, perhaps we can now step back and realize that one of the central pivot points here comes down to normalization. Web applications all fit perfectly in the same box (browsers, cloud) and communicate the same way (HTTP, HTML, JavaScript, etc.)…and from standardization we take control, says Patrick Jean, CTO of modern application development platform company OutSystems.

“What is standardization for? This reduces variability, but it also eliminates possibilities. This reduced variability means the developer can more reliably and faster deliver consistent experiences – web applications in a browser. But it also means that the developer may be prevented from providing a unique experience that the browser simply cannot deliver with the limited technology set. Hence the need to break away from the web app box and move to a full app and have more control,” Jean said.

OutSystems CTO explains that with traditional app development, the developer must make (and implement) decisions about “how” an app is built, what it runs in, how it communicates . In this case, if the developer wants the app to run directly on a specific device only (no cloud), a traditional app is usually the way to go.

“So there’s no right or wrong apps or web apps, it’s what fits the need and the use case every time, i.e. traditional apps for more control on user experience, or web applications for standardized delivery and communication,” said Jean.

The web app era first

The difference here is clear when you think about it. So now it’s interesting to think about how companies will work with the mechanics of software in the age of always-on web application connectivity and start to design things like search, AI, and automation into a software code that still has an electricity pipe (for code and content) plugged into it.

Will we have all our applications on the web in the future and rely on the X-as-a-Service cloud computing model for every software we use?

Probably not, at least for the foreseeable future. There are enough use cases for static, experience-specific, dedicated, custom, and (in the age of the Internet of Things) embedded applications (although they can also be delivered on the web and cloud) to ensure that the two main types of applications will exist in our world.

Comments are closed.