Re: [CODE4LIB] Safari extensions
Honestly I try to switch to Chrome every month or so, but it just doesn't do what Firefox does for me. I've actually been using a Firefox mod called Pale Moon [1] that takes out some of the not so useful features for work (parental controls, etc) and optimizes for current processors. It's not a huge speed increase, but it is definitely noticeable. Oh, and Chrome doesn't have Vimperator [2] :) Joel [1] http://www.palemoon.org/ [2] http://vimperator.org/ -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Richard, Joel M Sent: Thursday, August 05, 2010 4:24 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Safari extensions If I remember correctly, the latest versions of Firefox had problems, but I don't know if it's related to performance necessarily. More like bloat. http://bit.ly/c1c3m1 Either way, I definitely find Firefox too slow to use after the switch to Chrome, which took all of 5 minutes to completely convert me. If Chrome were a drug, I'd be strung out and living on the streets. But what's to say it won't head the same way as Firefox in the future (bloat-wise.) It's also a memory hog, especially when you load up Firebug. Chrome's debugging tools are like a dream come true. That said, I'm not that kind of developer, so I won't be able to help port any extensions to Chrome or Safari. Testing, yes, porting, no. :) --Joel Joel Richard IT Specialist, Web Services Division Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | (202) 786-2861 (f) | richar...@si.edu From: Raymond Yee y...@berkeley.edu Reply-To: Code for Libraries CODE4LIB@LISTSERV.ND.EDU Date: Thu, 5 Aug 2010 16:15:59 -0400 To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Safari extensions Has anyone given thought to how hard it would be to port Firefox extensions such as LibX and Zotero to Chrome or Safari? (Am I the only one finding Firefox to be very slow compared to Chrome?) -Raymond On 8/5/10 1:10 PM, Godmar Back wrote: No, nothing beyond a quick read-through. The architecture is similar to Google Chrome's - which is perhaps not surprising given that both Safari and Chrome are based on WebKit - which for us at LibX means we should be able to leverage the redesign we did for LibX 2.0. A notable characteristic of this architecture is that content scripts that interact with a page are in a separate OS process from the main extensions' code, thus they have to communicate with the main extension via message passing rather than by exploiting direct method calls as in Firefox. - Godmar On Thu, Aug 5, 2010 at 4:04 PM, Eric Hellmane...@hellman.net wrote: Has anyone played with the new Safari extensions capability? I'm looking at you, Godmar. Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/ @gluejar --
Re: [CODE4LIB] Safari extensions
On Fri, Aug 6, 2010 at 8:19 AM, Joel Marchesoni jma...@email.wcu.edu wrote: Honestly I try to switch to Chrome every month or so, but it just doesn't do what Firefox does for me. I've actually been using a Firefox mod called Pale Moon [1] that takes out some of the not so useful features for work (parental controls, etc) and optimizes for current processors. It's not a huge speed increase, but it is definitely noticeable. Chrome is certainly behind Firefox in its extension capability. For instance, it doesn't allow the extension of context menus yet (planned for later this year or next), and even the planned API will be less flexible than Firefox's . It is hobbled by the fact that the browser is not itself written using the same markup language as its extensions, so Google's programmers have to add an API (along with a C++ implementation) for every feature they want supported. Regarding the JavaScript performance, both Firefox and Chrome have just-in-time compilers in their engines (Chrome uses V8, Firefox uses TraceMonkey), which each provide an order or two of magnitudes speedup compared to interpreters that were used in FF 3.0 and before. Regarding resource usage, it's difficult to tell. Firefox is certainly a memory hog, with internal memory leaks, but when the page itself is the issue (perhaps because the JavaScript programmer leaked memory), then both browsers are affected. In Chrome, I've observed two problems. First, if a page leaks, then the corresponding tab will simply ask for more memory from the OS. There are no resource controls at this point. The effect is the same as in Firefox. Second, each page is scheduled separately by the OS. I've observed that Chrome tabs slow to a halt in Windows XP because the OS is starving a tab's thread if there are CPU-bound activities on the machine, making Chrome actually very difficult to use. - Godmar
Re: [CODE4LIB] Safari extensions
I tried Vimium and found it lacking, which actually led me to Vimperator. If I remember correctly, though, Vimium allows you to set your own bindings so perhaps the emacs bindings are already out there somewhere. Joel -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of David A. Faler Sent: Friday, August 06, 2010 8:41 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Safari extensions Joel, You could try vimium [1] to get vi keybindings for Chrome. I haven't used it (I'm waiting for emacs bindings), but it might help make it usable for you. [1] http://github.com/philc/vimium Thank you, David Faler IT Quality Control and Testing The Library Corporation - Joel Marchesoni jma...@email.wcu.edu wrote: Honestly I try to switch to Chrome every month or so, but it just doesn't do what Firefox does for me. I've actually been using a Firefox mod called Pale Moon [1] that takes out some of the not so useful features for work (parental controls, etc) and optimizes for current processors. It's not a huge speed increase, but it is definitely noticeable. Oh, and Chrome doesn't have Vimperator [2] :) Joel [1] http://www.palemoon.org/ [2] http://vimperator.org/ -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Richard, Joel M Sent: Thursday, August 05, 2010 4:24 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Safari extensions If I remember correctly, the latest versions of Firefox had problems, but I don't know if it's related to performance necessarily. More like bloat. http://bit.ly/c1c3m1 Either way, I definitely find Firefox too slow to use after the switch to Chrome, which took all of 5 minutes to completely convert me. If Chrome were a drug, I'd be strung out and living on the streets. But what's to say it won't head the same way as Firefox in the future (bloat-wise.) It's also a memory hog, especially when you load up Firebug. Chrome's debugging tools are like a dream come true. That said, I'm not that kind of developer, so I won't be able to help port any extensions to Chrome or Safari. Testing, yes, porting, no. :) --Joel Joel Richard IT Specialist, Web Services Division Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | (202) 786-2861 (f) | richar...@si.edu From: Raymond Yee y...@berkeley.edu Reply-To: Code for Libraries CODE4LIB@LISTSERV.ND.EDU Date: Thu, 5 Aug 2010 16:15:59 -0400 To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Safari extensions Has anyone given thought to how hard it would be to port Firefox extensions such as LibX and Zotero to Chrome or Safari? (Am I the only one finding Firefox to be very slow compared to Chrome?) -Raymond On 8/5/10 1:10 PM, Godmar Back wrote: No, nothing beyond a quick read-through. The architecture is similar to Google Chrome's - which is perhaps not surprising given that both Safari and Chrome are based on WebKit - which for us at LibX means we should be able to leverage the redesign we did for LibX 2.0. A notable characteristic of this architecture is that content scripts that interact with a page are in a separate OS process from the main extensions' code, thus they have to communicate with the main extension via message passing rather than by exploiting direct method calls as in Firefox. - Godmar On Thu, Aug 5, 2010 at 4:04 PM, Eric Hellmane...@hellman.net wrote: Has anyone played with the new Safari extensions capability? I'm looking at you, Godmar. Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/ @gluejar -- --
[CODE4LIB] Safari extensions
Has anyone played with the new Safari extensions capability? I'm looking at you, Godmar. Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/ @gluejar
Re: [CODE4LIB] Safari extensions
No, nothing beyond a quick read-through. The architecture is similar to Google Chrome's - which is perhaps not surprising given that both Safari and Chrome are based on WebKit - which for us at LibX means we should be able to leverage the redesign we did for LibX 2.0. A notable characteristic of this architecture is that content scripts that interact with a page are in a separate OS process from the main extensions' code, thus they have to communicate with the main extension via message passing rather than by exploiting direct method calls as in Firefox. - Godmar On Thu, Aug 5, 2010 at 4:04 PM, Eric Hellman e...@hellman.net wrote: Has anyone played with the new Safari extensions capability? I'm looking at you, Godmar. Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/ @gluejar
Re: [CODE4LIB] Safari extensions
Has anyone given thought to how hard it would be to port Firefox extensions such as LibX and Zotero to Chrome or Safari? (Am I the only one finding Firefox to be very slow compared to Chrome?) -Raymond On 8/5/10 1:10 PM, Godmar Back wrote: No, nothing beyond a quick read-through. The architecture is similar to Google Chrome's - which is perhaps not surprising given that both Safari and Chrome are based on WebKit - which for us at LibX means we should be able to leverage the redesign we did for LibX 2.0. A notable characteristic of this architecture is that content scripts that interact with a page are in a separate OS process from the main extensions' code, thus they have to communicate with the main extension via message passing rather than by exploiting direct method calls as in Firefox. - Godmar On Thu, Aug 5, 2010 at 4:04 PM, Eric Hellmane...@hellman.net wrote: Has anyone played with the new Safari extensions capability? I'm looking at you, Godmar. Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/ @gluejar
Re: [CODE4LIB] Safari extensions
If I remember correctly, the latest versions of Firefox had problems, but I don't know if it's related to performance necessarily. More like bloat. http://bit.ly/c1c3m1 Either way, I definitely find Firefox too slow to use after the switch to Chrome, which took all of 5 minutes to completely convert me. If Chrome were a drug, I'd be strung out and living on the streets. But what's to say it won't head the same way as Firefox in the future (bloat-wise.) It's also a memory hog, especially when you load up Firebug. Chrome's debugging tools are like a dream come true. That said, I'm not that kind of developer, so I won't be able to help port any extensions to Chrome or Safari. Testing, yes, porting, no. :) --Joel Joel Richard IT Specialist, Web Services Division Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | (202) 786-2861 (f) | richar...@si.edu From: Raymond Yee y...@berkeley.edu Reply-To: Code for Libraries CODE4LIB@LISTSERV.ND.EDU Date: Thu, 5 Aug 2010 16:15:59 -0400 To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Safari extensions Has anyone given thought to how hard it would be to port Firefox extensions such as LibX and Zotero to Chrome or Safari? (Am I the only one finding Firefox to be very slow compared to Chrome?) -Raymond On 8/5/10 1:10 PM, Godmar Back wrote: No, nothing beyond a quick read-through. The architecture is similar to Google Chrome's - which is perhaps not surprising given that both Safari and Chrome are based on WebKit - which for us at LibX means we should be able to leverage the redesign we did for LibX 2.0. A notable characteristic of this architecture is that content scripts that interact with a page are in a separate OS process from the main extensions' code, thus they have to communicate with the main extension via message passing rather than by exploiting direct method calls as in Firefox. - Godmar On Thu, Aug 5, 2010 at 4:04 PM, Eric Hellmane...@hellman.net wrote: Has anyone played with the new Safari extensions capability? I'm looking at you, Godmar. Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/ @gluejar
Re: [CODE4LIB] Safari extensions
On Thu, Aug 5, 2010 at 4:15 PM, Raymond Yee y...@berkeley.edu wrote: Has anyone given thought to how hard it would be to port Firefox extensions such as LibX and Zotero to Chrome or Safari? (Am I the only one finding Firefox to be very slow compared to Chrome?) We have ported LibX to Chrome, see http://libx.org/releases/gc/ Put briefly, Chrome provides an extension API that is entirely JavaScript/HTML based. As such, existing libraries such as jQuery can be used to implement the extensions' user interface (such as LibX's search box, implemented as a browser action). Unlike Firefox, no coding in a special-purpose user interface markup language such as XUL is required. (That said, it's possible to achieve the same in Firefox, and in fact we're now using the same HTML/JS code in Firefox, reducing the XUL-specific to a minimum). Safari will use the same approach. Chrome also supports content scripts that interact with the page a user is looking at. These scripts live in an environment that is similar to the environment seen by client-side code coming from the origin. In this sense, it's very similar to how Firefox works with its sandboxes, with the exception mentioned in my previous email that all communication outside has to be done via message passing (sending JSON-encoded objects back and forth). - Godmar
