We used Ionic 1.x for a few projects. We found that for relatively basic, brochure-ware apps, it worked just fine. However, for some of the more complex apps, we really fought the lack of support/options in the Cordova plugin space. This, of course, is not the fault of the Ionic team, but it does create a frustrating development experience that played a large part in us abandoning it as an option.
This was also our first experience with Angular. I really wanted to like Angular, but after more than a year of development, we left it for greener pastures. I understand that Angular 2/Ionic 2 are touted as being significantly better, but while all those improvements were being made, we invested our efforts in learning and building with Swift. I can say that we are delighted with the outcome and have no real inclination to leave it for an alternative.
Angular 2 is a completely different animal so I would disregard that part of this comment. However, the parts about Cordova still ring true with regards to Ionic 2.
Agreed. For me, that was another reason to move away from Ionic. That its largest dependency came to differ so greatly from that of the previous version, was enough for me. If I was going to be forced into learning something new, then Swift it would be.
I am about to release my largest Ionic project to date. It is a highly dynamic data entry and reporting system for field workers. My client is able to create and publish new data entry forms and reports from the private back and angular web app that I built for them.
The lack of any kind of commercial support is real and frankly that is the largest issue that you will have to deal with. I have searched high and low for any kind of commercial support that I can offer my customer. I am it. Or somebody like me.
However, I will say that in two years of using Ionic I have never had to modify one Cordova plug-in or any native code in order to release my apps. I do mess around with the native code sometimes but usually on an exploratory mission. Other than that, my biggest issue so far has been with how quickly ionic and Cordova get updated and how quickly my code gets out of date because of that. Then when I have to update I have to make sure that nothing breaks by writing all sorts of tests or doing manual testing yada yada yada. Also getting answers from support or anybody qualified is sometimes difficult and you have to wait days or just figure out your own work around.
To be specific--and maybe this only pertains to version 1.x--I found managing navigation state in our largest app to be quite clumsy and at times, downright perplexing. In Swift, managing navigation state is relatively easy to reason about, though it is a bit more laborious to implement.
The bigger issues were things like having access to leveraging background processes via Cordova. At last check, there was a plugin for backgrounding the app, but it came with a big, red warning that it may cause issues with Apple's App Store approval process.
Another issue was the dismal state of background geolocation. There is a commercial plugin; however, I found the maintenance schedule to be quite lacking. As well, the maintainer of the plugin was quite abrasive and impolite toward users raising valid issues.
Ionic 2 is much more performant and scales much better for app development than Ionic 1. I have yet to meet anyone who has not really enjoyed developing Ionic 2 apps. We take a tremendous amount of pride in the developer experience!
Native apps will always be a little faster but if you can get 60FPS either way, who cares? Ionic is easier to build apps with, and developing in the browser is a joy.
A huge advantage of Ionic is being able to deploy the same code base to the web as a PWA and to a phone natively as a cordova app. Soon Ionic Native will expand to support PWA and Electron, too, so it will truly be a write once run anywhere experience.
I was really very well impressed by the small size of ionic apps. It's in the order of ~3MB which is great.
But the startup times are somewhat big. I'm talking, for the simplest of applications a startup time of ~5.5 seconds in ionic 2 (the beta) vs ~2 seconds in React Native in Android.
For me, that detail has a significant impact in usability.
So start up time is something that we are very focused on at the moment. Especially on the PWA side of things, TTI (time to interactive) is exceedingly important to ensure a good user experience. We are working on a few things at the moment but most likely the first one to hit is gonna be code splitting. So with code splitting, instead of shipping just one big bundle you will be shipping smaller bundles that are lazy loaded based on routes. This means that when the app first loads only the first bundle for the first view in your app will have to be loaded, parsed etc and then the other bundles will be lazy loaded. With this setup the browser (or webview) will never have to parse and load a huge bundle all in once, it will instead only have to deal with smaller bundles. This should give a pretty big improvement as parsing javascript is slow in every browser. From my testing on a moto g each MB of JavaScript in an ideal situation takes about 2 seconds to be parsed, so reducing the amount of JavaScript the browser has to deal with is a very fast way to get better load times.
Well unfortunately ionic2 is super slow to develop..
Ionic1 is nice in the beginning, but if your app grows, you're simply waiting and waiting.
This is a problem with all javascript frameworks.. just 'watch' a directory for changes and restart, recompile everything
This isn't that big an issue if you set your JS build pipeline up properly with modern tools. Webpack can chunk your built files and will only rebuild the ones it needs to upon change. Combine that with hot module reloading and things are snappier than they've been in a long time.
Not long ago I was an Ionic believer, but not anymore... the lack of support for their cloud services [0] has turned many people off and signals that they don't mind leaving their users "locked".
Devs are migrating en masse to react native. I have friends in several startups leaving their jobs because they've been tasked with maintaining legacy Ionic 1.x/Angular projects, while the codebases are migrated to react native...
For hacking quick MVPs is not bad, it was even cool 2 years ago, but for serious projects starting from zero, react native is a smarter choice.
> I have friends in several startups leaving their jobs because they've been tasked with maintaining legacy…
It's better to not have such people working for you in the first place.
Maintaining existing software to focus on real business is just the kind of founders I'd want to work with. It's a part of being a part of a startup, and those who jump the ship too often do not leave any legacy behind.
Developers who jump because they'd rather build from scratch instead of helping maintain and improve an existing solution is irritating.
More power to them, but I respect developers a lot more who stay, fight through legacy code battles, make steps/headway to shift the application to a newer platform that makes practical sense than those who leave.
If your employer refuses to move to a stack you feel is justifiably better, in both business and technical aspects, then I totally understand leaving. If you're leaving because you don't want to maintain a system that's "older" and don't want to take on the challenge of improving it then I agree with your post. I'd rather not have those developers to begin with.
Exactly. You don't NEED to use Ionic's cloud platform. You can develop an app completely independent of it, or else integrate with other back end services.
Personally, I've developed Ionic apps that integrate with Firebase, PushWoosh, Back& among others... You are free to choose. No lock in necessary.
Right, AFAIK the framework itself functions independently of the services, so you can drop in whatever solution you want for push notifs / analytics / MDM.
Bingo! for hybrid development, I don't see anything better out there than ionic.
Key point - for hybrid development. There are a lot of use cases where hybrid mobile apps are appropriate (CRUD). With ever more powerful devices, the argument for hybrid increases.
Way to much hate here. I run an app with ~30k users and I never get any complaints about lag or comments on the stores that reflect negative on the performance. All criticism I've received has been by my own missteps.
Ionic 2 has given me two platforms and a great development experience. The few times I've had problems they have an amazing responsive team on Slack that's helped me out right away.
I've built many apps using Ionic, and usually with good results. I think the problem is that people don't really look at their 'use case' when designing their apps. There are apps where a hybrid solution works great, and apps where is doesn't.
If you are going to build an app that requires you to display 1000 items in a scrolling list, then yeah, forget any sort of Hybrid or Cordova based app - go full native.
Similarly if you want to have complex background geo-location tracking that doesn't suck your battery dry. You can't optimise that using Cordova as the 'go between', but you have to go native.
Outside of that, Ionic/Cordova will cover you bases and let you get apps to market 20x quicker without your users realising that it is not a native app.
I'm always afraid of investing a lot of time into this type of frameworks and then having the rug pulled from under me. Most of the time I spent learning angular ended up being a waste of time and I'm still scarred from then.
You're not wrong. I've worked with Ionic v1 a fair amount. The framework is good for mockups and prototypes but nothing more. What ends up happening, as you app grows to include notifications, deep linking, etc, is you need to rely on more and more hacky thirdparty solutions. These days I either code natively or use Xamarin.
You are wrong. I have few mobile apps, made with Ionic and Ionic 2, some have been used on warehouse as part of huge WMS (to scan items and manage whole business process of warehouse worker), some were apps for business as part of CRM (with geolocation, maps and handwritten signatures). And every time product owners were very satisfied with the result and with speed of development.
Ionic 1 had too hacky API and not great performance, but Ionic 2 is much more mature in both of these fields.
I don't believe I ever mentioned ionic v2... I don't doubt v2 brought many improvements. However you just can't beat the power of not operating in a Webview.
However, Webviews do give you a very predictable container to target. If you use something like Intel Crosswalk [1] as part of your project for Android, you can bundle a recent Chromium webview to much older devices. And Flexbox is very well suited to solve phone/phablet/tablet layout problems.
Because people seemed to love 80MB Chrome runtimes being bundled with terrible Electron applications on the desktop, Crosswalk allows you to bundle 40MB of chromium for your terrible application on Android.
Ionic2 is quite a bit different. In my opinion it scales really well especially with Typescript. Most of features that would have required thirdparty solutions are baked into ionic-native.
Curious why you think it was a waste of time. You can still make perfectly functional products using Angular 1, and most jobs (at least in the bay area) won't look down on you if you're not fluent in their framework of choice - they'll expect you to learn it on the job.
I think it's around 5 years too late to prevent the complexity explosion :)
JS has been object oriented since the beginning it just has an insane prototype based inheritance hierarchy that they're increasingly trying to hide/pave over.
> just has an insane prototype based inheritance hierarchy that they're increasingly trying to hide/pave over.
Can you elaborate more on why you think it is insane? I think it is quite elegant, and in my experience they only try to hide or pave over it because just so many damn people can't get over the fact that it isn't classical object oriented
the way inheritance works in JS leads to a ton of inelegant design patterns that need to be remembered and very inefficient handling of many casts because the prototype chain is literally just a linked list.
It also prevents sound encapsulation of class local variables and methods, the main point of object oriented programming in the first place.
There are many other languages that do not have multiple inheritance, or do not handle it the way you typically see in C++ or Java type languages, go being one of them, ruby another. Composition is more favored, and arguably a far better pattern regardless. I disagree with your assessment that it prevents sound encapsulation, and regardless, a better argument made against it is the fact that it is a dynamic language. In any way, there are patterns to achieve classical OO-style encapsulation, but that is not the main point of object oriented programming in any case.
My argument doesn't have anything to do with multiple inheritance. C is the only one I know of that supports multiple inheritance and it's largely considered a historical mistake (see deadly diamond of death). Javascript uses something called the prototype chain to determine InstanceOf(). It's literally a linked list, and a ton of disadvantages come with the object system being a re-purposed linked list. It's possible (and easy) to break the type of an object by corrupting the prototype chain. It's the reason you have to do hacky stuff like Array.Prototype.ForEach to make sure your code actually works in larger JS applications. It's also slow and a big reason why javascript runs around 10x slower than most JIT'ed languages. The crazy object system prevents a ton of optimizations from working.
Encapsulation isn't the "classic version" of OO. It's literally the main reason OO was created. Javascript fails to encapsulate because it doesn't support true private data members. There's patterns to achieve some sort of data safety (see http://speakingjs.com/es5/ch17.html#private_data_for_objects) but they all have disadvantages because it isn't built into the language, it's another hack.
Composition can be easily achieved using interfaces in most languages, another thing javascript doesn't support.
Excusing these faults to being dynamic language is like saying the model T is a nice car because "it was good for its time". Many languages before JS (including perl even) supported a more sound and convenient type system.
JS was badly designed in many ways and we are still paying the price for it today. ES6 and transpiling have made it finally worthwhile to try to develop anything significant using it which has led to the recent explosion of javascript development. I pray that EMCA continue to remedy what can be fixed in future and that Typescript catches on since it mows over much of the insanity.
The next generation of package management tools will allow for multiple "universes" of libraries, using different development philosophies. Then we'll have a real hard fork and the ES6/hundreds-of-control-structures+complex-build-pipelines crowd will have to compete with the JavaScript/small-idiomatic-modules crowd.
Type systems (e.g. TypeScript) expose complexity well. Maybe I don't understand your comment - are you writing only simple apps which don't use objects?
> Type systems (e.g. TypeScript) expose complexity well. Maybe I don't understand your comment - are you writing only simple apps which don't use objects?
Yes and no. With Typescript, js developers tend to write js code like they would write Java code, in all its verbosity. They don't need to, but they do.
At the moment we are in the process of evaluating different frameworks/solutions to build a simple native App for iOS and Android. Its mostly some basic forms to build simple objects that eventually get posted to a JSON API.
What astounded me most was that nearly none of the established solutions offers a simple way to just cache these requests until when the device is online or any other simple ways to get such basic stuff working when offline/the connection is bad.
Generally speaking: In early 2017 its still way to hard to get very basic stuff on native (let alone web based) mobile apps working offline. The whole offline-first movement still has a lot of educational work to do.
I'm not sure I agree with this 100%. About two years ago I had to have shoulder surgery and so couldn't go golfing with my buddies -- I ended up making a mobile app to mimick the one used by the PGA Tour where I could track all of their scores online as they played so I could still participate in the banter with my golf buddies. A big issue was the fact that I wanted the live updates but had to deal with pretty spotty connection around the course.
I ended up using Firebase and it handled that case just BEAUTIFULLY right out of the box; the data updates optimistically on the player's own device, and once a connection is established Firebase syncs it with the datastore and all other phones update accordingly.
I would say that this is some pretty sophisticated behavior that I, the developer, just used right out the box following documentation.
Firebase integrates beautifully with Ionic, and allows real time push, as well as offline caching. I've done it and it works great.
You can also use CouchBase (disclaimer, I haven't tried it yet, but have an app that I will be using it for in the near future).
As a last resort, we also have an app that uses LocalStorage on the device to store an 'offline copy' of a database, and sync up when the user wants to. It works surprisingly well in this particular use case, and no need for any complex library. Just load up the local storage database when the app is launched for the very first time, and then whenever the user does a 'pull to refresh', it goes looking for the latest data from our server - if it cannot find a server connection, it fails gracefully.
I've been using react-native for the last year and can't say I have much positive to say about it. Honestly, just about every day we hit a sharp pain point in component layouts, broken build scripts due to RN bugs, and runtime crashes. While Ionic 2 is young, I welcome another option to the JS native space. I'm also hoping Flutter.io will get to a stable release.
I've looked at nativescript- it's pretty neat... although still very young. Imho, there's no native JS platform that I'd recommend for a production app yet.
Stupid question, but Ionic is not native, or was not at least. But react-native is actually using only native APIs through Javascript. So if you want to have a native look and feel, why not go with react-native?
I don't think that's a stupid question at all. Ionic uses Cordova [1], which basically launches a browser that runs your web page as an "app". That said, Cordova does give you access to native APIs, so you still have access to Bluetooth/camera/whatever. Phone processors and browsers are getting increasingly powerful, so it's totally possible to achieve native or near-native performance in a web view-based app - assuming you properly optimize your JS and HTML. I believe Ionic provides consistent styling, so it's definitely possible to make your app look and feel like a native one.
The real win using something like Ionic is that you can build your app using web tech that works equally well on the phone or in the browser, and that your developers already know. The trade-off is that it becomes more difficult (but certainly possible) to make your app look and feel native.
React Native gives you many of those benefits, but since it compiles to actual native code you can't reuse your code for a browser app.
With react-native, if you isolate your components from your logic enough, (example: use Redux), you can reuse all the logic in a react-native app, and just change the components part, which is usually not that hard, at least on the simple apps I worked on. Another advantage that react-native would have would also be to be able to have native code and react-native code in the same app.
Simple answer: react-native takes longer to learn and longer to build in. It's really good if you absolutely need the performance and have a larger team of developers that all know React.
Ionic is ideal for smaller projects (one to about a dozen developers) or varying skill levels, many of whom already know web development to some level and don't want to have to learn yet another way to do things.
With Ionic, you can use the same code for your website and your android and ios apps, or at least re-use a lot of it easily. This is a big deal to people who want to keep costs low.
If you need serious performance on your mobile app, use react. If you want lower costs, use ionic.
a) Most users don't care and don't notice the difference between a truly native app and a well-done hybrid one. Ionic 2 mimics the platforms quite nice.
b) With Ionic 2, I can be productive right now, because I can mess around with CSS and HTML. React Native only supports a CSS-like subset and you need to relearn some layout things. It's close to web stuff, but not entirely.
c) My gamble is on progressive web apps (PWAs) in the long run.
I've got an app that I started way back in February 2016 using ionic 2, so I've followed the alpha and beta, it's been a long slog, but even back when I started I could tell it was worth it.
I'm currently using Angular 2 for another project - it's awesome.
I have already built tons of business apps with Ionic 2 (beta) and really like how easy it is and how well it scales. I also really like your ionic-app-scripts which make things like AOT a breeze.
I have developed native iOS since Apple introduced apps on the iPhone and I have created some very big macOS and also Android applications natively. I think there will always be use cases that you need to do natively. However for >90% of the apps I developed (and use) Ionic 2 is perfect and has saved me a lot of time.
The beta phase has been a bit though to keep up with because of how many changes where introduced by Angular and the build infrastructure, however since RC1 or so Ionic 2 is really really nice.
I came to the realization that native development is not feasible for many business contexts when I was tasked to build an application for iOS and Android simultaneously a few years ago. It was so much work and pain to keep both apps in sync that I have decided I never want to do this again. Luckily Ionic came to the rescue :-)
You will still find platform specific problems, but so far it has been relatively easy to resolve them.
No, Ionic 2 is a complete rewrite of the framework with all of the lessons learned from Ionic 1. Writing apps with Ionic 2 is an insanely great experience!
No body mentioned but Ionic Creator[1] still supports Ionic 1. I think it is great tool to start an app from scratch but it doesn't look cool when your own tool doesn't support your own latest product.
Not familiar with Creator, but I'd be frustrated if I had to wait for a drag-n-drop gui editor to catch up before seeing a release in any core framework.
I like Ionic, but not a fan of the name of "Ionic Native". I think that might confuse people with regard to parity with React Native, when it's really much different (it's a Cordova plugin wrapper)
This is actually something I'm excited about. I remember trying Ionic v1 and not really enjoying it. I built some MVPs and some apps using Ionic v2 about six months ago and I found it to be a pretty great experience. It was also my first experience with TypeScript and Angular 2 and I enjoyed the experience (especially versus traditional Android development). It's a neat product and I'm excited to see how the v2 final release compares.
I'm a big fan of the icon font released by this project too[0]. It's similar in concept to Font Awesome, but I've sometimes found it fits my needs better.
> So, isn't it just.. Ionic 2? or maybe Ionic 2.0?
Final is how they signify a version is ready for production and they'll stop modifying it. Up until now they've have 6 upgrades as Ionic 2.0.0-alpha, then 11 as Ionic 2.0.0-beta, 6 as release candidate, and finally, Ionic 2.0.0.
It seems as if the Ionic team is planning to support the desktop in the fuure:
> Coming next we are working on new features to add proper desktop and electron support, something we’ve dipped our toes into in the past but will be making a bigger priority going forward.
That being said, there is Electron, but that "only" provides you with the runtime to run a web app as a natively integrated desktop app, not with visual components and the like.
Electron would be analogous to Cordova, which is what ionic is based on.
Something like Microsoft fabric or similar, or even bootstrap would be the analogous thing for desktop.
This was also our first experience with Angular. I really wanted to like Angular, but after more than a year of development, we left it for greener pastures. I understand that Angular 2/Ionic 2 are touted as being significantly better, but while all those improvements were being made, we invested our efforts in learning and building with Swift. I can say that we are delighted with the outcome and have no real inclination to leave it for an alternative.