PatternFly 4 is generating a lot of excitement in the community. A more modular, accessible, and responsive design system will go a long way toward providing a better user experience. Anytime there is something new, that also generates a lot of confusion and uncertainty about the future. We wanted to share a bit more about how PatternFly 4 will impact existing users of PatternFly 3, and how we plan to address those concerns.
Why a full rewrite?
One question we’ve heard a lot is, “Why do you have to do a full rewrite?” The web community has been burned by forklift upgrades. The cost of rewriting a full web application using a new framework is usually daunting enough to prompt users to start looking at what else is out there. This is a normal reaction, but one that can completely decimate an existing community.
So why the full rewrite? PatternFly 3 is based on Bootstrap 3, and the Bootstrap team recently released Bootstrap 4. Since Bootstrap 3 is a float-based layout system and browser capabilities have evolved since it was released, it’s not a tenable long term solution. But migrating PatternFly to Bootstrap 4 would mean a full rewrite for our users, and we’d still be tied to another team’s release cycle with no guarantees that we’re not having this conversation again in a few years. Decoupling PatternFly from Bootstrap was the best decision we could make for our community.
What are we doing to support our community?
- We will not abandon PatternFly 3. We are committed to PatternFly 3 long term. This may mean the new PatternFly 4 structure will also have a PatternFly 3 theme, enabling people to maintain a consistent application while they work to migrate. Whatever the solution, we will continue to support all of the people still using PatternFly 3.
- We will provide a clear way to use PatternFly 4 alongside PatternFly 3. Using parts of PatternFly 4 should not destroy your application or force you to rewrite everything. Some applications are many years old now, and a full rewrite of things that are working just fine doesn’t make sense for many people. But we still want to make it possible for those teams to leverage and use new PatternFly 4 components. While this has proven technically possible, we also plan to investigate avenues for addressing the visual discrepancies that are introduced by mixing PatternFly 3 and PatternFly 4 to ensure the end user still has a good user experience.
- We will provide a simpler migration path for users of the framework repos. One additional benefit we have with PatternFly is the framework repos (PatternFly-React, for instance). They provide a surface that allows us to migrate the HTML/CSS to the new structure with minimal impact to users. While the package the component is coming from will change (allowing PatternFly 3 and PatternFly 4 components to live side by side), the interface should remain consistent.
If you have questions, please contact us via the communication channels listed on our community page. We are also active in the patternfly4-core and patternfly4-react channels on slack. Finally – we are tracking work around migration via GitHub and tagging them accordingly.