cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: adding 'browser' as a platform for cordova.js
Date Mon, 09 Dec 2013 23:32:58 GMT
Answers to Jesse inline (and should answer other queries too).

> Interesting.  Can you elaborate on use-cases that this would make sense
> for?
In order of selfish priority.

- Browser targeted deployment (an original goal of that PhoneGap thing we
based our efforts on)
- Surfacing platform incompatibilities from web browsers (such as page
visibility api vs our pause/resume thing)
- Simplest possible reference implementation for future platform targets
- Optimizing cordova.js (the size for exec/parse not an issue so much as
the size indicates waste)

> It is acceptable that cordova_plugins.js does not exist, as this should be
> caught, and recovered from in all platforms.  Yes, this file will be
> created when any plugin is added.
Cool. I created a bug for this. [1]

> The code you posted is essentially the FirefoxOS exec code, which is
> essentially the Windows8 exec code, maybe we should just make this a
> default exec.

I am all for consolidating them into the smallest possible implementation.

> >> Should we consider deprecating pause/resume for page visability api?
> >>
> > Makes sense to me.
> I think there is still value in having a distinction between the 2.  It may
> make sense for the browser to use visibility to trigger pause/resume, but I
> don't think native platforms should necessarily.  Worth some
> experimentation and more discussion though.

I'll start a thread. Would like to dig into this thinking.

Re: size of the file. There are several optimizations we could add, but as
> part of packaged apps, load time has not seemed to be an issue in awhile.
> Measurement should come first.

If the goal was performance I would agree but my goal is removing
unnecessary code and getting our thinking back to browser based
development. An alt impl that does not use the cordova.js ceremonies could
clock in at 10 LOC. I'm not trying to optimize performance so much as
leaving the footprint for the userland rather than our framework code that
effectively is a noop. (The nice side effect of this thinking is that we'd
gain better perf too.)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message