cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Camden <>
Subject Re: Summarizing thoughts on cordova-browser vs Ripple
Date Mon, 17 Nov 2014 11:37:17 GMT

On 11/15/14, 2:17 PM, "Michal Mocny" <> wrote:

>Ray, I think (hope) you are slightly misreading the distinction.  Trying
>Ripple is an (optional) tool for mobile-device-emulation.  It just happens
>to be implemented in a browser, and yes has historically been used by devs
>to run cordova apps locally in a browser.  But ripple does a lot more than
>some devs need/want.  We want to take all those extras out for
>cordova-browser, and leave them in for Ripple.

I disagree completely. ³just so happens to be implemented in a browser²
makes it sound like a random thing. Ripple was a way to make use of the
speed of a browser to run my PG/Cordova apps while Œfaking¹ stuff like
camera and GPS. It let me focus on the non-Cordova stuff, like random APIs
(especially since it lets me bypass the remote XHR restriction w/o CORS).

>Specifically, cordova-browser would provide a minimum valid cordova
>environment & plugin browser shims, just so your app loads without errors
>in a browser.  There would not be any specific mobile device or platform
>emulation.  Many devs do this manually today (Adobe even presented on this
>topic at PGDay), but cordova-browser will automate some of the work now.

And I strongly vote against this. The fact that I can fake camera w/ BAAP
now and not rely on Ripple, which again was dead for like a *year*, is a
huge big deal to me, and I¹d argue others as well.

It sounds like we are saying we should take BAAP, which has the beginnings
of a good Ripple replacement, and neuter it, which I think would be

>What you do with the browser targeted version of your application is up to
>you.  Some developers won't use it at all, others may use it for rapid
>development on a subset of the app, while others may use it to actually
>publically host for the mobile web.  I'm not necessarily sure if that last
>point is a great idea, but I'm convinced we shouldn't get in the way of
>others trying.  (Ray, if you don't want the public to use your app from a
>browser, just don't host it, that will be your call to make).

I guess this is the main sticking point then. It sounds like you are
saying we should support browser as a complete platform, and having the
plugins do too much will be a problem. I think there is a chance folks may
want BAAP to be used publicly, but I think a good debugging alternative
would be *much more* desired.

As an example, I¹ve got an app now which uses barcode scanning for one
small part. By adding the Browser platform to the plugin, I am able to do
all of my work in the browser now and fake a barcode when I need it. That
is a problem that - imo - is much more valuable than supporting browser as
a destination of my app.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message