Skip to content

Aquent | DEV6

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Options for Distributing and Packaging Web Applications

Written by: Chad Upton

Locally Rendered Web Apps

These are the most common web apps, the kind that are downloaded from the web server and are rendered locally in your browser. They are great in many ways and are especially light on the server since much of the logic and processing is offloaded to the user’s web browser.

The technologies used for local web apps are typically HTML, CSS, JavaScript and variants or extensions of these. The last blog in this series Choosing a Front-End JavaScript Framework covers some of the most popular frameworks to choose from in this area.

Server Processed Web Apps

Ultimately, these applications are rendered in the user’s browser with the same technologies (HTML, CSS, JavaScript); however: the layout, state and styles may be pre-rendered on the server when the user requests a page and the business logic that affects the data and the state of the application may be written in a language other than JavaScript and executed on the server instead of in the user’s browser.

Local web apps are not always well indexed by search engines, particularly when they are single page web applications – websites where the pages change but the URL may not. Google can and does process JavaScript to render and interact with single page applications but it’s not perfect and of course Google isn’t the only search engine out there. This is one of the reasons that server processed web applications are an option. That means server processed web applications may be a good choice for public facing applications that depend on search engine traffic.

On the flip side, applications that are behind your firewall or behind an authentication page do not depend on search engine traffic and server processed web apps are not necessary, at least for Search Engine Optimization. However, there may be other reasons why server processing is right for your application.

This option may also be selected if the development team is particularly skilled in a backend technology that is also popular for rendering web applications (ASP, PHP, etc). I would caution against deciding on server processed web apps if this is the reason since it may not be the best technology choice for the application. It’s usually easier for developers to learn the best technology than adapt the technology to the application.

If your first choice for front-end framework is typically rendered locally in the user’s browser, it’s important to know that there are some ways to get the best of both worlds.

Angular is of course the most popular front end framework and a lot of applications are built with it; and although Angular is a locally rendered framework it can also be used with PhantomJS or Node.js modules to render it on the server for additional speed and/or search engine indexing compatibility.

React can also be rendered on the server, and AirBNB open sourced Rendr to provide server-side rendering support to Backbone applications. So there are multiple options out there if server-side rendering is something you need now or want to have in your back pocket down the road.

Mobile Web Application

A mobile web app is a web application that is optimized to run in mobile browsers (tablets and phones). The same application may also use a variety of techniques to take advantage of desktop screens when they’re loaded on larger screens. The best websites change the way they look to be optimal on different screens and there are different approaches to do that.

Google actually has a recommendation for how this should be done, at least when considering Search Engine Optimization. That said you’re certainly welcome to deviate from their recommendation if your application is behind the firewall and SEO is not a concern.

The three methods that Google identifies are:

  1. Responsive Web Design
  2. Dynamic Serving
  3. Separate URLs

Responsive Web Design is one popular method where the component sizes and the styling define percentages and thresholds to describe the layout of the components in the application. Some people may further differentiate responsive design from adaptive design, but for the purpose of SEO they are treated the same because the URL and the page HTML remains the same in both.

In responsive web design, components on the page are laid out in a flexible way so they gradually grow and shrink depending on the user’s screen width. Adaptive web design defines specific thresholds at which the layout or sizes change. These thresholds typically represent common screen sizes for phones, tablets and laptops/desktops. For the purpose of SEO, both meet the needs for Google’s recommendation.

Dynamic Serving is a method that used to be very popular and may still be used in cases where the web server is dynamically generating the page. Regardless of which screen size a user is on, the browser will be at the same URL but the server looks at their screen size and generates page code that is most suitable. This is not recommended for SEO because the page’s content changes and Google’s spider may not see the same thing that a user sees which makes search results less accurate.

An even older method is Separate URLs. In this scenario, usually when a user first requests the page, the server will look at their screen size or device/browser type and direct them to a mobile version of the website. Sometimes it is the same site that is rendered with different templates and other times it is completely different site code that may or may not be similar to the other. This is probably the worst for SEO since chances are good that there will be differences between what Google’s spider indexes and what many users will see.

On the other hand, having separate templates for mobile and desktop screens may have some advantages if your pages are very large. Of course, page size should be reduced as much as possible but there may be use cases where the page size can be trimmed for mobile and that may be a good reason to do so. Since dynamic module loading is also becoming popular, this is another way to lighten the load on a case by case basis.

Since Google recommends it and we’ve had very good experience with it, we often use Reactive Web Design or Adaptive Web Design and sometimes a combination of the two.

Hybrid Mobile Apps

A hybrid mobile app is a web application that is packaged as a native mobile application. The developer created it with web application technologies (HTML, CSS, JavaScript) but then used a tool to embed that web app in a native mobile application container so it can behave more like a native app. The user installs it like a native app; typically from the app store or other accepted app install methods on the target platform(s).

There are different reasons why a developer might choose this path.

  1. They know web development technologies the best so it was fastest to build a native app.
  2. There was a compelling reason to use web tech but they needed access to system level information or services that aren’t consistently available to web apps (push notifications, vibration, battery level, etc).
  3. They had specific parts already written for the web and this was the most sensible way to reuse that code when building a native version.
  4. They want the ability to update application code without resubmitting apps (where allowed).

There are a number of tools available to package web apps as native mobile apps:


PhoneGap is the most popular distribution of Apache’s free and open source Cordova mobile application framework. PhoneGap makes the Cordova framework a little nicer to work with by providing some additional tooling, plugins and services.


Ionic is also built on Cordova, however it includes Angular as its opinionated way of building hybrid mobile applications. Both Ionic and PhoneGap offer cloud based build solutions so you can reduce the pain of packaging native apps by offloading some of the overhead to them, things like: framework updating and configuration, key management, etc.


NativeScript is trying to do things a little differently. A single NativeScript codebase will look different (and native) on each platform (Android, iOS, etc) without the developer doing anything to make them look different.

With PhoneGap and Ionic, the developer would have to add templates or styling for each native platform look they want. But NativeScript doesn’t require that because instead of wrapping web technologies in a native application shell, they actually convert web apps into native applications. That means the user is seeing the actual components that are native to that mobile operating system instead of web applications that are styled to look native. The benefit is the components look and work exactly as a user is expecting them to on each platform without the additional styling work by the developer.

Hybrid Desktop Apps

These are native desktop applications that are built with web technologies instead of native desktop application tools. Most of the same reasons to build hybrid mobile apps also apply to hybrid desktop apps.

This category is much younger than hybrid mobile apps. We could say that Adobe pioneered this space in 2007 with the introduction of their AIR platform which packaged Flash (and Flex) web applications into a native shell for execution on Windows, Mac and Linux.

I built a number of AIR applications back then and it was a very nice rapid prototyping and tooling platform since it had a lot of the benefits of building Flex apps for the web (rich component set) but it didn’t suffer from the same cross domain restrictions as a web browser, so it was great for building prototypes or tools for testing web APIs or processing and/or displaying data extracted from other sources.

So, I think desktop applications built from web technologies is a good idea but as the industry moves away from Flash and Flex we have to consider other options:


This is the newest modern way to build hybrid desktop apps. It is made by the wonderful people at GitHub and supports Windows, Mac and Linux. It uses Chromium and Node.js at its core, which means it’s fast and has a large community of developers making compatible plugins and libraries.


Formerly known as node-webkit, NW.js gives you access to Node.js modules directly from the DOM. It’s a few years more mature than Electron and it’s got better support for Chrome Apps and APIs and older Operating Systems. On the other hand, Electron has crash reporting and ARM CPU support so choose carefully.


People may be thinking of AppJS, but this project has not been developed for a few years and they now recommend looking at Electron and NW.js.


As you can see, there are numerous options for building and deploying web applications. The route you choose will depend on your audience, how they need to use your application and what system features your application needs to access. Once you have selected your distribution method, you can look at my previous post to help decide on a framework to get started.