I like the questions I get when I talk about my job. In fact, I can’t wait to hear 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 aspects of app design that I’m most passionate about.
Overture is tightly coupled with JMAP, the JSON Meta Application Protocol. JMAP Mail was designed in response to the limitations of IMAP, a protocol for interacting with email messages. From the start, JMAP emphasized speed and developer ergonomics. We use JMAP in all of our APIs: not just the typical culprits that are Internet Engineering Task Force (IETF) standards. In addition to email, we also use JMAP for things like managing hidden email addresses, user preferences, and messages to our support team.
We want to be proud of the tools we use. Some frameworks are more developer-friendly, and they may have more documentation and more people working on them, but those benefits come with trade-offs that we’re not comfortable making.
Take, for example, React. React is not slow, but it’s not fastmail fast. In contrast, Overture emphasizes speed. It defaults to lazily computed properties. An Overture view that represents data will do exactly the amount of work needed to render a page, with highly optimized paths for drawing at increasingly slower speeds. We also extend these optimizations to the design process of our application. For example, our data models, as code, end up looking amazingly similar to the specs we write and commit to our code repository.
Fastmail’s commitment to values-aligned development work
At Fastmail, our engineering principles are based on our values. Our use of Overture and JMAP reflects our commitments to our users and the Internet as a whole. We enjoy taking 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. In line with this, we integrate our work on open source software and our commitment to developing open standards into every step of our process.
For example, we have automatic tools to ensure that the code we write for Overture’s front-end application for Fastmail can be shared and used by the world. Likewise, Squire, the rich text editor we wrote for composing 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 main maintainers of the Cyrus mail server, which is open source software written in C; Fastmail CTO Ricardo Signs is on the Perl Board of Directors; even the Slack bot we use to have fun and automate our work is open source!
Many Fastmailers engage in standards work through the IETF, with JMAP being the primary, 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. However, working at Fastmail, using Overture and JMAP, I feel like I’m helping to shape the future of the internet, and that my job is part of something bigger than just one proprietary email service.
Open source work takes time, and sometimes that means time not spent delivering features to the public. It’s a lot less work when you don’t have to design and build your own tools. I see it as a process of building and working up front to pay off later. Working deliberately now allows us to move faster in the future. One of my all time favorite quotes is from a racing driver and performance coach Ross Bentley:
“Steer, shift and use the pedals smoothly and with finesse – not with blistering speed and brute force. The slower you move, the faster the car moves.
I think the results of this are evident – reflecting on the past few months, not only have we implemented custom swipes and scheduled messaging, but we’ve also made some exciting changes behind the scenes; one example being enhancements to our continuous integration automated testing framework. We are able to act quickly because we have a common understanding of our systems and a strong sense of our application design.
That’s not to say owning your own stack is right for everyone. I think once you hit a certain level, you’ll start to notice the inefficiencies around you. Once that happens, you might find it’ll be faster and maybe even more fun to build it yourself. Not every organization will have the expertise or the time to be able to go out and build things off the beaten path.
However, I would ask all of you to know your values: Know the Why behind the What will make the architectural decisions almost obvious. Knowing that everyone on the team shares these same values means that these conversations always start on common ground with a shared goal. If you understand that, the rest are just implementation details.