The Chrome Store itself is a pile of rubbish apps with very few exceptions.
If you're into client-side web development to any extent, you've probably heard of Facebook's React library. I was working on a Chrome extension, and decided to see how well React fit in to the development I was doing.
He also uses Browserify as well, which I'm interested in because I tried using RequireJS for sharing code between Chrome extensions and Firefox add-ons, and I struggled to get it to work in Firefox. My Firefox add-ons are using the Jetpack SDK rather than the old XUL way.
We wanted to get data from the current web page and then use it to populate a form that appears in a new window.
It was easy to create a context menu item that triggered an event, but sending data based on the current page to the new window wasn't obvious.
You might find this useful if you're just getting into Chrome extensions and want more concrete examples than what Google provides.
I know a lot of DailyJS readers who use Chrome and Safari as their main browsers, partly due to iOS and Android's popularity, and partly because Chrome's initial performance gains enticed them away from Firefox. The big issue over the last few years has been the fact browsers are switching to using multiple processes, the idea being that resources can be shared better and fallout from crashes can be mitigated.
If Firefox isn't your main browser, you probably use it for testing or just try it out every few months to see what's been going on. The thing most of us have been looking for is Chrome (and apparently IE)-style multi-process support. Bill McCloskey has written a post about this very topic: Multiprocess Firefox. Bill is a programmer at Mozilla, and you may remember his post about incremental GC in Firefox.
If you're an add-on author, you'll be pleased to hear add-ons are being taken seriously. However, Mozilla may need your help in the future:
We realize that add-ons are extremely important to Firefox users, and we have no intention of abandoning or disrupting add-ons. At the same time, we feel strongly that users will appreciate the security and responsiveness benefits of multiprocess Firefox, so we're willing to work very hard to get add-ons on board. We're very interested in working with add-on developers to ensure that their add-ons work well in multiprocess Firefox.
It's hard to imagine Firefox OS not using multiple processes, and Bill mentions this early on in the post:
Firefox OS relies heavily on the multiprocessing and IPC code introduced during Electrolysis.
Electrolysis was a project to use multiple processes, but the focus was tighter than changing the desktop browser. Firefox's layout engine, Gecko, supports multiple threads, and the "Gecko platform" supports multiple processes. But, as the Electrolysis wiki page points out, the Firefox frontend does not currently use multiple processes.
Will we see a browser share increase when Firefox is updated to support multiple processes? I don't know, but as a front-end developer I'm excited about seeing this feature released sooner rather than later.