
Overture JS – A powerful basis for building web applications - fanf2
http://overturejs.com/
======
nmjenkins
Hello, primary author of Overture here. Wasn't expecting someone to link to
this old site again!

Anyway, a few quick points. Overture is the basis for both the FastMail
([https://www.fastmail.com](https://www.fastmail.com)) and Topicbox
([https://www.topicbox.com](https://www.topicbox.com)) web apps and really
does provide a great basis for building large, performant rich applications.
However…

I do not recommend other people user Overture directly at the moment (although
you might like to look at the code base for some useful ideas you can steal).
We don't currently have the resources to build all the documentation,
tutorials and other resources needed to build a community around it, and with
that in mind we are currently not committed to non-breaking changes or
semantic versioning (we can update our own apps at the same time as any
breaking change). We originally open-sourced this when we were part of Opera,
mainly so that if we parted ways and needed to build something new, we could
still reuse all this code (it couldn't end up as proprietary Opera code!).

I'm happy to answer general questions here however if people are interested.

------
joekrill
Always nice to see competition... But I've been poking around this site for a
few minutes and I can't find anything convincing me why I would need or even
want to use this. There's no real "getting started" guide. No real sense of
what an OvertureJS App looks like or why it's better than existing option.

There's some vague performance comparisons, but I'm not even sure what exactly
is being compared. One comparison is to OvertureJS+, but there's zero mention
of what _that_ is and how is that different from just plain OvertureJS. Plus
any time I see React being compared directly with Angular it's a huge red flag
that we're comparing apples to oranges.

I don't know, maybe I"m just hypercritical because it's Monday morning.

~~~
helb
There are some examples in their github repo to get an idea what an OvertureJS
app looks like:
[https://github.com/fastmail/overture/tree/master/examples](https://github.com/fastmail/overture/tree/master/examples)

Todo.js seems to be quite amply commented (but yeah, i still don't see why
would i want to use it)

~~~
joekrill
Yeah it's got some decent commenting around a good chunk of the functions. But
there's no sense of the overall concepts. It looks like there's a "store" and
a "view"... there's some "actions", and something called a "source"...

I'm sure if I spent enough time I could figure out what all this stuff does
and how it interacts. But I'd need a compelling reason to spend my time to do
that in the first place. Why wouldn't I just use something like Angular that
provides this kind of information right upfront? Or React+Redux where there
are a million guides describing the concepts and how everything fits together?

------
danirod
Even though I prefer accessing my mail and notes through IMAP, and my
calendar, contacts and files through DAV using native apps on my computer and
phone, I love using Fastmail's web user interface. It's fast, it's responsive
(UI is simplified on mobile but it's still the same design; not an alternative
layout) and it looks really good.

Site is down because of bandwidth limits. This is also a Fastmail feature: you
can serve a directory uploaded to your file storage through HTTP. Even though
there are bandwidth limits, it works as an alternative to GitHub Pages or to
just make available some files you want to share with multiple people.
However, it seems it doesn't survive a Hacker News hug of death.

~~~
Theizestooke
Does it offer encryption features like protonmail or tutanota? I had a free
fastmail account for a very long time, but switched once they moved to a pay-
only model.

Basically fastmail is ok, but not really worth paying for. The interface isn't
revolutionary, but does its job. If you're happy with gmail or whatever web-
client you're currently using, you're not missing much.

~~~
reacharavindh
I'm a paying user of FastMail and love it for the same reasons you think
they're not not worth paying for :-)

Simple, minimal, FAST interface. I want it to just show my email and get out
of the way. It is great at it. No fancy animations, no heavy UI actions, very
FAST to use. I can happily use it even over a cellular connection without
bloat.

Encryption like Protonmail - I wish Protonmail was the E2E encryption tool
with convenience, but to me, it is NOT!

\- I need to trust their promise not to deliver malicious web encryption code.
What good is encryption if I need to trust them blindly?

\- As a collateral for this not so great encryption, they can't index my
emails - meaning I can't search my emails based on keywords. This regression
makes it useless to me.

I pay for FastMail to host my personal email, and if they ever sell my data
without my consent, I will look into legal action against them. It'd be a joke
to think such a logic with Google.

~~~
mercer
On the last point, how much does it matter if so much of your email will still
end up at google (either because of gmail accounts or google apps accounts
where you don't even know right away that it's Google)?

------
bigbrooklyn
I use fastmail, and it's pretty fast. I too have wondered what was under the
hood, but I figured it out a while ago [1]. The docs are pretty old, and it
could use better examples, but its a solid library. If you look at the code,
it won't take long to figure out how everything works. They also open sourced
JMAP[2] which is the synchronization protocol they use.

[1] [https://blog.fastmail.com/2014/12/20/open-sourcing-
overturej...](https://blog.fastmail.com/2014/12/20/open-sourcing-overturejs-
the-js-lib-that-powers-fastmail/)

[2] [http://jmap.io/](http://jmap.io/)

------
dewey
Looks like it's overloaded a bit

> The page you have tried to access is not available because the owner of the
> file you are trying to access has exceeded our short term bandwidth limits.
> Please try again shortly.

> 451 A file of this size would cause "overturejs.com//" to exceed the per-
> hour file bandwidth limit of 1000.00 MB, try again later

~~~
helb
Google cache:
[http://webcache.googleusercontent.com/search?q=cache%3Aovert...](http://webcache.googleusercontent.com/search?q=cache%3Aoverturejs.com&oq=cache%3Aoverturejs.com)

Github repo:
[https://github.com/fastmail/overture](https://github.com/fastmail/overture)

------
madspindel
> Overture is a powerful JS library for building really slick web
> applications, with performance at, or surpassing, native apps.

Surpassing native apps? Yeah, right.

Edit: Site is working now!

~~~
StavrosK
Have you used Fastmail? The UI is definitely on par, and probably faster, than
my OS's native apps.

I've long wondered how they do that, now I know.

~~~
fnl
As a FastMail user, I must say the UI _startup_ time is painfully loooong ...

~~~
chrismorgan
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.

~~~
fnl
Well, I'm baffled. :-) Thanks for this great response, looking forward to the
changes!

------
BrandoElFollito
When I see such libraries, I would like to quickly understand if I am a
potential user.

Instead of telling me the lib is great, things like the ones below are more
useful:

You use moment.js? Mylib.js has better support for time parsing. Example :...

You use vuejs? Mylib.js does not require blah and the binding uses standard
foo to do bar. Example :...

Etc. The author knows what others are using so pointing out how his lib is
better (or positively different) compared to the others would actually be
helpful

------
maephisto
"powerful", "really slick", "awesome". For a tool aimed at developers, I'd
surely enjoy more technical terms.

~~~
unit91
Sadly their pitch is probably about right these days.

------
joaojeronimo
Slashdotted ?

451 A file of this size would cause "overturejs.com//" to exceed the per-day
file bandwidth limit of 2000.00 MB, try again later

------
lpghatguy
My favorite red flag, a class with a name as generic as 'Object', indicating
the ultimate not-invented-here case.

[https://github.com/fastmail/overture/blob/master/source/foun...](https://github.com/fastmail/overture/blob/master/source/foundation/Object.js)

Or better, 'Class':

[https://github.com/fastmail/overture/blob/master/source/core...](https://github.com/fastmail/overture/blob/master/source/core/Core.js#L424)

JavaScript has classes! What are you doing?

~~~
chrismorgan
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.

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

------
geekamongus
> per-day file bandwidth limit of 2000.00 MB

Doh.

------
rammy1234
there is a bandwidth restriction to access this site !!

------
megamindbrian2
You should fire your host for not auto-scaling.

------
romanovcode
You should rename Angular to Angular.js in your comparison. They are two
completely different frameworks.

------
chrismorgan
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...](https://blog.fastmail.com/2017/12/18/using-the-modern-web-platform/).

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

~~~
nikkwong
Nitpick—based on your statements, I'm curious as to how you can claim
manipulating the DOM be faster/more efficient than using a virtual DOM? I was
under the impression that the very opposite was true, which is what gave birth
to the virtual DOM. In any case, good work.

~~~
chrismorgan
VDOM is cheaper than a _naïve_ DOM approach, but a lot more expensive than an
_efficient_ DOM approach.

Let’s use as our context TodoMVC ([http://todomvc.com/](http://todomvc.com/)),
and the action of adding a new item to the list, after having typed something
in the box and pressed Enter.

The most efficient solution to adding an item is to craft a single new <li>
and insert it in the right place into the list.

One extremely inefficient DOM approach would be to replace the entire list in
the DOM, iterating through all the items and making a new <li> for all of
them. This will work OK for a very few items, but once you get lots of items,
it makes adding items very slow, because the browser is having to throw away a
large number of DOM elements and insert a new bunch of DOM elements, applying
their styles and all.

The VDOM approach is to have a virtual DOM that can be comparatively cheaply
crafted, and rerender the entire list, but using that VDOM rather than the
actual slow DOM; then, compare the old rendering and the new rendering, and
apply any changes to the DOM—in this case, that will mean that it does finally
craft that single new <li>, inserting it in the right place.

The VDOM approach is inherently doing more work than is strictly necessary;
but it does so and has become popular in recent years because it makes it
decidedly easier to write that code, and makes it harder to make mistakes,
because you’re only defining how to render a view, rather than how to render a
view as well as how to synchronise changes in the data.

So long as you’re sensible in what you do, Overture is much faster than
anything that uses a VDOM. But you’re responsible for hooking things up so
that it knows that, when such-and-such a property changes, it needs to be
redrawn in such-and-such a fashion. That can be hooked up in many ways; the
most blunt is to say “when any property changes, redraw the entire view,” and
the most fine is to say “in a todo item view, when the text of the item
changes, replace the contents of its text node (which we stored a reference to
when we drew it in the first place)”—and you’re not going to get more
efficient than that! But as you can imagine, there’s a lot more scope for
making mistakes which lead the view being out of sync with the data.

It’s all about tradeoffs. The VDOM approach lets you develop things faster,
while the efficient DOM approach produces a result that runs faster and more
smoothly. There are good arguments to be made in both directions; but I’m glad
that we at FastMail focus on making it fast for the user.

The Ember team’s work with Glimmer is an impressive hybrid of the two models;
the _Why Tracked Properties?_ section of
[https://glimmerjs.com/guides/tracked-
properties](https://glimmerjs.com/guides/tracked-properties) is a really good
summary of some of the issues around VDOMs, and how Glimmer engineers around
them. I like Glimmer.

------
maxpert
Site is down :P seems down from github what socked me was command:

``` make docs ```

------
aphextron
Might want to consider moving the homepage to Github pages

------
nishs
The webpage says:

    
    
      Bandwidth Restricted
      
      The page you have tried to access is not available because 
      the owner of the file you are trying to access has exceeded 
      our short term bandwidth limits. Please try again shortly.
    

At first, I thought this was a banner to raise awareness on net neutrality.

~~~
y4mi
i'm guessing their marketing people used their own static website service to
host the site, which is rate-limited by default... and they probably forgot to
disable the limit for it.

would not surprise me the least from the last 12 month of service i've got
from them.

everything they offer is at best usable, slightly lacking would be the honest
opinion though.

i.e.

1\. 25GB Cloud Storage. can only be accessed from the browser.

2\. Mail sorting rules can only be applied when the mail first comes onto the
server, applying them to emails already received is impossible.

3\. Marking mails read on their own (not a third party!) app keeps them unread
on the web interface. The Web app is not a native application. I'm still
amazed how the managed that.

~~~
spystath
I believe files can be accessed by Webdav
[https://www.fastmail.com/help/files/davnftp.html](https://www.fastmail.com/help/files/davnftp.html)

~~~
y4mi
thats good to know, i wasn't aware of that.

the named problems were just examples though... there are sadly others.

* Right-click isnt implemented.

* Switching to their embedded DNS service pushes your whois information to the whole web (pretty much every other dns service hides it behind anonymized contact information)

* adding external mail servers (i.e. fetching mails from old gmail or hotmail.com account) constantly gets you 'the target mail server was unresponsive' messages. Its good that they're warning about incorrect information, but it does get old if it happens only once every few days on one refresh.

... and there are so many more examples

~~~
chrismorgan
> Switching to their embedded DNS service pushes your whois information to the
> whole web

Whois and DNS are two different things; whois information comes from the
registrar; DNS providers have no control over whois records.

~~~
y4mi
> (whois) Changed: 2017-10-02T13:26:26+02:00

Thats the day i've set the NS record to the fastmail server.

~~~
nmjenkins
Well you must have updated the whois data or protection options with your
domain registrar at the same time, whether intentionally or not. FastMail is
just hosting the DNS. It cannot have any effect on your whois data.

------
j4ship
what a advertisement. Get their interest by describing what you do then make
them fill in how.

You are about 5 years late. Please add more to your link page. Its not like
you are talking to an uninformed commuinty

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

