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) and Topicbox (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.
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.
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?
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.
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.
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.
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)?
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.
> 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
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.
Can't confirm. Reloading the page takes at most two seconds with a multi GB inbox. I've can't remember ever feeling that their initial page load time is slow. Odd.
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
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.
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.
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’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:
(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.)
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.
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/), 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 is a really good summary of some of the issues around VDOMs, and how Glimmer engineers around them. I like Glimmer.
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.
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.
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.
Anecdote vs anecdote, I've had my account connected to a Gmail account for email and two others for calendars for over a year, and the only errors I've received were when I changed my account passwords and didn't update them in FastMail.
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.
3) That's not true. I'm using their Android app and marking any mail read/unread is instantly replicated to the open web interface on my desktop machine and vice versa.
faster than native applications .... the borwser on the phone is a native application. The browser engine doesnt render faster then any other browser engine.
Anyway, a few quick points. Overture is the basis for both the FastMail (https://www.fastmail.com) and Topicbox (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.