Let the Framework do its job
Over the last year or so, modern frontend frameworks have largely converged on a set of standard, recommended build tools and approaches to common frontend challenges (such as building, routing, and testing).
As an opinionated UI framework, Ionic has had to do varying amounts of non-UI work in the past to support frameworks like Angular, including investing in build tools, enforcing project structure, building routing systems, and more. Some of that is because existing tools weren’t mature yet or community standards hadn’t fully developed. And some of that is because we had our own opinions on how these things should work in the specific environment Ionic apps operate.
Over the last year, we’ve reflected on the state of the frontend web development world, and we’ve adjusted the understanding of our position in the frontend ecosystem and how we intend to work with existing framework communities and toolchains moving forward.
Let the framework do its job
One of the core changes Ionic is making is moving from custom build tooling to using the official tooling for each Framework we support.
With Angular, Ionic’s primary framework target, Ionic 4 has moved entirely to using Angular CLI, Angular project structure, Angular routing, Angular unit testing process, and more. We are no longer building our own build process (i.e. ionic-app-scripts), instead letting Angular do what it does best.
With React and Vue (official support coming soon!) the story is the same: Ionic will work with create-react-app and React Router on the React side, and Vue CLI/Router/vuex on the Vue side.
This is awesome for a few huge reasons. Selfishly, this means less complex code for us to maintain so we can focus on what we do best (UI). But primarily it means that Ionic developers don’t have to invest in non-standard tooling and their skills will match with what the rest of that framework ecosystem is using.
It also means that Ionic supports any new updates to a given framework immediately (in general). No more waiting on us to support version N of framework X, it Just Works!
This doesn’t mean we will let our integration with major frameworks like Angular slide. Expect us to join the conversation around Angular development best practices, build educational materials on how to use the toolchain, and continue to invest in the community (see you at Angular Connect!)
What about Stencil?
Many of you know about Ionic’s new project, Stencil, built to help us generate Ionic 4’s web components using TypeScript, with a mixture of Angular and React coding patterns.
We built Stencil primarily to achieve the goal laid out here: support all frontend web technology and frameworks with our agnostic core of UI components.
Over the last 12 months, we haven’t always communicated that vision effectively. Our goal is not to remove the need for frameworks. We think frameworks solve many problems that projects like Stencil don’t and never will. We are excited by the idea that many apps can be built with just a collection of web components, but we don’t think that approach needs to replace any existing approaches.
I want to remind everyone that using Stencil will never be a requirement to use Ionic, and Stencil is not a dependency of Ionic. Instead, we will use Stencil only as a tool for ourselves to build and ship components that can be easily consumed in every framework, regardless of how well that framework supports Web Components (looking at you, React 👀).
If your team wants to explore building web components, Stencil is a great option and given that it is core to our toolchain, expect it to be maintained and supported for years to come.
One UI Framework for Everyone
A few weeks ago I shared a little blurb of our high level mission at Ionic. At the core, we want to be the best solution for teams building rich, interactive apps for multiple platforms, and using web standards to do it.
This mission says nothing about what tools and frameworks should be used. That’s up to you! We will do our best to support whatever you want to use, and we will have some opinions for teams that want a helping hand.
Ionic will continue to invest in the web platform as our primary technology platform. We think it has incredible value today and will only become more valuable in the years to come. We also believe the web platform aligns best with what our users and customers need: one code base running on all the platforms they care about (mobile, web, and desktop), that is easy to hire for and easy to build with. Finally, we are excited about being able to decouple from the changes happening elsewhere in the ecosystem so we can continue to support new technologies and framework features when the great teams working on them ship.
Add this all up, and we believe we can achieve these goals best by working with the existing ecosystem rather than forcing users to conform to our worldview, and so we’re going to do just that.