blog-rekahsoft-ca/posts/site-updates.markdown
Collin J. Doering 1a26f68e09
Add published but uncommited Site updates post
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
2017-11-04 22:28:01 -04:00

49 lines
3.0 KiB
Markdown

---
title: Site Updates and AppCache depreciation
author: Collin J. Doering
date: Feb 08, 2016
description: Stabilized site and removed javascript requirement
tags: general
---
I am happy to announce that this site is nearly complete. There are a few additional features I
still intend to add, mainly to do with offline viewing and user experience, but all-in-all I am
quiet happy with it. Now I intend to mainly focus on populating this blog with more content and
writing a little more frequently. Also for those of you wondering if pagination is working, it
is, completely! Both on the tag pages and the blog page, however currently I don't have enough
articles to trigger multiple pages (greater then 6 is required), so the pagination
next/prev/first/last page links at the bottom of the page are plain text. I at some point may
address this but it will only really be an issue for another few articles and could be resolved
quiet easily in the case of 6 or less articles.
Recently, I came across an article saying to my dismay that the Application Cache API is being
depreciated in firefox. I say to my dismay because this site uses Application Cache so it can
be viewed offline, which means I'm going to have to refactor my site for Application Caches
replacement. Some would say offline viewing is overkill for a blog but initially I attempted it
as a learning exercise, but am pretty happy with the end result of a pretty smooth offline
viewing experience.
<!--more-->
Needless to say, while setting up Application Cache, it seemed like it wasn't a very flexible
technology. I was able to make it do what I wanted (for the most part) but things like
selectively caching an article wasn't doable with Application Cache. I still intend on offering
this feature, however I was going to implement it via offline storage as it couldn't be done
dynamically on the client side with Application Cache. There is a better alternative though,
ServiceWorkers which replaces Application Cache provides the flexibility to provide just this;
dynamic caching based on whatever conditions the developer sees fit. In a nut shell,
ServiceWorkers act as a proxy running in a Worker (thus in its own thread) between your web
application and the browser.
Anyways, as I read through the documentation for ServiceWorkers I'll be sure to update my blog
to use them in place of Application Cache. I'm looking forward to experimenting with this new
web spec, and thinks it hold great promise for the future.
As a closing note: one thing that worries me about web applications becoming able to deliver
similar experiences to classical native programs is that of freedom and availability of source
code. Of course, this is why the [AGPL](http://www.gnu.org/licenses/agpl-3.0.html) exists, but
none-the-less, I fear the day when the majority of users simply use a web browser to do their
computing. It will leave them locked to a particular service without the ability to even
reverse engineer the application because all communication can take place via an encrypted
connection.