Q&A with Grammarly’s Sergey Yavnyi

Published in

Mozilla Tech

6 min readNov 20, 2017

Grammarly has an ambitious plan: to help people with their written communication, everywhere they type. So its software has to work with browsers, web editors, and Microsoft Office. Grammarly’s Lead Engineer for Extensions, Sergey Yavnyi, was up to the challenge. Speaking from his San Francisco office, he explained how he built the Grammarly add-on for all four major browsers.

Q: How did you get started with the Grammarly add-on?
Six years ago, we started developing browser extensions, first for Google Chrome and then for Mozilla Firefox. We started with separate code bases, but by the time we released on Firefox, we had a somewhat uniform code base. We used a browser extension SDK called OpenForge. That gave us a set of tools to develop cross-browser add-ons.

Q: How has the technology changed since then?
During migration to the WebExtensions API, we replaced OpenForge with a custom-built wrapper around browser APIs. It serves as a layer between the application code and browser APIs, which allows us to have a universal code base that is mostly shared between browsers.

Q: Why did you create a Grammarly add-on? What problem does it solve?
With Grammarly, we want to help people communicate in a more clear, effective way. We want people to have Grammarly everywhere they go and type. For most people, that’s the web. It’s incredibly useful to have Grammarly in the browser as a browser extension, so you can go to your social media website or email, and it can help with your writing.

Q: Why Firefox?
We did Grammarly for Firefox and other browsers because we wanted to reach as many people as we could. Also, we really like to work with Firefox. Its support for WebExtensions means we can reuse code, making development faster. Also, we’re really excited about all the latest updates in Firefox, like the new rendering engine coming in Firefox Quantum. I’m excited that the new Firefox will make our extension faster.

Q: What resources were useful to learn about the WebExtensions API?
Mozilla has really good documentation on MDN web docs, so it was easy to learn it.

Implementation

Q: What languages or tools did you use?
We used TypeScript, React.js, Redux, Stylus/PostCSS, Webpack, Gulp, Jest, WebdriverIO, and TestingBot.

Q: On a scale of 1 to 10, with 1 being the easiest, how difficult was it to implement your WebExtensions add-on?
It wasn’t entirely easy, since we have a large codebase, but I can’t say it was difficult either. I’d give it a 2 or 3, in terms of difficulty. We use a limited set of APIs, and we didn’t depend on any [Firefox legacy] XUL-specific APIs, so this migration wasn’t really hard for us.

Q: What problems, if any, did you experience while developing a WebExtensions add-on for Firefox?
There was just one issue we encountered, not related directly to the WebExtensions API. Sometime in early 2017, the new version of Firefox changed how localStorage works for extensions. We hadn’t anticipated that.

Q: How did that impact your users’ experience?
What happened was, it seemed that local storage wasn’t persistent, at least, not every time and not for every user. In our case, it led to an issue with the welcome page that we show to new users. Since we used localStorage to remember whether the welcome page was shown before, we ended up showing it every time the browser started up. So we had to disable that functionality until we figured out what was going on.

Q: How did you fix it?
We migrated to WebExtensions API storage. That fixed it. Our complication was that we had to migrate existing localStorage data for users who had it. It took us a couple of releases to complete the migration.

Q: What advice do you have for developers who have this same problem?
My advice is to pay more attention to Mozilla’s documentation than we did. :)

Q: How much time did it take to port your add-on to a different browser?
It took about four months to build an internal alpha for Microsoft Edge, which was the last browser we implemented on. Then another month to make it ready for the public. So five months total.

Q: What are the challenges there?
Each browser has a different implementation of the extension API. Even though the interface might look similar across browsers, there are still differences. For instance, it was challenging to implement the messaging API layer in Apple Safari, since its native messaging API is so different from other browsers’ messaging APIs. While it has its own differences, Edge’s messaging API interface is the most similar to the WebExtensions messaging API.

Q: Do you have any advice on dealing with the different browser APIs?
Yes. For us, it was very useful to come up with an abstraction for messaging that can handle the communication between the browser tabs and background. Then, we can implement the abstraction for each browser. Another tip I would give is to test messaging thoroughly, as it can often play a key role within the application. Incorrect implementation of the messaging API can lead to issues that are difficult to diagnose.

Areas of Improvement

Q: How well do other browsers support the WebExtensions API?
Besides Firefox, I cannot say technically that other browsers are WebExtensions compliant. Edge comes the closest. Chrome is similar. But Safari is completely different.

Q: Would it help if other browsers also adopted the WebExtensions API?
Yes, it would definitely make browser extension developers’ lives easier if all browsers adopted an extension API standard like WebExtensions. So far only Microsoft Edge seems to be embracing the WebExtensions API standard. Even though Chrome’s API was the inspiration for WebExtensions, there doesn’t seem to be any forward movement right now. Safari, on the other hand, is going in an opposite direction with native app extensions.

Q: What other platforms do you develop for?
So we mentioned the add-ons for Firefox, Chrome, Safari, and Edge browsers. We also do a web editor application, desktop editors for Windows and Mac, a Microsoft Office add-in, and a mobile keyboard on iOS and soon Android. For each of these, a user would have to install Grammarly separately, to have access on all these platforms. We don’t have a unified installer today. But if you are logged in to the desktop app, you are able to work on the same documents as you had in your web app.

Q: How is the process of publishing an add-on different today?
Firefox’s change to WebExtensions was great from a business point of view, because the review process is now automated, so it’s much faster. Before, every time we had a release cycle, it took two to three weeks to get it live in the store. Our first submission of the Grammarly add-on was under review for almost six months. There were a lot of issues that we fixed during that time, and we had multiple reviews. Since Mozilla switched to WebExtensions, reviews for our update releases take about 10 minutes.

Q&A with Grammarly’s Sergey Yavnyi

Implementation

Areas of Improvement

Related Content

Written by Judy DeMocker