What Ionic 4 Is Doing Right
The lifespan of Ionic 3 is slowly drawing to a close, but that’s no reason to panic – Ionic 4 has been in public beta testing since July 2018 and its future is looking bright.
Their basic functions have remained the same, most of which you’ll already be familiar with. However, there has been an optimisation of processes making them more streamlined. Ionic has always been about building better apps, faster. This ethos comes across loud and clear in how Ionic 4 has been designed. Most notably, Ionic 4 is now entirely agnostic of the base framework. This gifts you with more freedom in what and how you create, prolongs the life cycle of your viable code, and allows updates without having to deal with changes to the framework.
This new framework flexibility also becomes an exciting open invitation for any developer, from any background and knowledge base, to jump in and reap the benefits of Ionic. It makes building hybrid applications for iOS and Android more accessible, and now allows you to use Vue.js as well as the latest versions of Angular and React to build native mobile apps and progressive web applications (PWA).
The key to making these improvements possible has been a substantial shift in how Ionic 4 operates. The framework has adopted the use of standard web APIs. Each component exists in isolation from the rest of your code, packaged up as a Web Component, and integrated as HTML tags.
As Web Components are custom elements, the device browser already recognises there is no need for external libraries or frameworks. This negates the need for frequent rewrites and API changes for updates as components become outdated and incompatible with the native platform. Taking advantage of a device’s native code also allows for performance improvements – less code in an app results in faster load and startup times. This is a big change to make, but if you’re concerned about learning how to work with Web Components, don’t be. The Ionic team has created a compiler tool called Stencil, which produces Web Components based on pre-existing frontend frameworks. Once you pick up this skill you should be good to go for the foreseeable future. There is also no need to be worried about a browser not supporting a specific Web Component natively. Ionic 4 is able to polyfill these, downloading code to clients that need it based on feature detection. Most users will never experience this, and those that do are unlikely to notice it happening.
Some changes have less impact on the structure of your projects than other Web Components, but are no less significant. If you use Ionic with Angular, one shakeup is the shift to using the Angular Router. While the classic push/pop style of navigation is still possible, parallel navigation is now an alternative. This lets you have multiple navigation stacks and exchange them at will, no longer restricting you to the linear backwards/forwards navigation.
Finally, while not the most radical change in workflow processes, perhaps the most future facing change is Ionic 4 partnering with Capacitor. Although still supported, Capacitor has been created by the Ionic team to do everything Cordova does. It also aims to be a solution which is more in line with Ionic’s goal of one codebase for all platforms. Capacitor is designed to easily integrate with your projects, being locally installed with just the path to the web code that you want to include within the native application. There is no need to tailor your existing code to work with it.
This once again proves Ionic 4’s basic ideology – less code and fewer dependables mean no need for frequent updates or edits to your framework, further enabling more efficient cross-platform development. All these changes and improvements aside, whether or not we can truly wave goodbye to the unforgiving cycle of framework churning remains to be seen. So far, however, Ionic has taken a significant step closer to that goal. Where do you think they’ll go from here, are you itching to get started on a new project? We know we are!