
Gmail.js – JavaScript API for Gmail - rodrigocoelho
https://github.com/KartikTalwar/gmail.js
======
jamies888888
I've written a couple of articles on the proper Gmail API, why doesn't this
just use that instead of scraping the DOM?

[https://www.sitepoint.com/mastering-your-inbox-with-gmail-
ja...](https://www.sitepoint.com/mastering-your-inbox-with-gmail-javascript-
api/) [https://www.sitepoint.com/sending-emails-gmail-javascript-
ap...](https://www.sitepoint.com/sending-emails-gmail-javascript-api/)

~~~
sb8244
I don't think that this seeks to achieve the same thing as your articles. Does
it?

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.

------
seibelj
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.

~~~
phaed
It's open-source, if you rely on it, fork it and fix it yourself.

~~~
seibelj
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.

~~~
alooPotato
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.

~~~
zkhalique
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?

~~~
alooPotato
Our terms of service are listed at
[https://www.inboxsdk.com/terms](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.

------
nathancahill
This is a great library. Standardizes most of DOM manipulation/action
triggering for everything Gmail does. Although Gmail's DOM changes sometimes
like seibelj pointed out, you'll have the same issue if you roll your own
implementation, so, for me, this is preferable.

If I remember right, it underwent a major rewrite a year or so ago, after
which is has been very solid.

~~~
kartikt
Creator of gmail.js here - thanks Nathan! I started working on this almost 3
years ago for a personal project. At that time there weren't many libraries
available to work on top of gmail so I decided to compile all the helper
functions into a standalone library hoping that after it goes on github,
others might contribute.

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 :-)

------
tedchs
You may be interested to know Google has an official REST API and associated
Javascript library.
[https://developers.google.com/gmail/api/](https://developers.google.com/gmail/api/)
[https://developers.google.com/gmail/api/quickstart/js](https://developers.google.com/gmail/api/quickstart/js)

------
redtrackker
InboxSDK (from Streak) is the best API to use for Gmail.

~~~
dmix
They have slightly different usecases. I used them both extensively and one is
intended for adding a sidebar style chrome extension ala Streak, while
Gmail.js is a simpler event based system.

I personally found both to be lacking in different areas, too bad they weren't
merged together to cover a broader base.

~~~
alooPotato
Founder of Streak here (we make the InboxSDK). Would love to know which use
cases we don't cover but do agree, both libraries were targeted at different
layers.

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.

~~~
dmix
I had more clarity in my thoughts regarding this but it's been a year since I
worked on the chrome extension and the startup folded. Thanks for your
contributions to OSS.

------
idbehold
Can the title be changed to indicate that this is only for userscripts and/or
browser add-ons/extensions?

------
sdegutis
Seems this is mainly meant for writing Chrome extensions.

------
apetresc
Now for somebody to use this to write a Gmail extension that removes the
hundred-levels-deep signature and reply chains that Outlook appends (and which
evades Gmail's currently reply-collapsing).

------
yeukhon
I want to thank the author. Like many users, to repeat this project entirely
on my own would be a nightmare. The GMail HTML source produced from the server
is "minified". Random, meaningless class and id names. Author took on the
burden and made Gmail more accessible for browser extension/add-on. I
implemented a FireFox addon (for accessibility purpose for my senior thesis)
using Gmail.js. Furthermore, the code is very readable and the API is
extremely intuitive and well-designed. Thank you!

~~~
kartikt
Thank you for the kind words!

------
jonahx
I skimmed the README, but it wasn't clear to me what this does that the
official Gmail API doesn't do...

------
uyoakaoma
Why are the advantages of using this API over other tools like Google App
Script.

~~~
kartikt
This is primarily designed to make chrome extensions on top of gmail

------
yclept
Would this not be against the terms of service :)

