4 ms·

Capacitor creator and co-founder of Ionic here (company that owns and works on Capacitor). If you aren't familiar with Capacitor, it's a way for web devs to bu

• sroussey 5y ago
  Capacitor puts all APIs in the same context and thread as the UI. Something that Electron did a long long time ago before realizing the security implications.
  • difosfor 5y ago
    What do you mean exactly? Could you give an example?
    • dwaite 5y ago
      XSS gain access to native API
  • yesimahuman 5y ago
    You are correct that Capacitor plugin API entry points are in the same thread as your web/UI code (which will run in a separate process from your native plugin code given WKWebView sandboxes your app in a separate process. They communicate through message passing only). I don’t think it’s directly comparable to Electron for a few reasons. What Capacitor is doing is more like adding new Web APIs to the browser. You have full control over which of those APIs are exposed and they are all backed by the native sandboxing and permission model available on each platform. Additionally you are almost always only loading trusted local content. Electron exposing node runtime to untrusted remote content running in unsandboxed win32 apps, for example, is a pretty different beast. We do take security seriously though and would be happy to review or consider how we can enable users to lock down their apps even more.
    • sroussey 5y ago
      Electron apps, like Capacitor app, are trusted content. This is a red herring. However, both can have a bug that exposes XSS and give direct access to all the nice APIs both add. For example, adding a SQLite plugin gives the attacker full access to all local db data for the app. Or node APIs vs FileSystem APIs. The solution to have have two threads and let the dev specify their own API to communicate. Electron had bad solutions for a while but it’s gotten better these days and might offer some ideas I’m a fan of your work improving the stalled Apache product and moving it forward as Capacitor. I use it! v2 though, as I haven’t upgraded to v3. Maybe I’ll try that this weekend.
      • yesimahuman 5y ago
        Appreciate the feedback and insights! Definitely more we can do there and will see about incorporating more of their techniques
• la_fayette 5y ago
  I am very happy using ionic, stencil and capacitor! You are really doing a great job, thank you!
• benoits 5y ago
  Some of those things in the pipeline like wkwebview-friendly HTTP sound great, would we be able to more easily see requests in the browser Dev tools for instance (a la native browser fetch)? Also can we expect any perf improvements over Cordova (I assume rendering perf would be identical)?
• adflux 5y ago
  Whats the usecase of capacitor vs using a tool like pwabuilder.com to deploy pwas to the app stores?
  • yesimahuman 5y ago
    Capacitor let’s you add any native functionality that you need to create your full native app experience. Also keep in mind you can’t just wrap a PWA and expect it to be accepted into the App Store without adding some additional native functionality which Capacitor provides
• _fat_santa 5y ago
  Hey! React Native developer here. What advantages do you think Capacitor has over React Native?
  • yesimahuman 5y ago
    One of the biggest ones is you can use any web technology, and even plain React. Most React development actually happens with react-dom today so you can bring those apps and that code to mobile through Capacitor. Ultimately Capacitor is the most true to web development of the alternatives out there, so if that matters to you it’ll be better on that front. It’s also a lot simpler than RN and feedback has been there’s a lot less upgrade hell with Capacitor
• archibaldJ 5y ago
  How does this compare to React Native from a build-tool persepctive? From experience Native, Cordova, Xamarin, etc, all took a while for their build-tools to mature (mostly by making the right trade-offs) so to allow a degree of freedom without running into some build hells (though sometimes still do). It's for this reason that I normally just go plain objc/swift/java
  • yesimahuman 5y ago
    The answer is nuanced because a good chunk of your app is just your web app, so you use standard build/dev tools there. For the native side, Capacitor probably has the least amount of abstraction over native compared to Xamarin or RN, it’s quite a bit simpler than both of those. We have some CLI commands to run your app locally but otherwise you just use Xcode or Android Studio directly, no need for a lot of custom brittle tooling
    • archibaldJ 5y ago
      I see! Thanks for the info. One of my concerns is more about extendability & language-bridging; eg my app needs to access a bluetooth module or uses opencv: would it be easy to plug in an existing Swift/Java libraries that has deps on these low-level stuff (without mingling too much with the build process like enabling or turning off some flags, hijacking some of Capacitor's own build processes, etc)
      • yesimahuman 5y ago
        Absolutely. If it’s not in a Capacitor plugin and it’s custom native code or config, you manage those things as you would any other native iOS or Android project. On iOS just add it to your Podfile or add the library in Xcode. In Android add it as a dependency. We have some automated configuration tooling coming if you really don’t want to touch the IDEs at all: https://github.com/ionic-team/capacitor-configure/ https://github.com/ionic-team/capacitor-configure/
        • archibaldJ 5y ago