Ionic 4 Roadmap: New Features, Release Schedule, & Goals—Oh My!
We’re thrilled to have recently announced the release of Ionic’s fourth major version, and its ability to work across all frameworks (or with no framework at all).
We’ve been overwhelmed with the positive feedback, and so far 4.0 has exceeded our expectations of what’s been possible with a rewrite. So, with the official Ionic Framework 4.0.0 release behind us, I figured now would be a great time to lay out our roadmap and immediate plans for next steps—a vision, if you will, for where we hope to take Ionic Framework in the near future…
Improved Desktop Support
As you might be aware, we’ve always had a ‘mobile-first’ mentality, focusing on providing a mobile and tablet friendly user interface and experience—something that, traditionally, has been difficult to pull off with only the web. However, as more developers and organizations have adopted Ionic as their UI framework of choice, the request for improved desktop support has been ever increasing.
As a result, our next big area of focus will gravitate towards improving the desktop experience with Ionic, while continuing to ensure its mobile-friendliness. Our first step will be to improve Ionic’s media queries by ensuring components adjust as expected when the browser’s real estate space expands or changes. Beyond that, we’ll ensure individual components adjust accordingly.
For example, the current ion-datetime component acts as expected on a mobile device, however, it looks a bit out of place on desktop. What’s great is now that Ionic is able to lazy-load components, on-demand, we’ll be able to instead load a different calendar component that is expected for a desktop UI. Other plans involve vertical range sliders and investigating if we should provide another mode following the desktop macOS patterns. Please feel free to submit, or add to any feature requests for desktop UI components that we should look into next.
Framework Integrations
With the initial 4.0.0 release, we also shipped @ionic/angular, which is based on top of the framework agnostic @ionic/core. The next step is to get both Ionic React and Vue up to the same quality as the Angular release. Throughout their beta versions we’ll keep them at 0.x.x, but once they’re ready for the official major release, we’ll then line them up with the same release version as @ionic/core.
Luckily, a vast majority of the work within Ionic is already available to each integration without any code duplication, and the framework integration itself is a minimal wrapper. In most cases, if a bug is found within a certain component, then the fix is immediately available to each integration. Same concept goes for any new features.
Another upcoming improvement is packaging up each Ionic component as a stand-alone, self-contained web component. By default, each component has the added feature to allow them to be lazy-loaded. But, we also want to ensure each component can act as a traditional web component, which allows Ionic to be consumed in any way possible.
Server-Side Rendering (SSR) and Prerendering
One enhancement that can drastically improve startup performance is server-side rendering, which renders components to static HTML on the server, or prerendered during a build step. For more information about the “why”, plus benefits and trade-offs, please see Rendering on the Web. Most frameworks provide a way of rendering their components without a browser, and Angular Universal is Angular’s way.
Upcoming versions of Ionic will provide methods to “hydrate” themselves on the server. In the case of Ionic Angular, this means we’ll be providing the IonicServerModule which can be imported within Angular Universal builds. The exciting part here is that the core server-side hydration code is reusable in each framework, and only a minimal wrapper is used at the final step. Expect to hear more about this soon!
Custom Web Animations
Animations within a web browser have come a long way since Ionic 1 was first released. In previous versions, even the game-changing requestAnimationFrame API wasn’t available on many mobile devices, resulting in the janky animations from the fallback use of setTimeout.
Ionic 2 and 3 saw many improvements due to our internal animation library, which actually continues to power 4.0’s page transitions. However, this animation library has been intentionally kept as an internal tool knowing that we’ll soon be able to migrate to the standardized Web Animations API.
By following a web standard, it’ll make it easier for developers and third-party libraries to provide custom animations for Ionic. Making this transition has long been in the back of our minds, and we hope to start providing even more animation options, soon.
Improved Stability and Predictable Releases
With the core team focused on refactoring Ionic and shipping 4.0, it was often difficult to triage issues that came in. Now that the API has stabilized, and the refactoring is behind us, we’ll be able to dedicate more time to handling issues reported by the community. This effort can already be seen from our cadence of patch releases since 4.0.0 was released. At the top of our list, right now, are page transitions, navigation fixes, and keyboard issues.
Patch releases, meaning any release that fixes existing features, are scheduled to ship every two weeks. To see which issues we’re currently working on, or what is next in the queue, please see our Github Project Board. Major releases will not be released any sooner than six-months from the last major release.
Let’s Build Some Apps!
Obviously, we’re pretty excited about Ionic Framework and what the future holds for Ionic developers! And, we hope this update gave you a little glimpse into all the next steps to come. We are also beyond grateful (THANK YOU!👏🏽👏🏽) for the Ionic community and their support throughout this process.
As always, we’re open to your feedback so please feel free to hit us up on Github, Slack, or the community forum.
Happy building with Ionic Framework 4.0! 🎉
