I am the author of Simple Gmail Notes (a free extension for Chrome and FF). When I started to develop the extension years ago, I did some research of InboxSDK and Gmail.js. I am not sure if it's still true now, but at that time when I use the SDK I need to load a remote and minified JS file hosted at the Streak server, which seems not a good idea for security concerns. I don't think Streak will try to steal the data in purpose, but still... Also, I wonder if that might cause problems with extension verification nowadays. Both FF and Chrome has more strict safety policies now.
I then tried to use Gmail.js for a while, but it seems not that stable, the extension got a lot of complaints of not working from time to time (Gmail.js cannot load email data correctly, but not every time).
After a few months, I finally decided to parse the DOM data myself, it's actually not THAT difficult, if you are not trying to build an extremely powerful extension.Gmail.com did change the UI from time to time, but it's not that huge actually. For the latest big UI change on Gmail, I remember it took me about 1MD to finish all the required code changes.
We also decided not to use InboxSDK because it has to dynamically load from Streak's servers. If you are open source hobby project this is probably okay, but for a real business this is a potentially business-ending risk.
What do you do if Streak's servers go down? You pay them nothing and have no priority support.
What do you do if Streak pushes a breaking change and brings down your app in real time?
What about if Chrome Web Store continues to lock down the ecosystem and restricts all dynamic script loading from cross origins?
We only needed a fraction of InboxSDK's API footprint so we just built our own adapter layer similar to theirs covering what we need. Now we control our own destiny.
I think their SDK had a better value prop when Google was maintaining both Gmail and Inbox. But now that they've merged there's only one DOM to worry about. And let me just say from experience that Google alters the Gmail DOM very rarely. I think they know there are a ton of extensions leaning on it, which is why they communicated the new UI so far in advance.
Hey founder of Streak (authors of the InboxSDK) - sorry the SDK didn't meet your need. See one of my other comments about why we remote load (its so that we can react to Gmail changes without all the extension developers needing to update their extensions AND to guarantee compatibility between extensions).
Will try to address some of your questions:
> What do you do if Streak's servers go down? You pay them nothing and have no priority support.
It's a fair concern, we don't charge for the SDK. But we do charge for Streak and have built an 8 figure business. We care a lot about the dependability of the SDK because we care a lot about our own business. Streak loads the SDK in the exact same way as other extension developers do and we use the exact same APIs. We also have large organizations that depend on our uptime (Dropbox, Hubspot, etc)
> What do you do if Streak pushes a breaking change and brings down your app in real time?
We are the most advanced user of the SDK (we use almost all the APIs) so we'd be breaking ourselves too.
> What about if Chrome Web Store continues to lock down the ecosystem and restricts all dynamic script loading from cross origins?
Great question. It is true that they are locking down the remote loading. InboxSDK currently has an exemption to this rule (as do some other popular and similar libraries). However, over the long term (think years) we will move away from remote loading. We're currently working with Google on a solution that should retain some of the benefits of remote loading, while allowing Google to statically analyze the SDK for security. It hasn't been finalized but the SDK will be allowed to continue remote loading until that is in place. Remember, we have every incentive to make this work for everyone including ourselves.
Yes，I did fix a few. However, there are two places I am uncomfortable with gmail.js (again, that's a few years ago):
1. I remember it greatly depend on hijack of a global variable in Gmail.com, but occasionally the value is not available (depend on where the user refreshed the page and network speed of the user)
2. it try to send network requests to Gmail.com directly (on behalf of logged in Gmail user) and get the query result, but those API are supposed to be used only by Gmail.com internally. So once the API format changes, some data could not be collected.
In general I think this approach raised too much dependency on misc aspects of Gmail.com. Now customized DOM parsing also depend on Gmail UI, but that should be the ONLY thing that would break the system.
I then tried to use Gmail.js for a while, but it seems not that stable, the extension got a lot of complaints of not working from time to time (Gmail.js cannot load email data correctly, but not every time).
After a few months, I finally decided to parse the DOM data myself, it's actually not THAT difficult, if you are not trying to build an extremely powerful extension.Gmail.com did change the UI from time to time, but it's not that huge actually. For the latest big UI change on Gmail, I remember it took me about 1MD to finish all the required code changes.