I enjoy the questions I get when I talk about my work. I’m really looking forward to hearing those questions that start with “Why don’t you just use…” followed by the name of something cool. These conversations give me the opportunity to talk about the parts of application design that excite me the most.
Overture is closely associated with JMAP, the JSON Meta Application Protocol. JMAP Mail was designed in response to limitations with IMAP, a protocol for interacting with email messages. From the beginning, JMAP has emphasized speed and ergonomics for developers. We use JMAP in all our APIs: not just the typical culprits: Internet Engineering Task Force (IETF) standards. In addition to email, we also use JMAP for things like managing masked email addresses, user preferences, and messaging our support team.
We want to be proud of the tools we use. Some frameworks are friendlier to developers, and they may have more documentation and more people working on them, but with those benefits come compromises that we can’t easily make.
Take React for example. respond is not slowly, but it’s not Fastmail fast. Overture, on the other hand, emphasizes speed. It uses lazy calculated properties by default. An Overture view representing data will do exactly the amount of work it takes to render a page, with highly optimized paths to draw at progressively slower speeds. We also extend these optimizations to the process of how we design our application. For example, our data models, as code, are surprisingly similar to the specifications we write and record in our code repository.
Fastmail’s Commitment to Values-Aligned Development Work
At Fastmail, our technical principles are based on our values. Our use of Overture and JMAP is a reflection of our commitment to both our users and the Internet as a whole. We are happy to take on the challenge of building something the right way to improve the user experience.
One of our company values is that we are good internet citizens. Accordingly, we intertwine our work on open source software and our commitment to developing open standards at every stage of our process.
For example, we have automatic tooling to ensure that the code we write for Overture for Fastmail’s frontend application can be shared and used by the world. Likewise, Squire, the rich-text editor we wrote for composition on Fastmail and Topicbox, is open source and used by places like ProtonMail, Tutanota, Zoho Mail, Superhuman, and Google Earth.
At the other end of the stack, we are also the primary administrators of the Cyrus mail server, open source software written in C; Fastmail CTO Ricardo Signes is on the Perl Steering Group; even the Slack bot we use to help us have fun and automate our work is open source!
Many Fastmailers engage in standard work through the IETF, with JMAP being the main, but not the only, driver of this work.
Using open standards unlocks the potential of email
Email is one of the oldest technologies on the Internet. But by working at Fastmail, with Overture and JMAP, I feel like I’m shaping the future of the Internet and that my work is part of something bigger than a single email service of its own.
Open source work takes time, and sometimes that means time not spent sending public features. It’s a lot less work if you don’t have to design and build your own tools. I see this as a building process and doing work up front so it pays off later. By working consciously now, we can act faster in the future. One of my all time favorite quotes is from driver and performance coach Ross Bentley:
Steer, shift and use the pedals smoothly and with finesse – not with blinding speed and brute force. The slower you drive, the faster the car goes.”
I think the results of this are clear – looking back over the last few months, not only have we implemented custom swipes and scheduled messaging, but we’ve also made some exciting behind-the-scenes changes; an example of this is improvements to our automated testing framework for continuous integration. We can do this quickly because we have a shared understanding of our systems and a strong sense of designing our application.
This is not to say that having your own stack is right for everyone. I think once you get to a certain level you will start to notice the inefficiencies around you. Once this happens, you may realize that it’s faster and maybe even more fun to just build it yourself. Not every organization will have the expertise or the time to build off the beaten track.
However, I would like to ask all of you to know your values: Why behind the what will make architectural decisions almost naturally. Knowing that everyone on the team shares the same values means that these conversations always start on a common ground with a shared goal. If you figure that out, the rest is just implementation details.