We used this for a project before, just be aware that the DOM changes regularly for gmail, and if an API you rely on breaks you will be SOL until someone fixes it.
Thats exactly what I was wondering about; you can see in the latest merge 11 days ago that a selector had to be updated with random junk to match a recent change (from '.ii.gt' to '.ii.gt div.a3s.aXjCH')
Agree.
I did a gmail plugin before gmail.js came out.
You kind have the same problem if you are the only one using your custom lib and you dont have a huge army of others who could fix it. And it's… so… much… more exhausting
It seems like you might be able to come up with a way to auto-generate these selectors based on known content on the page. ie, find the thing that has this text in it and use that as the selector from now on.
back then we even ended up using surprisingly complex structures that actually are close to what you describe but clientside. as in: we didnt rely on classnames but often on positions next to some text.
The issue is that gmail will update at anytime, without warning, so there will always be a period when your service will break. And you need to have unit tests running often to figure out when it breaks, and have a dev on call 24/7 to ensure a speedy fix. This is a universal problem with extensions targeting website DOM's, but worse if you have an SaaS product that has an SLA.
Founder of Streak here (we make the InboxSDK) - this is one area where we take a slightly different approach than Gmail.js.
We host our SDK and you remotely load it at runtime. The benefit is that we detect breakages due to gmail and automatically update the SDK. Your users just need to refresh gmail to load your extension and the latest SDK which is compatible with any changes Gmail makes.
InboxSDK looks awesome. I took a look at it several months ago, and we want to build something on GMail. We're a little concerned about the licensing and availability of the library, though. Is it possible that a month from now you decide that we're competing with something you want to do, and stop serving the library for our app? What would be our recourse then?
Our terms of service are listed at https://www.inboxsdk.com/terms. Specifically we will notify registered developers whenever we change our terms and you can use the old terms for some period of time.
In general though, we treat the SDK as its own product and have several competitors to Streak using it. We have millions of end users using apps built on the SDK from major companies (Dropbox, Hubspot, etc) so we're pretty careful with our terms.
The main goal is to retain the ability to maintain compatibility between different extensions being run by the same user and being able to respond quickly to changes in Gmail.
We use your InboxSDK and it is wonderful. Made development of an extension delightful, especially compared with the workflow around Outlook Add-ons and Wordpress Plugins.
By the way, there's a real opportunity to own the content side of gmail development. Articles on getting up and running, like building a basic Rapportive clone, would be incredible.
The library is remote loaded at runtime. We update it on our servers and the next time the user refreshes gmail, the library gets pulled down again.
EDIT: we have automated systems that help with this though making our turnaround time incredibly fast. We also see the changes to gmail before 99% of users so usually our updates are out before users even refresh to get the new version of gmail
That still doesn't make it reliable. If it's known the DOM changes regularly and breaks this api library, then why bother in the first place? Sure you can fix it yourself, but why not avoid the hassle and use something standard that doesn't break as much.
If it's acceptable that it breaks often then it's fine to use, but if you're expecting reliability, then no.
We were creating a chrome / firefox extensions to manipulate the gmail UI, the project was unrelated to email protocols (but I understand the snark ;-) )
