Gmail.js – JavaScript API for Gmail
github.com
github.com
https://www.sitepoint.com/mastering-your-inbox-with-gmail-ja... https://www.sitepoint.com/sending-emails-gmail-javascript-ap...
The big selling point for me is the observation of events like compose window. You can then write code that plugs into the gmail interface.
> Linux (or BSD [U+1F642]) would
EDIT: Does HN not support emoji?
EDIT^2: How it should look: https://pastebin.com/raw/rKmTCdFX
A square box with 01F 642 in it? I'd rather have a nose on my smilies.
edit: you downvoters are lame. What a bunch of wimps
edit: You downvoters of my comment, however, are lame!
If it's acceptable that it breaks often then it's fine to use, but if you're expecting reliability, then no.
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.
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.
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
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.
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
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.
``` find(SomeTitle).parent.parent.find(p[something]).text ```
If I remember right, it underwent a major rewrite a year or so ago, after which is has been very solid.
After I did a Show HN in late 2013 a lot of people expressed interest in using this and ever since then, gmail.js has been used by a lot of individuals and startups. I'm really happy that people still frequently contribute to the library by adding features and/or reporting bugs and it has definitely gotten stronger and more stable over the past year (a very special thanks to Brent Kelly)
As a funny observation, the public sentiment towards gmail's DOM still remains the same as it was 3-4 years ago, and while I agree that it changes quite often, I do believe that the severity of those changes is heavily overstated. The disadvantage of an abstraction layer like gmail.js is that you always have to be on top of the DOM, but gmail.js is at a place where enough people are using it that if some major change occurs to the gmail UI, it'll be reported a lot faster because there is now a community using the library. In the past 3.5 years, only a single DOM change on gmail (about 2 weeks ago) has made a breaking change that affected all users from this library.
The whole thing is intentionally designed to be a single file where majority of the functions are standalone so if something goes wrong, anyone can easily understand how it works! That being said, a lot of the focus of this library is to abstract network events so developers making extensions on top of gmail can fire off events when a gmail user gets a new email, sends email, deletes etc. Those things rely very little on the DOM.
And as always, feedback and bugs welcomed :-)
I personally found both to be lacking in different areas, too bad they weren't merged together to cover a broader base.
Gmail.js lets you avoid doibng the DOM hacking yourself but is still fairly low level. The InboxSDK was targeted for people who are building apps inside of Gmail. We assume multiple extensions to be running and make sure they play nice, we handle auto updates to handle changes in Gmail and we try to guide developers to using standard Gmail UI styles. We have inbox support coming soon which will let you write your app once and have it work in Gmail and Inbox.