geo and code musings

23 Aug 2017, 19:28

It would be a fair assessment to state that Progressive Web Apps (often abbreviated to PWA) are a popular buzzword in the web development and JavaScript communities at the moment. We have also seen further excitement recently, generated by Apple’s move to start supporting development for PWA features within Safari.

Many great posts and documentation exist around explaining the full case for PWAs and how they benefit users. For a solid introduction to Progressive Web Apps check out Google’s page on the matter. In addition, if you’re looking for something tangible there’s also lots of great examples of PWAs that you can explore in more detail at pwa.rocks.

Perhaps now more than ever it’s time to start exploring how you can start looking into aligning your app or site with PWA functionality. This post will be more practical than theoretical, but to give some context I will list out some of the core concepts of what makes a PWA for those of you unfamiliar:

Pages are responsive: The app’s content fits in a sensible way on a tablets, mobiles etc

Site is served over HTTPS: assets and resources are served using encryption over the wire

The entry page loads offline for users

The app uses a manifest.json file to allow adding the app to a users homescreen

Load times are reasonable even on slower connections like 3G

Each page has its own unique URL

The site works across modern browsers

Here we will just focus in on two of these concepts and how to integrate them, namely adding a manifest.json file and adding a Service Worker. Subsequently, we can also use the Service Worker to allow the initial page to work offline by using a precache.

Adding a Manifest File

A manifest file provides a few additional weapons to the web app arsenal for developers. The file itself is fairly plain; a JSON file that contains configuration and metadata for various aspects of the application.

However what the manifest file allows for is a whole host of interesting benefits for those looking to give a more ‘app like’ experience:

Allowing users to add a web app to their home screen

Giving that home screen button a unique name and icon

Giving a splash screen to the app when the user loads it

Being able to add a theme colour for the web app

Define if the app should load ‘standalone’ or in a web browser

Now we’ve gone through why you would add a manifest.json file, let’s take a look at an example config:

You can see that we provide a name and short_name which give a name and an abbreviated name for the app when space is a premium. start_url expresses where the kick off URL for the application when the user starts the app. For example, it could be their profile page or the home page.

As mentioned, we can decide if the app should load in a web browser or have a more native experience. This is realised through the display property. We can provide standalone to give a more native feel as it hides away browser features like the URL bar (this may be a negative feature depending on your feelings!). There are other options for this such as fullscreen which hides OS UI features, and also minimal-ui which take a middle ground on the matter.

The background_color property allows for us to express a colour that will occur before the app has fully loaded into its container. icons provide a way to give icons for our applications at different device sizes. For a full list of options check out MDN’s page on the matter.

You could write the manifest file manually (see Google’s instructions here). However, if you want a more streamlined experience you could use a generator instead. One generator I found user-friendly and straight forward is the app-manifest app on Firebase, which you can use to generate a zip file which can be unloaded into your web app directory.

Lastly we can include it in our home page’s HTML as so:

<link rel="manifest" href="/manifest.json">

Adding a Service Worker

The Service Worker is a slightly more complex concept than the manifest file. In essence Service Workers are web workers that allow code to run outside of the web page context within the browser. The Service Worker also in some ways acts as a network proxy, allowing the developer to change the behaviour of network requests (i.e. to read from a cache rather than a remote resource). In principle, these two concepts allow for a host of new opportunities for web apps, including push notifications, offline interactivity and background sync (sending server requests upon resumption of connectivity).

Before we dive in any deeper, it’s important to note that Service Workers require HTTPS to operate, so you will need to have that setup on your site before continuing (checkout Let’s Encrypt if you’re in need of an SSL certificate).

Although we could dig in deep into the Service Worker internals and life cycle, I would rather focus on getting us up and running with a Service Worker. Others have done a great job explaining Service Workers in depth, for example see the Google primer on Service Worker or check out Phil Nash’s great introductory video here. Instead we will focus on one example Service Worker template that allows us to get a registered Service Worker into our page quickly.

An easy to leverage Service Worker template is provided by sw-precache. Using a precache allows you to serve resources from the Service Worker cache, rather than having to wait for it to come over the wire which improves the performance of the app. It also allows us to get resources whilst offline. sw-precache itself is a tool that allows for the automatic code generation of a Service Worker for caching assets that we would normally receive over the network (images, css etc). As sw-precache requires a preprocessing step to generate the Service Worker we need to leverage a task runner. Here we can use gulp, a JavaScript task runner to create a task to generate the list of resources we want to precache. Here’s some example code with comments:

Once the Service Worker is registered the user will make use of the cache when making network requests for cached assets.

Conclusion

Here we have shown how you could add a manifest and a Service Worker to your web app without complicating your application code too much. If you already have gulp in your build process integrating sw-precache shouldn’t be too much extra effort to get up and running. Similarly using the manifest.json app shown above we can simply generate a working manifest file for our application.

Hopefully, this article has begun to pave the way for further PWA features in your applications. Support is gradually getting there so the reasons to avoid the potential benefits are decreasing. If you are interested in auditing your app to see how much it adheres to Google’s PWA checklist, check out a Chrome extension called Lighthouse. Lighthouse will score your app depending on how well it compares a set of pre-defined criteria.

22 Jul 2017, 11:30

Wanting to explore more around geospatial tools with Go, this week I’ve been exploring Globe. Globe creates wireframe global visualisations of data sets, provided they contain latitude and longitude points. Here’s an example of the API from the README:

I decided that I wanted to build a web service that would allow users to generate an image (PNG) using some sort of interface. With a few free evenings I got to work!

The Backend

For all request serving activity I used the built in http package. Go has a fantastic standard library for building web apps. However I did find it a little tough to find sensible examples of file upload handling.

For extracting the geospatial elements of the data, I used Paul Mach’s GeoJSON package for extracting latitude and longitudes from GeoJSON and then used the standard library CSV package for the doing the same operation with CSVs.

Finally for the drawing; we use the aforementioned Globe package to do the actual drawing. This was all relatively straightforward minus hitting one issue around trying to use RGBA colors rather than NRGBA (non-alpha-premultiplied 32-bit color) colors with the library. It turns out NRGBA produces a lot cleaner results, you can see the issue on the Globe package here.

The app is hosted on Heroku. It took me a little while to get to grips with deploying Go apps on the platform (leveraging Go’s vendoring system was a first for me), but apart from that it was pretty painless. The GitHub push-to-deploy integration is also a very nice touch!

The Frontend

The frontend uses jQuery (boooo) as a general DOM/request helper library. It would have been relatively straight forward to replace these with smaller modular libraries but I was feeling a tad on the lazy side (Pull Request anyone?). For the user interface we leverage Skeleton CSS for the layout.

Spectrum.js is used as the colour selector, which we pass to the backend to generate the dots. To get unique file names, I leveraged a UUID library that prevents clashes.

Lastly, and potentially most interestingly, we make use of Turf.js to find the centroid of the latitude/longitudes. For those of you who aren’t familiar Turf.js is a geospatial analysis library for JavaScript, with a very powerful set of tools at its disposal for dealing with geometries. Mapbox’s csv2geojson was also used to convert CSVs over to GeoJSON so that it can work alongside Turf.js (it uses GeoJSON as it’s operating format). Overall I feel like this was a pretty nice solution as it allows for ‘smart defaults’ of the center of where the image is generated, without the user having to guess/analyse there data extensively.

25 Jun 2017, 14:59

There has been an on going discussion about wether Icon Fonts or SVG Icons are ‘better’ for usage on the web. This css-tricks article outlines the introductory differences between the two nicely. The author concludes that “If you can go IE 9+ / Android 3+, inline SVG is better at pretty much everything than icon fonts”. This view has been debated somewhat, with Tyler Sticka laying down a solid case for moving away from Icon Fonts and Ben Frain making a succinct rebuttal. The general consensus within the web development community appears to have been to move over to SVGs however.

One notable benefit I saw for moving to inline SVG was another opportunity to prevent unnecessary render blocking; the process by which content such as CSS/JS/Fonts slow down the rendering path for a page, preventing meaninful content getting to the screen whilst they load.

With this in mind I decided to use my own blog as a way to explore how to make this transition and critically examine any benefits (or problems) it might hold. This post will lay out my approach for swapping out my blogs icon fonts (on the left hand panel, or a the top if you’re on mobile!).

Steps

Remove the icon font CSS

In this case we were using Font Awesome. Font Awesome is a great resource, and I really admire what they’ve done. Of course however, this post is about removing icon fonts, so out it must go!

For the SVG Icons I am choosing to use edent’s SuperTinySocialIcons. These are very efficient SVG icons, covering the majority of your favourite companies/logos. This won’t cover none-social icons (arrows etc) that you might need, in my case I got the cube icon from the The Noun Project and ran it through Jake Archibald’s SVG optimiser. For a more robust approach checkout Sara Soueidan’s superb blog post about using fontello-svg to take Fontello (an aggregator for web fonts) fonts and convert them down to SVG.

Inline the SVG Icons

You might choose to link out to an external SVG asset, however for performance reasons I have inlined the SVG right into the sidebar, for example:

We need to do a little bit of extra work to take the coloured icons and convert them to monochrome. Taking the Twitter icon for example, we can get rid of the rectangle entirely to remove the light blue box:

Using a CSS class we can use vertical-align: middle to align the icons vertically and set the width to be in fitting with the adjacent text (16px). We could also just use direct inline CSS if desired.

Outcomes

By default Font Awesome CSS was 5.83Kb over the wire (23.18Kb uncompressed), plus the actual font itself 55.45kb (WOFF2 is compressed). That’s 61.28kb in total, plus two network requests. Using Fontello, I was able to get the font down to 3.17kb (!) by removing all the unused icons. So in total, at it’s most optimised we get down to 9.0kb compressed and two network requests (if uncached).

Inlining the SVGs in the sidebar for the index page takes the HTML page weight up from the original 8.85Kb (compressed) to 9.68Kb (compressed) increasing it by 0.83kb compressed. Using icon fonts in this case eliminated two network requests for render blocking content, and removed 8kb in page weight in the best case and over 60kb in the worst case scenario (using the default Font Awesome CDN CSS link). Lastly, I would say even if you don’t want to make the switch, at least investigate condensing your icon font usage usage down to the icons you use explicitly, using a tool like Fontello.

Things to note:
* I didn’t do any scientific experiments on actual page load times (boooo I hear you shout), however there has been some evidence to suggest there are some marginal losses in rendering using SVGs.
* IE9+ for support for SVGs (hopefully no longer an issue for 99% of developers)
* Similarly older versions of Android lack support (2.3)