Websites vs Web Applications – A Full Comprehensive Guide
The state of the web is constantly evolving and the technologies behind web development are following suit. Standard websites are still the bread and butter of most of the businesses, brands, and product sites.
You may have heard of the term web application when referring to a website instance. It is a term that is often used to describe a modern website. When choosing between a web application and a website, you might wonder what the actual differences are between the two.
Some interpretations make out like there’s no difference at all. So it can be difficult to distinguish between the terms of web application and website.
This is partly because they overlap in certain areas namely:
- Both run in browsers
- Both require access to the internet
- Both have interactivity
- Both have content
- Both can have authentication
So, they essentially serve the same purpose, right? On the surface, they provide a web presence where you can view and interact with information. But while they might share similar aims it’s important to differentiate the core differences between a website and a web application.
While many would consider user interaction in a web application the fundamental difference between the two, this isn’t completely true as a user interaction takes place on both types.
The main differences between the two are outlined here:
|Performance||Web applications pride themselves on being extremely performant using the latest single page application web technologies. Navigation is nearly seamless. Interactions are fluid and fast.||Websites can vary in performance. Navigating from page to page can feel slow while assets are being retrieved. Interactions can feel static and unresponsive.|
|Offline Functionality||Using service workers, web applications and progressive web apps have incredible offline functionality.||Websites have limited offline capabilities without any technologies such as service workers|
|Presentation||Web Applications tend to presented to look more like dashboards (think Gmail).||Websites tend to follow a convention that makes the user easy to navigate. Header, footer, main body etc.|
|Interaction||Web applications have more complex interactions by their users. This includes adding, editing and deleting data in the web app.||Interactions can still be complex and with logic in a website, however interactions are not as fast in comparison to web applications. There is less feedback during interactions (no snackbars, toasts or notifications|
However, there is a lot more to discover in these differences. But first, let’s establish a clear and concise definition for a website vs a web application.
A website is a number of publicly accessible, interlinked web pages which are accessed by a domain name. The use cases of a website range from individuals to large businesses and organizations. They have a broad range of purposes including:
- Brochure Websites for products
- Ecommerce shops
- Info Product Demonstrations
What defines a web app?
While the basic concept of a website is easy to comprehend, on the other side we have web applications. What exactly defines a web app?
Well, a web application is more of a functional program that is accessible by any web browser. Previously, software that had complex logic and intricate user interaction needed to be installed locally on a desktop.
So think of any desktop application you have used in the past such as photo editing software, file extraction programs or word document editing.
As the technology of the web has evolved, these types are software are built on the web and consumed with a browser. These types of applications provide far more functionality and features than traditional websites.
Web applications have a wide range of purposes including but not limited to:
- Email applications
- Communications applications
- Calculation applications
- Analytical Applications
The behavior of a web application mimics the interactions commonly seen on mobile applications and desktop applications. Some recognizable examples include:
- Google Sheets
- Google Analytics
Web applications became renown during the rise in popularity of SaaS (Software as a Service) projects. These types of applications cemented the idea of a web application being different from a website.
SaaS applications often come with a subscription fee or a one-off payment that allows a user to unlock the features of the software in a particular niche.
The level of interactivity in a SaaS application far exceeds that of a standard application. There might be a whole host of tasks a user can complete within the confines of one SaaS application.
For example, a photo editing web application allows a user to perform many actions such as creating a photo, editing a photo, exporting a photo, viewing photo history, etc. This is clearly demonstrated in an application like pixlr
It is feature-rich and has multiple use cases for executing photo-related tasks. These kinds of actions tend to be too complex for a standard website.
So while we have demonstrated some examples of web applications, let’s delve deeper into specific features that differentiate it from a web site.
What are features of web applications?
A modern web application tends to have far superior offline functionality compared to a website. This is due to the advanced technology used to serve offline assets to the web browser.
In general, as long as additional data is not required for interaction, it is more than likely that this functionality is available to be used offline.
If your web application experiences a temporary disconnect from its network, the user is still able to continue on a task, this disconnection is not signaled by the application and is often unnoticed by the user. By the time connectivity returns the user may not have been aware that interruption even happened.
This contrasts to an offline experience with a website, without any network connection navigation is futile as there are no assets available to load a new area of the website.
When an application’s features are broken down into many different subsections, it’s important to inform the user of any notable changes.
This is typically done by sending notifications to the user and is a strong indicator of the web applications having features that would not be available on a website.
There are two main types of notifications:
The Web Push Notifications protocol is a relatively new feature of web applications. They give the ability to act like native applications and receive messages pushed from a server. This gives a simple and practical way to re-engage users even when the web app is not active in the browser.
Once permission for push notifications has been given, the website can notify you of updates news and changes from inside your browser.
If you would like to test some push notifications, the web push book allows you to do so.
Notifications at the app level are another definitive feature of using web applications. They are commonly located in the top right navigation header. Some recognizable example includes Facebook, Airbnb or Dropbox.
A notifications panel acts as a centralized hub of information about the application. In-app notifications are powerful tools to notify users of crashes.
What is most striking about the in-app notifications is the logical divide between different categories of messages. The design of notifications would often include an icon that is distinctly part of a category of notifications for example.
This gives the user some visual context on the type of notification even at a glance.
To suggest that there are new notifications available, there is usually a subtle visual indicator that typically has the number of unread notifications listed.
Dynamic in nature, the visual indicator disappears as soon as a user clicks to view the new messages.
So, while notifications certainly exist in standard websites, their value significantly increases in a web application because of the necessity to give users updates on actions they have taken.
Snackbars are one of the most common UI components used in web applications. They are unlikely to be found in most standard websites. If you notice a snackbar appearing at the bottom of your screen. There is a good chance you are using a web app.
The purpose of a snackbar or a toast is to provide the user with a snippet of information that will disappear after a few seconds.
They usually appear after the user has performed a specific task including:
- Submitting a form
- Clicking a button
- Deleting an item
- Saving an item
- Editing an item
- Attempting a task that needs to be logged in
- Attemping tasks that require a created account
Additionally, snack bars can be indicators of both positive and negative actions. When an error has occurred in the backend after the submission of some form data, this can error can be made visible to the user via a snackbar.
Rather than displaying the information somewhere on the page that the user might miss, snack bars are an effective technique for drawing the user’s attention to important information.
With the additional complexity and user interactions of a web application, snackbars are vital for surfacing pertinent information that the user needs to see.
They are a practical visual cue for providing this data, and they can be consistently styled and positioned resulting in the user always recognizes the snack bar component when it surfaces. They are hugely beneficial to keeping a user informed when performing important actions in a web application.
Providing peripheral messages to communicate the status of the user’s interactions in a non-obtrusive way is the true value of a snackbar component and is a staple in any modern web application
There are definitely some considerations around the strength of Search Engine Optmization (SEO) for web applications.
Being able to interpret the page markup is essential to determining what a specific web page is about. Information such as titles, headings, subheadings, descriptions and paragraph text are gathered from HTML markup.
This has led to a debate about that search engines will rank a client-side rendered web application poorly because this markup is not instantly accessible.
Google has added some levity to the situation by stating:
Googlebot queues pages for both crawling and rendering. It is not immediately obvious when a page is waiting for crawling and when it is waiting for rendering.
This message is a little bit cryptic and doesn’t really say which side of the SEO pendulum does JavaScirpt swing towards
The rest of the article can be found here.
However, web applications can avoid this whole scenario by implementing server-side rendering. By doing so, the markup of the web application is identical to a standard website.
Single Page Applications
Whereas websites have noticeable transitions between pages, single-page web applications allow the user to navigate within the confines of a single page.
A single page application provides a more fluid experience akin to a desktop application. Instead of constant communication between client and server for a typical web website
A typical request for a website might look like this:
- The user navigates to a landing page
- The browser requests the landing page from the server
- The server responds with landing page
- Only this particular landing page is loaded
Rinse and repeat this process for every single page the user navigates to. On the other hand, the process for a single page application looks like this:
- The user navigates to the landing page
- The browser requests landing page from the server
- Application is fully loaded and accessible
Overall, single-page applications and their seamless approach to navigation opens the door for more complex apps that might be a strain for a normal website to emulate
Dashboards can be seen all over the modern web. They are a graphical user interface that commonly depicts metrics and data visualization.
The term dashboard became commonplace in web development terminology as web application technologies were improving and allowing for more extended functionality. The term originates from automobile dashboards where drivers monitor the main functions of their vehicle.
In a similar vein, the user monitors and interacts with multiple pieces of functionality in a web-based dashboard, hence the term carrying over. Almost all modern dashboards are built with web application technologies. These technologies allow the fluid presentation and instantaneous interactions required to have an interactive dashboard.
Dashboards contain a lot of logic and are typically used as analytical tools for stats, metrics and big data. They also depict trends, summaries, and reports which can be directly interacted with by the user.
But not all dashboards have to be based around analytical tools. A perfect example of this is the dashboard design of Contentful, a content management system used for many websites. This is a multi-purpose CMS dashboard built on web application technologies.
Dashboards tend to vary in styles and designs, however, there is a common pattern of putting the navigation panel on the left-hand side. This small design decision tends to separate a dashboard from a standard website.
Overall, there is a surprising amount of different interpretations of websites vs web applications. And undoubtedly, there are overlaps in many aspects. Still, the differences between the two seem to revolve around user interaction and logical complexity.
Web applications have the capacity for an endless amount of functional depth. While websites are more focused on content and highlighting information.
The ability to differentiate between the two, allows you to choose the right one for your business, idea or project.