Capacitor vs. Cordova: What's the Big Deal?
What's up Ionic geeks? Welcome back to a new vlog episode. And this week we are going to focus on a very, very important question, but is this actually a question or more like a hint? Over the last time I got a lot of comments on my videos that were using Cordova that I should use Capacitor, and I also reviewed a lot of the old comments on the video that I did on this topic. Today we will answer a lot of questions that you might have about Capacitor, about migrating to Cordova, about the future of Capacitor. So stay tuned for a lot of great content.
Why Ionic Recommends Capacitor & Debunking Myths
If you're on Ionic and start a new application and see this log on the CLI, it's definitely recommended right now, or as of now, to use Capacitor in your applications. But what does this mean about Cordova in general?
If you have an old application that is using a lot of Cordova plugins, there's not really the need to upgrade this to Capacitor. Of course, you can do it, you can migrate it, we will talk about this in a second as well. But overall, it's not like you will get a lot of performance benefits from upgrading to Capacitor. Still, Capacitor of course comes with a lot of benefits that we will also talk about. It's not like you are updating your app from AngularJS to Angular 9. It's not going to have this kind of impact on your application.
Also, over the last time I got questions like Apple is rejecting my web view apps or Apple is killing all hybrid applications, and this is not related to Cordova or Capacitor at all, and also not really related to Ionic. It is simply not true. They are not killing web apps or applications that look like this. They are limiting applications to the new WKWebView instead of the old deprecated UIWebView, but you can achieve this with both the latest version of Cordova and also the current version of Capacitor.
Also, our application is not loaded from a server. It is completely bundled into the application, even if you use something like Appflow or CodePush updates, the main part of your application is still a native application and lives in this container. You're not serving something from a completely different URL, which would be really insecure, and it's a surprise that Apple is rejecting this behavior. But with Ionic, with Capacitor and Cordova, none of this applies.
Is Cordova Dead?
So because Ionic is recommending Capacitor, they are completely betting on this topic. Does this mean Cordova is dead? I would say definitely not. If you take a look at the Cordova project on GitHub, there are thousands of plugins, new Cordova plugins come up, and it's not like Ionic is the only framework or company that is using Cordova. You can also create a completely bare Cordova application. You can just wrap whatever webpage you've created with Cordova inside a native application, and I think other frameworks still enjoy this approach. So from what I know, I wouldn't say Cordova is dead. You can definitely still use it. Ionic is definitely supporting it still over the next years and therefore it's still a valid option.
How to Migrate from Cordova to Capacitor
But let's move away from Cordova and focus on a bit more of Capacitor. Of course, the first natural question that comes up is if I have built my app with Cordova, can or how do I switch to Capacitor? Of course, this depends on the size of your application. For a small app, I'm pretty sure it will be like perhaps an hour because how Capacitor worked is kind of easy with setting up the native project, and you can still integrate all of your old Cordova plugins or use the core API of Capacitor. There is a migration guide inside the Capacitor documentation, and that guide isn't actually too long. It's basically about replacing your config.xml with basically doing the things that Cordova is doing automatically, manually inside your native application projects for iOS and Android.
Using Cordova Plugins Within Capacitor
So how can I then use Cordova with Capacitor? Well, Capacitor's backward compatibility for Cordova plugins is really great. To install it, you just install the NPM package of the Cordova plugin, and it handles the rest. Capacitor works with the native project as like source asset that you also check into your Git repository. The project that you get for example for iOS is the main project and Pod project based on CocoaPods to install the additional libraries. For Android this works kind of the same and you can find a whole great article on this topic by Max Lynch, I'll also link to it below the video if you are interested in all of the internals.
Some of you jump to the conclusion that if I can use Cordova plugins within Capacitor and Capacitor targets Progressive Web Apps as well, and Electron, that I can use Cordova plugins inside a progressive web app. That conclusion is apparently wrong. The Cordova plugins inside Capacitor still require a bit of the Cordova environment in the application, and within the native application Capacitor handles this. I don't know exactly what the magic of that environment looks like. I know they ported a bit of the code from Cordova into their project so it works, but on the web, which is a progressive web app, there's no Cordova environment, and so the Cordova plugins that you added through Capacitor are not available on the web and you can't use them inside your progressive web app.
Plugin Compatibility and Manual Configuration
Another question, can I use every Cordova plugin with Capacitor? The answer to that question is no, but because you can use like 95% of the Cordova plugins on this way with Capacitor, it simply works. But I also got a comment that a lot of the specific elements of Cordova don't work with Capacitor, and that's especially the case if the plugin requires some certain hooks to execute, variables for the initialization, or any specific elements of the Cordova environment that are not available within Capacitor.
There's a list, actually a very tiny list of plugins known not to work with Capacitor that you can check out on the Capacitor page. The other plugins that, for example, require a variable to be passed to the native project can be used as well because you have full control of the native project. You once generate the iOS and Android project with Capacitor, and afterwards Capacitor is not touching, regenerating, or doing any kind of thing like Cordova is doing to your native project. That means you can still install a plugin and then just set the settings in the Android manifest or in the iOS P-list to have these native variables available in these projects. And you don't need to rely on the Cordova tooling or the config.xml to inject these values into the native project. It's really easy in the native project itself.
Why You Check In Your Native Project Folders
Which also brings us to the question, why do I actually check in my iOS & Android folder? I've never done this with Cordova. Yes, with Cordova, any of your colleagues could check out the project without the platforms folder and they would just add the platform based on the information in your package.json and config.xml. These elements are not used with Capacitor anymore. So as I said, Capacitor only creates these native projects once and afterwards only syncs your web asset into the native project or updates the native project if you make any changes to plugins.
That means you can configure your native project, you can add files, images, whatever it might be to the native project. They are checked into source control and whoever checks out your project will also check out the native project and get all the custom settings that you made in their project. This is like the core philosophy of Capacitor: to have really just a small tooling included, because this is really problematic if the Xcode updates in iOS or Android SDK updates. And it's also the problem that a lot of you have with Cordova in the past when things suddenly stopped working. So with Capacitor, there are no magical updates of your project. You just configure it, you can update it yourself if you want to and it's actually a lot easier.
Live Reloading on Your Devices
Another quick question there, so can I actually run my app on the device or do I have to run the ionic build and npx sync all the time? Well, apparently there is a live reload command which looks like this and I use it all the time to actually have live reload available on my iOS device, on my Android device, and on the browser. Because this will bring up the server with your local IP of your computer, it will be used as the URL for testing when you install the application, and it also means since it's basically the same IP that I can deploy the application to all of my devices and all of them have live reload. It is amazing, amazing, really nice.
Are Capacitor Apps "More Native" Than Cordova Apps?
Are Capacitor apps more native than Cordova apps? I think this question is interesting, but maybe we should answer this in another video because lately there was once again a conversation about how native Ionic applications are in general. I've already said this, it depends on the point of view. From a point of a customer, they are completely native because they live on your phone, they are inside the App Store. That's an application. From a technical point of view, you can discuss about hybrid and all these concepts, but in general, Capacitor packs your application in a webview, and Cordova, also our hybrid application in a webview, which is not really a huge difference. Capacitor might work a bit different but let's talk about this. If you're interested in the conversation about hybrid versus native, please let me know a comment and we will talk about this again.
Building Your App from the Command Line
I'm not going to use Capacitor unless I can build from the command line. Well, this is a valid argument and I definitely see it, but you can actually do this. So since the Capacitor philosophy, as I said, is to have really just a small bundle of tools available, this is currently not included in the general tools. What you can do is you can definitely prepare your Android or iOS application with a sync, and then you don't have to open Android Studio. You can simply navigate into the Android folder and use the Gradle scripts to create a bundle, release bundle, debug file, deploy to your device, anything like this, just using the native tooling of the specific application platform. Which means just use the best tools available for Android, which might be Gradle, or for iOS, which I think are kind of limited with the Xcode command on the command line. But there's also Fastlane that you can use with actually both iOS and Android. So there are definitely options available to build your Capacitor application, Ionic application in general, from the command line.
Will Capacitor Eventually Replace Cordova?
Will Capacitor replace Cordova? I honestly have no answer to this because this is looking into the future. A lot of applications right now are still powered by Cordova. They have a lot of Cordova plugins, they're likely not migrating to anything else right now. So Cordova will definitely live like on for the next, I don't know, five or 10 years. But I definitely think that if people are starting new applications, they will now use Capacitor. So if you would draw something, it will look like the apps started with Cordova will kind of decline while Capacitor goes up. And at some point, there will just be a few Cordova applications and many more Capacitor apps, I guess.
The Future: Capacitor's 2020 Roadmap
And finally, what's the roadmap for Capacitor for 2020? We just already saw the release of the 2.0 version, which came with additional support for the latest Swift and Xcode versions, and also AndroidX was included. But of course, the journey for Capacitor continues, and here's what I read between the lines and in the various articles that I actually went through before creating this video.
The first thing that you will likely see very soon is an implementation of a native HTTP provider within Capacitor. This will help people to resolve the CORS issues because the origin of Capacitor applications is like 'capacitor://' and they will run into a lot of troubles with JavaScript. This is currently in merge mode and I think it will be likely in one of the next releases. So a very cool thing if you encounter CORS issues in the past and couldn't resolve these on the server side.
If you were hoping for some great desktop support, that's actually on hold a bit. As far as I've seen, they're reducing the Electron support to beta once again because they want to focus for now on iOS and Progressive Web Apps. I think it makes sense because these are the platforms that are most popular. And once they're finished or feel confident about the state of these platforms, they will once again go back to supporting Electron in a better way. I have no date about this, perhaps if somebody of the Ionic team is watching, let us know. But what I read as well is that since Capacitor is now in 2.0, a lot of people are now using Capacitor. They made it like the standard for new Ionic applications. They invest more resources in the development and maintenance of Capacitor, which means we will see things that we don't know of yet. Perhaps more core APIs, more community plugins perhaps even supported by Ionic, anything like this. But it's always a good sign if the Ionic company is putting more resources in this topic.
And one feature that I kind of was looking for and was like a future dream and mentioned in one of Max's articles was having a layer that makes it really easy within JavaScript to access native SDKs. This exists for example in NativeScript where you can basically target every native SDK right in your application, even if the SDK just came out a day ago. This is not something super easy, it comes with a lot of security concerns as well. Should your app really be allowed to automatically access all the native SDKs from JavaScript with this layer? It's kind of a complex topic, but I think this would be a cool addition to Capacitor as well. But as of now, it is already pretty easy to generate a new plugin. I've done this in the last video, which I actually couldn't remember when I just watched it. But that's basically it.
Final Recommendation & Conclusion
I hope this answered a lot of questions that you have about Capacitor. If you're starting a new application, I would definitely recommend to go with Capacitor. For my future courses, products, tutorials, whatever it might be, I will definitely use Capacitor since I can always fall back to the Cordova plugins in Capacitor. And otherwise, I think the tooling of Capacitor and the general philosophy make it a lot better in terms of using it in one to three years. I think it will be a lot easier to update your Capacitor applications in the future than it might be to still work with Cordova that was initially created over 10 years ago, I think or something like this. And Capacitor's general core technology stack is just better in my eyes.
Let me know your opinion about Capacitor. Let me know if you got any other questions. I hope I was able to answer most of them. And of course, if you want to see Capacitor tutorials, make sure that you stay subscribed to the channel and hit the bell icon so you never miss out on any new video. That's it for the week. I hope you will have a great week of using Capacitor. Perhaps give it a try if you haven't used it. I'm sure you will enjoy it. If you've got any questions, always feel free to ask and I will catch you next week. Stay safe, and like always, happy coding.
