21–30 of 52 posts
Earlier quoted context omitted.
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.
Which Gmail addon did you work on?
https://www.sitepoint.com/mastering-your-inbox-with-gmail-ja... https://www.sitepoint.com/sending-emails-gmail-javascript-ap...
Earlier quoted context omitted.
It's open-source, if you rely on it, fork it and fix it yourself.
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.
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.
Earlier quoted context omitted.
It's open-source, if you rely on it, fork it and fix it yourself.
That 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.
InboxSDK (from Streak) is the best API to use for Gmail.
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.
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.
Earlier quoted context omitted.
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.
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.
By the way, there's a real opportunity to own the content side of gmail development. Articles on getting up and running, like building a basic Rapportive clone, would be incredible.
Earlier quoted context omitted.
Thank god for POP3, IMAP, and SMTP: the superior ways to use Gmail.
We were creating a chrome / firefox extensions to manipulate the gmail UI, the project was unrelated to email protocols (but I understand the snark ;-) )
Earlier quoted context omitted.
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.
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.
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/sending-emails-gmail-javascript-ap...
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.