Building a Progressive Web App (PWA) - blog series

We've started a cool blog series here. The three words on everyone's mouths these days are Progressive Web Apps - or PWA for short. It is predicted by Google to revolutionise the way we build and consume mobile apps. A true challenger to native apps. Just build your app the way you normally do, implement a set list of features and support (for offline, etc) and your webapp will work just as an native app on mobile! Access to bluetooth? No problem. Install on homescreen? No problem.

Follow us on our journey to investigate PWA more, and how we build our first PWA! We start out from the very beginning by exploring all the different alternatives we have for front-end frameworks and back-end frameworks. Follow our reasoning, learn from  our research, and keep the comments coming!

So far we have two posts published (stay tuned for more, we'll be blogging about this until the app is ready for download):


Part 2: RESTless search for a front-end framework

What happens when our developers are challenged to choose a front-end framework suitable for our Progressive Web App, and at the same time to drop the RESTful approach for the new-kid-on-the-block: GraphQL? This is the second post where we share insight from our development team when building a PWA from scratch.

Read entire article


Part 1: Background and Back-end

Have you been forced to build apps for iOS and Android to stay relevant? Are you annoyed by websites pushing it's native app every time you visit? Did you ever wish you could use web-technology instead? The solution is finally here - it's called Progressive Web Apps (PWA).

Read entire article

In a series of articles we explore all you need to know about how to design and build a Progressive Web App from scratch. What is it? How to build it? What components are needed? What are the backend needs? What are the frontend needs?

Continue reading »


Building a Progressive Web App - part 2: RESTless search for a front-end framework

Missed the first post? Building a Progressive Web App - Part 1: Background and Back-end

The Office League

Time was ripe for a better name for our project than "the foosball app". With big dreams of building an online community of Foosballers, we went megalomaniac as we realized the concept could be applied to just about any "office sport". By launching the app as a service, we can enable players across "sports", companies and nations to enjoy friendly office battles!

One thing leads to another, next a concept of leagues falls into place. Anyone should be able to sign in and create a league of their own. A league should be associated with a sport, such as foosball, ping-pong, dart and who-knows-what. And so begins the history of  "The Office League" !

The fabulous world of front-end frameworks

Developers love to cut code, but history has told us this it is not always the fastest way to results. Thus, we decided to identify the frameworks out there that would fit our modern web-application requirements:

  • Routing (sending you to the right view based on url)
  • Client side rendering of pages and components
  • PWA capabilities (caching, push etc etc)
  • Testability (making it more agile and robust)
  • Performance and more..

In short, we're looking for a modern Model-View-Controller (MVC) framework running in the browser.

The developers were split into three teams, independently given the job to identify potential candidates for the job. Next, they would present their findings and declare their favorite! The following day, they would use the selected framework to implement an "Office League" prototype.

Meanwhile - in the back-end

Two developers were isolated from the rest, and given the daunting task of composing a back-end prototype for the Office League. We had been peeking at an exciting piece of technology called GraphQL, and wanted to give it a go. Maybe this could be a better solution than the traditional RESTful approach?

In short, GraphQL is a new and effective way of building http API's. It origins from Facebook and has grown very popular in little time. This is not surprising when looking at the benefits GraphQL brings to the table:

  • Fast - get exactly the data you need in a single request
  • Strongly Typed and self documenting - quickly understand the API you are using
  • Supports both read and write, a.k.a. queries and mutations
  • Language neutral, as it is based on JSON
  • Early solution for server-events a.k.a. subscriptions

Surprisingly many tools are already available, like the API browser GraphiQL and the various tools form Apollo including production grade javascript clients.

GraphiQL interface shoing query, result and documentation panels
Screenshot of GraphiQL querying "players" in the prototype API

If you are more curious about GraphQL, check out Awesome GraphQL for an extensive list of resources.

As we just had one day to create a live back-end prototype, with testing data, and had little experience with graphQL before in combination with Enonic XP, we went with the graphql-express API on Node.js and booted a server on Heroku.

Test data was retrived from the spare-time-project Foos app and placed in simple JSON files on disk. Finally all the hard work put into "collecting data" a.k.a. "playing foosball" would come in handy!

At the end of the day we had a fully functional graphQL API running, ready for the teams to use with their favorite frameworks. We already concluded that GraphQL looks like a REST-killer and will share more details on this in our upcoming posts.

Framework research

Showing logos of popular front-end frameworks
Polymer vs Angular vs Ionic vs React

In total, our three developer-teams had quickly researched four frameworks. Here is how they ranked them and why:

#1 Polymer - by Google

All three teams actually ranked Polymer as their favorite, with the following comments:

  • Installs quickly
  • Huge set of components
  • Lightweight
  • Based on Web Components
  • CSS encapsulation
  • Lots of documentation
  • PWA supporting tools

Apparently, the only downside was Polymer being less popular than Angular.

#2 Angular 2 - by Google

Ranked second amongst two teams that investigated it with the following comments:


  • Big community
  • Uses Web Components extensively
  • Material library
  • Plus for using Typescript (as we have been using typescript for years already)
  • Fast - when loaded
  • Mobile toolkit in progress (for PWA support)


  • Appears to be high initial loading time
  • PWA tooling is not finished yet
  • Not suited for server-side rendering

#3 Ionic Framework - by Ionic

One team looked ad Ionic and gave the following comments:


  • Large component set and feature rich
  • Appears to be mature
  • Based on Angular and supports Web Components
  • Good community and traction


  • Built for "hybrid" apps and using native bindings (not what we are looking for)
  • PWA support is still emerging, but Ionic could become really interesting in future versions based on their statements regarding PWA

#4 React - by Facebook

All teams looked at React, and ranked it last - or as one team put it, number 10 out of 3.

React is hugely popular these days, so one might wonder - why all these negative vibes then?:


  • Very popular
  • Lightweight
  • Performant
  • Supports server-side rendering (isomorphic style)
  • JSX


  • Not a framework by itself - just a piece of what you need
  • Steep learning curve
  • No component system or encapsulation
  • Requires writing CSS in Javascript
  • No PWA support
  • Licensing issues (already popular forks out there)

In short the developers argue using React will be a longer and more complex approach over the more integrated frameworks from Google. Also, the license put us off.

Frameworks in action

Three teams of developers cannot be wrong, right? Polymer was dominating in the first round. Now the gloves come off as each team gets a full day to build a prototype using their favorite framework. Only problem is, just one team will use Polymer as we need to see how the other frameworks play out as well.

As no-one wanted to use React, and Ionic was pretty much ruled out for the moment - the remaining teams set out using Angular 2 and Aurelia?!. Aurelia was suggested as interesting alternative to the other frameworks, so why not throw in a wildcard in the game?

Team Polymer

The polymer team managed to deliver a fully functional and good-looking prototype, extensively using the GraphQL api provided. The prototype provided a nice user experience handling responsive design, navigation and routing with nice url's and re-use of components across pages. Additionally the team managed to make large parts of the app support "offline" mode thanks to the PWA toolkit provided by Polymer. It should also be noted that one of the developers had some previous experience with Polymer, and also got the opportunity to put in an extra day of work.

Mobile screenshots showing listing of games and top ranking players
Screenshots from the Polymer prototype

The team points to the following benefits of Polymer:

  • Get started fast
  • Easy to learn and understand
  • Built-in web server and package builder
  • Web Components with isolation of HTML, CSS and Javascript inside the Shadow DOM
  • Big library of UI and helper components which solves complex issues such as google api components  (analytics, maps, youtube), infinite scrolling, ajax requests, offline storage, modal dialogs etc.
  • Lots of custom components made by community members
  • Common/shared CSS styles can be easily imported inside a component via style modules
  • PWA support through toolbox
  • Localization support
  • Two-way data binding
  • Support for gesture events (down, up, tap, track)
  • Super-simple event handling: specify event listeners via element attributes
  • Auto-generated documentation
  • Easy to test (tests are shipped with components)

The following was identified as negative:

  • Event communication between components might not be straightforward
  • Have to include entire WebComponents library and Polyfills
  • Examples in the official docs are not diverse enough
  • Limiated community, so there is not so much help on Stack Overflow etc.

Team Angular 2

The Angular team only consisting of two people produced a fully responsive prototype with navigation, routing, nice URLs and component re-use. Even if it required more effort than for the Polymer team, they also managed to add offline support for the Prototype. One of the developers had been experimenting with Angular for a few hours on his spare time, so that gave them a quick start.

Mobile screenshots showing lists of games and teams
Screenshot from the Angular prototype

The Angular team were impressed with the framework and how cleanly it was built. Also, the application seems performant and easily maintainable.

The team highlights the following benefits of Angular 2:

  • ES5, ES2106 compatible
  • Written in Typescript
  • Extensive use of Web Components
  • URL routing
  • Readable code
  • Data binding
  • Uses annotations
  • Easy to learn (natural and logical)
  • Dependency injection
  • Loose coupling - good for testing (toolbox generates test-skeletons)
  • Huge community
  • Toolbox - ngserve

The negative side of things are said to be:

  • A lot of files
  • Big footprint
  • Toolbox is under development

Team Aurelia

So, how did the "wildcard" team do? Unfortunately the result suffered from many smaller issues not directly related to the framework. Nasty url's (which could easily be fixed they assured),  and poorly working responsiveness was obvious. Routing appeared to be working fine. All-in-all the team only managed to produce parts of what the other teams made - in the end the most exiting part of the prototype was the name: "Foosbook" :-).

The team pointed out that Aurelia was entirely new to them, and that they lost some time initially getting installed and figuring out use of things like the http-req library.

Screenshot listing games
Screenshot from Aurelia prototype

Summarized the team highlights the following benefits of Aurelia:

  • ES5, ES2106 and typescript compatible
  • Uses Web Components
  • Full routing support
  • Easily readable code
  • MVVM approach
  • Configurable data-binding
  • Convention over configuration
  • Easy to learn
  • Testable with dependency injections

and also points out the following potential caveats:

  • Smaller eco-system compared to the alternatives
  • Commercial bindings (could also be a plus in some cases)
  • Hard to come across examples and documentation
  • No big success stories (so far)


The tems jointly consider Polymer as the best framework for a typical web-developer with Javascript background. Angular 2 appears to be better suited for developers coming from typed programming languages languages such as Java and C#.  This is in particular reflected by the fact that every Angular component has a Typescript class as its core, where Polymer uses an html-template definition.

The fact that Angular 2 is based on Typescript was also considered as a big plus for our team, given the fact that the Enonic XP UI has been built entirely using Typescript and we value the benefits this brings to more complex applications.

Aurelia was considered similar to Angular in many ways, but remained the outsider also after testing it.

In the end, there are striking similarities between all these frameworks when it comes to how they work and the features they provide - we believe all frameworks are of high quality and recommend you to evaluate what fits best for your project and team.

When forced to choose a framework the developers were now split right down the middle. Given the equilibrium our CTO (yours humbly) tipped the weight in favour of Angular 2 for three reasons:

* Angular is very popular so our project might be relevant to more people
* We want to learn more about Angular 2, as we are considering using it for future development of the Enonic XP UI
* The MEAN stack (A for Angular) is an alternative to Enonic XP in certain projects. Thus, adding Angular starter kits and examples to XP makes perfect sense.

We now embark on the real tasks of creating the Office League, using Angular, GraphQL and Enonic XP - or the AGE stack if you like :-).

Look forward to our next post in the series - where the data-model is established and the application interface starts to take shape.

What happens when our developers are challenged to choose a front-end framework suitable for our Progressive Web App, and at the same time to drop the RESTful approach for the new-kid-on-the-block: GraphQL? This is the second post where we share insight from our development team when building a PWA from scratch.

Continue reading »


Building a Progressive Web App - Part 1: Background and Back-end

Native applications can deliver amazing user experiences, but at the same time building and maintaining them can be both expensive and hard. Native apps run on mobile operating systems such as iOS and Android, or desktop variants like Windows, MacOS and Linux. Developers have to build, test and distribute software for multiple different platforms, often through proprietary app-stores. Additionally they must build and maintain web-based back-end services to support them - often using an entirely different set of tools and technologies.

As users tend to stick with a limited set of trusted applications, native app adaptation is declining. The threshold for finding and installing new applications is high. Analysts predict, as much as 20% of brands will abandon their native apps by 2019 - likely replacing them with Progressive Web Apps. If you haven't tested a PWA already, check out PWA rocks.

Progressive Web Apps are made possible through a combination of several new web technologies, and marks a paradigm shift for the web - it has the potential to greatly simplify development and distribution of software.

Some things you will love about PWA's:

  • Instant loading (No install)
  • Automatically updates
  • Offline support - Yes, completely offline
  • Add web-apps to your home screen
  • Works with regular Url's and supports deep linking
  • Push notifications
  • Access to Bluetooth and other native capabilities
  • No proprietary app-stores
  • Everything else you love about the web
  • and more.

Google massively promotes PWA, and I'd recommend you to check out this video by Jake Archibald from the Google I/O Conference.


Allow me to introduce myself. My name is Thomas Sigdestad, I'm Co-founder and CTO @ Enonic.

This post is the first In this series where we will take you on a journey with our development team, as we embark on a mission to create a full-blown Progressive Web App from scratch. Mixing application and content is another major issue for a lot of projects, so to raise the bar, our PWA must also provide editorial content and general marketing capabilities such as search engine optimization.

Our goal is to practically explore every relevant aspect of PWA from front-end to back-end, hit a lot of problems and hopefully come up with good and practical solutions. During this endeavour we expect to learn a great many things, and we will be sharing our discoveries through new posts on Webagility.com.

The Foosball App

To push the limits of the web we need to build a web-app that touches as many different use-cases and technical features as possible. Here are the overall requirements for the project:

  • Both developers and non-techies must be able to relate to the concept
  • Should have an interesting data model, with potentially big volumes
  • Needs to provide a relevant offline experience
  • Support storing of personal settings or data
  • Login support with popular ID providers such as Google and Facebook
  • Support User generated content
  • Provide transactions of some kind
  • Relevant use of push notifications
  • Nice URL handling and deep linking support
  • Include public facing content, for easy access and search robot indexing
  • Support localization
  • Re-useable beyond Enonic, potentially as a cloud service
  • Interaction with physical devices / IoT if possible

After some hardcore brain-twitching, we realized some of our most eager in-house developers already had a spare-time project that could be used as inspiration - an app to keep track of players and scores for Foosball. Foosball is happily played in every break - and the competition is fierce!

Two men playing Table Football in an office room
Alex and Glenn playing Foosball during a break

Turns out the potential features of a Foosball app is unlimited, and in our case - the perfect project to maximize developer engagement. At the time of writing we have identified the following features we can implement:

  • Public pages for marketing the "Foosball" service, rules, etc etc
  • Login to register new players
  • Teams, players and games would be the core datamodel - with a growing data-set
  • Notify players of upcoming games, or changes to their ranking
  • Offline support for playing and recording games
  • Deep linking into content, player statistics and game info
  • User comments on games played
  • Challenge other users for a new game

We're building the Strava of Foosball! :-)
Some Enonic Developer

Choosing a Back-end

As we're building a PWA, we stricktly don't have to choose a client, but we'll be focusing on using Chrome as it apparently is the most mature browser in terms of PWA.

To build the back-end of the Foosball app we will need a great many tools to deliver on the requirements:

  • Database to store the data
  • App engine to build and run the various services
  • Web server to deliver the PWA and assets
  • Basic identity handling
  • Content Management System for the marketing parts
  • Search engine to produce reports
  • In our case, everything should also be portable across clouds, including on-premise.

Facing a task like this, most teams will compose and integrate a suitable stack of tools, based on what their developers know and recommend - or what is "company standard". There are dozens of applications stacks out there from the "hip" Javascript-based MEAN stack through more established platforms such as .net, Java and the LAMP stack. Additionally we will most likely require search engine, a CMS, and an Identity system. For the search engine we could for instance use Elasticsearch. For Content Management Systems pretty much nothing is defined at the moment, which means we could do anything from a "headless" approach, via Wordpress to more advanced solutions.

In our project we're setting off with "company standard" infrastructure. The fact that we are a software company that builds this web infrastructure for a living makes it a lot more interesting. From a management perspective this is considered an excellent opportunity for dog-feeding :-)

At Enonic, our main effort is an open source platform called Enonic XP. Enonic XP provides a "stack-in-a-box" approach to web-development. Providing the essential API's required to build and deliver mission-critical web applications.
Some highlights are:

  • Javascript App Engine and web server (based on PurpleJS)
  • Embedded Storage and Search (based on Elasticsearch)
  • System for identity and role handling (pluggable with 3.rd party systems)
  • Content Studio for editorial content (supports both headless and rendered modes)
  • Built with Java and runs in any cloud

This means XP should provide the essential tools we need. Missing capabilities identified during the process will be fixed or added. We're ambitious in making XP the preferred platform for PWA projects out there.

Enonic XP can conceptually be compared to traditional OS', in that it provides everything you need to run web apps, rather than native apps. We actually refer to it as "The Web Operating System" - or WOS among friends.

Web Operating System illustration - Enonic XP logo with three round bubbles showing App Engine, noSQL Storage and Web CMS
Central components of Enonic XP - App Engine, NoSQL storage and Content Management

Enonic XP aims to simplify developent, testing, deployment, distribution, and scaling of web-apps and their back-end services. While providing freedom in choice of frameworks and clouds.

In our next blog post we will deliver a spec for the Foosball apps and choose a front-end framework...

Have you been forced to build apps for iOS and Android to stay relevant? Are you annoyed by websites pushing it's native app every time you visit? Did you ever wish you could use web-technology instead? The solution is finally here - it's called Progressive Web Apps (PWA).

Continue reading »