Irakli Gozalishvili

JS Guards

2011-07-03T00:00:00-07:00

I’ve written micro library, to solve a very common problem in JS code today. Most likely following example looks familiar:

function Constructor(options) {
  options = options || {}
  if (typeof options.url !== 'string')
    throw new TypeError('url is required!')

  // Finally, your logic here!
}

First of all, code is wrong. If falsy value is passed to a function it will misbehave. Secondly, boilerplate code makes it less readable. It takes three lines to validate just one property (very likely to have more) of the given data structure. Finally, validation code does not even belongs there, as it has nothing to do with an actual logic of a function.

What we actually need is an annotation enforcing certain constraints. We don’t have annotations in JS, but we have functions that are omnipotent! Just about everything can be solved everything using functions.

function ConstructorOptions(options) {
  if (options === null || options === undefined)
    options = {}
  if (typeof options !== 'object')
    throw new TypeError('Options must an object!')

  if (typeof options.url !== 'string')
    throw new TypeError('url is required!')
}

function Constructor(options) {
  options = ConstructorOptions(options)

  // Your logic here!
}

This example is much better, because reader of Constructor function can concentrate on function logic, without being distracted by a validation boilerplate. In addition, options’ validation code can be independently unit tested and in some cases reused.

JS guards, is a small library that takes this idea to the next level. It provides declarative and recomposable way to define data type & data structure validations.

var guards = require('https://raw.github.com/Gozala/guards/v0.3.0/guards.js')

// Define a { x, y } data structure, where x and y fallback to 0.
var Point = guards.Schema({
  x: guards.Number(0),
  y: guards.Number(0)
})

// Define any type of guard as a function
function color(value) {
  // If validates just return value
  if (typeof value === "number" && value <= 255 && value >= 0) return value
  // If not throw TypeError
  throw new TypeError("Color is a number between 0 and 255")
}

// Define a [0-255, 0-255, 0-255] data structure guard.
var RGB = guards.Tuple([ color, color, color ])

// Compose data structure out of existing guards.
var Segment = guards.Schema({
  start: Point,
  end: Point,
  color: RGB,
})

Segment({ end: { y: 23 }, color: [17, 255, 0] })
// { start: { x: 0, y: 0 }, end: { x: 0, y: 23 }, color: [ 17, 255, 0 ] }
Segment({ start: 0, end: { y: 23 }, color: [17, 255, 0] })
// TypeError: Object expected instead of number `0`
Segment({ color: [ 10, 40, '30' ]})
// TypeError: Color is a number between 0 and 255

You can use this library in browsers, jetpack and nodejs. Also, you can try it out right now via interactive example on JSFiddle. For more details and examples check out library documentation. Finally, there is a guards proposal for EcmaScript and chances are we’ll get a syntax sugar some day (It will take a while though as it’s not even in Harmony).

As always I’m more than happy to hear your feedback!

Packageless modules

2011-06-16T00:00:00-07:00

Packages

Every time I write code in javasciprt for jetpack or nodejs I question myself: “Do we really need packages ?”. Even with amazing package manager like npm it still feels wrong to me for a few reasons:

1. Size and scope

Writing code for the web taught us keeping line numbers tight, to a bare minimum. It could be a platform limitation, but more importantly it’s a best practice that has multiple advantages:

You never overgeneralize by trying to solve each and every problem.
You reduce a surface for bugs, less lines => less bugs.
You build reusable building blocks, with a focus on one thing only. Also, such blocks are easy to mix and match.
Faster to download, parse, execute.

Most of the modern js libraries / frameworks consist of one file, solve one problem and do it well. MicroJS started a great job of promoting this trend by building a nice spot for discovering fantastic micro frameworks and libraries!

Package definition, on the other hand, implies wrapping collection of things into a single form. So no matter how great package manager is, packages will tend to grow in size attempting to solve bigger set of tasks.

2. Explicitness

Looking at source should be enough to understand what program does, what it depends on, etc.. Unfortunately this is not the case with packages as it requires looking at the package descriptors and understanding non trivial module search logic. To put it other way

bar = require('foo/bar')

expression depends on too many things: requirer module, package descriptor, existence of various files in various places. In jetpack module search logic ended up being very complex. NodeJS has a better story, but still there more than two axis involved. It should be simple & straight forward.

3. Simplicity

When I find some useful & well maintained module on the web, I just want to be able to use it straight away, without downloading and bundling with my code, or even worth creating a package out of it publishing into some centralized registry in order to finally be able to require it! And when I want to alter some functionality in third party module I don’t want to go through change / rename / publish routine, I just want to fork on github and require!

4. Interoperability

Packages are not for browsers, because they have dependencies that have their own dependencies etc.. All this dependencies are expressed in a separate package.json files and it’s impossible to interpret require without reading package descriptor or knowledge of a requirer and I won’t even go into details of search paths and dependency duplications. Only visible solution for using packages in browsers requires build step on each file change or a server that does this at runtime. It’s a big compromise to make even though we do builds before deployments.

5. Far from harmony

No packages are in harmony, just a simple modules with compile-time resolution and linking. Hopefully very soon, I heard that by end of this year, we will have a first class modules in JavaScript and that will be the ultimate way to distribute building blocks with built-in support from js engines, so closer we stick to the model cheaper will be migration.

Alternative

Web is awesome, it’s cross platform, fully distributed, yet connected via links / URLs.

I think we should be building ecosystem for building web, with a same spirit: cross-platform interoperable modules, that are fully distributed across the web, still connected via URLs. Each doing one thing only, but doing it well. No need for complicated module search logic or central authority for distribution! I’m very happy that, that’s exactly how modules are thought to work in Harmony.

Solution

In my spare time I have prototyped a tool called graphquire that makes it possible to write and use such modules, that will work across different platforms including: jetpack, nodejs and browsers. Unfortunately different platforms limitations made it impossible to require modules with an actual URLs, but it very close:

// Relative
require('./foo/bar')
require('./bla.js')
require('../baz')

// Absolute
require('http!foo.org/bar')
require('https!bla.org/baz.js)

You might have some constraints:

Long require statements:

Can be solved in many ways, starting from URL shortening services, finished with a private module registries, similar to MicroJS.
Updating require statements more than 1 place:

Not really an issue with right set of tools like replace for example, also editors and even graphquire might get build-in support for this. In any case that’s something we will have to face in harmony.
Content under URL can change:

This is true, but same can happen in package registries. We just need to make sure to require modules from URLs that are guaranteed to have the same content: modules under version tags, registries, own servers.

Please let me know what you think!

Addons in multi process future

2011-06-04T00:00:00-07:00

The most frequently asked questions on jetpack mailing list concern content scripts. It’s not obvious for users why these scripts are powerless, why modules don’t have access to the content’s dom and why they need to communicate between them by message passing. The short answer is: Mozilla platform is moving towards a model were separate processes are used for chrome, content and add-ons. Therefore SDK modules were designed with Electrolysis in mind, to guarantee painless transition to a new model. Much more details about this may be found in the documentation of content scripts.

Even though we won’t ship 1.0 with support for Electrolysis, some of us (Atul, Alex and me) have explored some ideas, but until few month ago I was still unsure we were heading a right path.

Several month ago I was reading Peter Michaux’s blog post about MVC Architecture for JavaScript Applications from which I’d like to quote following description of “Real MVC”:

“In a nutshell the classic MVC architecture works like this. There is a model that is at the heart of the whole thing. If the model changes, it notifies its observers that a change occurred. The view is the stuff you can see and the view observes the model. When the view is notified that the model has changed, the view changes its appearance. The user can interact with the view (e.g. clicking stuff) but the view doesn’t know what to do. So the view tells the controller what the user did and assumes the controller knows what to do. The controller appropriately changes the model. And around and around it goes.”

Even though I’ve been writing apps with MVC architecture for a while, it never occurred to me to look at jetpack in MVC.

Light side

Ironically, most of Add-on SDK APIs provide access to the things that are basically models, associated with a different views of the browser UI (like windows, tabs, widgets). Also, low level modules can be seen as controllers of two types:

Model observers that propagate changes to the associated views.
View observers that update associated models.

Such perspective also makes whole multi-process architecture switch way more simple. All we need to do is to move models to the other process and make sure that changes on views and models are synchronized via controllers.

Dark side

Unfortunately big part of the code base was not written with such MVC perspective, or in other words we don’t have a strict separation between models and outlined controller types.

Technical side

This part of the blog is probably too technical to enjoy, unless you plan to hack jetpack itself, so feel free to skip :)

Overall, everything boils down to few key components:

Pipe for delivering messages across processes, something like port on our worker objects.
Models that are serializeable and fully reconstructible via JSON. This is important as models are going to live in add-on processes. Model synchronization logic can be encapsulated in one function that just emits events on the port.
Controllers observing views, or in other words, event listeners that extract and serialize interesting data from events and emits to the pipe so that models can react.
Controllers observing model changes, via listeners on the pipe and updating views.

Outlined strong separation of roles is a good practice anyway, so I tried to stick to it to make transition to E10S easier.

Models that can be serialized / recreated: hotkey
Controllers that emit events on view (Browser UI) changes: tabs/observer, keyboard/observer, windows/observer
I don’t have examples of controllers that update views on model changes.

Finally here is a link to “in progress” implementation of models that I hope to get into jetpack in a future.

Yet another take on inheritance

2011-04-23T00:00:00-07:00

Every now and then you need to use inheritance in JavaScript. When you do, you suffer, because there’s just too many ways to do that and regardless of your choice, syntax noise will make your eyes bleed! Well you may consider saving your eyes by using a library, but this is not going to save you as you’ll be drown in an ocean of endless choices!

Choice is good, but when it’s in manageable quantities. Anyway only reasonable solution is: Yet another new library that does exact same thing in a slightly different fashion.

That’s a short story of how extendables micro-library started. It is super minimalistic. Function Extendable is only thing it exports, which is just like built-in Object. Only difference is extend own property that behaves similar to backbone’s Model.extend.

Extendable.extend may be called with an object containing properties that will be defined on the resulting constructor’s prototype. Which by the way, will inherit from the target function’s (function who’s extend was called) prototype. In addition all own properties of a target will be copied to the resulting constructor.

That’s actually all of what this library does! In contrast to backbone, library is built with ES5 in mind, which makes it aware of new goodies: non-enumerable, non-writable and non-configurable properties. This also means that it requires ES5 engine to run. But don’t get broken hearted yet, as you still can use it on IE6 (Please note that you’ll burn in hell if you do!) and friends, with a help of another micro-lib es5-shim.

Library is known to work in browsers via AMD loaders, in jetpack and in nodejs. Likely it’s going to work on any other CommonJS compliant platform as well. Finally here is a jsfiddle and source gist showing it off with a few examples:

/* vim:set ts=2 sw=2 sts=2 expandtab */
/*jshint asi: true undef: true es5: true node: true devel: true
         forin: true latedef: false supernew: true */
/*global define: true */


define('demo', function(require, exports, module, undefined) {

'use strict';

var Extendable = require("https://github.com/Gozala/extendables/raw/v0.1.2/lib/extendables.js").Extendable

var Base = Extendable.extend({
  inherited: function inherited() {
    return "inherited property"
  },
  overridden: function overridden() {
    return "property to override"
  },
  // No supers by default, use prototype and be proud, but if you really want
  // super get one!
  _super: function _super() {
    return Object.getPrototypeOf(Object.getPrototypeOf(this))
  }
})
// Adding static method.
Base.implement = function implement(source) {
  // Going through each argument to copy properties from each source.
  Array.prototype.forEach.call(arguments, function(source) {
    // Going through each own property of the source to copy it.
    Object.getOwnPropertyNames(source).forEach(function(key) {
      // If property is already owned then skip it.
      if (Object.prototype.hasOwnProperty.call(this.prototype, key)) return null
      // Otherwise define property.
      Object.defineProperty(this.prototype, key,
                            Object.getOwnPropertyDescriptor(source, key))
    }, this)
  }, this)
}

var b1 = new Base
console.log(b1 instanceof Base)              // -> true
console.log(b1 instanceof Extendable)        // -> true
console.log(b1.inherited())                  // -> "inherited property"

var b2 = Base()                             // -> Works same as without `new`
console.log(b2 instanceof Base)             // -> true
console.log(b2 instanceof Extendable)       // -> true
console.log(b2.inherited())                 // -> "inherited property"


var Decedent = Base.extend({
  constructor: function Decedent(options) {
    this.name = options.name;
  },
  overridden: function override() {
    // I'd rather copied `overridden` with a diff name overriddenBase for
    // example or used `Base.prototype.overridden.call(this)`
    // But this works as well :)
    return "No longer " + this._super().overridden.call(this)
  },
  // overriddenBase: Base.prototype.overridden
})
Decedent.implement({
  bye: function bye() {
    return "Buy my dear " + this.name
  }
})

var d1 = new Decedent({ name: "friend" })
console.log(d1 instanceof Decedent)       // -> true
console.log(d1 instanceof Base)           // -> true
console.log(d1 instanceof Extendable)     // -> true
console.log(d1.inherited())               // -> "inherited property"
console.log(d1.overridden())              // -> No longer a property to override
console.log(d1.bye())                     // -> "Bye my dear friend"

})
require.main("demo")

Finally, if you are a coffee fan like me, you’ll love the fact that regular coffee class syntax may be used to extend Extendable and it’s decedents. Also all coffee classes that extend Extendable can be extended further from javascript.

Shareable private properties

2011-04-11T00:00:00-07:00

In JavaScript it is not possible to create properties that have limited or controlled accessibility. It is possible to create non-enumerable and non-writable properties, but still they can be discovered and accessed. Usually so called “closure capturing” pattern is used to encapsulate such properties in lexical scope:

Unfortunately given approach does not works very well with OO inheritance:

Code readability degrades and some code duplication becomes necessary.
(See firs lines of Base and Decedent constructors).
Prototypes do not contain any properties and there for each instance gets it’s own fresh copy of them.
(Not very good for performance).
Own and inherited methods access different copies of private properties and there for changes do not propagate.
(boom method of Decedent illustrates the issue).
Access to a private properties can not be shared with a limited group.

I believe because of these reasons ”-” prefix was established as a “de facto” standard for private property names. Unfortunately it’s just a coding style that does not implies any property access restrictions.

In Jetpack we’ve explored different techniques to overcome issues mentioned above, but property access sharing to the limited groups of consumers remained painful and unobvious.

Recently I got an interesting idea inspired by private names proposal for ECMAScript (I recommend to reading Allen Wirfs blog post explaining details of the proposal). Here is an illustration of the idea with a same example:

Please note that this solves all the issues outlined. Also access to the privates can be shared with any group, just by giving them a KEY. After tinkering with this idea for some time, I’m happy to announce birth of namespace micro-library. Below you can see same example, but this time coded as a commonjs module and using mentioned library:

Library not only wraps outlined idea into a nice API, but also allows provides a way to use multiple namespaces with the same object.

Finally here is a jsfiddle link containing this example if you wan to play with it. Of course comments / feedback / ideas is more then welcome!

Evolving VS Adjusting

2010-10-20T00:00:00-07:00

We often have to make the choice between adjusting to conditions or paying a price for improving them. Usually it is safer to adjust, but still we have to be very careful we don’t miss an opportunity to improve. Probably the best way to do that is to compare the price and improvements.

Asynchronous Module Definition is one of the hottest topics on the CommonJS mailing list this days. Unfortunately my impression is that most of the participants of these debates forget to measure price VS improvement and this can be harmful.

I believe there are two sides:

People that believe that CommonJS modules are not well suited for in-browser usage (suggesting an alternative, “browser friendly” syntax).
People who believe that CommonJS modules are perfectly usable within browser without any changes.

I’m one among few others who uses CommonJS modules both on the server and in the browser already. With that in mind it’s not easy to convince me, that change in well established standard is absolutely necessary.

Issues with current modules

There were many arguments why current modules are not suited for in-browser usage, but unfortunately I did not manage to convince enough people to make a list of them, so I will summarise them as: “Non of the existing module loading techniques provides perfect debugging experience across the different browsers without involvement of a server component or a building step.”

Different view on these issues

Debugging story is not that bad actually (much better than it used to be not a long time ago), but it’s true, rarely, but still strange issues occur. In any case those are bugs in debuggers not with a modules. Only way to fix bugs is by report them. I’m pretty confident that firebug team is going to make their best, to make debugging experience as good as possible. I also hope that it’s true for a web inspector.
Dismissing a server as a show stopper is also inadequate IMO, since there are few other things like Offline Application Caching that would still depend on it and won’t work without. And in the end it just matter of running one simple command before starting development. For instance to hack on jetpack you need to run source bin/activate and I believe it was show stopper for anyone.

Issues with proposed changes

Proposed changes are not perfect either:

Some people will argue against this statement, but there is nothing in common between proposed Asynchronous Module Definition and existing module specs other then the CommonJS label. This will be a source of confusion and community fragmentation.

Below you can find a simple module being rewritten according to two different specs:

Asynchronous definition:

CommonJS module:
Asynchronous definition seem to encourage handwritten boilerplate but what is puzzling here is, why would any programmer prefer writing a boilerplate code by hand over writing a program that would do that for him. Yes it’s nice to refresh browser and be ready to go without any build step, but nothing prevents us form writing programs that support this workflow.
A most important issue is that the new proposal suggests to adjust to the unpleasant situation browser are in now, and what is even worse, it brings this mess to the server. Adjustment to broken tooling is only going to delay innovation! I truly believe that if we had had such a big adoption of CommonJS modules a few years ago, we would have perfect debugging story today (well maybe not in all browsers :). I also think that wide adoption of CommonJS modules already triggered some innovation and partially that is the reason why we might get native modules in harmony. And you know what ? Once we’ll get them, no magic will happen, as it did not happened when Web Workers arrived. It will take some time to get a decent tooling support. Again it should not stop innovation by trying to adjust new amazing platforms to the mess we are at with browsers.

Evolving

I think that the only sane thing to do now is to bring the innovation that happens in server side javascript back to the browser without compromising anything. With that in mind I’m planning to put a lot of effort in teleport, a tool that I wrote some time ago. It allowed few projects to share CommonJS modules across server and client. I don’t believe there is any perfect solution to all problems, but each problem has a solution and I hope that teleport will be a set of solutions addressing CommonJS module loading problems. The list of tasks I’ll be working on, is probably the best way to get a better idea what is it all about. Feel free to fork me, suggest new ideas or just comment here.

oh my zsh

2010-10-09T00:00:00-07:00

I have been thinking about switching to the zsh shell for some time, mainly because I was missing vim environment in the console. About a month ago I’ve decided to switch. Quickly enough I got tired of tweaking my .zshrc, I was about to give up when I discovered very nice project called oh my zsh.

A community-driven framework for managing zsh configuration proved to be very nice. At the end of the day I ended up with a new theme and improved git plugin.

As you can see there is bunch of small icons on the right side that’s a visualisation of the git working tree:

✭  Displayed if there are modifications.  
✈  Displayed if there are staged changes.  
✗  Displayed if there are deleted files.  
➦  Displayed if there are moved files.  
⚑  Displayed if there are untracked files.  
⚡  Displayed if there is a merge conflict.

Hope you’re excited and considering to try out zsh. If that’s a case I’ll definitely recommend to try out oh my zsh. There is already made pull request with my new theme gozilla and get plugin improvements. If you cant wait you can pull changes directly form my fork.

Git status in bash prompt

2010-09-04T00:00:00-07:00

There are a lot of blog posts describing techniques of putting your current git branch in your bash prompt. After reading one of those posts more then year ago I immediately edited my ~/.bash_profile and was very happy until very recent, when I have started using --color argument with git commands. Surprisingly to me colors made me so much more effective that I quickly tweaked my git config: git config --global color.ui auto This allowed my to have colors everywhere by default. Shortly after I got an idea that colors in prompt may be used for displaying a status of the working tree / index.

Motivation

I really wanted to try that idea out, because I thought it was a chance to solve a problem that bugged me for years already. I was looking for a way to remind myself to commit more often, since I tempt to commit only after I’m done with a task and it’s hard to imagine how many times I regretted that!!

Design

So my plan was to display “current git branch” in a bash prompt in a different color depending on a state of the working tree / index:

No changes
Untracked files
Stashed changes
Modified files
Deleted files

Implementation

I wont bother you with a details on how to get a “current git branch” since there are lots of posts about it, instead I’ll focus your attention on snippet that parses git status and adds colors:

I am not that good at bash and I would be more then happy to hear your your suggestions how to make implementation smaller or faster. Any other suggestions or comments are also very welcome.

Finally if you want to see full implementation check out my git repo.

CommonJS based Github library

2010-05-28T00:00:00-07:00

This post is about CommonJS Package, a library, allowing consumers to list, read, write, delete & comment private / public gists. Library employs v2 & v1 Github API’s in combination with some dirty hacks to make this possible.

Main target platform is a browser, but it can run on any other platform that will provide implementation of XMLHttpRequests. Since browsers have many limitations in comparison to other platforms this idea was a challenge form a beginning. The first thing and probably something you already have in mind is same origin policy. Luckily all modern browsers today implement W3C standard for cross-origin resource sharing. Unfortunately though, only a few websites employ this technique and reply client with Access-Control-Allow-Origin headers. Believe me or not, Github is not one of those!! Actually convincing them to start useing this standard was not as easy either…

I did not want to give up, so I have decide to implement this library anyway with accompany of two proof of concept experiments demoed in previous posts. I really hope this way I’ll get enough attention from Github folks and they will see a value of improved browser friendly Gist API’s :)

As you could’ve guessed I found a workaround, actually not, I’ll better call it an elegant solution :) Anyway solution to this problem was YQL. If you don’t know yet, it’s a very cool service from Yahoo and likely easiest way to make rest services + all in JavaScript, you should definitely check it out!! After some hacking I’ve managed to put together several “YQL Open Data Tables” with an access to data that can’t be retrieved with a current Github API’s. Most importantly allowing users to select and insert private gists. Since YQL puts Access-Control-Allow-Origin headers, same origin policy problem was solved, as a side effect it also allowed some optimizations by moving several operations from client to server.

Unfortunately it’s not the end of the story neither it was end of the issues I had to run into. After a while I discovered that firefox sends HTTP OPTONS request, before sending desired HTTP POST on which YQL replies without necessary Access-Control-Allow-Origin header. With HTTP GET everything is fine since HTTP OPTIONS are not send in that case. Other browsers don’t have issues nor with GET nor with POST since they don’t seem to send HTTP OPTIONS. I have reported about this issue to YQL folks and they were super fast with picking it up, they plan to have a fix in for a next release, which I hope will be anytime soon.

After all the efforts github library is ready to be forked!! So please give it a try and lets make some amazing stuff to show Github folks that,

we need a better Gist API’s!!

Taskhub

2010-05-05T00:00:00-07:00

Majority of web applications today are data owners. Yes, even if data is mine, it’s still owned by application, since all the ways to interact with it go through application. In some cases application kindly allows to export and import data, sometimes even delete or access it with other applications, but the point is, that somehow it is always between me, my tooling and my data. For example I just can’t simply move my social activity data access privileges from Facebook to MySpace or vise versa.

Still not sure weather this is fundamentally wrong or just can be better. One way or another, Taskhub is an experiment, trying to make it differently. With Taskhub I am an owner of my data and application itself is just a tool of my choice to interact with my data. To achieve this, Taskhub takes Jekyll like approach and saves tasks as Markdown formatted, plain text gists. This way application respects my freedom of choice by allowing me to switch to any alternative task manager at any moment, making switch as painless as it can get, just stop using it. And if I’ll decide to switch back, Taskhub will just work. Think in summary, data is just mine and it should not bound me to any application. One can say here that it’s bounded to github, but it’s not true, because github in this case is just wire that connects my data to the cloud. In ideal world we will have “Data Clouds”, virtual hard drives with standard data access APIs. Users will buy them to store their data, just like they do with hard drives today.

For the moment Taskhub is just a geek toy, but I hope to see it’s decedents, being more useful to a regular users, one way of doing this is through adding support of saving data in less geeky storage, for example saving data to files in Dropbox, will make a trick, besides it’s a step towards “Data Clouds”.

I’m not in illusions that, high performance will be easy to achieve with this model, but I do believe in smart people :).

Under the hood

HTML5 Offline web applications
As I mentioned high performance with this model is not easy. To reach acceptable performance application uses HTML5 localStorage for a live data, that concurrently gets synchronized with a gist storage. HTML5 offline application caching APIs are used to make it possible to run application while being offline. All the data is synchronized once user goes back online. So far there is no conflict resolutions, because of limited gist APIs, so browser always gets priority, which leads to a funny results when used with multiple clients. Fixing this is on my taskhub list, so stay tuned.
CommonJS
Application is build on top of CommonJS. It uses yet another CommonJS module loader Teleport, which asynchronously delivers modules from mapped CommonJS packages. One of the main components / packages is github library allowing to list, read and write gists straight from a browser and I’ll be posting details about it in the next post.
Backendless
One of the interesting moments of architecture is in it’s selfhostness. That makes it possible to run app from any server, it even can be dropped to dropbox or can be used directly from local filesystem.