Overture JS – A powerful basis for building web applications

The Overture+ performance comparison is virtualizing the list nodes and not adding them all to the dom so its kind of an unfair comparison. You could do that with react-virtualized.

faster than native applications .... the borwser on the phone is a native application. The browser engine doesnt render faster then any other browser engine.

This is such bs snake oil.

As a FastMail user and staff member, I agree. You’ll be glad to know that when we implement offline support soon (and I’ve been looking forward to doing that since before I started working at FastMail!), startup will be much, much faster, because it will no longer need to ask the server a few questions before it can load the UI—it will already have the answers (though it’ll then ask the server whether anything changed since last time, once it’s finished loading).

I believe network latency is the largest factor in the current slow startup; I imagine it’s a second or more faster in the US than it is in Australia or Spain.

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.)

When writing data binding systems, you tend to need to have a generic base class to provide the basic magic functionality; it can’t be done any other way unless you strictly separate functionality from data (perhaps using an immutable data approach) which tends to makes the library less usable.

So this ain’t NIH; it’s a legitimate and very popular architectural pattern.

On a more flippant note: the name Object is a bit unfortunate due to its collision with the builtin global Object; we used to write `O.Object` everywhere, but now we’re using imports for such things we’re calling it Obj everywhere else, so I intend to rename it to Obj altogether one of these days.

For Class: yes, JavaScript has classes now. It didn’t five years ago. On of my experiments involves removing the magic from Class (moving it into the Obj constructor), leaving it just a shell, with class syntax available for use. But even then, class syntax isn’t perfect; prototypal inheritance is really pretty cool and lets you do some very nice things that class syntax doesn’t let you do (I’m planning a conference talk about prototypal inheritance, including some of Overture’s magic that is possible because JavaScript uses prototypes rather than classes); because of that, we may not adopt native class syntax.