cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: Summarizing thoughts on cordova-browser vs Ripple
Date Sat, 15 Nov 2014 20:17:42 GMT
Ray, I think (hope) you are slightly misreading the distinction.  Trying to

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.

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.

For Ripple, which alongside device emulation has been implementing cordova
plugin shims, the cordova-browser platform gives a new fallback option for
plugin implementation.  When/how to do use these fallbacks is up to the
discretion of the Ripple maintainers, and needn't really be our concern.  I
would advise that they fallback for all plugins that they aren't adding
debugging value for, but not my call.

As a developer, you will now be able to run the cordova-browser version of
your app in your "browser" of choice:
- A local desktop browser (possibly with DevTools mobile-emulation turned
on, possibly with live-reload added).
- From the ripple emulator.
- From a browser running inside a mobile device emulator (e.g. the awesome
new Microsoft Android emulator even has device sensor manipulation built
- From a browser running on a usb/network connected physical device.
- From a cordova based application-shell ("app-harness").
- ...

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).

Finally, I don't see a need for ripple platform implementations to ship
with plugins, nor have the Ripple maintainers signalled a need for this.


On Fri, Nov 14, 2014 at 4:23 PM, Ray Camden <> wrote:

> I¹m pretty late to responding to this thread, but I wanted to throw in a
> few comments. In the first msg, Michal Mocny said this:
> "Basically, browser-platform is for getting apps running in a browser (duh)
> with as much working functionality as possible.  Its supposed to simplify
> the 'if cordova then dialog else alert' problem, so you can build even more
> of your app with just local development.  Seemingly this could be used to
> make targeting both web and app even easier.
> Ripple is for instrumenting/debugging apps by manipulating plugins.  Its
> about having a UI that reaches into geolocation or camera and controls what
> the plugin returns to the app.  Its about re-running the same device events
> over and over for tracking application logic changes.²
> I could not disagree with the second part more. I can tell you that from
> my experience, the casual end user/PG developer did not see Ripple as any
> different from what you described in the first paragraph. Maybe I¹m not
> reading you right, but I honestly don¹t think most users of Ripple saw it
> as anything but a way to test your code in the browser.
> Michael Brooks said:
> "Ideally, the Browser Platform is a production deployment environment for
> the web, while Ripple is debugging instrumentation that runs on the Browser
> Platform.²
> Again, I just don¹t see this. ³Production deployment²? As in - it is used
> by the public? I don¹t think our users will see that. I don¹t want the
> public to use my PG/Cordova app in the browser. I, the developer, want to
> use the browser just because it is quicker and the debugging tool is
> better.
> Kirupa said:
> "Cordova-browser shouldn't be responsible for providing mock data, UI, or
> any additional functionality for simulating a plug-in. It¹s primary goal
> is to (as you both mention) be responsible for getting apps to run in the
> browser.²
> I love Ripple, butŠ
> It was dead for a *very* long time. It has come back, and there is
> activity, but I¹m not convinced it will carry on. (Don¹t get me wrong, I
> want it to!) BAAP (I¹m using that for Browser As A Platform, much easier
> to type ;) is baked into Cordova and ³just plain works² once a plugin
> author adds support. It isn¹t an external tool - it is part of the core
> functionality. I think then that if it makes sense for a plugin to do UI,
> then BAAP should do it. I see no reason not too. Since the only one seeing
> it is the developer, then this UI, or mock data, can be simple and direct.
> If it lets me run my app quickly in the browser, then it doesn¹t have to
> be production-ready, just dev-ready.
> Andrew said:
> "From reading this, seems like it could work well to have plugins provide
> both browser and ripple implementations. They could make them the same, or
> have the ripple one provide some sort of nice emulation UI. e.g.²
> I see that as unlikely myself. If I were to write a plugin (I¹ll be
> honest, I haven¹t yet), I can¹t imagine doing the same thing twice for
> both, especially with how little movement has been done in Ripple. As a
> feature, isn¹t it fair to say BAAP is ³done²? I mean it needs support from
> more plugins, but as a feature, it is complete. I don¹t have to worry
> about it not working in the future as Ripple did.
> On 11/14/14, 12:38 PM, "Horn, Julian C" <> wrote:
> >Yes, that's absolutely right.  The ripple and browser platforms can
> >coexist, and you can refer to the API implementations in the
> >cordova-browser platform from the ripple platform.
> >
> >You can imagine how this would work.  The exec call should land in the
> >ripple implementation of the API.  That code can decide whether it needs
> >to delegate to the browser implementation of the API.  (It could use UI
> >to guide this decision.) If so, it finds the browser implementation via
> >execProxy and invokes it.
> >
> >This is easy when the ripple implementation is built in.  Ripple's
> >implementation of "exec" separates the Services registered with Ripple
> >from those that self-register with execProxy. Ripple therefore can prefer
> >its own implementation when both exist. When the ripple and browser
> >implementations are both in the same plugin then you have a conflict
> >because both of them want to self-register as the same service.  Still,
> >I'm confident that this can be sorted out.
> >
> >For example, say the JS part of a plugin calls exec for service S,
> >function F.  The browser implementation self-registers with execProxy as
> >S.  The ripple implementation could self-register as "Ripple S".  When
> >asked to invoke a function in service "S", the Ripple exec function can
> >look for the object registered as "Ripple S" before looking for the
> >object registered as "S".  Easy.
> >
> >    Julian
> >>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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