I did an Ionic/Angular project a few years back and it's a perfectly cromulent technology if stay within it's wheelhouse. If the app you're building could easily be a website, but the client wants an app store presence, this is by far the easiest way to get there. For delivering content-heavy screens that aren't a drag on CPU, it works fine. And it's also fine for layering in basic device functionality like location services.
If expectations and budget are low, it's a great option.
Thanks for teaching me a new word in “cromulent.” While we think Ionic is for more than just low-expectation apps (many brands and consumer apps use Ionic) we appreciate that it fills a need beyond that. Cheers!
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.”
It's one of my favorite Simpsons quotes. Wonderful little bit of linguistic hackery.
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".
And it's a pretty useful word. It's somewhere between "acceptable" and "plausible". It can kind of just mean whatever you need with a slight air of "I don't really know what I'm talking about, but don't worry it'll be fine."
I'm glad I can share the opposite experience. We developed a B2B app which featured a maps module and some fancy visualizations. It was well received and a pleasure to work on. No porting issues and the Android performance was fine with the webview plugin.
Kudos! This is a great project. I have one bone to pick, though. Had a show stopper issue a few months back with capacitor and the entire Ionic team was unresponsive, even on github. The issue was sending cookies to the server. Cookie would get set on the response but subsequent requests would not include the cookie. This was extremely aggravating and I had to halt my development. Relevant Github issue: https://github.com/ionic-team/capacitor/issues/1373. Would be great to know if a solution was ever found.
I used Ionic for 2 projects a few years back. Support on GitHub was, frankly, crap. I can sympathise to some degree, because they were still trying to figure out a commercialisation model, but they were far more interested in shipping new stuff and breaking things than actually stabilising what they already had. Major bugs affecting lots of people were ignored forever or closed without comment. It made for a horrible dev experience, and I honestly can't see myself touching it again with an extra-long barge pole.
Sorry about that, we definitely had some growing pains given we were a team of < 5 on the OSS side with a user base in the millions. Tried to automate as much as possible on the github side and over-applied our issue robot. I think our process has improved quite a bit recently and hope you give us another shot!
My main problem with Ionic (having used it for several apps) is that it is very difficult to find answers to question on the web. Reference sites are full of "this is how I fixed it" that work on v1 or v2 or v3 and most of all don't work for v4.
Unfortunately the speed in which they are changing things make community references obsolete quickly.
We hear you. This is why we moved to embracing core framework tooling like in Ionic 4 with Angular, where you don't need to go through our custom Angular build tooling which was a big source of issues and made it hard to get help.
Interesting, although true none for the current version, in my case a working solution has nearly always been in the top few results, even if it's originally from an older version
It would be nice if it were possible to not have it load Material Design by default. It's a bad idea in general for people to build their products with Google's visual branding. It basically paves the way for Google to become the entire platform.
That's much worse than I thought. The Web is not a Google or Apple product, and your product's design shouldn't change based on which browser you use. That entirely misses the point of the open WWW. It's a terrible idea to build things in that way.
That’s ridiculous. We have to make it look like _something_ the user would expect, and something good. Why not pick standard UI designs and patterns in use today? The alternative is that we build our own standards and force users to learn something new.
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.
The Web is open and independent. Google's and Apple's visual branding are not the standards of the Web. There are countless non-Google, non-Apple designs on the Web and they are not forcing users to learn anything new.
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.
What if it hadn't been ionic, but was instead the browser itself that rendered the same website differently when in different OS? Oh wait...that's already the case...
Google's browsers don't automatically load your websites with Google's visual branding and Apple's browsers don't load your websites with Apple's visual branding.
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.
You do realize that Ionic is mainly used for App Store and Google Play right? You're free to not use it. It's a correct decision for Ionic to go with iOS and Android standards, from my point of view, and the implementation is superb as always with Ionic components.
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.
That’s stupid. Of course you can decide to force a specific theme via the config or even create a completely independent theme within Ionic - it has great tooling for that. However having an app behave like an iOS app when being opened in Safari on iOS absolutely makes sense. After all, Ionic is a mobile web framework and one of its goals is to look native on the specific platform.
Yes, but in this case you aren't really developing for the web, you're developing a "native" looking app that happens to use a WebView to display it. Using native looking controls therefore makes sense for this use case. There is a reason why Apple and Google provide UI widgets for use in applications, so that user have a consistent experience across apps.
The open Web is independent of the browsing device. If you play Google's game of using their visual branding, you're making it easier for them to hijack the WWW into a Google product.
Having that as a default means that many people will implement it.
Pretending that you speak for “the open web” in an attempt to sell some obsolete web design dogma that open web advocates have spent the last dozen years or so fighting against is pretty solid evidence that you’ve also missed the point of the open web.
This looks pretty neat! First I've heard of Ionic, and I want to use it. I have a question for anyone familiar with 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?
I´ve used Ionic for both mobile apps and PWA (web sites that access the device hardware).
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.
I really want to understand it. It reminded me of my days migrating from the Vb5/6 UI to java swing. It was painful, but after you groked its logic, it made sense.
How can I get to grok Android's Ui layout process?
Until now Ionic has been mobile first. But they announced earlier this year [1] that they are working towards better desktop support. So I'm not sure it would be the best choice if you need a mature framework for desktop web apps right now and don't need hybrid/native mobile apps.
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.
For what you mentioned you might consider Sencha (assuming you want to pay as they're not exactly cheap). Here is the demo page with all their visual components:
My company’s main app is built with ionic. Started with v 1.x and is now on 4.11. I love it but, our app was mostly aimed at mobile. It has since become much more desktop focused and we often have to create our own components. (Which is really easy using Stenciljs, also from ionic). Here’s some things you’ll need to work out:
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.
We've abandoned V3 because of the shift in focus. I wish they would have improved the native build service (I think it's called appflow now?) instead of going for 2 more frameworks and an IDE. Wish them all the luck with their new releases.
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.
To piggyback off this: AppFlow is such a great idea in concept, however their execution is half baked.
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).
App Flow generally works really well for native app builds for us.
- 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.
Thanks for the feedback. While I’m sad you had a bad experience, I’m happy to report that we’ve made significant improvements to those areas. Capacitor comes with a solid push API out of the box, and we will be launching App Store submission in Appflow soon! Appflow also supports Capacitor as of this summer.
- 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?
Ionic was a huge velocity-booster at my last startup. They caught some (unfair) flak for being Angular-centric when React got hot. Glad to see them constantly improving things!
Glad to hear that! And while creator.ionic.io likely won't get more love, our new Ionic Studio product is quickly catching up to the simplicity of the drag and drop experience in Creator and will quickly be surpassing it, so I hope you check that out! https://ionicframework.com/studio
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.
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.
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 :)
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). 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:
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.
Currently we're working on an angular/ionic 3 hybrid project with libraries shared though git submodules (Ionic does not support symlinks).
"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.
I feel Ionic is more engaged into open web than big companies trying to enforce their own standards. The question is when Appple and Google will start blocking (outside of walled garden app stores) hybrid apps?
Why would they block hybrid apps? Apple only cares if your hybrid app loads its code at runtime. They couldn't care less if it's JavaScript.
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.
We see that sometimes and it's almost universally apps that are just websites wrapped up, or more "brochure" apps. Apple doesn't like those, but it has nothing to do with Ionic/Cordova/Capacitor.
Were you going out of your way to circumvent native functionality somehow? A calculator app probably "doesn't use much native iOS functionality", but I don't see how that would get it negative points on App Store approval.
That's your issue then. They have rules to stop the App Store being flooded with website wrappers. For it to be in the app store, there needs to be something it offers to make it worthwhile for users. If it's just a website, they can just use a web browser and pin it to the home screen if it's something they use frequently.
I'd definitely consider using this. Mobile browser support used to be painful for this kind these "hybrid web apps", and animation performance wasn't up to scratch. But engine support is much better since Android 5, and phones have only been getting faster. It's not that hard to produce a performance mobile-web app these days.
I espect Ionic React to take a huge share of react native developers on the long term.
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.
Wow, thanks, we appreciate the vote of confidence!
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).
The challenge for your marketing is to educate people and to update their beliefs.
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.
I believe Capacitor is the absolute life-saver of hybrid development. I've been using Cordova for quite a while and switched to Capacitor last year, and it made my life so much easier. Where Cordova tries to do anything and everything, for all platforms, with its super flaky plugins and buggy config.xml, Capacitor is really focused on doing one thing well: being the shell between your code and native hardware.
One of the major points is the code it generates for iOS and Android can be committed to GIT and is yours; you have full control over the native part of your app and could extend it in any way shape or form.
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.
Glad you're liking it! While we remain big fans of Cordova we do have the fortunate advantage of building Capacitor in 2019 where we have access to much better JS standards, native tooling that is far more mature than before, and a clearer outlook on what devices/platforms need to be supported, not to mention Progressive Web Apps. We've tried to take advantage of those technological leaps and apply them where possible.
I have a responsive React app that I want to convert to an app. I thought you could just drop it in Ionic and it would work automatically but this is using stuff like IonPage, IonContent etc. Do I need to rewrite a lot in order to get it to work and how can I keep a shared codebase in the future? I really don't understand the appeal vs using React Native if I need to rewrite it using Ionic specific components anyway.
Yes you would need to use our components because they have meaningful logic when it comes to building an app experience.
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.
I've had great experiences with Ionic in the past. Capacitor removing the headache that is Cordova looks promising and I'm glad Ionic is moving in that direction. It's a great platform and there's lots of support out there for it. I've chosen Flutter for my latest project however for two main reasons: 1) JS ecosystem fatigue. 2) Not having to write JS or CSS is frankly a breath of fresh air. I can build a UI logically with out the refresh-and-pray experience, even if things get kinda verbose. I should also add that this app is not "brochureware" and needs a more app and less web-like UI. I think Ionic currently excels in the latter.
I'm just a bit concerned how Flutter is basically going its own way rather than building on web standards. E.g. HTML provides declarative layout while JavScript is ubiquitous and could also be transpiled to native code. Rather, Flutter is building its own declarative UI approach, rendered with its own canvas, building on a significantly less ubiquitous language/ecosystem, and is principally governed by a single organization.
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.
I wouldn't use Flutter for web development. It solves targeting iOS and Android without having to use a Javascript Bridge. Neither mobile platform defines its interfaces in terms of HTML. There are definitely a few development teams where React Native is also a valid choice, but cross-platform mobile app development has a learning curve regardless.
I build the occasional small mobile application. I evaluated Ionic, React Native, and Flutter about 18 months ago; and ultimately landed on Ionic for the projects I needed to ship.
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.
Hey Brad, definitely take a look at Capacitor. We built it explicitly to solve those issues in Cordova. Also keep in mind Flutter also has to deal with native projects and deps so there are some “hard problems” not unique to Cordova here
Oh I have no doubt the grass isn't purely greener on the Flutter side. There's a ton of moving parts here for any solution to deal with.
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.
Huge congrats to the team! This is a giant milestone in Ionics life. Am a huge fan of the original Angular.js and Angular versions and it's nice to see the flexibility with React.
Awesome news. For quite a while we had ionic for Angular, react native for React, quasar for Vue, now glad to see ionic officially supports react from now on.
re: downloads, it's not quite that simple. `ionic` is our CLI while `react-native` is the actual library that is installed and will be installed frequently for build systems, etc. Also there are multiple versions of Ionic under multiple package names. Not arguing that React Native has more NPM downloads though but Ionic is quite popular on its own!
Really excited to see this. We have an Ionic Angular app that is running in production and being actively developed.
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.
Thanks! I believe that being able to publish a PWA alongside an App Store app is a magic power for products that have a purpose as a web app through link sharing and an app in the stores. Why risk losing users to a download when you can ease them into your world through a PWA first?
It's a combo. While we offer support and advisory services to medium-to-large enterprises, increasingly companies are deploying our native solutions for local app security (https://ionicframework.com/identity-vault) or our Mobile DevOps service that has seen a lot of growth recently (https://ionicframework.com/appflow). Finally, our new Studio product has been growing very quickly and will be getting a lot more "low code" dev features in 2020 (https://ionicframework.com/studio). Those products are sold on a subscription basis, either yearly w/ multi-year contracts for bigger companies, or on a self-service basis.
One of the main differences is that Capacitor projects treat build artifacts as source code, and hence the artifacts are to be version controlled. I thought such aspect was kind of nice for cases in which you need some customization.
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.
That's a good assessment and we're keeping an eye on that future issue. However, we also see the native project and API structure of Capacitor to be very stable and don't anticipate significant changes that will require native project tweaks.
I might be misunderstanding how Capacitor code generation works, but would re-running the build process overwrite code customizations on the previous build? If so, how would this be avoided?
I see how my comment was confusing. In capacitor, when you initialize a project for a platform (IOS, Android, etc), a bunch of native source code is generated and they are not overwritten.
I love Ionic! Glad to see them reach this milestone. Great product and company and while I am not using them in my current role I wish them the best of luck moving forward. I hope I get a chance to use it again, if not professionally - I'll have to take a look at Ionic React for my next personal project.
You can think of it as a "Bootstrap for Mobile/Desktop Apps" if that helps. It's not based on React Native but could be used with it to build out certain screens in the app.
I'm a huge fan of Ionic. Capacitor is a great project and fixes a lot of issues I had with Cordova. I have made a few apps that are websites and apps on both stores and they work pretty well I think.
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)
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.
Having that as a default means that many people will implement it.
Some apps are web technologically, but are local tools by purpose; that's where blending it could be beneficial for the user.
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?
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...
https://examples.sencha.com/extjs/7.0.0/examples/kitchensink...
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).
- 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.
- 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?
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:
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.
"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 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.
It seems interesting, still I believe ionic has a far bigger community which is a big time saver.
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.
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.
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.
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.