This guest post is sponsored by Fastmail. Fastmail is a Technical.ly Talent Pro client.
I enjoy the questions I get when I talk about my work. I actually look 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 a chance to talk about the parts of designing applications that excite me the most.
Overture is tightly coupled 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 outset, JMAP has 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 the management of masked email addresses, user preferences, and messages to our support team.
We want to be proud of the tools we use. Some frameworks are friendlier to developers, and they might have more documentation and more people working on them, but with those benefits come trade-offs that we aren’t comfortable making.
Take, for example, React. React is not slow, but it’s not Fastmail fast. In contrast, Overture emphasizes speed. It uses lazily computed properties by default. An Overture view which represents data will do exactly the amount of work that’s needed to render a page, with highly optimized paths to draw at ever-diminishing speeds. We also extend these optimizations to the process of how we design our application. For example, our data models, as code, end up looking surprisingly similar to the specifications that we write and commit to our code repository.
Fastmail’s commitment to values-aligned development work
At Fastmail, our engineering principles are built on our values. Our use of Overture and JMAP are a reflection of our commitments to both our users and the internet as a whole. We take delight in the challenge of building something the right way in order to make the user experience better.
One of our company values is that we are good internet citizens. In alignment with this, we weave our work on open source software and our commitment to developing open standards into every stage of our process.
For example, we have automatic tooling to make sure that the code we write for Overture for Fastmail’s frontend application can be shared and used by the world. Similarly, Squire, the rich-text editor we’ve written for composition on Fastmail and Topicbox, is open source and used by places like ProtonMail, Tutanota, Zoho Mail, Superhuman and Google Earth.
On the other end of the stack, we are also the primary maintainers of the Cyrus mail server, which is open source software written in C; Fastmail CTO Ricardo Signes is on the Perl Steering Council; even the Slack bot we use to help us have fun and automate our work is open source!
Many Fastmailers engage with standards work through the IETF with JMAP being the primary, but not only, driver of this work.
Using open standards unlocks email’s potential
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 work is part of something bigger than a single proprietary email service.
Open source work takes time, and sometimes that means time not spent shipping public-facing features. It’s a lot less work when you don’t need to design and build your own tools. I think of this as building process and doing work upfront so that it pays off later. Working deliberately now allows us to move faster in the future. One of my favorite quotes of all time is from racing 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 move, the faster the car moves.”
I think the results of this are obvious — reflecting on the last handful of months, not only have we implemented custom swipes and scheduled message sending, but we’ve also made some exciting changes behind the scenes; one example being improvements to our automated, continuous-integration testing framework. We’re able to move this quickly because we have a shared understanding of our systems and a strong sense of how to design our application.
This is not to say that owning your own stack is right for everyone. I think, once you reach a certain level, you’ll start to notice the inefficiencies that surround you. Once this happens you may find yourself realizing that it’ll be faster and maybe even more fun to just build it yourself. Not every organization is going to have the expertise or the time to be able to go off and build things off the beaten path.
I would ask all of you, though, to know your values: Knowing the why behind the what will make architecture decisions nearly self-apparent. Knowing that everyone on the team shares those same values means that these conversations always start on a common ground with a shared goal. If you figure that out, the rest are just implementation details.Learn more about Fastmail and explore jobs
Knowledge is power!
Subscribe for free today and stay up to date with news and tips you need to grow your career and connect with our vibrant tech community.