How and Why We Use a Component-Based Framework on Our Web Platforms
By John Schimmel and Louise Story
Imagine if drivers on a highway needed to understand the motor of every other car around them in order to change lanes? Even worse, imagine if a break-down in one motor affected another car 1,000 feet away?
Sounds impossible, right? Yet, for a long time, that’s how web pages worked.
Fixing that metaphorical highway system is why The Wall Street Journal moved to a component-based framework across our web platforms.
The shift is part of a broader evolution in our approach to technology. Over the past couple years, we have further embraced open web technology and standards and prioritized reusability across our work. Our engineers and designers collaborated for faster — and sometimes automatic — integration with our design system. The results are faster, better product development … and better, fresher news experiences.
We’re accomplishing this by using a component-based framework across our web platforms. These components let parts of our page operate like separate cars on the highway: they’ve got their own motors and they know how to stay in their lanes.
Components aren’t something we discovered, and they aren’t something that’s totally new at our company. But there’s this thing that happens when enough of your engineering teams get behind the same thing. That thing is called momentum, and that’s happened with our shift to components.
The component-based framework we are using is called React. Developed by Facebook for its home page and released to the world’s open source community in 2013, React is a framework that allows developers to make components for web pages that can be shared across teams. Each component has everything it needs bundled inside, from design elements to its internal code. The framework allows engineers to quickly understand how a component works and how they can integrate with, or fix it, if needed. Using React, a web developer doesn’t need to overthink how to structure her code. With strong coding standards, she can work on a component without having to understand everything going on within our pages. And components are reusable, allowing them to be placed anywhere they are needed.
This description sounds rosy, but we didn’t go down this path without a lot of thought. Not all open source options have the right maturity for us to adopt them. As with everything in life, there are trade-offs to consider.
Benefits
Making New Hires Successful Right Away
As we’ve been growing our product development teams at The Journal, one of the things we have focused on is: How do we hire someone new and help them make an impact right away?
Component-based user interfaces provide an answer. You don’t have to be a computer science major to pick it up quickly. If you can learn the pattern, you can get things on screen faster, and the more things you get on screen, the more you learn. React makes it more approachable for people to get into programming — as opposed to learning everything about our pages just to get going. It consolidates where a programmer needs to focus and puts aside areas like cloud architecture or infrastructure for other teams.
This is important because the market for technology talent is tight. There are tons of companies hiring developers and one of the things we have to offer is the ability to see your work affecting our news experiences right away. It also makes it easier for people from other parts of the newsroom to contemplate moving into our unit.
More Stable Technology
Using an open-source framework like React allows engineers to build user interface components with programming techniques and best practices that are known by web developers all over the industry.
It means our tech is more stable because we’re using something that has been vetted by thousands of engineers from different backgrounds and has been tested in a way that we would never have the capacity to do.
React, for instance, has gone beyond Facebook and there is a whole community of developers committing code to it online. (There’s a similar framework available called Vue.js that is the main alternative to React. Both are JavaScript libraries.)
Faster Experimentation
One key upside of our teams all using React is that we can experiment much faster and roll out new features with fewer bottlenecks across our org. For instance, we have integrated our components with our product design system. Others have had design systems for a long time, but we built on the practice by moving from proprietary systems to open web standards.
With the actual design specifications — the colors, the approved look and feel — integrated into our framework, we don’t need so many Slack messages and meetings when we try new things. Any engineer can take a component out of our framework and know that it has already been vetted by design. This collaboration between engineers and designers came out of a grass-roots effort. A few engineers kicked it off without a mandate from the top.
Grass-roots, bottom-up innovation breeds excellent ideas and awesome new experiences for our audiences. Using a clear component framework gives engineers more freedom to try things out in limited spots on our pages without a lot of overhead, approvals or creating a slew of new dependencies. The result? More innovation, faster.
Convergence in Our Front End and Our Tools
The shift to component-based systems in user interfaces mirrors shifts elsewhere in our technology stack and in the industry. One important area where this is true is in our new content management system. We are building it in Wordpress, leveraging the Gutenberg editor, which is a block-based system based on React components. It has been great to see that as our front-end web engineers adopt React, they can now almost seamlessly build things in our CMS, including the interface for our journalists. We have found we can build a CMS block that looks a lot like the component that we will render on the web side. In fact, we are even able to reuse some of the code and save time. We are seeing a path to having block-level tooling for many of our journalism tools.
All this will unlock a lot of innovation — from both our engineers and reporters.
Tradeoffs and Drawbacks
Components do have some drawbacks and we are keeping an eye on these.
Keeping up with updates
The React ecosystem changes frequently and it often feels like an updated React feature or design pattern will arrive just as we are finding our pace. The question becomes “Should we try to upgrade?” and “If we wait to upgrade, will it be more work when we finally update our components?” While we want consistent updates for security reasons, updating React for new features always involves a balancing act of finding time, estimating the benefit and trying to predict the future effort required to update all our components.
Servers still exist
React is a frontend user interface component library, but we still need to offer the best solution to deliver customized/personalized data for users. Do we have the webpage rendered on the initial request via the server or do we have the frontend load first, then make a request to fill custom user data? Using React, developers are left to decide how loading dynamic data is implemented and picking a solution will greatly affect how a web application is designed.
Plenty of alternatives
React is one of the most popular web UI frameworks but there are plenty of alternatives that offer similar capabilities and patterns. Selecting a framework requires a “buy in’’ from a team that might be hard to separate from in the future. Vue.js, Svelte, Angular, Ember and others are all frameworks that could be incorporated into our work. They all provide a component-based development environment and vanilla web components, which are supported by all modern browsers. So why not pick one of these? Some frameworks are smaller in size and complexity, some are documented, some have been held up as the solution to the problems of the other frameworks. But our teams have expressed support for React in our ecosystem after discussing the alternatives.
And so…
This is where we are today: an organization embracing components. As technologists, we’ll always be in transition, journeying to something better.
John Schimmel is a WSJ VP of Engineering; Louise Story is the WSJ’s Chief News Strategist and Chief Product & Technology Officer. Dion Bailey, WSJ VP and Head of Technology and Architecture, also contributed to this post.
