Issue 2: Electron.js, Add to Homescreen on Desktop, Server Side Rendering & Ember, DevTools Dimensions and PWA Roadshow

Matt Gaunt
Totally Tooling Tears
10 min readMar 25, 2016

Totally Tooling Tears is a new companion to Matt and Addy’s YouTube show Totally Tooling Tips. It’s a raw weekly brain-dump of notes, issues and workarounds we’ve found building apps and libraries over the last 7 days. Co-authored by Addy, Matt and unicorn tears.

“Add to homescreen” for desktop webapps?

On mobile, the concept of adding a webapp to your homescreen is still something of a paradigm shift for a lot of users. Chrome on Android has been exploring ways of better surfacing this capability, such as Web App install banners and the ability to programatically trigger this action with your own UI. A question we’ve been asked a few times this week is what we’re doing about this experience on desktop.

The Chrome App Launcher we’re retiring

Well, related, this week we announced that we’re retiring the Chrome App Launcher on Mac, Windows and Linux. We always found it a super weird feature as it gave you a separate app menu mostly only targeted at Chrome apps (this makes sense on Chrome OS, but not outside of it) rather than being a first-class citizen.

Thankfully, there’s an another experiment available vying to bring a clean way for webapps to live alongside native apps called ‘the new bookmark app system’. It’s been kicking around in flags since last year (okay, not sooo new), currently lives under chrome://flags/#disable-new-bookmark-apps and the UX it offers may differ based on your OS. If you have an interest in features like this, the Chrome team are always down to hear feedback on what does and doesn’t make sense. We have a keen interest in this experience as it could lead the way towards us not needing tools like Electron for apps that don’t require as tight integration with the OS.

Windows

If you navigate to a Progressive Web App (or any site) you regularly use then select Menu -> More Tools -> Add to desktop you’ll be able to add a bookmark for the webapp to your desktop. This allows you to launch the app in a streamlined Chrome window — a little similar to the experience you might get with Electron or a native app. If the app happens to support Service Workers (PWAs ftw), it will fully function offline. Sime Vidas recorded a video showing this in action for ponyfoo.com (which is enabled with PWA features):

Sime Vidas Ponyfoo.com Add to Homescreen

Mac

On Mac, we had to manually enable the flag in Chrome Canary. After this we were able to navigate to a PWA then go to the hamburger menu -> more tools -> Add to applications. It prompted us to customise the title of the desktop entry for the app then took us to a filesystem directory where packaged versions of apps we had added in this way were available to launch. We could move these to the desktop or anywhere else on oursystem. The downside to the OSX experience for this feature is that it literally acts as a bookmark, launching the site in a new tab. There’s currently no slimmer chrome window for the app, although your Service Worker experience should still function as expected.

Matt’s Two Cents

Matt has some concerns that removing / adding the add to homescreen feature on some platforms and not others creates a fairly unstable / unpredictable base for developers and ultimately, it’s kind of scary that some of the benefits web apps will get on mobile are blocked on desktop, where arguably, web apps have become a reliable norm for accessing apps.

Speaking of Electron.js

An increasing number of the ‘native’ apps we use on the front-end (Atom, Visual Code, Slack) are built with Electron — a platform for web devs trying to create native-like desktop apps using JS. It’s been interesting to see a whole ecosystem of these shells spring up for everything from color pickers (check out our pal Roman’s new Material Design one here), to system tray apps like Cumulus to image optimisers. We’re even using Electron for the WIP Yeoman GUI app at the moment.

Sindre’s awesome-electron list contains some good examples of shells folks are building for existing apps in the community and is worth checking out. (Side: My long-term hope is that we can enable these types of apps to be shipped directly using the web platform so you don’t need to bundle 100s of megs of similar runtime for each one).

Cumulus — a SoundCloud app running on Mac

After playing around with some of the other Electron apps making the rounds on Reddit and HN, we wanted to offer some constructive feedback for folks hacking on Electron apps (that might apply as well to NW.js) because some of y’all are making us cry :’)

Many of the newer Electron apps built by individual contributors seem to only take things 40% of the way. They don’t offer proper packaging using tools like electron-packager and require their end users to manually clone/npm install/run the app locally rather than providing pre-built cross-platform binaries. For those of us that are JavaScripters, waiting 15 minutes for an npm install is a way of life, but some of these apps are really nice and we wonder if adoption could improve if we just made grabbing pre-built binaries a one-click op for most of these projects. Caprine (https://github.com/sindresorhus/caprine — the standalone facebook messenger) is one project that we think gets this right and is worth using for reference.

It’s important to note that electron-packager is not perfect and misses quite a lot. An ideal solution might create installers, tackle auto-updating, releases and more with minimal configuration by the author. Until browsers improve support for building the types of experiences Electron currently enables, it’s a decent option. It has its downsides (large binary sizes) but is an otherwise decent stopgap solution for building native-like desktop apps.

If you’re looking for more Electron app suggestions, Addy also really liked http://mikaa123.github.io/linear-website/ (a pretty nice free ruler app for Mac) and https://github.com/feross/webtorrent-app (a desktop GUI for the popular web torrenting client).

Server-side rendering + Ember

Addy is a crazy man and wanted to build something with Ember and FastBoot (https://github.com/tildeio/ember-cli-fastboot) to play around with the current state of the art for server-side rendering in that part of the world. We’ve been hacking on the application-shell architecture with frameworks and Ember’s just another example we’re looking at alongside React and Angular 2.

So..FastBoot aims to allow Ember apps to be rendered on the server so you can optimise for a fast initial page load (it also gives you output that should be search crawler friendly). The hope is that you can then ‘rehydrate’ this on the client-side (asynchronously?) with the bundles needed to enable features requiring user interaction. This allows users to see HTML and CSS for your UI right away with the JavaScript downloading and taking over once it has fully loaded. It looks like at the moment, the blocker for rehydration is Glimmer2 shipping in Ember which is landing as we speak.

Addy wanted to see what was possible today and found that the roughest edges with FastBoot were manually having to guard against use of globals like ‘document’, which don’t of course don’t exist in Node (but need to be done for any libraries you’re using) and limitations on it not being able to serve JavaScript or work with https://github.com/tildeio/ember-cli-fastboot#no-didinsertelement. Thankfully after some tinkering Addy did manage to get a multi-view POC put together and he’s going to try rewriting it so it’s..we believe the scientific term is “not shit”, next week. He also plans to look at adding in Service Worker to the mix for offlining the application shell, maybe using either raw Service Workers or https://github.com/jkleinsc/broccoli-serviceworker.

Side: The Ember community would really benefit from more up to date example apps using FastBoot that work out of the box with the latest ember-cli. The majority we found on GitHub were pretty busted or didn’t correctly work with `ember fastboot — serve-assets` or `ember fastboot — environment production`. It looks like Bustle.com and the Nest Store (https://store.nest.com/) are using FastBoot in production without rehydration so we might have a chat with them about their approaches to getting all these bits playing nicely. We also noticed the new Ember docs site might use FastBoot+ServiceWorker, so will be keeping an eye on https://github.com/fivetanley/ember-api-docs.

Debugging ES2015 Promises

A regular complaint in the office this week was that no one really fully understood how ES2015 Promises worked (except Jake, who helped write the spec). We’ve been re-reading blog posts and debating patterns and when cancelable promises will finally be a thing, but we did notice that a lot of folks were still console.log()’ing to debug their Promise chains. If you’re in Chrome, this is a friendly reminder that under DevTools Experiments we’ve had a Promise Inspector you can enable that offers a nice visual way of tracking changes in state, when promises resolve or get rejected. It looks like this:

Also don’t forget the ‘Async’ checkbox. Enable it and Chrome will reconstruct the call stack for you as if it were synchronous code. There’s an article on it from a few years back over here: http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/

Note: given this feature has been in experiments since last year, it’s unclear to me what the future of it might be sooooo enjoy it while it’s there!

PS: You might also like the Promisees visualisation playground over at http://bevacqua.github.io/promisees/

PSS: Not sure if this works for service workers.

PSSS: Matt says “Thanks Jake” for helping with a silly Promise bug the other day

DevTools Device Mode dimensions

Quick note: the dimensions overlay in Chrome DevTools was removed in Canary a short while back. A ton of folks were asking this week if it could be brought back and when that might happen. Just like magic..it’s back! Check out https://twitter.com/ChromeDevTools/status/712675286110707717 and follow the @ChromeDevTools account for updates like this if you’re living on the bleeding edge.

Progressive Web Apps in London and Bangalore

We had two events on Progress Web Apps, huge thanks to everyone who came along! We published the slides from the second event here.

There were a couple of common problems / questions that came as a result of the event:

Do PWAs work with framework X?

In short yes. Progressive Web Apps are essentially a set of API’s used to create an experience for users that works fast, offline and can be added to homescreen with push notifications.

What is the storage limit for service workers?

When you cache something using the cache API it goes towards part of Chromes storage limit. Chrome’s storage limit is essentially a set amount of space that is determined per device. Should / when Chrome reaches it’s limits it’ll clear space as it sees fit, which means the Cache could be removed.

DevTools is lacking for PWAs

  • Can’t test add to homescreen on desktop.
  • Can’t easily test splash screens.
  • It’s hard to understand and follow the lifecycle of service workers.

How does PWAs affect SEO?

Coming back round to inconsistencies, during the codelabs at these events, developers were recommend developing in an incognito window, this way when you close the window, all service workers and caches will be unregistered and closed, it’s a nice reset switch. When it came to the push notification code lab, this was bad advice since push notifications don’t work in Incognito. It’s a small thing, but inconsistencies == :(

PS Matt bought a phone for £45 — surprisingly good.

❤ AppShell + Docker

Matt is hoping to have a couple of articles out after getting a new version of his site out on a staging URL.

  • One article on just the structure of the web app to share construct the page in such a way that it fits the app shell model
  • Some nifty tricks with Docker
  • Matt’s already using docker, but he thinks there are some handy tricks he wasn’t aware of that will make development and deployment easier

Cool tools and reads and stuff

Finally — Happy Birthday Addy!!!

--

--