[nolan@nprescott.com] $>  cat blog archive feed

Browsers in 2015

2015-11-13

More often than not, new application development seems to happen in the browser. I've been playing with some "new" browser APIs to try and find out why and had some fun along the way.

I've written previously about getting back to basics with web development. I find it helps focus my understanding and reveals gaps that I didn't even know I had. I've been playing around with a few new-to-me concepts today with another poorly named hack: simply write.

The idea isn't really original1, but I set to making a "distraction-free writing environment". Something that was entirely painless to jot down notes in and which would not require saving files or opening previously saved work. It's another idea that appeals to me for it's simplicity.

New things

The following were largely new to me and proved the most interesting in developing simply write.

Blob File API

The Blob/file API is used to construct immutable, raw data objects, which is a little abstract sounding. To make things more concrete I implemented a download feature which would write the text of the note into a plain text file. The blob is really only half of the download, its complement is URL.createObjectURL, which accepts a blob object and returns a URL to that object (which you can follow to trigger the browser-defined action, depending on blob type).

One interesting aspect of the download action is how it can be built on a simple anchor element using the download attribute2. Although it seemed a bit circular, the download link that is presented to the user actually triggers my download function which itself creates a new anchor tag and programmatically clicks the new link. This is so that the Blob object referenced in the generated href captures the text data at the correct point in time (i.e. when the download is requested).

Fullscreen API

I'll admit, this one felt a bit like cheating. It seems most browsers have yet to standardize on a fullscreen API so each requires a vendor prefix. In searching for the appropriate prefixes I found that MDN has a snippet for toggling fullscreen. All that I did was a bit of copy-paste.

It's a bit of a shame that something like fullscreen still requires vendor prefixes, but even more vexing is the behavior on mobile. Using fullscreen in Firefox on mobile has a tendency to confuse the browser and required I close out entirely before I could resume using it even after closing the page. Frankly, that's as close to a critical bug as something like simply write can come. The reason I haven't prioritized the issue is two-fold:

  1. I don't really believe anyone uses fullscreen on mobile
  2. It would unnecessarily complicate the application

You see what I mean about it feeling like cheating.

Offline-enabled browser storage

The most surprising to me of those new features I tried out was the app cache. For an application as simple as mine I only needed to specify the three files which make up the application ( simply-write.js, index.html, style.css) and the whole thing became offline-accessible immediately.

The one caveat to creating an application cache manifest file is to include some means of "busting" the cache when new changes should be pushed to the user. In my case I have included a timestamp comment, any updates to which will force the browser to refetch the app's content.

 CACHE MANIFEST
 # delicious cache bust
 # 1447452128

 index.html
 simply-write.js
 style.css

So Why Browsers?

Circling back to the lead in: More often than not, new application development seems to happen in the browser. I feel like I have a better sense of why this is the case (and it's not simply intertia). Browsers, for all their faults, package a pretty standard interface for all users. They have a host of functionality built-in, a shortlist of things which I didn't need to write myself include:

To say nothing of the previously mentioned file handling and fullscreen. Because this all happens in the browser I'm afforded some level of guarantee that these will all work across platforms. A few vendor prefixes is a pittance compared to the thought of writing an application compatible on OSX, Windows, Linux, BSD. The browser has done all of the hard work for me already.

It seems redundant to say that browsers have assumed the mantle of "write once, run anywhere"3.

Not All Roses

Every platform is accompanied by its own slew of peculiarities, browsers vary in their implementations and performance. I simply think that web application development presents a much more promising avenue than some of the alternatives.


  1. WriteRoom, PyRoom, and a bunch more...
  2. Download attribute on MDN
  3. Wikipedia: WORA
[nolan@nprescott.com] $> █