We should measure it. It will most certainly be slower if the init does some sort of native marshaling but lazy loading behavior can be coded into the plugins themselves to mitigate this. Having an entry file is more expected (imo) for a runtime behavior.
On Wed, Apr 9, 2014 at 10:54 AM, Andrew Grieve <[email protected]> wrote: > It changes semantics (code that didn't use to run at start-up, now does). > That's not backwards compatible. > > We had a huge perf gain in CLI by not requiring sub-modules on start-up. I > don't think it'd be quite as bad for plugins... but... > > One example in the org.chromium.runtime plugin is that it includes a crypto > library as a module that isn't parsed until someone accesses the > chrome.runtime.id getter. Parsing this at start-up would be noticeable. > > > > On Tue, Apr 8, 2014 at 1:19 PM, Anis KADRI <[email protected]> wrote: > > > It is not a breaking change therefore it is backward compatible [1]. If > > there is a good reason to keep the current "feature" then I'd like to > know > > it. > > > > [1] http://en.wikipedia.org/wiki/Backward_compatibility > > > > > > On Tue, Apr 8, 2014 at 10:51 AM, Andrew Grieve <[email protected]> > > wrote: > > > > > If there's an option to not change the behaviour, I think we should use > > it. > > > This is a pretty big change, so anything we can keep the same will > help. > > We > > > can't say that it's backwards compatible if the runtime behaviour > > changes. > > > > > > > > > On Mon, Apr 7, 2014 at 6:39 AM, Braden Shepherdson < > [email protected] > > > >wrote: > > > > > > > Strictly speaking it may be that a plugin could actually want to not > be > > > run > > > > until it was require()d. In practice, I suspect most plugins either > > want > > > to > > > > clobber, merge or run, all of which will require it. So I think we're > > > okay > > > > with this change. That seems like an odd practice by browserify, but > I > > > > suppose it should be mostly harmless. > > > > > > > > Braden > > > > > > > > On Sat, Apr 5, 2014 at 1:09 AM, Michal Mocny <[email protected]> > > > wrote: > > > > > > > > > So I did try your node.js sample code, and you're right, it runs > all > > > > > modules by default. This surprises me, but I guess having all > > modules > > > > have > > > > > an implicit <runs/> is better than dropping support for it. > > > > > > > > > > The thing to keep an eye out for is degraded startup performance > with > > > > this > > > > > change. > > > > > > > > > > -Michal > > > > > > > > > > > > > > > On Fri, Apr 4, 2014 at 11:04 PM, Anis KADRI <[email protected]> > > > > wrote: > > > > > > > > > > > The reason why JS-only platforms (firefoxos, tizen, windows8, > ...) > > > use > > > > > > <runs/> is because they need to populate their commandProxyMap in > > > order > > > > > for > > > > > > exec to direct calls to the appropriate module. All js-only > modules > > > > call > > > > > > something like this: > > > > > > > > > > > > require("cordova/firefoxos/commandProxy").add("Vibration", > > > > > module.exports); > > > > > > Obviously this has to run before the module can be used. > > > > > > > > > > > > browserify runs all modules by default (yes, even if they're not > > > > > required) > > > > > > when the bundle first loads. Which means a module can set itself > > up, > > > > > > clobber, merge whateva...or just define itself and set its > > > > module.exports > > > > > > map for it to be consumed by other modules. > > > > > > Check out my response in the long thread if you want to > experiment. > > > > > > > > > > > > _There is a way_ to call only a subset of modules or just one > > module > > > > > (like > > > > > > a main.js) but the real point is: > > > > > > > > > > > > Do we have a reason to prevent a module from running (defining > > itself > > > > > > really) until require()d ? That's the example I am requesting and > > the > > > > > > question I am asking. > > > > > > > > > > > > > > > > > > On Fri, Apr 4, 2014 at 7:05 PM, Michal Mocny < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > gfind -name plugin.xml -exec grep -Hn "runs" {} \; > > > > > > > ./cordova-plugin-battery-status/plugin.xml:90: > <runs/> > > > > > > > ./cordova-plugin-camera/plugin.xml:37: <runs /> > > > > > > > ./cordova-plugin-contacts/plugin.xml:159: <runs /> > > > > > > > ./cordova-plugin-device/plugin.xml:29: <runs /> > > > > > > > ./cordova-plugin-device-motion/plugin.xml:34: <runs /> > > > > > > > ./cordova-plugin-device-motion/plugin.xml:133: > <runs/> > > > > > > > ./cordova-plugin-device-orientation/plugin.xml:36: > <runs > > > /> > > > > > > > ./cordova-plugin-device-orientation/plugin.xml:145: > > > > <runs/> > > > > > > > ./cordova-plugin-dialogs/plugin.xml:34: <runs /> > > > > > > > ./cordova-plugin-geolocation/plugin.xml:147: <runs > /> > > > > > > > ./cordova-plugin-globalization/plugin.xml:91: > <runs/> > > > > > > > ./cordova-plugin-media/plugin.xml:138: <runs/> > > > > > > > ./cordova-plugin-network-information/plugin.xml:32: > > > <runs > > > > /> > > > > > > > ./cordova-plugin-network-information/plugin.xml:143: > > > <runs > > > > > /> > > > > > > > ./cordova-plugin-splashscreen/plugin.xml:103: <runs > /> > > > > > > > ./cordova-plugin-vibration/plugin.xml:27: <runs /> > > > > > > > ./cordova-plugin-vibration/plugin.xml:115: <runs /> > > > > > > > ./cordova-plugins/websql/plugin.xml:12: <runs /> > > > > > > > > > > > > > > > > > > > > > Most of these are for firefoxos or tizen (Haven't > investigated), > > > but > > > > > one > > > > > > is > > > > > > > not: > > > > > > > [android]: ./cordova-plugins/websql > > > > > > > -- Why is it needed? Because it only clobbers WebSql when run > > from > > > > > > file:// > > > > > > > protocol > > > > > > > > > > > > > > > > > > > > > Anyway, more generally, its useful for when you need to do some > > > setup > > > > > > > before pluginready / DOMContentLoaded, which is especially > useful > > > > when > > > > > > you > > > > > > > are dealing with code that isn't cordova.require() aware. > > > > > > > > > > > > > > > > > > > > > For Chrome Apps, we used to use <runs/> a lot, but > miraculously I > > > see > > > > > now > > > > > > > that we have replaced all usage with <clobbers/> and <merges/> > > > (which > > > > > is > > > > > > > like runs + extra). I proposed we could replace > clobbers/merges > > > > with a > > > > > > > single runs in another thread. > > > > > > > > > > > > > > -Michal > > > > > > > > > > > > > > > > > > > > > On Fri, Apr 4, 2014 at 8:47 PM, Anis KADRI <[email protected]> > > > wrote: > > > > > > > > > > > > > > > If we need it. Could anybody point me to an example of > how/why > > > that > > > > > is > > > > > > > > needed ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
