It's a nightmare to maintain an ionic app

Ionic Framework
21

Obviously I don’t have a crystal ball, and am not in a position to guarantee you anything, but I would ask you to take a look at what has happened with Angular. The migration from Angular 1 (AngularJS) to Angular 2 basically demanded a complete rewrite of everything. Going from Angular 2 to 3 or 4 wasn’t snapping fingers, but it was nowhere near as disruptive as 1-2 was. By the time they got to 5 or so, there were even some automated upgrade assistance scripts. Ever since then, unless you’re deep in the weeds of the internals so that you got bit by the ViewEngine / Ivy transition, it’s been pretty much a “less than an hour of work” situation.

Throughout this story, Ionic versioning tracked Angular fairly closely, because it was the only framework supported. What you are going through would have been needed if we were having this conversation during the Ionic 2 rollout. It’s been 5 years since then, and there has not been any Ionic release anywhere near as disruptive over that entire time period.

I would therefore feel fairly safe predicting there won’t be another one anytime soon.

22

While I haven’t been in any upgrades of major projects, I did go through the journey which has been described earlier, multiple times.

As @rapropos has mentioned, with the arrival of ionic5 and webcomponent, framework agnosticity was introduced which should help a lot.

What always bothered me the most was the apparent lack of documentation (or my understanding) of the actual node version you ought to be using, to avoid disruption of upgrades, even the documented ones. Has given me some real dependency nightmares.

Thank god for NVM in that case.

23

Acknowledging that there may always be disconnects between what is supposed to work and what does work, I think the most reliable heuristic one can follow looks like this:

  1. Go here.
  2. Look at the left box with “LTS” after its name.
  3. You want that one.
24

2022 here. I am switching to Flutter. I am not writing this out of spite. I loved Ionic 3. The upgrade to 4 and 5 was really painful, so much so I seriously considered switching at that time.

I am a database developer turned app developer and I was able to successfully release an Ionic app but the process was just too painful. Not only does Ionic upgrades breaks things, I also found the whole NPM tool chain to be insufferable. So. Many. Breaking changes. All the time. The plugins are often out of step with production version of Ionic and the developers have long lost interest so it is a Russian roulette of finding out “will this 6 months old plugin” work with the latest Ionic or did some underlying library 3 layers down is imploding the whole thing. I wonder how many plugin authors gave up too because of the version changes.

I’d admit at first I hated Flutter. Dart looked like a hot bowl of spaghetti with UI and logic all mixed up. But as time goes on I really appreciate the Hot Restart (saves me probably 30 minutes-1 hr a day), the quality of the plugins (they are actually rated on pub.dev so you know what you are getting yourself into), I am not smart enough to know 50 million things and the status of each. Developer experience should be part of the design considerations of a framework.

Just my 2c. Thanks Ionic for the good times and bad.

25

Hey there!

Sorry to hear your experience with Ionic was not great. I was hoping to learn more about some of the frustrations you experienced so we can improve the quality of our projects.

A couple clarifying questions:

  1. Which plugins did you have trouble with?

One of the pain points we have heard over the years is regarding Cordova and plugins regarding compatibility (i.e. “will this 6 month old plugin work”). I am not sure if you were using Capacitor, but it aims to be the spiritual success to Cordova. One of the big things we did was move a lot of the plugins in-house so they are maintained by the Ionic Team (See: GitHub - ionic-team/capacitor-plugins: Official plugins for Capacitor ⚡️). The idea here being that all the plugins are guaranteed to be compatible as they are actively maintained by us.

  1. You mentioned “Ionic upgrades breaks things”. Are you referring to Ionic Framework, or something else? Regardless, I would also love to know if there were any breaking changes that were particularly painful.

Ionic Framework v3 → Ionic Framework v4 was a complete rewrite, so I can definitely understand how the v3 → v4 migration may have been frustrating for some. However, you also mentioned that the v5 upgrade was difficult, so I would love to hear more about this.

1 Like
26

Ionic has live reload which is just like hot restart in Flutter. To use it, use your framework of choice’s live reload capability. It’s just as if not faster than Flutter.

Unfortunately, with a large ecosystem of volunteer-driven projects, it’s not possible to guarantee that all dependencies will be maintained. As @ldebeasi mentioned, we’ve made great strides here to help the community improve the quality of the plugins that are maintained by passionate volunteers, but there’s no silver bullet here. Flutter will have the exact same challenge, this is just the nature of open source sustainability. Maintainers lose interest, move to new projects, or just don’t have a need for their project anymore.

Finally, the upgrade story for Ionic Framework post v4 is just very different than it was pre v4. We know the upgrade from earlier versions can be challenging but the project itself has had a much stronger and easier upgrade story for > 4 years by now.

2 Likes
27

Thanks @max @ldebeasi , didn’t quite expect to hear back and thanks for the discussion.

I think I’ve misspoke couple of things so I should clarify. I am aware that Ionic has live reload but I didn’t use it often probably because the changes I made are usually bigger and required rebuild. With Flutter, I often use “hot restart” as “hot reload” often doens’t work for me either. So I guess I was comparing full rebuild in Ionic with flutter “hot restart”, upon significant (non UI) changes. I don’t fully understand the technical details so if I am incorrect please correct me.

Thanks for take time to explaining the design goals of Capacitor, that makes a lot of sense to move some of the plugins in house. Sadly for me, Capacitor came across as “yet another thing” and I didn’t understand the benefits over the pain of upgrading again and at the beginning some of the plugins I needed wasn’t in capacitor.

I don’t remember which plugins I had trouble with, just remembering getting tons of warnings and sometimes errors in NPM, manually upgrade dependencies as a regular occurance, so much so it feels like I was building on a pile of janga sticks after awhile, which is no fault of Ionic itself. I know I am probably doing 50 things wrong in the process but that is just what I went through with what I know.

Also clarification that I went through v2 to v3, then v3 to v4 / v5 at the same time (not v4, then v5 like my original post might have suggested).

@max you are right, part of the flutter’s appeal is everything is new and nothing (AFAIK) is broken, yet. maybe the paint will come off later, but for now I feel more stable. Maybe if I started app development today and came on board straight to Ionic V6 capacitor I’d had the same great experience. Really do appreciate everything you all are doing and Ionic got me started on app development. Thank you.

2 Likes
28

Appreciate the response and we’re happy you found something you like using! We’re actually going to be likely supporting Flutter in a few ways for our mobile devops cloud service Appflow and for our Portals micro-frontend product. Portals currently supports traditional Native and React Native so this change is already in progress.

We certainly still think hybrid/web native is the right choice for many apps but our commercial products operate on native iOS/Android projects and don’t care what they’re built with. We’ll have more on these updates later this year, you’re hearing it here first :grin:

1 Like
29

(post deleted by author)

30

I’m new to Ionic I have to say the same, the documentation is actually really bad. I’m coming from the Django and Python world that clearly explain what classes do themselves, how they interact with the rest of the system, the gains and potential pit falls of them are.

Here in Ionic, I look up the documentation for “IonPage” and get the most convoluted answer I’ve ever read in 25 years of software development.

Ionic Framework

Ionic Framework

Ionic is the app platform for web developers. Build amazing mobile, web, and desktop apps all with one shared code base and open web standards

" The Ionic Page handles registering and displaying specific pages based on URLs. It’s used underneath NavController so it will never have to be interacted with directly. When a new page is pushed with NavController, the URL is updated to match the path to this page.
Unlike traditional web apps, URLs don’t dictate navigation in Ionic apps. Instead, URLs help us link to specific pieces of content as a breadcrumb. The current URL gets updated as we navigate, but we use the NavController push and pop, or NavPush and NavPop to move around. This makes it much easier to handle complicated nested navigation.

We refer to our URL system as a deep link system instead of a router to encourage Ionic developers to think of URLs as a breadcrumb rather than as the source of truth in navigation. This encourages flexible navigation design and happy apps all over the world.
"

Just what? Talk in circles about absolutely nothing. “Things happen, URl’s are not real. This class, maybe you shouldn’t use it”… I don’t even know where to begin, this fragmented utterly ridiculous statement that really explains nothing and half of it should be placed into a different document.

Look how much more clear even the beginning of Django Documentation is:

" A model is the single, definitive source of information about your data. It contains the essential fields and behaviors of the data you’re storing. Generally, each model maps to a single database table.

The basics:

  • Each model is a Python class that subclasses django.db.models.Model.
  • Each attribute of the model represents a database field.
  • With all of this, Django gives you an automatically-generated database-access API; see Making queries."

Some other examples, sometimes is actually inside , usually they are not. So what do those sit in? You would think IonPage, but after reading he documentation, absolutely not.

Overall, the Ionic documentation is quite poor.

31

Thanks for posting and thank you for sharing your feedback on the Ionic Docs. Although I recognize that this may sound a little cheesy, we are working to improve our documentation and we appreciate you sharing the specifics of your pain-points with us, as well as an example of a structure that you find more helpful.

32

Pretty much agree that this page on its looks pretty gibberish and confusing. If you get there first time without prior experience

it is just that understanding navigation and routing starts with the js framework you use - like angular vue or react

Which concepts are beyond ionic to teach you - its a dependency

And after you grasped them you will find yourself not having to care for (or even) look at this part - which btw is regarding v3 which is non longer current as per notice on top

Maybe still there is a component page that gives you the same experience. Would be interesting to know which one!

33

I’m a dev with 20 years experience using various frameworks. The past 6 years of my dev life have mostly been working with Angular. I built several Ionic apps for small clients duing this time, and I’ve recently come back to Ionic to rebuild an Ionic project that I built just 2 years ago that is completely unusable now . Mind you, I’m talking strictly here about ANGULAR Ionic, I don’t have any experience with other flavors within the Ion-iverse.

With all of that said, I completely concur with the author of this post. I came back to Ionic now ( June 2024 ) and I’m actually surprised at not only how bad the documetation is, but how much of a mess the framework is in general. They moved to optional stand-alone components, which I was super excited about at first, but there are so many gotchas when using them and so many noremal “Angulary” things that just simply won’t work with it. You’re going to be constantly looking up how to do basic things and dependency injection becomes super convoluted.

Other frameworks like React / React Native and even just using raw Angular itself with MD will behave in an intuitive way with very very clear documentation. Ionic has gotten worse over the years. After two entire days of fiddling around with Ionic 7 I’ve given up … I’m going to have to pivot to another framework.

The biggest issue with Ionic Angular is that it can’t make up its mind about how much Angular it wants to support. It’s straddling the fence between being its own thing and being an Angular thing. That leads to endless rabbit holes of confusion when using the “stand alone component” version where doing something simple like using *ngFor or using httpClient or using any of the Ionic components becomes a short little errand that requires you to figure out how to get “x” working. Sure, these errands are very quick and some of them are one time learning curves, but if you add up several little 90 second errands, it actually ends up being a lot of time.

When not using the stand-alone component, there are still numerous things that do not work intuitively, and several Angular things that simply don’t work and the “Ionic way” of doing it is not easily found in the documentation or just simply non-existent.

I loved the idea of Ionic but it’s going to have to increase its usability a lot in order to gain the traction that a framework like this should really have. It’s a great concept and I hope they iron out the developer experience issues.

34

That leads to endless rabbit holes of confusion when using the “stand alone component” version where doing something simple like using *ngFor or using httpClient or using any of the Ionic components becomes a short little errand that requires you to figure out how to get “x” working.

What kinds of issues did you run into when using ngFor or HTTPClient?

It’s worth noting that standalone components is an Angular feature that Ionic has adopted, and standalone components in general have a slightly different way of working than the traditional NgModule approach.

I’m actually surprised at not only how bad the documetation is

Do you have any examples of where the docs could be improved?

2 Likes
35

Thanks for your reply ! I will respond a bit later with detail.