3 ms·

I haven't used Ionic React, so I can't comment on that, but I've been working on a medium sized Ionic Angular app and I have mixed feelings about it (to the poi

by vially 7y ago

I haven't used Ionic React, so I can't comment on that, but I've been working on a medium sized Ionic Angular app and I have mixed feelings about it (to the point where if I were to start a new project today I wouldn't use it). Some random issues that come to mind: 1. Stacked (push/pop navigation) This was really bad in Ionic 3 where you didn't actually have a proper router, so this was the only way you could navigate in an app, but it's still an issue in Ionic 4. Basically you can have multiple (stacked) pages in the DOM at the same time which negatively impacts performance (e.g.: more DOM nodes, more computation during change detection cycles, etc). Also, extra cognitive load because you now have to decide for each link whether you want it to push a new page onto the stack, pop it from the stack or replace the root page. 2. Performance problems and/or memory leaks Simply navigating in an Ionic app is enough to create memory leaks: https://github.com/ionic-team/ionic/issues/19242 https://github.com/ionic-team/ionic/issues/19242 3. Trying to use canvas (or size sensitive components) inside an Ionic app - https://github.com/ionic-team/ionic/issues/17920 https://github.com/ionic-team/ionic/issues/17920 - https://github.com/ionic-team/ionic/issues/17940 https://github.com/ionic-team/ionic/issues/17940 4. Slower developement edit/build/reload cycle I don't have the exact numbers right now but last time I checked, just importing the `IonicModule` into an Angular app module (without using any actual Ionic components) resulted in an order of magnitude slower edit/build/reload cycle (I think plain Angular was something like 100-200 ms; after importing `IonicModule` that jumped to 1-2 seconds; not that bad but significant enough that you could actually feel it). Given the overwhelmingly positive community feedback I hear about Ionic in general, I think there's a good chance I may be doing something wrong, in which case I'd love if someone could point it out. That being said, huge thanks to the Ionic team for giving us Capacitor. My experience from migrating the same app from Cordova to Capacitor was really positive. I feel like it brings a breath of fresh air to hybrid app development.

WA 7y ago
Hey, I'm just an Ionic user, but maybe a few comments: 1. Not sure about that, but the default is that it pushes to the stack. Isn't this what anyone would expect? 2. Are you sure that Chrome records the number of currently existing nodes or the number of nodes created? I just gave this a try. I have a very simple script that: empties a container div, creates another div, appends it to the container. All of this executed when a button is pressed. The number of DOM nodes should actually stay the same. But Chrome reports an increasing number of nodes. So I'm not sure what the profiler actually does here. 3. I use Canvas inside an Ionic app. If you render your Canvas at the right point of your component lifecycle, it works just fine. 4. Haven't observed this. What I'm doing now: Instead of using Ionic 4 (I have an app made with Ionic 3), I switched to Stencil with @ionic/core. This gives me very fine-grained control over everything. I like it a lot more than the Angular version of Ionic. Maybe you wanna give this a try as well. Less moving parts :)
- vially 7y ago
  Thanks a lot for taking the time to provide some feedback. > 1. Not sure about that, but the default is that it pushes to the stack. Isn't this what anyone would expect? If you assume the stacked navigation model is the right model, then yes, I guess pushing pages to the stack is a good default behavior. However, I'm not completely sold on the stacked navigation concept in general. Let's take GitHub as an example and try to think how the default Ionic behavior of pushing pages on the stack would apply there. 1. You navigate to the homepage. Stack: [homepage] 2. You click on a link to open a repository. Stack: [homepage, repository] 3. You click on the issues tab of that repository. Stack: [homepage, repository, issues] 4. You open a particular issue. Stack: [homepage, repository, issues, issue#1] Obviously this is not very scalable as you now already have 4 full-blown pages in your stack that are eating away resources (DOM nodes, more change detection computation, etc). So in order to fix it, you now need to decide which pages should be pushed on the stack and which ones are replacing old ones. And then, as your app grows, you also start hitting some edge cases in the Ionic stacked navigation implementation (e.g.: https://github.com/ionic-team/ionic/issues/18197 https://github.com/ionic-team/ionic/issues/18197). And at that point you start questioning whether this whole stacked navigation is actually worth it. > 2. Are you sure that Chrome records the number of currently existing nodes or the number of nodes created? I've been using the Chrome DOM Nodes counter in the past and in my experience it's been 100% reliable (at least for the use-case that I mentioned in that issue). What I did notice is that the baseline count fluctuates (e.g.: refreshing the same HTML page sometimes gives you a different _baseline_ counter after each refresh; not sure what that's about). But the difference between the initial baseline count and the resulting count always reflects the DOM manipulations performed, so I think it's a good tool for identifying these kind of leaks. However, you might want to spam the "Collect garbage" button (found in the Performance tab) after performing these kind of tests as there's a chance the DOM node was correctly destroyed but it just wasn't collected by the garbage collector (and that's why it's still reported in the DOM Nodes count). > 3. I use Canvas inside an Ionic app. If you render your Canvas at the right point of your component lifecycle, it works just fine. Completely agree. Once you find the right hook everything seems to work as expected. However, I feel like Ionic doesn't provide enough hooks for this, and the introduction of Stencil in Ionic 4 only made things worse (actually this started affecting us only after migrating to Ionic 4). To give you an example, let's say you have this DOM structure: <ion-content> <ion-grid> <ion-row> <ion-col> <ion-card> <my-canvas-component /> </ion-card> </ion-col> </ion-row> </ion-grid> </ion-content> In one particular instance we noticed that the <my-canvas-component> had to wait for the `<ion-col>` component to be ready (using the barely documented componentOnReady stencil method) before its size was "stable". Which makes it almost impossible to create a reusable `<my-canvas-component>` that works everywhere, because it can't know in advance in which DOM tree it's going to be placed. > 4. Haven't observed this. The easiest way to test this is to start a plain Angular project and an Ionic project and do a edit/build/reload cycle. Obviously, it depends on hardware and you need to try match the dependencies as closely as possible, but what I noticed is that the plain Angular project is noticeably faster. > Instead of using Ionic 4 (I have an app made with Ionic 3), I switched to Stencil with @ionic/core. This gives me very fine-grained control over everything. That's interesting, thanks. We may give that a try.

by vially 7y ago

WA 7y ago

Hey, I'm just an Ionic user, but maybe a few comments: 1. Not sure about that, but the default is that it pushes to the stack. Isn't this what anyone would expect? 2. Are you sure that Chrome records the number of currently existing nodes or the number of nodes created? I just gave this a try. I have a very simple script that: empties a container div, creates another div, appends it to the container. All of this executed when a button is pressed. The number of DOM nodes should actually stay the same. But Chrome reports an increasing number of nodes. So I'm not sure what the profiler actually does here. 3. I use Canvas inside an Ionic app. If you render your Canvas at the right point of your component lifecycle, it works just fine. 4. Haven't observed this. What I'm doing now: Instead of using Ionic 4 (I have an app made with Ionic 3), I switched to Stencil with @ionic/core. This gives me very fine-grained control over everything. I like it a lot more than the Angular version of Ionic. Maybe you wanna give this a try as well. Less moving parts :)

vially 7y ago
Thanks a lot for taking the time to provide some feedback. > 1. Not sure about that, but the default is that it pushes to the stack. Isn't this what anyone would expect? If you assume the stacked navigation model is the right model, then yes, I guess pushing pages to the stack is a good default behavior. However, I'm not completely sold on the stacked navigation concept in general. Let's take GitHub as an example and try to think how the default Ionic behavior of pushing pages on the stack would apply there. 1. You navigate to the homepage. Stack: [homepage] 2. You click on a link to open a repository. Stack: [homepage, repository] 3. You click on the issues tab of that repository. Stack: [homepage, repository, issues] 4. You open a particular issue. Stack: [homepage, repository, issues, issue#1] Obviously this is not very scalable as you now already have 4 full-blown pages in your stack that are eating away resources (DOM nodes, more change detection computation, etc). So in order to fix it, you now need to decide which pages should be pushed on the stack and which ones are replacing old ones. And then, as your app grows, you also start hitting some edge cases in the Ionic stacked navigation implementation (e.g.: https://github.com/ionic-team/ionic/issues/18197 https://github.com/ionic-team/ionic/issues/18197). And at that point you start questioning whether this whole stacked navigation is actually worth it. > 2. Are you sure that Chrome records the number of currently existing nodes or the number of nodes created? I've been using the Chrome DOM Nodes counter in the past and in my experience it's been 100% reliable (at least for the use-case that I mentioned in that issue). What I did notice is that the baseline count fluctuates (e.g.: refreshing the same HTML page sometimes gives you a different _baseline_ counter after each refresh; not sure what that's about). But the difference between the initial baseline count and the resulting count always reflects the DOM manipulations performed, so I think it's a good tool for identifying these kind of leaks. However, you might want to spam the "Collect garbage" button (found in the Performance tab) after performing these kind of tests as there's a chance the DOM node was correctly destroyed but it just wasn't collected by the garbage collector (and that's why it's still reported in the DOM Nodes count). > 3. I use Canvas inside an Ionic app. If you render your Canvas at the right point of your component lifecycle, it works just fine. Completely agree. Once you find the right hook everything seems to work as expected. However, I feel like Ionic doesn't provide enough hooks for this, and the introduction of Stencil in Ionic 4 only made things worse (actually this started affecting us only after migrating to Ionic 4). To give you an example, let's say you have this DOM structure: <ion-content> <ion-grid> <ion-row> <ion-col> <ion-card> <my-canvas-component /> </ion-card> </ion-col> </ion-row> </ion-grid> </ion-content> In one particular instance we noticed that the <my-canvas-component> had to wait for the `<ion-col>` component to be ready (using the barely documented componentOnReady stencil method) before its size was "stable". Which makes it almost impossible to create a reusable `<my-canvas-component>` that works everywhere, because it can't know in advance in which DOM tree it's going to be placed. > 4. Haven't observed this. The easiest way to test this is to start a plain Angular project and an Ionic project and do a edit/build/reload cycle. Obviously, it depends on hardware and you need to try match the dependencies as closely as possible, but what I noticed is that the plain Angular project is noticeably faster. > Instead of using Ionic 4 (I have an app made with Ionic 3), I switched to Stencil with @ionic/core. This gives me very fine-grained control over everything. That's interesting, thanks. We may give that a try.