Live data from Hacker News

Show HN: Gmail.js – JavaScript API for Gmail

github.com

41–50 of 63 posts

Re: Show HN: Gmail.js – JavaScript API for Gmail

#41
post #18

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…

sounds exciting - I've pinged you an email and am keen to check it out!

Re: Show HN: Gmail.js – JavaScript API for Gmail

#42
post #38
post #18

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…

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

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.

Re: Show HN: Gmail.js – JavaScript API for Gmail

#43
post #36

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/gma...

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.

Re: Show HN: Gmail.js – JavaScript API for Gmail

#44

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…

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

#45

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…

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…

Thank you Andy!

Re: Show HN: Gmail.js – JavaScript API for Gmail

#46
post #15

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…

Not sure Google would like this?

Why would they not like this? You still need to open up gmail.com. This is pretty much like you scraping google search results.

Re: Show HN: Gmail.js – JavaScript API for Gmail

#48

Hi 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 :)

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

Re: Show HN: Gmail.js – JavaScript API for Gmail

#50

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?

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.
Post reply on HN