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.
The following were largely new to me and proved the most interesting in developing simply write.
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).
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:
You see what I mean about it feeling like cheating.
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
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.
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.