Hey yall, so I just wanted to address some comments that have been mentioned here.
So some of the facts regarding github issues seem to be misunderstood. We’ve been working on ionic for several years now, and with the focus shift to V2, the increase in issues is to be expected.
We could spend all the time in the world shipping betas/RCs, making sure every issue is addressed, and never shipping 2.0 final.
Or we can get things to a point where we feel good about the code base, ship 2.0 final release and then continue work after.
We choose to release 2.0 now because the code base was at a point where it had a solid, well tested core, and had the features that we thought it needed for now. This doesn’t mean we’ll stop adding features, or fixing other issues, but we needed to pick a point and say “Here is 2.0.0, this will be 2.0.1”.
Regarding build and startup speed:
With RC 0, we moved over from gulp to using app-scripts. This allows up to update the build task independently from the framework, which is huge.
Prior to this, if something in the build process broke, that normally meant having to:
- cut a new release of the framework
- adding notes on how to update gulp and the gulp tasks
- Install/Update any packages
- lots of manual changes needing to be done by a dev.
Instead, now, we can just cut a new release of app-scripts separately from the framework, and not have to have the framework involved at all.
Now if we need to add features to the build process or work on build performance, it can be done independently from the framework. So any build related issues/question, have nothing to do with the framework and it’s releases.
With app-scripts being 1.0.0 now, we’re not resting either, but we have not been very good at talking about what we’re doing.
Launch speed is something we’re working crazy hard on, and some of the techniques that we are trying are brand new. As we stated in the 2.0.0 release blog, this but is a bit of an uncharted territory for everyone. No one has a solid answer on “this is what you do”, but we’re getting a better picture everyday. What I can tell you what we’re working on is working with code-splitting, tree-shaking, and lazy loading. These features take time to work on though, so please be patient.
For some of the other speed related issues, we’ve noticed 2 common trends, both of which have been addressed many times:
- Slow startup from not running a production build (app-scripts change log)
This was introduced in 0.0.47 of app-scripts, allowing for a much smaller build and therefore faster load times. Most of the time when people mention to me “I have slow load time”, they haven’t run with the --prod
flag.
- Slow builds due to source map generation during dev build.
Another thing I hear people say is that build times take a long time to complete. This is due to the source maps being generated. There two kinds of source maps, eval
and devtool
. We originally had eval as the default but switch after hearing that people wanted more detailed source maps for debugging. devtool
source maps take longer to produce, as it has to go through bundled code, es6 code, and then to TS code. It’s simple to switch to eval, and is noted in the app-scripts README page.
A lot of the pain points that I haven’t mentioned, we’re aware of, and are working hard to address them. We appreciate your patience, and ask that if you find something new, please open and issue, and we’ll work on it over on github.
Thank you for hanging in there with us