Offline Enabled Webapps And Open Source

I’m currently working on a rather simple Todo list application intended to meet the requirements I outlined earlier. I’m developing this as an offline-enabled webapp and while I haven’t gotten very far (don’t try it, it barely satisfies the most elemental requirements), I have some interesting observations to make:

First, the app is currently 100% Javascript. Its wrapped in a Django project because I’m going to have to make it online enabled at some point, but I wrote this app from the ground up to run in offline mode. This is a huge departure from traditional web 2.0 development (as of now, web 2.0 is to be considered ‘traditional’), where logic is mostly stored on the server and an ugly mess of ajax calls run that business logic on different events. Instead, I have a Javascript app that is surprisingly elegant. MVC under this architecture is basically SQLite (model), XHTML/CSS (view), and javascript (controller). Then I will have a workerpool to sync up with the server in the background.

As a result, the entire code-base for this app is being served to the web browser. So if you personally want to hack this app, you can download the source files from the browser. Basically, I can’t release this app as closed source. I could put a license on it forbidding you to modify or redistribute it, but you can still read the code; the source is open.

Of course, that’s not a problem for me, as I release most of my code as open source and its already up on github. But it could kill corporate migration toward offline-enabled web 3.0. Because while its one thing to keep your trade secrets locked up on the server and provide a few incoherent javascript calls that interact with that API, it is a completely different beast to put your entire app available for download as a .js file.

I suspect the open source movement has gained enough momentum that any companies who have these fears will simply be put out of business by more modern outfits that will spring up to take their place. Otherwise, either web 3.0 will fail to grab market share, or somebody will come up with a way to ‘compile’ javascript into a standards compliant byte-code so they can pretend nobody can reverse engineer their app. This would be a damn shame as its a politically-motivated technically useless layer of complexity on a web based architecture that I am finally happy to be working with.

2 Comments

  1. Changaco says:

    There is one important thing you are forgetting, HTTP was not made to maintain a bi-directional authenticated connection and that is exactly what you need for server synchronization. Both AJAX and HTML5 Server-Side Events are terrible hacks and the only protocol fit for this task is XMPP, Google understood that a while ago, XMPP being a part of Wave. As I really don’t like Google I hate it when they’re right but what I hate even more is to see that a very large part of the Open Source community is wrong, HTTP is not the future, XMPP is. That being said I believe that, being more than 10 years old, XMPP needs some rethinking to embrace a more generic role and get rid of the stupid retro-compatibility dogma.

    So all this to say that if you do not know XMPP you might want to look into it, read the XMPP-Core RFC and at least the PubSub XEP …

  2. dusty says:

    I will follow up on the wave and XMPP protocols later; they’ve been on my radar, but I don’t have much info on them.

    I agree that HTTP is, in some ways, not the best system for the kind of apps I’m describing. I’m interested in the architectural changes rather than the underlying protocols. We’ve been using a stupid architecture on top of a protocol for which it wasn’t designed for years. If we’re migrating toward a smart architecture on an inappropriate protocol, perhaps the next step will be the correct protocol for the job.