Plenty of comments have arisen while I slept, so rather than answering all over the place, I’ll just post this comment to cover most of it, with a little unsolicited commentary as well.

I’m presuming Overture has come up today because of its mention in our blog post yesterday, https://blog.fastmail.com/2017/12/18/using-the-modern-web-pl....

# Concerning the status of Overture:

I’ve been doing much of the maintenance work on Overture in recent months, involving things like updating the code style to use modern techniques (e.g. ES6 modules), and updating the build process to use more standard tools rather than a bunch of cobbled-together scripts and a makefile. (The tools directory contains various scripts of this nature used in the Topicbox and FastMail build processes, things like the C-style preprocessor of ifdef.js, and the localisation-handling functionality of localise.js.)

At this stage, the first phase of improvements are finished in Overture, and steadily progressing in Topicbox; for FastMail they’ll come next year; but as part of this, things like the documentation builder got mostly broken, and I haven’t fixed it in any way yet. (It’s a fair way down my list.)

We’ve been neglecting overturejs.com while making all kinds of changes, because we’re the primary user of Overture. When things settle down again, we’ll make sure things are updated (for our own sakes, if for no one else!). That will entail comparing it against other current libraries more as well.

I’ve been playing around with a few more experimental things, too, such as replacing the get() and set() methods with property descriptors. I have a working prototype, but some aspects of it are moderately complex to make work everywhere. This has been a common pattern with data-binding libraries: they all started with get() and set() methods (provided they’re old enough; some new ones come out now without needing it), but eventually switch to using property descriptors. Or proxies in at least one very recent example (their main benefit is allowing indexing of array-like objects without using a special method, ours being getObjectAt). Browser support and performance are the foundation of any such decisions: property descriptors are ~IE 9+, while proxies are recent-any-browser-except-IE. At FastMail, we currently mostly support IE​ 8+ and fully support IE 9+, but plan to drop IE ≤ 10 next year which will allow us to depend on property descriptors and the likes in Overture.

Another piece we’re playing with is moving more of the layout out of JavaScript (for historical and browser support reasons, it prefers a fair bit of absolute, precisely calculated positioning) into CSS.

# Concerning Overture versus other libraries like Ember, Vue and React:

Overture is essentially a full-stack framework. It’s thus decidedly heavier than options like Vue and React, but it includes a lot more as well—good support for localisation, dealing with dates, a solid data store with committing, undoing and more, intelligent handling of keyboard shortcuts (e.g. add `shortcut: 'Cmd-g'` to a button view, and ⌘G on Macs and Ctrl+G everywhere else will Just Work™), that kind of thing.

Overture doesn’t use a virtual DOM like React and Vue; it works directly with the DOM. Data dependency tracking is done with precise knowledge of which properties things depend on (its model is inspired by things like SproutCore—people that have worked with such a model will feel right at home).

Altogether, these things mean that Overture is typically harder to work with and more verbose than React or Vue, but so long as you’re sensible, it’s much more efficient.

Oh, and the state of Overture documentation means that unless you can spend a few days with Neil (who wrote it all in the first place) or me to work through things you’re likely to find Overture even more difficult to work with.

At present, the annotation of data dependencies is a little odd, blocking `{ foo () { } }` object shorthand:

  const NameView = new Class({
    Extends: View,

    firstName: null,
    lastName: null,

    name: function () {
      return this.get('firstName') + ' ' + this.get('lastName');
    }.property('firstName', 'lastName'),
  });

(This is the main thing that blocks shifting to class syntax wholesale, which is one of my experiements—not that it has been clearly and unambiguously determined that class syntax is superior to our current approach.)

One of my experimental pieces (well, a combination of a few experiments) heads in this kind of direction:

  class NameView extends View {
    firstName: string;
    lastName: string;

    @property('firstName', 'lastName')
    get name (): string {
      return `${this.firstName} ${this.lastName}`;
    }
  }

We’ll see how it all goes.

One last thing: Overture’s data store model is more conducive to offline support than most; combined with JMAP, we’re expecting implementing very robust offline support for FastMail and Topicbox to be fairly straightforward. (By “very robust”, I mean the robustness of a desktop email client, where you never expect anything to go wrong, as distinct from normal web apps which try to add data persistence on top of what they already have, which are hit and miss, mostly miss.)