I can find nothing in change logs about ionic 2.2.3 supporting angular 4
The http://blog.ionic.io/ionic-3-0-has-arrived/ says ionic 3 has been updated to support angular 4
Yet a new app scaffolded by 2.2.3 appears ( according to all the package.json files ) to be using angular 4.
What’s going on ?
Ionic 3.x supports angular4 out of the box. Aren’t you by any chance confused with the Ionic-CLI, which latest stable version is 2.2.3? The CLI is something entirely different from the ionic-angular package.
To further expand on what @luukschoen has said, you can see the Ionic Framework changelog here where it talks about upgrading to Angular 4: https://github.com/driftyco/ionic/blob/master/CHANGELOG.md#300-2017-04-05
I’m not even sure if I’m confused anymore…( this day is going from bad to worse )
>ionic info
Your system information:
cordova CLI: 6.5.0
Ionic CLI Version: 2.2.3
Ionic App Lib Version: 2.2.1
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Windows 10
Node Version: v6.10.2
Xcode version: Not installed
I take it from the above that I’m on Ionic 2.x and not Ionic 3.x ? - ( and that ionic-CLI 2.x is Ionic 2 - this is crucial to my interpretation of the situation )
Sigmuund’s link says, as I said, that 3.x introduced support for angular 4 ; "With this release comes a major update to Angular (Angular 4.0!), "
So why, if I am using Ionic 2, is my app scaffolded with angular 4 ?
That’s your CLI version. You would normally install the CLI with the following command: npm install -g ionic. That gives you most definitely ionic-cli version 2.2.3 since that’s the latest stable release. The CLI is there to make your life as Ionic developer easier; it isn’t the ‘framework’ itself. There are a lot of threads here on the forum about this specific distinction between the two, so I can understand your confusion.
ionic App Lib is actually documented over here and is mainly there to make the CLI easier to use.
The version of the framework, i.e. where you’re code is based upon can be found inside the contents of your package.json. It’s referred to as the ionic-angular package.
No matter the version of the CLI you’re on, ionic start myApp --v2 (or with the new cli commands) will generate a setup with the latest version of the ionic-angular package and angular dependencies. So if you’re on the latest version of the CLI and you create a new project, it will probably be on angular 4.0.2 and ionic-angular 3.1.1 at the time of writing.
To further elaborate on this, the Ionic Framework (ionic-angular package) you asked about (ionic 3) is actually on 3.1.1 at this time. And it supports Angular 4, hence your project created with CLI 2.2.3 has ionic-angular 3.1.1 and angular 4 dependencies.
Cheers. That HAS cleared things up.
Though, wouldn’t it make more sense to have the last stable CLI default to using the last stable framework ? As it stands it means anyone using ionic who hasn’t gone through “this” is most likely using a pre-release version of the framework.
One last question ; is there a way to check the angular version from the console while debugging the app ? ( would be so much more reassuring )
Actually ionic-angular 3.1.1 is the last stable release of the framework, so the Ionic CLI does install the latest stable version of the framework 
To find out which version of Angular your app is using (if you’re not sure if package.json’s angular version is the one installed on your project), just check your developer tools. Open up the dom inspector, search for the ion-app attribute (first one inside your body) and it will say something like ng-version=“4.0.2”
EDIT:
You could also do this in your app.component.ts (but it seems redundant):
import { VERSION } from ‘@angular/common’;
and then log version yourself. Should give you an object with the current version you’re using!
Yes - I’ve just realised ; been using
npm view ionic versions --json
when OBVIOUSLY I should have been using
npm view ionic-angular versions --json
I should feel good about getting to the bottom of this and people offering their help - but after over an hr I actually feel a bit pi$$£& off that someone did this ; No one talking about ionic X.x is talking about the the ionic node package !! - this should be in a permanent headline banner on the ionic home page.
but thanks again and also for all the other version info you’ve added.
This is sort of why I try to discourage all use of “Ionic 2” and “Ionic 3” altogether. It sows confusion. I try to use “framework” and “cli” instead, as CLI v3 is probably better left in the oven for a bit longer, whereas framework v3 is the latest released and supported version. Framework v2 is no longer maintained.
Well it’s a shame no one else is following your lead.
Now not only do I have the steep learning curve of angular 2/4 to deal with and ionic’s cli and ionic’s implementation of ng ( I seem to recall routing being handled differently ? when I briefly looked at the two a couple of months back )… but there’s this unbelievable and unnecessary element of confusion thrown in for good measure at the start.
It’s not funny.
Routing in phones and tablets is different from routing on a desktop. Ionic’s routing tries to emulate that, instead of Angular’s emphasis on desktop routing.
@rapropos isn’t the only poster here who tries to separate out different parts, though it’s probably fair to say he’s taken the leading role. But the situation is even worse than you think, in that it really helps to understand some basics of Node, npm, rxjs – and advanced Angular – to do interesting things with Ionic. I think a lot of people start using Ionic, thinking they just have to learn one framework. I certainly held that foolish assumption. It turns out that, to be an Ionic expert, you have to be halfway decent at several other tools. At least for me, it’s taken a lot of peeling away one layer of the onion after another, before I finally understand what’s going on. (Not that I’m an expert-expert now. I’m very good at a few things, and pretty crappy at most others.)
So the learning curve is steep, but once you get through it, you’ll be able to do some pretty cool things. Also, I think it’s easier than learning to program natively in iOS, Windows and Android. So it’s a big thing to chew, but compared to what it’s replacing, I don’t think it’s so bad.
Unfortunately it’s not replacing - we’re going round in a big circle again ; Java was a waste of 20 yrs. Javascript will be a waste of another 20. - and largely for the same reasons ; the (broken) promises (pardon the pun) of “write once - run anywhere”.
I only got into Javascript 3 yrs ago and was very soon a total convert -now I’m looking forward to getting out of IT. If I was younger I’d be looking forward to the day when you can write web pages in C++ and there’s no reason to use JS… and that will happen eventually (see webassembly / emscripten). although by then C++'ll be screwed up too ( currently planned revisions every 3 years but no doubt someone’ll need more community time to feel good about themselves and that’ll change to at least once every yr - like Android and look how that’s worked out).
You cannot be an expert in anything these days as nothing lasts long enough. Add to that the massive ever growing ever changing list of “tools” and everyone and their dog’s favourite language/DSL. Then add the nonsense terminology, term abuse and vacuous new non-concepts everyone’s pushing.
The right thing to do would have been to kill Java before it got out and instead produce a vm to compile C++ against and add a general and extensible application framework to use with that.
Just look at WHY JS and asynchronous programming arose and look now at the move toward strong typing (typescript) and C++/Java style OO ( soon prototype OO will be something no one knows anything about because you won’t have to ) and compiling. Probably the biggest aspect of JS was asynchronous execution so the user wouldn’t have to wait for the page to load before they started reading. Now every ng app starts with “loading…”. and asynchronous programming so coders wouldn’t have to deal with multithreading - now multi-threaded programming would simplify what’s there in many places ( eg. use a webworker and see how much simpler your (synchronous) file handling code is ) HELL the focus of JS these days is on writing Desktop and Mobile Apps - but often all the time thinking about it still as web development .
And of course you’ve got to waste time getting through all the hype - no one tells you in plain english on their page what they’re selling - you have to download and try it - usually to find it isn’t what you were led to expect. Then if you do want to persevere you’ve got to try and wade through all the IT $£!T£ speak without gagging to try and pick out what they’re ACTUALLY talking about - see the angular page on what they call a “compiler” ( ok haven’t finished reading yet but by the looks of it it makes angular a language not a framework ).
I seriously looked into going back to C++ and using Qt recently. The main thing that stopped me was that it doesn’t cover the web platform and what I really want is one set of tools to develop for all platforms.
On a more positive note Node is an amazingly productive, easy to get to grips with tool - gives me a nice warm fuzzy feeling.
Got lost in a rant there earlier - but on your point [quote=“AaronSterling, post:11, topic:89390, full:true”]
Routing in phones and tablets is different from routing on a desktop. Ionic’s routing tries to emulate that, instead of Angular’s emphasis on desktop routing.
[/quote]
How so ? I have a menu, button or other control that takes the user from A to B in an app - be it on a mobile ( small tablet ) , a tablet ( small desktop ) or a browser ( desktop without native menus ). They are all Single Page Apps - essentially hiding / showing sections of one page. And now they’re all using angular. So why would I want or need to learn, implement and maintain a different syntax and/or pattern to manage that ?
I have developed mobile , desktop and web UIs and I don’t understand what you mean by routing being different on the different platforms. In many cases the GUI presented to the user will be exactly the same across all platforms and they’re all using angular - what if I just used angular in a web app / cordova on a mobile without ionic - presumably the angular routing would work.
Maybe something’ll become apparent when I get stuck in but I can’t see any obvious reason for it at this point.
There are lots of UI details. You’re at page A, you scroll down a bit, then go to page B, then pop back to page A. What’s your vertical position in page A when it is redrawn in the DOM? Desktop and device don’t agree there. The Ionic team met with the Angular team for a week to hash out stuff like this. There might be a doc somewhere with a comprehensive list, I’ve never bothered to look for one.
That’s an implementation not an API issue.
Mmmmmaybe. Put enough of those together, along with navigation by click instead of by url, and you either have to put some giant kluge on top of Angular routing, or develop a different router.
Edited to add: you could take a look at this comment and the one after it to see some of the official thinking here.
Well, looking at the comment it seems like the ng router is lacking - that particular requirement to return to the same point on the page could apply to a desktop or browser app just as much as a mobile app…which leaves me with a bit of a conundrum - do I maintain 2 code bases (ah that broken promise…again) for essentially the same app or use the lesser framework (sorry, Ionic doesn’t appear to have quite the same stature as ng ) or forego the benefits of the ionic router…leaning towards design it so point on the page doesn’t matter and go with the ng router and 1 codebase.
I can’t see how ng adding the point on the page(in the component ?) should be that difficult.
But hey ! cheers for the heads up - you’ve saved me some time.
Thank you sooooo much for clarifying this…