Why are the advantages of using this API over other tools like Google App Script.
Gmail.js – JavaScript API for Gmail
31–40 of 52 posts
Re: Gmail.js – JavaScript API for Gmail
#32I skimmed the README, but it wasn't clear to me what this does that the official Gmail API doesn't do...
Re: Gmail.js – JavaScript API for Gmail
#33Earlier quoted context omitted.
We were creating a chrome / firefox extensions to manipulate the gmail UI, the project was unrelated to email protocols (but I understand the snark ;-) )
The snark was uncalled for, so is drawing noses on emoticons.
Snark is always called for, always appropriate!
edit: you downvoters are lame. What a bunch of wimps
Re: Gmail.js – JavaScript API for Gmail
#34Earlier quoted context omitted.
They are also running into this issue: https://xkcd.com/541/
The 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
> How it should look
A square box with 01F 642 in it? I'd rather have a nose on my smilies.
Re: Gmail.js – JavaScript API for Gmail
#35We 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.
Thats 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')
Re: Gmail.js – JavaScript API for Gmail
#36Earlier quoted context omitted.
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.
How can you automatically update the SDK?
The library is remote loaded at runtime. We update it on our servers and the next time the user refreshes gmail, the library gets pulled down again.
Re: Gmail.js – JavaScript API for Gmail
#37Why are the advantages of using this API over other tools like Google App Script.
This is primarily designed to make chrome extensions on top of gmail
Re: Gmail.js – JavaScript API for Gmail
#38Earlier quoted context omitted.
How can you automatically update the SDK?
The library is remote loaded at runtime. We update it on our servers and the next time the user refreshes gmail, the library gets pulled down again.
So you don't automatically update the library. You only automatically distribute your manually-updated library.
Re: Gmail.js – JavaScript API for Gmail
#39Earlier quoted context omitted.
How can you automatically update the SDK?
The library is remote loaded at runtime. We update it on our servers and the next time the user refreshes gmail, the library gets pulled down again.
The library is remote loaded at runtime. We update it on our servers and the next time the user refreshes gmail, the library gets pulled down again.
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
Re: Gmail.js – JavaScript API for Gmail
#40This 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.
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 :-)