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 featu…
Show HN: Gmail.js – JavaScript API for Gmail
41–50 of 63 posts
Re: Show HN: Gmail.js – JavaScript API for Gmail
#42Unfortunately 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 featu…
> 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.
It would be great if Gmail would officially support extensions. Their current approach is very limited.
Re: Show HN: Gmail.js – JavaScript API for Gmail
#43Thanks 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...
$('.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.Re: Show HN: Gmail.js – JavaScript API for Gmail
#44It 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…
(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!
Re: Show HN: Gmail.js – JavaScript API for Gmail
#45It 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…
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…
Re: Show HN: Gmail.js – JavaScript API for Gmail
#46It 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…
Not sure Google would like this?
Re: Show HN: Gmail.js – JavaScript API for Gmail
#47Re: Show HN: Gmail.js – JavaScript API for Gmail
#48Hi Kartik, Gmelius ( http://gmelius.com ) developer here! Great stuff. Will be glad to help you maintain the API up-to-date, if you wish so :)
Re: Show HN: Gmail.js – JavaScript API for Gmail
#49Re: Show HN: Gmail.js – JavaScript API for Gmail
#50I'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?