Hi Anthony, Just a relatively quick response for now.
It would be easy to say that the emerging alternative (Tampermonkey) has come a long way in the past couple of years, and that GM could be abandoned. However, I would disagree with this path. I see there is space, and value in having diversity in terms of userscript implementations. Particularly given that Mozilla have said they plan to extend webexts, not just be compatible with them. TM started on Chrome and has become portable on the basis of its webext compatibility. GM on the other hand, focusing on FF that is known to be popular for tinkerers, can forego the portability (as an extension) in exchange for niche and innovative integrations. The other key benefit I see in GM over TM is the UI. If you look at the configuration options on TM, its overwhelming, and in many areas unnecessary. Meanwhile, GM is quite simple and easy to work with, particularly when you write many userscripts for non-developers as I do. There is just so much less that can go wrong. My suggestions would be for option 2.1 above. Version 4 of GM could be webext going forward along with its unchanged API (except now asynchronous). With the emergence of generator functions (and yield) in js specification, converting synchronous function to asynchronous is easier than ever. An alternate related approach is to look at the implementation of TM, and advance that as TM did with GM. How did they implement asynchronous functions for the webextensions API? Learn from the TM folk in terms of how they went about their GM fork. They must already be supporting async calls in the API already, given its webextensions-based anyway. So rather than start completely anew, base the work of GM on TM. I'm not meaning specifically forking code, but rather their design approach and principles, perhaps algorithms in some instances, and improve on that work. See if you can find some Mozillians to work with in extending the webexts API in meaningful ways. Just some quick initial thoughts. Regards, Damien. On Saturday, May 13, 2017 at 4:44:08 AM UTC+10, Anthony Lieuallen wrote: > > Greasemonkey is over ten years old, as are most of its special APIs for > user scripts. They're all (save GM_xmlhttpRequest) synchronous calls, > which made sense at the time. > > In Firefox 57 legacy extensions are gone, only WebExtensions remain. > Webext is different in several ways, including parent (chrome) and child > (content) process separation, communication/coordination via message > passing, and concentration on asynchronous APIs. As I understand it, > there's no way to "block" on an async backing API. > > This leaves several paths forward for Greasemonkey, in no particular order: > > 1. Do our best to emulate the old APIs, with possibly slow, buggy, > inefficient, or inferior functionality. > 2. Add new similar APIs, but with asynchronous interfaces. > 1. With the same names as old APIs. > 2. With new names/organization. > 3. Give up on supporting special APIs. > 4. Give up completely, don't even port Greasemonkey to webext. > > I've got my own opinions here, but before I voice them I'd like to hear > from the community. What would you (script authors especially) like to see > happen? Do you have other ideas I haven't listed? > -- You received this message because you are subscribed to the Google Groups "greasemonkey-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/greasemonkey-users. For more options, visit https://groups.google.com/d/optout.
