Wondering what is a web application, and what's the difference between a web app and a desktop program? Here's a simple definition with additional details to help you grasp the concept better.
If you're using the Internet, chances are, you're already using web applications (or apps, for short). G Suite, Office 365, ZOHO suite, Salesforce, HubSpot, FreshBooks, Dropbox, the browser version of Slack, etc., are all examples of web applications.
So what's the definition of a web application?
A web application is an application that's developed using web technologies. It's usually executed in a web browser by going to a specific URL.
I'm saying "usually executed" because in some use cases developers utilize "wrappers". The role of the wrapper is to make the experience of using the web application indistinguishable from using a native application.
How do web applications work?
Every web application consists of two parts:
- One is the so-called front end or client-side. The web browser executes this part. The front end serves as an interface for the user to enter data, run commands, and view data. Think of this as something like a car's dashboard, steering wheel, navigation system, etc.
- The other one is the so-called back end or server-side. A remote computer called a server executes the server-side code. All the users from the front end connect to this part to input or query data and to run commands. The back end usually cooperates with other services like data repositories, email servers, external APIs, etc. Using the car analogy from the previous point, think of this part as the engine, tank, wheels, cruise control, etc.
Technically, a web application can consist only of the first part, but usually, that's not the case.
Users access a web application by typing a URL into the address bar of a web browser. After firing up the app, the following happens:
- The client-side loads, showing a dynamically generated web page to the user. Dynamically generated pages are pages generated at the moment. The opposite of this is a static page that is created ahead of time like this blog post. At some point, the client-side could contact the server-side to acquire data needed to show the page.
- The user uses the interface of the web page to issue commands to the web application. This can consist of filling out forms, pressing buttons, accessing links, and so on.
- At this point two things can happen:
- No server communication. This happens when there's no server-side or no need to communicate with it. The client-side will do some calculations in place, and it'll show the resulting, dynamically generated web page to the user.
- With server communication. This happens when there's a server, and there has to be an exchange of data or commands with it. The client-side will send commands and data to the server-side. This is called making a request. After it receives the response from the server, it'll show the resulting, dynamically generated web page to the user.
- Go to point 2.
That's a very basic description, but it's enough to give you a good idea of what's going on behind the curtains.
Some technical details about the web apps
Front end/client-side technological stack
HTML is the simplest tool of the mentioned above. It's used to describe the structure and content of the different screens (or pages if you prefer) of the web app.
The visuals of a web app are described with the help of CSS. This includes simple animations, fonts, colors, sizing and spacing, borders, etc.
Back end/server-side technological stack
The server-side is a bit more complicated. There are numerous options when it comes to serving your app, each with its tools, languages, etc.
I'll list some of the more mainstream server-side languages. I'm going to use a popular usage index from TIOBE to rank them.
This is one of the well-established languages. It has a great eco-system of different tools, libraries, etc.
Often Java is the preferred language for enterprise applications. The reason being it's a secure and performant language. Also, it provides developers with a lot of options.
Python is another wide-spread language with a vast number of libraries and tools.
It's known for its rapid prototyping capabilities. In some cases using Python can reduce the development time for an MVP to hours instead of days.
It lacks a bit in performance compared to others, but there are ways to remedy this.
Microsoft is developing C#. It has syntax and features similar to Java, but it's not as widespread.
Applications developed in this language tend to stick to the Microsoft tech stack.
As for performance, js is not exceptionally fast. Theoretically, it can be pretty performant for some more specific, IO-bound use cases.
Today PHP powers 80% of the internet. It is very popular, and Wordpress, the most widespread blogging CMS, uses it.
Out-of-the-box performance isn't exceptional. Of course, there are ways to remedy the situation a bit like HHVM.
One of the biggest business advantages of PHP is the abundance of cheap shared hosting for it. This is especially useful when bootstrapping or creating an MVP.
Web applications vs. websites
I guess by now everybody reading this is wondering, "What is the difference between a web application and a website?".
Truth be told:
There's no clear distinction between the two. Technically every web application is also a website.
There is, however, a common understanding that websites are above all informational. This means that the important part of a website is its content, and this content is mostly static. Examples of websites include Forbes.com, Bloomberg.com, and DigidWorks.com.
The ability of the user to do stuff (send commands, perform actions, call it however you want) is a distinguishing feature of web applications. Web applications have content too, but it's dynamic. Above all, they allow the user much more interaction in comparison to a website. Good examples of web applications are Gmail, Google Docs, Google Analytics, Office 365, Amazon AWS, JIRA, Asana, Wave, etc.
Web applications vs. web services
A web service is a piece of software that accepts commands and serves data in any format. The format can be JSON, XML, some proprietary data format, or something else.
Usually, people refer to web services as APIs. The API is the interface of a web service, the part somebody can interact with and thus use the service.
As a rule, a web application uses a web service. It's the back end part (or the server), that's serving data to and accepting commands from the front end part (or the client). This doesn't apply to the rare cases when a web app has no back end.
You can think of it like this:
A web application's purpose is to serve the user. It's an interface intended to be used by humans. On the other hand, a web service serves machines, and it's an interface that's used by other computers and devices.
Web applications vs. mobile applications
Web and mobile apps can be almost the same or they can be very different. It depends on the purpose of the application, and how it's implemented.
Progressive web apps are web applications designed to be easy to use on mobile devices and desktops.
There are hybrid apps. They use some kind of a wrapper to make them more native-like.
There are also frameworks like React Native and Flutter that use web technologies to create native applications. It's kind of a mix between web and mobile applications trying to get the best of both worlds. Their strongest advantage is that you only have to support a single code base for all operating systems. On the flip side, when coding native mobile apps you have to support a separate code base for every mobile OS.
Pros and cons of web applications
Depending on the project, a web application might or might not be the best choice. Their popularity is increasing, but there are still use cases where a web application is not the best fit.
Unlike desktop and mobile applications, you can run a web application on every device that has a web browser.
This makes them much more convenient than their counterparts.
You don't have to install a web application before you can use it. The only thing to do is to navigate a web browser to a certain URL.
This is another benefit for end-users because it eliminates the need for big downloads, installation, configuration, hard disk space requirements, etc.
Updates are the responsibility of the developers of the application. The end-user does not have to do anything to use the latest version of a web application.
Less software piracy
You can't crack a web application. You might be able to "lend" your account to somebody, but it's impossible to use it for free if the authors of the app don't want you to.
Hackers might be able to get access to an account, they don't own, in less secure web apps, but that happens rarely in comparison to software piracy.
Fewer resources for development
In most cases, developing a web application takes less time and money than developing a desktop app.
This is a bit controversial. In general, every piece of software that performs network communication is vulnerable to attacks.
So why are web apps secure?
Because they are sandboxed in the browser environment. They access everything through the browser and can't access the user's computer directly. This makes it impossible for a web application to cause data loss on a user's machine.
Also, if a computer is stolen or damaged too badly to recover, your data is safe on the servers of the web application.
Access from everywhere
Web apps store their data in a centralized server (or servers). This means that a user can access their data from everywhere, without the need to transfer files.
Easy data backups
Since web applications have centralized data storage, it's easier to create automated backups of your data.
You can track what your users are doing. Of course, I'm not talking about their private data, but rather what features are they using, are they utilizing the application to its fullest potential, etc.
This is very convenient for the providers of the application. With this information, they can determine ways to improve their software.
The developers of a web application can choose the most optimal deployment environment, and that's the only one they'll have to support. This eliminates issues caused by problems in the device of the end-user or different operating systems.
Performance and hardware access
Some of the more specialized software programs need a bit more resources than the rest.
CAD software and vector and raster graphics editing software, among others, need 2D and 3D computing power. That's provided by your computer's graphics processor. Accessing it through the browser can be limiting and is usually not enough for the needs of programs like Photoshop, CorelDRAW, AutoCAD, Solidworks, Revit, ArchiCAD, LibreCAD, etc.
Digital audio workstation software might need access to specialized hardware on your machine. This is impossible to access through the browser alone.
These are some examples of software that can't be implemented as web applications.
The simple rule of thumb is:
If you need access to some specific hardware on the users' computer web applications aren't the way to go.
If your application is very performance-dependent web applications aren't the way to go.
Like any other application that uses the Internet, web applications are vulnerable to a variety of attacks. They can be hacked, users can be misled into giving their credentials for accessing sensitive data, and so on.
That's why it's crucial to harden the security of the web application and its server. Implementing the best security practices often isn't enough. The users of the web application have to be educated on the subject of security in order not to be scammed.
As you can see, web applications are a very versatile tool. Their fairly quick development time and great accessibility make them preferred for a variety of use cases.
They help companies reduce costs, increase efficiency, and optimize processes. With the ever-increasing Internet usage amongst businesses and people, web applications are becoming the norm for software.