Websites vs Web Applications – A Full Comprehensive Guide

web applications vs websites

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 HTML, CSS, and JavaScript
  • 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:

FeaturesWeb ApplicationWebsite  
SEOWeb Applications are rendered with JavaScript. This can result in an application being not as crawlable by Google bots.Websites have clearly defined HTML markup for its content. Very easy and crawlable for search engines to understand
PerformanceWeb 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 FunctionalityUsing service workers, web applications and progressive web apps have incredible offline functionality.Websites have limited offline capabilities without any technologies such as service workers
SizeWeb applications tend to have a bigger JavaScript assets. Although minifications and optimisations do take place. The increased interaction needs more logic, so the code resources are of a bigger sizeStatic websites tend to be smaller than a web application as heavy user interactions are encouraged less
PresentationWeb 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.
InteractionWeb 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:

  • Portfolios
  • Blogs
  • Brochure Websites for products
  • Ecommerce shops
  • Info Product Demonstrations
  • Contact
  • Locations

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:

  • Gmail
  • Google Sheets
  • Facebook
  • LinkedIn
  • Trello
  • Slack
  • 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?

Caching

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.

Notifications

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

Push 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.

In-app notifications

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 include 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

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 a item
  • Saving an item
  • Editing and item
  • Attempting a task that needs to be logged in
  • Attemping a tasks that require an account
  •  

Messages such as “data saved” or “item deleted”

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 

SEO

There are definitely some considerations around the strength of Search Engine Optmization (SEO) for web applications.

As most web applications are built with JavaScript-heavy frameworks, there is concern over the ability of external web crawlers such as Google bots to decipher the markup of the page.

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.

Web applications using these latest JavaScript technologies do not explicitly have this semantic markup available to read until after the JavaScript code has been executed.

Webpages, however, have this markup visible from the moment the user or crawler requests and receives the web page.

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

If we look into another statement, it is evident that Google still advises caution regarding JavaScript SEO.

“Sometimes things don’t go perfectly during rendering, which may negatively impact search results for your site . . . Sometimes the JavaScript may be too complex or arcane for us to execute, in which case we can’t render the page fully and accurately . . . Some JavaScript removes content from the page rather than adding, which prevents us from indexing the content.”

The rest of the article can be found here.

And although Google is still optimizing its approach to crawling JavaScript, it is one of the very few search engines doing so.

The key takeaway from this is that in 2019, even with positive information from Google, we cannot rely on search engines to correctly crawl and render a JavaScript web application.

It is too much of an intensive resource for Google to crawl and will likely underperform in search results.

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 application.

For example, user navigates to landing page —-> browser requests landing page from the server —-> server responds with landing page. —>

Rinse and repeat for every single page the user navigates to.

In comparison, the process for a single page application looks like this:

user navigates to landing page —-> browser requests landing page from the server —-> server responds with JavaScript —> browser executes JavaScript 

There will not be another reloading of the page, the application is fully accessible because of this JavaScript execution hence the term single page application.

This saves a significant amount of bandwidth, time and is a much more pleasant experience for the user. The slow refresh experience from a conventional website has been eliminated.

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

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.

Gareth Dunne

Full Stack Developer and creator of JSdiaries. Passionate about the latest in web technologies and how it can provide value for my clients.