New York Public Library on Choosing React To Rebuild Website

The New York Public Library knew it needed a React-based framework for rebuilding its Digital Collections site. It chose Next.js.

The digital collections team at the New York Public Library owns everything that’s digital and not an ebook. That includes prints, photographs, videos and audio.

It has more than a million items on it and adds from the library’s collections every day, according to Emma Mansell, a software engineer at the New York Public Library.

“We have over 54 million items in our collection and you know the saying with great collections comes great responsibility,” she joked, riffing off the famous Spider-Man quote. “We have a really small team, we have limited resources, and our priority is access, almost to the exclusion of everything else.”

There are about 80 people in the whole digital department, including product managers and designers.

Accessibility Is Priority One

The library is focused on one goal with its apps and websites: Making the digital collection accessible.

“If it takes forever for an item’s metadata to load, then it’s really difficult to do research and the site isn’t performant,” Mansell said. “If a patron is googling items that are in our collections and what we have doesn’t even come up, then you can’t really say it’s easy to find what’s in our collection.”

The digital collections website allows items to be searched and cited. It displays the items with a lot of detail and, while it can be fun just to browse the collection, it’s a serious research tool, she added.

It’s not enough to optimize the home page for accessibility. The library has to be accessible across all its websites and in every sense of the word, Mansell said. Each component on the site is individually vetted for accessibility.

Every page of every website is tailored to meet Web Content Accessibility Guidelines standards, which are part of a series of web accessibility guidelines from the World Wide Web Consortium.

“All of these websites and apps are built to create access to our collections on every level,” she said. “Our tech needs to support a kindergartner reading their first book, as much as it does an academic who’s here to work at one of the top research institutions in the country today.”

Library’s Stack

Under all those library apps and websites, the New York Public Library has its own open source design system called Reservoir Design System. It’s a library of extensible React components, including the hero button, and each is vetted for accessibility, she added. The goal of this system is to provide a consistent visual experience for all users across the digital world of the NYPL, Mansell said.

But some of the library’s sites couldn’t use Reservoir because they weren’t compatible with React.

The old digital collections website was built using Ruby on Rails in 2013. Even though it was performant, its look was dated and it didn’t meet the library’s accessibility standards. From the font size to the color contrast, it needed work, she said.

They wanted to update the design of the site to be more modern and more accessible, and they wanted to do it using Reservoir. That meant they needed a React framework.

The site was also deployed with AWS, a decision made before Mansell arrived due to intense security concerns libraries have after the British Library was hacked in 2023, she said.

Next.js Versus Express

The team needed a Node.js framework to work with and settled on a choice of either Express and Next.js. They picked the open source Next.js because:

• Next.js is super lightweight and works out of the box, she said. Because the library’s digital collections team was small, they didn’t have the manpower to create elaborate custom configurations on the frontend.
• NYPL wasn’t upgrading its backend and that was significant, Mansell said said. “Some very smart engineers with a library science degrees already had built that for us,” she said. “We’re not messing with it. We wanted to just have something that was going to click into place.”
• Next.js also performs hybrid rendering eloquently, she noted, and NYPL also wanted to move to server-side rendering. “We wanted something that combines both approaches really nicely,” she said.
• Finally and actually most importantly, the NYPL digital collection team had developers with experience in Next.js versions 9, 10 and 11.

“Even though Next.js has actually changed a lot since those versions, we knew it was a great place to start and that we could collaborate and share knowledge as digital collections and other sites [of] the library move towards using Next.js,” she said.

Organizing the Migration

The first challenge was migrating the Ruby on Rails app into a new Next.js app, she said. To make that more manageable across the site, they split it along URL lines, so that phase one focused on the home and about pages.

“Originally, we had a vision of saying let’s take Ruby controller functions, one to one, and map them to Next.js API routes,” she said. “We dropped that pretty quickly.”

Ruby on Rails uses a MVC pattern, or Model-View-Controller (MVC) pattern, which is a web development design pattern that’s used to separate an application’s user interface, data, and logic. However, Next.js has a different approach to data fetching.

“Next.js data fetching was totally unfamiliar,” Mansell said. “I was coming in as a developer that was mainly experienced with React, and so it was maybe easier for me to get into that, but we had a lot of developers that had been used to working at Ruby on Rails.”

A Blank Next.js Slate for the Site

The team decided to start with a blank slate. At first, the team started with Page Router, but then the App Router came out of beta. That led to the next big decision for the team: Should they switch to the relatively new App Router?

“We were on the fence because we couldn’t use App Router in the way that it was really intended; that is to say, with server components,” she said. “If you’ve been listening very carefully, you might have seen this already coming down the pike, but we had a very big obstacle to using server components, which was our very own design system.”

“We believe this is the future of web development. … We have the pieces in place in this project to use server components once our design library is ready for them.”
– Emma Mansell, software engineer, New York Public Library

The digital collections team was migrating the site in order to use all of the already-built components of the Reservoir system — but none worked server-side because the design system is built on top of Chalk UI, a CSS and JS library. It required that everything be client-side, she explained.

“We ended up essentially recreating get server-side props in the App Router for every single one of our pages,” she said. “We’re basically grabbing the data on the page component, server component and passing it immediately into a page-level component.”

The team found there are other benefits in Next 14 beyond server components. For instance, Router caching has been huge for the digital collections team, which has universal headers and footers to help with page load time. The error boundary, which existed in a previous version, saved the team a lot of work with error handling, she said. Finally, the move improved documentation for the team, which found that loading and Suspense were a lot clearer in Next 14 docs.

But there was also symbolic meaning in the Next.js decision, she added.

“We’re a nonprofit. Things move pretty slowly, and so for us, it was worth it to open up that conversation of how can we use server components?” She said. “We believe this is the future of web development. … We have the pieces in place in this project to use server components once our design library is ready for them.”

For the library, it was a huge step to even have that conversation, she added, demoing the new site.

“It’s a lot prettier, a lot cleaner,” she said. “We’re really happy with the performance as well, but accessibility has also improved.”