6 ms·
Gmail.js – JavaScript API for Gmail
- sdegutis 10y agoSeems this is mainly meant for writing Chrome extensions.
- seibelj 10y agoWe 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.
- J_Darnley 10y agoThank god for POP3, IMAP, and SMTP: the superior ways to use Gmail.
- seibelj 10y agoWe were creating a chrome / firefox extensions to manipulate the gmail UI, the project was unrelated to email protocols (but I understand the snark ;-) )
- phaed 10y agoThe snark was uncalled for, so is drawing noses on emoticons.
- nathancahill 10y agoThey are also running into this issue: https://xkcd.com/541/ https://xkcd.com/541/
- colejohnson66 10y agoThe one thing I like about emoji is that it solves this problem. > Linux (or BSD [U+1F642]) would EDIT: Does HN not support emoji? EDIT^2: How it should look: https://pastebin.com/raw/rKmTCdFX https://pastebin.com/raw/rKmTCdFX
- J_Darnley 10y ago> How it should look A square box with 01F 642 in it? I'd rather have a nose on my smilies.
- tomc1985 10y agoSnark is always called for, always appropriate! edit: you downvoters are lame. What a bunch of wimps
- mrb 10y agoMaybe you should explain this in the README. My first thought too was "why are they not using IMAP"?
- deleted 10y ago[deleted]
- phaed 10y agoIt's open-source, if you rely on it, fork it and fix it yourself.
- JoshGlazebrook 10y agoThat 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.
- alooPotato 10y agosee my comment to your sibling...
- seibelj 10y agoThe 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.
- nathancahill 10y agoWhich Gmail addon did you work on?
- seibelj 10y agoAn MVP for a startup we never got any traction on :)
- alooPotato 10y agoFounder 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.
- andreasklinger 10y agoAgree. 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
- foota 10y agoIt 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.
- andreasklinger 10y agoi dont know how it's today 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 ```
- taternuts 10y agoThats 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')
- idbehold 10y agoCan the title be changed to indicate that this is only for userscripts and/or browser add-ons/extensions?
- iqisracist 10y agoAnything available for google hangouts like this?
- nathancahill 10y agoThis 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 10y agoCreator 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 :-)
- redtrackker 10y agoInboxSDK (from Streak) is the best API to use for Gmail.
- ivanstegic 10y agoI agree, here's the link: https://www.inboxsdk.com/ https://www.inboxsdk.com/
- dmix 10y agoThey 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 10y agoFounder 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 10y agoI 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.
- apetresc 10y agoNow 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).
- jamies888888 10y agoI'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-javascript-api/ https://www.sitepoint.com/mastering-your-inbox-with-gmail-ja... https://www.sitepoint.com/sending-emails-gmail-javascript-api/ https://www.sitepoint.com/sending-emails-gmail-javascript-ap...
- sb8244 10y agoI 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.
- kartikt 10y agoCreator of gmail.js here - please see my comment to nathancahill on this thread :-)
- uyoakaoma 10y agoWhy are the advantages of using this API over other tools like Google App Script.
- kartikt 10y agoThis is primarily designed to make chrome extensions on top of gmail
- jonahx 10y agoI skimmed the README, but it wasn't clear to me what this does that the official Gmail API doesn't do...
- yeukhon 10y agoI 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 10y agoThank you for the kind words!
- yclept 10y agoWould this not be against the terms of service :)
- tedchs 10y agoYou 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