Ionic React
ionicframework.com
ionicframework.com
If expectations and budget are low, it's a great option.
Cromulent first appeared in the February 18, 1996 episode of The Simpsons called "Lisa the Iconoclast," in what could be considered a throw-away line given during the opening credits. The schoolchildren of Springfield are watching a film about the founding father of Springfield, Jebediah Springfield. The film ends with Jebediah intoning, “A noble spirit embiggens the smallest man.” One teacher at the back of the room leans over to another and says that she’d never heard the word embiggen before she moved to Springfield. “I don't know why,” the other teacher replies. “It's a perfectly cromulent word.”
https://www.merriam-webster.com/words-at-play/what-does-crom...
They make up one word, embiggen, and just from the obvious root word of "big" it's clear what it means. Doubly so when taken in context, "A noble spirit embiggens the smallest man."
Then they make up a second word, cromulent, and the meaning can be entirely inferred from context. Embiggen is a perfectly cromulent word. Acceptable, adequate, maybe a bit unorthodox but "good enough".
There's nothing unusual about this. That's how people learn the meaning of every word. You're born knowing zero words; there's no alternative.
Unfortunately the speed in which they are changing things make community references obsolete quickly.
If you enter responsive design mode in the chrome dev tools and switch to e.g. an ipad config, it will use ios styles.
I really like ionic and capacitor and have built lots of great apps with it. Performance is really ok nowadays (was a problem in the days of ionic 1)
Some apps are web technologically, but are local tools by purpose; that's where blending it could be beneficial for the user.
Having that as a default means that many people will implement it.
This is a feature of Ionic you’re free to disable but many users like very much. It is more widely used for apps running in the App Store that want to map to iOS and Android UI standards for each platform.
We also pride ourselves on making Ionic easily brandable so the platform standards provide a good base you can easily remix to make it look quite different.
Sorry to disagree, but Material Design itself lacks aesthetic restraint and has accessibility problems with the constant flashing and animation, but that's another conversation.
Edit: I'm talking about the browser, not apps (though I don't like MD there either). I mean that websites shouldn't change their design based on the company that makes the web browser.
There's a battle between some of the large tech companies for appification of the Web at the moment, and that way of thinking is a trap.
A company shouldn't design its website with Google or Apple's visual branding as if it were locked into a closed platform. It also appears to be a problem with things like Flutter, though I haven't looked closely.
I assume you have never tried it.
I mostly make Web apps with very complex UIs that target desktop computers specifically. I'm not as concerned with the mobile app story right now, I just want a batteries included UI framework. Is that a valid use-case for Ionic, or should it only be used if cross-platform deployment is needed?
It is pretty straightforward to do both in Ionic.
As a side comment, the other day I wanted to do a very simple single page "app" (I jog, so I wanted a "sonar" kind of app that told me how far to my target speed I am, constantly).
I thought I was going to give native Andriod Studio a try... as this was a very simple app and I was going to use GPS functionality, it sounded right. I was badly surprised by the way UIs are built in Android Studio, it is so fugly, it took me back to the AWT/Swing framework I worked with in the late 90s. After battling with the ConstraitLayouts and other bullshit, I went back to Ionic to do a simple HTML layout and had the app working in 1 hour.
I can't believe in 2019 that is the way Google is making people build interfaces in Android.
How can I get to grok Android's Ui layout process?
https://examples.sencha.com/extjs/7.0.0/examples/kitchensink...
We're currently adding desktop support to our existing Ionic app that has been mobile only so far so we are banking on being able to work around that and Ionic adding better desktop support over time.
[1] https://ionicframework.com/blog/ionic-4-roadmap-new-features...
Datepickers. The ones provided by ionic are strictly for mobile. I think they are planning to do a desktop version but I have waited 4 years for that.
IE 11 support. Forget it. Luckily it is less and less important but if you need I wouldn’t bother.
Desktop style menus and lists. Possible to create but is not included.
Ionic are improving dekstop features but it still mostly aimed at mobile. If possible, try creating one of the most desktop centric parts of your app and see how far you get. If mobile use is not important at all you might not get many benefits from using ionic.
What we would have needed: - Actually usable and maintained plugins. Getting something like push notifications to work is too difficult. And then the plugins won't even build on their build service. It's a lot of hair pulling but should really be low hanging fruit for the ionic team. - Easier submission into the app stores, because onboarding new people on how to do all the manual steps for every legacy app we maintain updates for is a pain in the ass.
I would LOVE to have a build pipeline that builds both iOS and Android and automatically submits them to the app store, ready to go (whether that's TestFlight or an actual prod build)...AppFlow gets you 80% of the way there to much frustration.
I ended up just using Fastlane myself and building my own pipelines that accomplish the exact same thing. Funny too, if you look in the AppFlow build output, they're also using Fastlane. I wish they would have pushed it out _more_ feature complete and include the publish to app stores (I'd be first in line to shell out).
- IAP, even Subscription - Easy OTA update like via Expo with RN - Handling gestures on web: already laid out well? - different default browsers via different vendors on phone (especially chinese Xiaomis and Huaweis) broking the cross-platform web. Does Capacitor solve that?
- Cordova plugins can be a pain - we have had to do a lot of research in Github issues/source code and in one case built our own plugin. We also have a few custom build scripts. Other than that things have worked pretty well for us.
- Automatic submission to app stores will be great since we have to spend a good bit of time doing that manually and we currently rely on TestFlight/Play beta testing rather than Ionic Deploy.
P.S. Can the creator.ionic.io get more love? 0:)
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
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/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.
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 :)
> 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). 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>
> 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.
"Libraries" are shared between the Angular app (1 app) and a half dozen or so Ionic apps. Basically the API calls, pipes, directives and other stuff like that.
It works well, even though submodules are a pain.
We'll be upgrading to Ionic 4 at some point, probably keeping the architecture the same. I don't think we'll be moving to React.
Edit: If by "hybrid app" you meant "progressive web app", then yeah, Apple has made it somewhat inconvenient to pin websites to your home screen as apps. But they'd never really be able to block them altogether without blocking the web itself, because there's no hard distinction between the two.
React native has far less support of web standards/ features than Ionic, especially modern CSS support. Thus ionic give you more power to build feature rich, UX rich apps.
Secondly react native has very poor debugging experience, meanwhile ionic support devtools (I couldn't get it to work on RN).
Thirdly, contrary to popular belief, I expect ionic to have generally better performance than react native. Chromium evolve quickly and has an army of engineers that bring state of the art optimizations to the web. For example in a few releases, chromium will render elements using Vulkan by default.
Lastly, ionic is more native than react could ever be as it supports all 3000+ cordova plugins and seamless Java interop.
The ability to reuse the codebase for the web and for electron are also huge advantages.
Things will only get better once capacitor stabilize.
Still, I really wish that Ionic now focus on Vue.js/ts support.
It seems interesting, still I believe ionic has a far bigger community which is a big time saver.
It is interesting to think about the possible performance gains to be had running JS in the browser rather than in a detached JS engine. For example, WKWebView on iOS has access to the full JIT-ed JS engine on iOS, while JavaScriptCore does not (as I understand it).
It would be nice if you ran public benchmarcks of two equivalent app one in Ionic, one in RN (and eventually more (flutter, etc)) If you are empirically the fastest (maybe we will need to wait a few chromium milestones or to manually enable Vulkan) You could market those numbers by showing you are the first to have Vulkan rendering, HTTP3, CSS contains, dom fragments, etc (I believe Microsoft is working on moving chromium input handling out of the main thread)
And if you showed things you can't do/easily do in react native. For example backdrop-filter has recently been added to chromium and is the future of UX. https://ferdychristant.com/please-help-make-backdrop-filter-... But really there's so many features that you offer and others don't! OpenXR, SVG support, css width auto, css grid, etc If you want an exhaustive list: https://www.chromestatus.com/features
Really if react native was on https://caniuse.com/ people would see the truth (the feature gap).
Your marketing also could just make visualizations about the gap in size between the ionic ecosystem (more plugins than RN + all npm packages) vs RN npm packages, that would show the order of magnitude of order of magnitude difference and so how many billions of dollars of man/hours developpers miss by choosing RN.
Unrelated: I hope that you are aware of the cordova maintenance issue https://github.com/apache/cordova/issues/163#issuecomment-54... And capacitor won't be a true successor until it will have full compatibility with prior cordova plugins.
I have an app running in production now for almost a year and am so so glad I've chosen Ionic 4 and Capacitor. Kudos to the team.
Can't make the judgement call on whether it's worth you moving to Ionic vs React Native, but Ionic would be a fit if you prefer a "web-native" approach, using the traditional react dev experience around react-dom, and want to target Electron and the web as a Progressive Web App with the same code.
Next one will likely use Flutter.
The "Hello world" story on Ionic is pretty good--you generate a project and it works. But configuring and maintaining the various layers (Ionic, Cordova, Android Studio and XCode projects for actual building the apps) has been pretty brutal for apps I only touch every few months. So many dependencies that prove very difficult to update correctly.
The story looks to be improving with Capacitor though, so I suppose I'll give it another look when that stabilizes.
Capacitor does look really nice--it was in early beta (maybe even alpha) last time I started a new app project, haven't looked since. Will definitely give it a fair shake when the opportunity arises.
EDIT:
Adding a bit context to my earlier comment: one of the bigger points of frustration in managing dependencies was figuring out which versions of ionic, ionic-native, ionic/angular, angular, and angular's 6 dozen peer deps actually work together.
Definitely doesn't help that I don't use Angular or Ionic on a regular basis, but documenting the expected versions of other components would be a huge help for me.
That said, I am seriously considering using Flutter for a future development project, but am on the fence due to the value and familiarity I see in the web platform.
At the moment though, React-Native has 7x downloads comparing to Ionic: https://www.npmtrends.com/ionic-vs-quasar-framework-vs-react...
We probably won't get the chance to use Ionic React soon but really hoping this gets more people excited about Ionic. Being able to deploy to iOS, Android, and web with a single codebase is incredible for starting with a MVP and transforming it into a great product.
They have enterprise support version but my gut feeling is that they make more money on the tooling.
If you're curious I did a 2019 business update with more details: https://ionicframework.com/blog/ionic-2019-business-update/
At a high level we are generating real revenue, growing > 100% y/y (and our enterprise business is ~1.5 yrs old), and nearing profitability.
Here is an example. In Cordova, when using plugins, a developer would have to use various hooks to produce an artifact with a specific customization. But in Capacitor, they can just make changes in the source code itself. As a result, the build is more predictable. On the other hand, such feature might make it more painful to upgrade stuff if the artifact gets littered with tons of customization. While such problem might be rare due to the infancy of Capacitor, maybe in the future it might come back to bite many projects.
Edit: I initially read this to be yet another layer on top of React Native, but it appears to be an alternative to it. So less glue than I thought.
best example of ionic @PWA ? What about iOS ?
Camera, gps, webauthn, you know the cool new api's
I wish to compare :)
Native is dead, on both phone and desktop.