

Show HN: Gmail.js – JavaScript API for Gmail - kartikt
https://github.com/KartikTalwar/gmail.js

======
grinich
Unfortunately this type of hacking isn't really sustainable. Even small tweaks
to the Gmail UI often change the DOM in very unpredictable ways. When they
released the new compose feature, pretty much every single Gmail Chrome
extension broke.

We haven't really announced it yet, but I've been working on a new email
platform with some friends to solve a lot of these issues. It's essentially
Rails/Meteor for email features, and lets you skip past hacking Gmail or
writing a full IMAP client.

It's called Inbox, and we're aiming to open source it in January. Ping me if
you're interested in playing with it early. :)

~~~
kartikt
Thanks for your feedback. I agree, which is why i decided to put it out there
because I use the library in a chrome extension and if something breaks, I
would be trying to get the extension fixed - patching gmail.js. Still better
than finding random solutions from here and there or duplicating efforts. :-)
I'd be interested in seeing what you guys are working so, so I'll ping you
soon

~~~
grinich
Yeah, I'm certainly not meaning to belittle your efforts. I wrote something
similar (based on jamesjyu's gmailr stuff) for my thesis last year. It's the
best way to do it for relatively simple one-off projects.

The first big challenge is definitely just having a shared toolkit, but it's
next to impossible to provide backwards-compatible APIs when the Gmail UI
changes.

Oh... and IMAP. :-/

------
gkoberger
It would be amazing if this were a service. Easier said than done, I know --
but, basically this but have it check a JSON file every few hours and gets the
updated selectors.

(For people who don't know, all GMail's classes and IDs are things like
'.xb3', and they change often.)

Having worked on Mozilla Add-ons for a long time, one of the biggest problems
was by the time any G-Mail add-on was approved, it was already out of date
again. API calls, when done correctly, are allowed by both Chrome and Firefox
-- this could be a good solution.

(You could easily charge a few bucks for this, and even contact Firefox +
Chrome about making sure the reviewers allow it. Market it as "cutting down on
their time" since there will be less to review.)

~~~
andymitchell
As I understand, from one of the early Gmail product managers, element class
names are the most stable of all the 'fingerprints'. The Javascript data
structures are quite stable, and the element IDs change pretty much every
session.

(Source: I'm the author of the ActiveInbox Gmail extension, and at various
times have spoken to Gmail engineers directly).

I agree a service would be a useful thing. A killer bit of value would be if
it could workaround Mozilla's addon rules. (We actually stopped publishing on
Mozilla addons, because if Gmail changed, we couldn't wait 10 days to be "re-
approved" to fix it, and as mentioned by gkoberger, Mozilla really clamps down
on dynamic in-app updates).

Ymmv, but if it helps... From the POV of an extension developer, service
reliability is critical, and I'm not sure if there's enough GMail extension
developers to be customers and make it economically viable?

If there is, I think the ideal service would taint DOM elements with class
names to make the important things selectable (rather than a Javascript API to
retrieve elements). That way, we could build our own selectors with fail safes
to fall back on (and we don't have the security headache of incorporating your
dynamically-updated code within our own protected sandbox. We can just share
the modified DOM instead).

Whatever you do with it, I'm really impressed with how cleanly you built this
kartikt!

~~~
ma2rten
Maybe it could just be a JSON file with the xpath of all important elements?

Also maybe it doesn't really have to be a service. It could just be a file on
github, where anyone could issue a pull request if gets broken broken. That
way way you would essentially crowd source it.

------
untog
Interesting - and a very good job given what you have to work with. Surely its
incredibly brittle, though? As soon as they release a new version of Gmail
it's going to fail.

But then, I suppose that's how most Chrome extensions work.

~~~
Griever
Yeah, the strange selector names that never cease to change were what
ultimately caused me to abandon my relatively popular Chrome extension "Gmail
Attachments to Drive". Having to constantly update the code every time Gmail
changed just got old really, really fast.

~~~
Hurdy
There's a new "Save to drive" button now anyway!

~~~
Griever
True! And because of that, the project would have been killed regardless. A
year ago though, this was not the case.

------
tericho
Thanks for making the library, glad to see you put lots of time into the docs
too. Hopefully the can of worms you've opened doesn't drive you crazy,
personally I would've stopped the second I found myself writing something like
this...

$($($($('.nH .if').children()[1]).children()).children()[1]).children()[1]

:)

[1][https://github.com/KartikTalwar/gmail.js/blob/master/src/gma...](https://github.com/KartikTalwar/gmail.js/blob/master/src/gmail.js#L49)

~~~
nilliams
To be fair, that's a pretty odd way to write jQuery, which is designed to be
chained. It could be rewritten as:

    
    
        $('.nH .if')
          .children().eq(1)
          .children()
          .children().eq(1)
          .children().eq(1)
    

But if you were just pointing out how brittle it is, then yes, that's still
apparent.

------
jamesjyu
Author of Gmailr here, which apparently inspired this project. Kudos! Glad to
see someone taking the ball and running with it. I haven't had time to update
Gmailr lately, as it is something that needs active maintenance. The main
challenge here is that Gmail will have continue to have bursts of updates that
break extension libraries, with relatively long periods of stability.

~~~
kartikt
Thanks James! Your library was the inspiration for the observer methods. I
agree with the maintenance part but I think having this out there will help
reduce duplicating efforts.

------
driverdan
I'm curious why you'd use the DOM instead of making API calls to the server.
If Google can do it as part of their UI surely a 3rd party script can too. Is
the API more complex than the frequently changing DOM?

~~~
kartikt
Most email data related methods are making the API calls. The DOM is being
used for methods like checking if a user inside an email or if the user has
preview panes enabled. Since the primary goal of the library is to aid with
chrome extension development, checking items in the DOM is quicker.

------
xpressyoo
Hi Kartik, Gmelius ([http://gmelius.com](http://gmelius.com)) developer here!
Great stuff. Will be glad to help you maintain the API up-to-date, if you wish
so :)

~~~
kartikt
Surely! I think the having it out there for anyone to contribute and modify
will benefit all our us. Feel free to add on your suggestions or features that
are missing :)

------
typpo
This is pretty useful. A couple months ago I started making a free self-hosted
version of Boomerang for Gmail, but lost interest because I felt like I would
have to devote most of my time to gmail's idiosyncrasies. Maybe it's time to
get back to work.

Is there a way to add navigation events (eg. user opened email) to the observe
gmail.observe API? Right now it looks like I would have to poll
gmail.check.is_inside_email.

~~~
kartikt
Definitely! Mind creating an issue out of it? I'll add it to the list

------
catmanjan
These projects are already pretty advanced versions of this:

[https://github.com/jamesyu/gmailr](https://github.com/jamesyu/gmailr) and
[https://github.com/joscha/gmailui](https://github.com/joscha/gmailui)

In fact gmailr is used in "Cloudy" \- one of the more advanced gmail plugins.

~~~
kartikt
Hey catmanjan, see jamesjyu's comment :-)

------
togasystems
I use Selenium tests that run on a cron job to check for elements on third-
party websites. This works great and I am able to keep the extension mostly up
to date. One of the issues I have come up against is when a third-party A/B
tests. I usually have to hack around and find an account with the B portion to
make sure everything works.

------
rohitv
Your name sounded very familiar, finally realized from where after reading the
recent opendata email! Great job on this and the OpenDataUW API stuff. I am
also admiring the PHP Scraper Class as I was planning on writing something
similar.

~~~
kartikt
Thanks Rohit!

------
gailees
This is awesome.

~~~
ten7
Yep. Mind blown.

------
zrgiu_
I'd love to use this but I can't figure out what's the action/event for when I
open an email to read it. I'm sure it's there, I just can't see it ..

~~~
kartikt
Hey zrgiu_, there isn't a native observer for that action yet but the closest
call is to check if the user is inside an email. I've created a gh issue out
of it so hopefully you'll be able to set triggers with the observer method,
instead of setInterval

------
advisedwang
Did you know there is a remote API for Gmail which is compatible with
Exchange, Outlook.com, yahoo mail and every other mail provider out there?

It's called IMAP/SMTP!

~~~
kartikt
SMTP? Never heard of it. This library is more for developing chrome extensions
that take advantage of gmail's DOM and UI state

------
sumit_psp
This looks awesome. You should make a demo extension and open source it to
show some of the applications that can be built on top of it.

~~~
kartikt
Planning to switch the Gmail code on
[https://trysignal.com](https://trysignal.com) to gmail.js. That should be out
soon

------
jorgem
Similar in some ways to api that is in streak.com

------
melpomene
Been looking for something like this! Perfect. Thanks for the effort!

~~~
kartikt
Thanks!

------
kirbyk
You probably know more about Gmail then you ever wanted to, right?

~~~
kartikt
haha will not disagree

------
pknerd
I would love if someone make it to work by using oAuth in js.

