7 ms·

Show HN: Gmail.js – JavaScript API for Gmail

212 points by kartikt 13y ago

untog 13y ago
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.
- abentspoon 13y ago
  First, yes, this is really cool. However, it's even worse than you think. It's making a lot of references to minified/obfuscated names. Things like $('.nH.hx'). When I was working on a gmail script[1] a year or two ago, many of those were changing every few hours. It's solvable, but not easy. 1. http://qwerjk.com/revert-gmail/ http://qwerjk.com/revert-gmail/
- Griever 13y ago
  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 13y ago
    There's a new "Save to drive" button now anyway!
    - Griever 13y ago
      True! And because of that, the project would have been killed regardless. A year ago though, this was not the case.
gailees 13y ago
This is awesome.
- ten7 13y ago
  Yep. Mind blown.
gkoberger 13y ago
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.)
- kartikt 13y ago
  Neat suggestion. It could totally be uploaded to a cdn where people can simply import it and once a change occurs on Gmail and the script gets updated, everybody benefits.
  - gkoberger 13y ago
    That probably won't work. The add-on reviewers are very strict about running arbitrary code loaded from somewhere else, and no add-on using it would be approved. (After all, you could change your code and store people's emails.) That being said, you should be able to use this to load new selector strings for the API: https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/request.html https://addons.mozilla.org/en-US/developers/docs/sdk/latest/... http://developer.chrome.com/extensions/webRequest.html http://developer.chrome.com/extensions/webRequest.html
    - joshuacc 13y ago
      It wouldn't necessarily need to be code. It could just be JSON data with updated selectors, etc. Just make sure you use JSON.parse on it, and there aren't any security issues from just fetching the data.
      - gkoberger 13y ago
sumit_psp 13y ago
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 13y ago
  Planning to switch the Gmail code on https://trysignal.com https://trysignal.com to gmail.js. That should be out soon
jorgem 13y ago
Similar in some ways to api that is in streak.com
- deleted 13y ago
  [deleted]
typpo 13y ago
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 13y ago
  Definitely! Mind creating an issue out of it? I'll add it to the list
grinich 13y ago
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 13y ago
  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 13y ago
    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. :-/
- znowi 13y ago
  > I've been working on a new email platform This! You're doing it right. I wish all the Gmail tweakers united to build a better platform rather than spend their time propping the old, PRISM-tainted, UI-crippled service.
  - andreasklinger 13y ago
    People are building those gmail extensions because people already use gmail. Not because they couldn't build a nicer interface. It would be great if Gmail would officially support extensions. Their current approach is very limited.
togasystems 13y ago
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.
deleted 13y ago
[deleted]
kirbyk 13y ago
You probably know more about Gmail then you ever wanted to, right?
- kartikt 13y ago
  haha will not disagree
jamesjyu 13y ago
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 13y ago
  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.
advisedwang 13y ago
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!
- csallen 13y ago
  This API is for interacting with Gmail's user interface more so than for interacting with its back-end data.
- kartikt 13y ago
  SMTP? Never heard of it. This library is more for developing chrome extensions that take advantage of gmail's DOM and UI state
- OGC 13y ago
  AFAIK Gmail's implementation of IMAP is kind of borked and stuff like the "smart" categorization (e.g. social networks, notifications, etc) doesn't reflect into imap folders (or RSS their RSS feeds, for that matter). Labels do, though, with a workaround.
Sicp 13y ago
I don't understand the potential..
tericho 13y ago
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/gmail.js#L49 https://github.com/KartikTalwar/gmail.js/blob/master/src/gma...
- nilliams 13y ago
  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.
catmanjan 13y ago
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 13y ago
  Hey catmanjan, see jamesjyu's comment :-)
xpressyoo 13y ago
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 13y ago
  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 :)
driverdan 13y ago
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 13y ago
  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.
rohitv 13y ago
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 13y ago
  Thanks Rohit!
zrgiu_ 13y ago
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 13y ago
  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
melpomene 13y ago
Been looking for something like this! Perfect. Thanks for the effort!
- kartikt 13y ago
  Thanks!
pknerd 13y ago
I would love if someone make it to work by using oAuth in js.

212 points by kartikt 13y ago

untog 13y ago

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.

abentspoon 13y ago
First, yes, this is really cool. However, it's even worse than you think. It's making a lot of references to minified/obfuscated names. Things like $('.nH.hx'). When I was working on a gmail script[1] a year or two ago, many of those were changing every few hours. It's solvable, but not easy. 1. http://qwerjk.com/revert-gmail/ http://qwerjk.com/revert-gmail/
Griever 13y ago
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 13y ago
  There's a new "Save to drive" button now anyway!
  - Griever 13y ago
    True! And because of that, the project would have been killed regardless. A year ago though, this was not the case.

gailees 13y ago

This is awesome.

ten7 13y ago
Yep. Mind blown.

gkoberger 13y ago

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

kartikt 13y ago
Neat suggestion. It could totally be uploaded to a cdn where people can simply import it and once a change occurs on Gmail and the script gets updated, everybody benefits.
- gkoberger 13y ago
  That probably won't work. The add-on reviewers are very strict about running arbitrary code loaded from somewhere else, and no add-on using it would be approved. (After all, you could change your code and store people's emails.) That being said, you should be able to use this to load new selector strings for the API: https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/request.html https://addons.mozilla.org/en-US/developers/docs/sdk/latest/... http://developer.chrome.com/extensions/webRequest.html http://developer.chrome.com/extensions/webRequest.html
  - joshuacc 13y ago
    It wouldn't necessarily need to be code. It could just be JSON data with updated selectors, etc. Just make sure you use JSON.parse on it, and there aren't any security issues from just fetching the data.
    - gkoberger 13y ago

sumit_psp 13y ago

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 13y ago
Planning to switch the Gmail code on https://trysignal.com https://trysignal.com to gmail.js. That should be out soon

jorgem 13y ago

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

deleted 13y ago
[deleted]

typpo 13y ago

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 13y ago
Definitely! Mind creating an issue out of it? I'll add it to the list

grinich 13y ago

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 13y ago
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 13y ago
  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. :-/
znowi 13y ago
> I've been working on a new email platform This! You're doing it right. I wish all the Gmail tweakers united to build a better platform rather than spend their time propping the old, PRISM-tainted, UI-crippled service.
- andreasklinger 13y ago
  People are building those gmail extensions because people already use gmail. Not because they couldn't build a nicer interface. It would be great if Gmail would officially support extensions. Their current approach is very limited.

togasystems 13y ago

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.

deleted 13y ago

[deleted]

kirbyk 13y ago

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

kartikt 13y ago
haha will not disagree

jamesjyu 13y ago

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 13y ago
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.

advisedwang 13y ago

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!

csallen 13y ago
This API is for interacting with Gmail's user interface more so than for interacting with its back-end data.
kartikt 13y ago
SMTP? Never heard of it. This library is more for developing chrome extensions that take advantage of gmail's DOM and UI state
OGC 13y ago
AFAIK Gmail's implementation of IMAP is kind of borked and stuff like the "smart" categorization (e.g. social networks, notifications, etc) doesn't reflect into imap folders (or RSS their RSS feeds, for that matter). Labels do, though, with a workaround.

Sicp 13y ago

I don't understand the potential..

tericho 13y ago

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/gmail.js#L49 https://github.com/KartikTalwar/gmail.js/blob/master/src/gma...

nilliams 13y ago
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.

catmanjan 13y ago

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 13y ago
Hey catmanjan, see jamesjyu's comment :-)

xpressyoo 13y ago

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 13y ago
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 :)

driverdan 13y ago

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 13y ago
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.

rohitv 13y ago

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 13y ago
Thanks Rohit!

zrgiu_ 13y ago

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 13y ago
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

melpomene 13y ago

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

kartikt 13y ago
Thanks!

pknerd 13y ago

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