When people talk about Ionic Framework, they often put it in the “Cordova” or “Angular” buckets, because historically that’s what Ionic was: a UI kit for Cordova and Angular apps.
That was fine for the first few years of Ionic’s life, but up to around 2018 things started changing. Ionic started working on a new native runtime to replace Cordova that was fully built in house and deeply integrated into the Ionic developer experience: Capacitor. And then a year later, Ionic Framework added support for its first non-Angular framework: React (and later, Vue).
And last week, we rolled out the biggest release of Capacitor yet: Capacitor 3.0, further cementing the future of the Ionic stack as one built on the foundation laid by Capacitor.
That means, in 2021, it’s not accurate to say that Ionic Framework is just a framework for Cordova or Angular anymore, because it’s actually a framework for Capacitor that has official support for Angular, React, Vue, and unofficial support to be used in pretty much any JS stack out there.
In fact, Capacitor installs on npm recently eclipsed Cordova, and the vast, vast majority of new apps created using the Ionic CLI and online app creation wizard use Capacitor. It’s time to fix this misconception once and for all!
Here are some thoughts on how the Ionic community can change this misconception:
Ionic on Surveys
One of the big problems with simply lumping Ionic Framework under the Cordova bucket is that prominent surveys, like the StackOverflow developer survey, use Cordova as a “catch-all” bucket for apps built on technologies like Ionic Framework. And the StackOverflow survey is doing it again this year.
Thus, when the results come out, they never really reflect the unique community and technology stack that modern Ionic/Capacitor developers are building on.
One way we can start to change that is by writing in Ionic (and Capacitor if given multiple write-in options!):
The StackOverflow 2021 Developer Survey in “other frameworks and libraries”
Also, can’t hurt to let the Stack Overflow team know your thoughts on Twitter.
Ionic with Vendors
The other opportunity is with 3rd party vendors and SDK developers.
Many vendors believe they are targeting the Ionic community by building Cordova plugins, but that’s not the case. Today, a proper Ionic native plugin is built for Capacitor and using the modern Plugin API and developer experience that Capacitor provides. While Capacitor does have backwards compatibility with most Cordova plugins, it does so as an on-ramp to make the transition to Capacitor easier, not because the Cordova plugin API is preferred.
The problem with vendors focusing on Cordova plugins is that they tend to fall into the same traps over time. First of all, creating and maintaining Cordova plugins is more difficult than Capacitor, so working on them over time can be straining, and that impacts long term stability and velocity (want to read more details on the changes Capacitor makes over Cordova? Check out our docs on the subject).
The second is using features in Cordova like hooks or auto-configuration that create long-term maintenance nightmares for plugin users and maintainers. Hooks are not supported by Capacitor even for Cordova plugins because they are a footgun. Instead of providing a custom script to set configuration values for users, Capacitor prefers documentation that explains to users where to enter values in their native project. Often this documentation can be just a few lines long, replacing hooks that are hundreds of lines of brittle code.
Finally, Capacitor has full support for the web platform and Progressive Web Apps. Capacitor developers are often building iOS, Android, desktop, and Progressive Web Apps with one code base. Historically, Cordova only had basic support for web environments. Capacitor developers expect to be able to target web with the plugins they use, when possible.
The end result is that Capacitor developers vastly prefer using Capacitor plugins, and Cordova support is available only for backwards compatibility and to ease the transition.
Web Native is the future
While developers can still use Cordova in the Ionic stack, the future is Ionic with Capacitor (or Capacitor on its own with any popular web stack!). These apps are known as Web Native apps, in contrast to the older hybrid approach.
This future is bright. Earlier this year Capacitor was voted the highest satisfaction mobile development project on the State of JS Survey. An 84% satisfaction compared to 30% for Cordova:
It’s high time the Ionic community and Capacitor team get credit for making dramatic improvements to the developer experience around building apps with web technology, and for shaking up the mobile ecosystem.
It no longer makes sense to simply call Ionic a framework for Cordova or Angular, and it makes no sense to leave Capacitor out of the conversation around building Web Native apps with standard web technology.
Let’s get out there and change these misconceptions!