Statement that firefox Add-ons inside the broweser don't have a sandboxing is false. All the add-on SDK built add-ons load in sandboxed in a less privileged JS

Statement that firefox Add-ons inside the broweser don't have a sandboxing is false. All the add-on SDK built add-ons load in sandboxed in a less privileged JS sandbox, although it is true that there is an escape hatch via `require("chrome")` as some add-ons just want to make modifications that are not even possible elsewhere. This is also reflected on reviews add-ons that do not use `require("chrome")` go through a faster review process while add-on's that do use `require("chrome")` get more thorough reviews. Your criticism in regards to tooling is valid, but it ignores a bigger picture. Two of the the three different ways of writing add-ons have existed long before chrome was even announced and made great add-ons like firebug possible. The fact that there is already a three different ways to write firefox add-ons is outcome of constant improvement of the firefox add-on platform. While this makes things little confusing for newcomers, it still necessary to keep old add-on systems in place, as this keeps people's add-on's alive and subsequently make users using those add-on happy. You also misreading blog posts about JPM, as it is not a new official tool yet, but we are working hard to get there. As of reason why, add-on SDK was designed with commonjs modules in mind as we saw it becoming de facto standard. Back then node was not announced yet, needles to mention npm and tons of packages published to it. There for toolchain named CFX was written in python. Now that node became a standard tool in the JS toolchain and npm is where js libraries get published we are working to refresh our toolchain and embrace all this, subsequently making thousands of packages available in npm available to an add-on authors.