Vaadin Dev Day videos published

Vaadin Dev Day

Vaadin Dev Day Raleigh and Dev Day Munich are just around the corner, so we wanted to release the material from the previous Dev Days. Those Vaadin Dev Days were held in Berlin and New York in May. If you couldn’t attend then, we now have made the video recordings available for you. The topics were:


So sit back, enjoy, learn and please share your comments in the videos.

If you are eager to learn more with Vaadin, the Vaadin Dev Day series continues with fresh topics on November 29th in Munich, Germany and December 1st  in Raleigh, NC, United States. Make sure to reserve your seat and learn how to really master Vaadin.

Vaadin Dev Days are one-time events organized around the world. This is the third time we organize a Vaadin DevDay.

Read more about Vaadin Dev Day

Building Progressive Web Apps: Webinar and Tutorial

Progressive Web Apps are web applications that utilize the best features of the web to provide app-like experiences. As users visit your web app, the apps progressively become more like native apps with offline support, push notifications, and the ability to add your web app to the home screen of their device.

Last week we presented the Building Progressive Web Apps webinar. Check out the webinar page here.

As a companion, this blog post will show you how to set up a simple progressive web app with Vaadin Elements and Polymer.

Your completed app will look like this:
Demo PWA that you'll be building

Getting started

First, install the Polymer CLI and the Vaadin Elements generator. This will build out a basic app that you will modify to add progressive web app features like service worker and offline support.

$ npm install -g polymer-cli generator-polymer-init-vaadin-elements-app
$ polymer init vaadin-elements-app

Serve the app with the Polymer CLI to see this basic app.

$ polymer serve --open

This runs the app, however if you disconnect from the internet or set your browser to offline, then you’ll see that your app stops working.

PWA going offline and failing


Tools for working with Progressive Web Apps
Chrome Developer Tools has an applications tab, which is perfect for working with Progressive Web Apps. You can toggle the network, you can inspect the service worker, and you can view and clear the cache.

See Chrome DevTools at the Google Developers site

Service Workers and offline support

To add offline support to the app, you’ll use a service worker to cache resources and display the cached app when there is no network connectivity.

Service Workers

A service worker is a programmable proxy that runs in a separate thread from your code. It cannot access the DOM and it can run even after you close your app. The service worker works in conjunction with your app to provide fast startup, background sync, and offline support. For this example, you’ll use a service worker to help run your app offline.

Diagram of application talking with the service worker proxy

Learn more about Service Workers at the Google Developers site

The App Shell Model

The first thing you’ll do is make sure that when users visit your app they are presented with something, anything that’s not an offline dinosaur. One way to do this is to serve up the basic shell of your app before there is even data to put into it. This is called the app shell model, and it enables you app to still look like an app even without network.

Learn more about the App Shell Model at the Google Developers site

Trying it offline

Your app has already been set up to work as an app shell. You just need to make sure the service worker serves the correct data.

The basic app is already set up to load a service worker when you first visit it, but if you inspect the service-worker.js file in your project directory, it will read:'Service workers will be generated at build time.');

So to get service worker support you will need to use Polymer to build your application. Run:

$ polymer build

This will create two build folders: an unbundled folder, which is optimized for HTTP/2, and a bundled folder, which bundles all the assets into as few files as possible. You’ll serve the the bundled build for now.

If you check the service-worker.js in the build/unbundled folder you’ll see that there is now quite a bit of data there that was generated in the build step. This built service worker will serve just the shell of your application.

Next serve the application with:

$ polymer serve build/bundled

When you refresh your browser then the app will be there as expected, but when you then go offline and refresh your page, you’ll see that the basic shell of the app still loads. The service worker takes the basic skeleton of your site and serves it to the visitor.

PWA app shell working offline

Despite the shell loading, no data is served up. This is better than displaying the offline dinosaur, but it is still a bad experience. Next you will implement caching with service worker.

Toward real offline functionality

We can assume that the employee data used in this app doesn’t change very often, so it’s reasonable to serve up the latest cached version of that data so that the user can see it even when offline. Then, when the user comes back online, the cache is replaced with the latest data from the network.


To implement caching, you can use sw-precache a tool that makes it easy to set up service worker caching. sw-precache will look through your project and cache the resources you’ve specified in a config file.

Open up sw-precache-config.js and change it to read:

module.exports = {
  staticFileGlobs: [
  runtimeCaching: [{
    urlPattern: /^http:\/\/localhost.*json/,
    handler: 'networkFirst'
  navigateFallback: '/index.html'

The staticFileGlobs section is where the application shell is cached. Those three files are static files that the service worker knows explicitly to cache.

The runtimeCaching block, on the other hand, tells the service worker which files loaded by the application should be cached. These are files that will be cached when they are first loaded into the app. The urlPattern is a regular expression matching json files in our app and handler is a the caching strategy your app uses for these files.

As mentioned previously, the service worker is a programmable proxy that lives between your application and the cache or network. Requests will go through the service worker and then the service worker will decided how to handle those requests using handlers.

networkFirst is a caching handler for the service worker that says that when a json file is requested, first try to grab the latest version of the file from the network, and if that request fails, then serve the copy of the json file from the cache. networkFirst is just one of many handlers provided by sw-precache.

Read documentation for sw-precache and caching handlers on Github.

Putting it all together

Because sw-precache is a build time tool, you’ll need to rebuild the app to implement this runtime caching.

Clear the build directory and once again run:

$ polymer build
$ polymer serve build/bundled

Now make sure you’re online and refresh your app twice. The first refresh is to enable the new service worker to see the app and the second one is so that the service worker grabs the latest version of the json file and puts it into cache.

Now when you go offline and refresh you’ll see that all the employee information remained in the application.PWA Working Offline


This is just a brief example of what you can accomplish with progressive web apps. You can find out more about progressive web apps in a number of places:

Vaadin is very focused on progressive web apps so keep following this blog for more tutorials about PWAs.

We Are Vaadin - Devarsh Desai

I caught up with Devarsh Desai on an Ask Me Anything session via Skype. We discussed how the last few months have been, the challenges he faces ahead, and any advice he might have for new candidates.

Devarsh met the team at an HTML5 Developer Group talk at Google in San Francisco. “It was actually my first introduction to Vaadin’s work with Polymer and had a really good time that evening. As luck would have it, I began speaking with Vaadin’s recruitment team a week later, hit it off with the US engineering group a couple of days after that and before I knew it, I was wrapping up my on-site interviews”.

He’s enjoyed working on his first case project which deals with an end-to-end platform for the registration, management and delivery of geofences. “The intersection of business knowledge required to lead a project as well as the technical competency for the implementation is a lot of fun. Within a couple of hours on any given day, we’ve had meetings with CEOs and CTOs on the direction of our project and then immediately after that an internal talk on Shadow DOMs and Shady DOMs. The dichotomy between business and technology is great, and I’m pretty fortunate to be able to learn on both those topics.”

Life is a continuous learning curve and Devarsh is studying at UC Berkeley. “I’m also a phlebotomist, that means I take samples from my patients through their antecubital veins in their arms and hands. The biggest thing I’ve learned is how to listen to my patients. It’s an invaluable skill, and I try to make my customer meetings a reflection of the same critical thinking. I’m also concurrently enrolled at U.C. Berkeley where I study chemistry. While it doesn’t directly translate into a beneficial relationship for work, I’m fortunate that I’m able to study while working full time, and that refreshed feeling I get from studying the hard sciences makes my day that much better.”

It is great to see new faces, personalities and skills at Vaadin. If you haven’t seen them yet, also check out Sebastian from the Berlin office and Johannes from Vaadin HQ before to get to know more people at Vaadin.

To see yourself here, check out the open positions at and apply today. If you have any questions or comments, leave a comment below!