Some experiences so far from my migration:
I tried to move to Capacitor as the Ionic CLI strongly recommend to do that. New script hooks system with slightly changed format, fine, fixed that. But then further in it turns out though that Capacitor requires typescript and you need to make an ugly hack to make it usable from old-school javascript used in ionic-v1. So Capacitor is not compatible with ionic itself…
Then I changed back again to cordova. Cordova has changed a bit too, but no real breaking changes. However again ionic cli has removed all cordova wrapping commands, while I can write “ionic cordova …” it seem to provide no value whatsoever over just running cordova command directly. I thought the idea of the ionic CLI was to wrap clumsy commands and make things easier. It turns out to be the opposite due to that the CLI keeps changing.
So now the plugins need to be installed and managed by cordova directly. Which seems fine by me as cordova’s command line seems to be a lot more stable and not deprecating commands all the time. Some of my plugins had become deprecated, but then replaced by new one with the same API. With one exception – the ionic keyboard which had been replaced with a new plugin with an incompatible API.
Ionic just keeps popping up as one that make source-breaking changes… it seems like the ionic team doesn’t understand the value of keeping a stable course and make designs that can hold up for a long time. I seriously think that they team should reconsider the balance between following the fashion of the day and striving to have an eco-system that makes it somewhat easier to maintain apps which has a life span of more than one year.
I also admire the hard work. I don’t want this to be just a bunch of negative feedback, but I think this feedback is important too if they want Ionic to become even more successful and useful to a broader audience.
For my next project I may look into running just cordova and some generic HTML5 gui toolkit. Not because I dislike Ionic, but because my next project is also expected to have the same property as this one, that is a long life span, while being “complete” at the first release and thus not needing more than minor maintenance over the years. And then using a framework that constantly re-invents itself is not the right tool for the job.
I need stable long-lived APIs and thought put into backwards compatibility.