Capacitor: Universal Web Applications

Capacitor: Universal Web Applications(capacitor.ionicframework.com)

100 points by fariz_ 8 years ago | 50 comments

Capacitor creator/Ionic co-founder here. Didn’t expect to see this on the front page! Disclaimer: it’s still alpha.

We’re building Capacitor based on feedback from the Ionic community to improve our ability to move across platforms such as App Store/web/electron, make it easier to interact with Native SDKs, mix web and native UI, and manage native app projects/tooling.

One feature I'm really excited about is having Web UI implementations of many Native experiences when running on the web/electron. Here's an example of how the `Camera` plugin looks when running in the web: https://twitter.com/maxlynch/status/961749127657910272. This uses our new Ionic Web Components so you can easily use these controls with low overhead even if you aren't using Ionic.

We hope Capacitor will be useful to other web developers that want to build mobile and desktop web apps, even if they aren’t using Ionic, and we’re building support for hitting the hybrid sweet spot of native UI shell (nav/menus) with web content.

Capacitor will eventually be replacing Cordova in Ionic’s toolchain so it’s going to be a core part of the experience.

joshstrange 8 years ago | |

Can you point me in the direction of any documentation you might have on how a project should be handled with regards to source control? Currently my team doesn't commit the generated platforms/plugins folders but it appears that with Capacitor we might need to start committing some/all of these since it isn't expect to re-generate them from a config.xml like it was with cordova.

Sujan 8 years ago | | |

You commit it all (except what .gitignore already ignores or your IDE adds), the native projects are are not build but source artifacts here. Benefit: Once the project is created, you can modify and adapt it in any way you want and have those changes versioned like all other code changes.

madhato 8 years ago | |

Why not add changes to Cordova instead of making a replacement?

Sujan 8 years ago | | |

Capacitor is not Cordova plus a bit of stuff, but a total reimagining how such a tool should work. Cordova for example is defined by dynamic platforms you can add or remove, or that builds are (or can be) done with the CLI. Capacitor has none of that.

osrec 8 years ago |

Why not just PWAs? I think the browser has come a long way, and a great number of things can now be accomplished in the browser without any additional frameworks. We built Bx (https://usebx.com) without any frameworks and it feels much like a native app on a phone or tablet when added to the home screen.

michaelgreen 8 years ago | |

We built a PWA with vanilla javascript that does a lot of augmented reality work with the camera. The main issue is the lack of iOS support. Apple recently updated iOS to include support for the service worker (literally like this week) but it still lacks a huge number of features that chrome on Android has and basically every desktop browser has.

You do get access to a lot of the core sensors on the device but the inconsistencies on iOS just really make life a lot harder. Hopefully this will change over the next year but I'm not sure how quickly it will happen. So basically yes, you should build PWAs but until apple gets completely on board you can't really leverage them to their full extent like you can with chrome on android.

bl4ckm0r3 8 years ago | | |

ios supports PWAs (service workers) now doesn't it?

chris_engel 8 years ago | |

As soon as you like to access any sensors on the device, the PWA sadly isnt an option anymore.

SparkyMcUnicorn 8 years ago | | |

It depends on the sensors you need access to. An iOS PWA has access to Geolocation, Magnetometer, Accelerometer, Gyroscope, Camera, Audio, Apple Pay, etc.

rhacker 8 years ago | | |

That may be, but I tend to see soo many apps now days that just need basic rendering. I almost wish there was a revolution to go back to when the IOS app store just installed links to URLs. It's so terrible inside phonegap apps such that apps simply can't save my f-ing password! Instead of building out more mobile features to complete the progress made by HTML5 we keep going back to native apps for no reason. Yes I get that there is a certain class of apps that MUST be native, but I would argue the bulk of apps don't need this.

osrec 8 years ago | | |

You're not wrong, but I see this becoming a smaller issue as time progresses. Browsers are adding features all the time and I can see this one being resolved soon as lots of devs are asking for it!

ggg9990 8 years ago | | |

Yes, but half the apps just need to maintain state without logging in.

servercobra 8 years ago | |

I think there's a lot of instances you need more than is currently exposed for PWAs, especially on iOS. Push notifications is a big one. And the home screen installation on iOS (even with 11.3) leaves a lot to be desired compared to Android.

P.S. Bx looks pretty awesome :)

reaperducer 8 years ago | | |

>And the home screen installation on iOS (even with 11.3) leaves a lot to be desired compared to Android.

Can you elaborate on this? I recently added a web site to the home screen of an iPhone 6 and a Galaxy S7 and they look the same to me. Is there additional functionality in the Android home page icon of which I'm unaware? (Not an Android expert by any stretch of the imagination.)

osrec 8 years ago | | |

You're right, but I see it coming soon. Service workers have just appeared in Safari, so I can expect push notifs to be there soon as well.

Also, thanks! You should check Bx in a month when we roll out the next major release which (we think) makes it even better :)

yesimahuman 8 years ago | |

PWAs are awesome, but we don’t see it as either or. If your app needs access to proprietary native SDKs then you need a native app. Capacitor gives you optionality to do both with the same code.

osrec 8 years ago | | |

I think that's a fair point. I had a more detailed look at your proposed deliverables, and it all looks pretty cool. Wish you all the best with the launch :)

rhacker 8 years ago | | |

Instead of this madness device manufacturers could work together with HTML5 cons... to make a set of APIs that access native things, and for not-so-standardized features they could use prefixes kinda like we did in CSS. The websites accessing these HTML5 APIs would simply check for their existence first, then start using them. Usage of the APIs would then kick of device specific permission prompts, etc... Think about the integrations too, we would no longer have to set up application forwarding URLs like twitter:// to route to our app, everything would work from any device!

Even if manufacturers don't work together, if they at least provided JS API access built into their native browsers - then we can build shims on top of them.

tootie 8 years ago | |

I fully support PWAs, but it's not just a matter of doing what's practical, it's also a matter of user expectations. It's become standard business strategy that you need an app store presence whether or not it's an effective way to deliver functionality. Plenty of users (iPhone users in particular) just expect it.

mamcx 8 years ago | |

Android webviews is a total turtle (even with hacks and crosswalk).

jacquesc 8 years ago |

Glad to see they're moving beyond Cordova's main issue: trying to fully automate the native build processes with disastrous results.

I am perfectly happy opening up Xcode to build and configure. Same with Android Studio. Trying to find a "Cordova solution" to very common build tasks was a continual nightmare for me.

I ended up just switching to React Native to wrap a progressive web app. It makes no sense since I'm only using a single React component (UIWebView), but the build / deploy process was just so much easier to manage than the mess of Cordova scripts and outdated/broken plugins.

yesimahuman 8 years ago | |

You're hitting on something we hear a lot, and that's a use case we are really going after. Even if you use RN today with a webview, there's no core way to expose plugins/modules to that web view (like Cordova does). I think there's a middle ground here where the web layer is first class but it's easier to drop into native code and manage your native project as you wish, while staying as close as possible to the standard tools/APIs that each platform developers typically use. If we can save you 95% of the time on your app, and have simple escape hatches to get full control, that's a win.

the-dude 8 years ago |

I stumbled upon https://blog.ionicframework.com/announcing-capacitor-1-0-0-a... last week, much more info there.

Sujan 8 years ago | |

I had an early look and wrote a bit about it as well: Introduction article that touches on all the relevant bits at https://ionic.zone/capacitor/overview and an Overview of the CLI at https://ionic.zone/capacitor/cli

oldgun 8 years ago |

Love to see this happen, but how's the performance (responsiveness, memory consumptions) compared to native? I believe the main reason people are reluctant to develop web-based apps is performance, which results in poor user experience.

Any benchmarks/testings to show the performance is on par?

yesimahuman 8 years ago | |

We're not building Capacitor in a vacuum, it's targeted at the existing and large community of Ionic developers that are already successfully building these web-based mobile apps today. If you need the highest performance option for your app and don't care about PWAs or Electron compatibility, you should just build a pure native app and get as close to the metal as possible.

zedpm 8 years ago |

I hope this works out, and I hope it fixes some of the grief that Cordova causes. We've ended up with some legacy apps built with Ionic, and have had so many problems that trace directly back to Cordova that we're looking very seriously at complete rewrites.

Integrating with some third-party like Auth0 goes smoothly for our projects until we get to Cordova, at which point we start chasing absurd bugs and explaining to their support that we do actually need Cordova support. We've been told more than once that Cordova is the "problem child" in terms of supported platforms.

yesimahuman 8 years ago | |

Agreed that we need to fix that and also make it easier for people to build/maintain plugins. A hard problem across the cross-platform mobile space that I hope we can help with.

atonse 8 years ago |

Is this a competitor to React Native? RN seems to be the ideal: truly native components but a JS programming model.

yesimahuman 8 years ago | |

We’re focused on pure web applications, and being able to run an app in the App Store and on the web as a PWA and Electron with the same code is a problem our users and customers are asking us to solve. It’s a different approach and I think those that want to stay web-native but still have easy access to native SDKs will find Capacitor interesting.

We’ve had some good feedback from some react native developers that they’d love to build out pages with web content and wrap it with a native shell (nav/menu/etc), while easily exposing native modules/plugins to the webview, so that’s a use case we’re going to support. Being able to use that app as a PWA is a compelling value prop of this project as well.

atonse 8 years ago | | |

Gotcha. Thanks for the clarification.

My concern is that too often, embedded web apps still never feel right. It's that uncanny valley. I'm sure it's better than its ever been, but do you have thoughts on bridging that uncanny valley? (through maybe some CSS animation libraries that mimic the native controls?)

meesterdude 8 years ago | |

> RN seems to be the ideal: truly native components but a JS programming model.

I'm not sure i would call React Native "ideal". I think it's "progress" though.

Can_Not 8 years ago | |

There are actually several. NativeScript supports Angular, vanillajs, and recently VueJS. There is also a bridge to use VueJS inside of reactnative itself. There are many other libraries that claim to be "native" but are actually only "native look and feel" (meaning HTML+CSS+Cordova/Phonegap, not native components).

mamcx 8 years ago |

Please, if possible, make it truly easy to integrate.

All of the others tools requiere multi-steps to integrate into android/ios projects. Even if "generating a already integrate project" is available, the ideal is just import with gradle or carthage/coccoapods and that is all.

headcanon 8 years ago |

I see this is from the ionic people - What are the goals for this vs ionic? Is this supposed to eventually replace it? Will it still be pushing Angular on us, or is it possible to use any JS framework?

yesimahuman 8 years ago | |

This is not a replacement for Ionic! Ionic provides a cross-platform UI layer for mobile web apps. Capacitor is a replacement for Cordova which manages the native SDK interaction and native app project management/tooling side of your app.

Once we integrate it into the Ionic CLI, you won't really have to think about which part is Ionic UI and which part is Capacitor.

mt3ck 8 years ago | | |

With this in mind do you plan on offering a path for migration from existing Cordova apps?

frlnBorg 8 years ago |

Early 2018?

jessaustin 8 years ago | |

Link should probably be updated to something which has some information:

https://capacitor.ionicframework.com/docs/

yesimahuman 8 years ago | |

Technically it's here already (in alpha), just haven't updated the landing page.