The Challenge

Converting Jupyter notebooks into production web applications is a common challenge in modern development workflows. While the backend transition is manageable due to shared Python foundations, the frontend handoff often becomes a bottleneck. Let's look at why this happens and propose a solution that can streamline the process: bringing your component library into your notebooks.

Through the course of my work at Nitro Bio, I've been tasked with converting many researchers' notebooks into production-grade web applications. The backend work can be painful, but since the notebook and the backend runtime are in Python, there's at least a shared language for the software engineer and the researcher to discuss any issues that come up. This is usually not the case for the frontend work.

It's (understandably) rare to come across a researcher/data scientist who has put "character points" into frontend or design skills, and so the notebook that is handed off to a software engineer typically won't capture many ideas of what the UX of the productionized app should be. In truth, the software engineer may not have the UX skills either, and so a designer is brought in to help. But the designer probably doesn't have the domain OR engineering knowledge to have a good feel for the UX either!

Meetings, design reviews, and other processes are brought in to make all of this work, and after a ramp up period, it usually does. But what if we could get further down the development lifecycle before bringing all of this process in?

The Solution: Shared Components

The answer is to empower your data scientists by giving them access to the same component library your software engineers already use - built with design tokens your designers have already curated. This approach lets researchers build working prototypes that demonstrate not just the computational logic, but also the actual user experience of a production application.

Your software engineers and designers (hopefully) already understand the benefits of UI components. Software Engineers like them because they're easier to develop, extend, and fix. Designers like them because they help keep the UI feeling consistent. Your Data Scientist will like them because their prototype will look and feel closer to the final product, and they can find ways to improve the UX earlier in the development lifecycle.

The (Technical) Challenge

These UI components are typically built by software engineers for other software engineers to consume from a public repository like npm or an internal corporate repository. Unfortunately, these components are usually built with a different technology stack than the one used in the notebook, so the data scientist can't use them directly. Some extra work is needed to make these components available to the data scientist.

Next: The (Technical) Solution

Breaking down the divide between notebooks and web apps isn't just about better tooling - it's about enabling better collaboration and faster iteration. By bringing your component library into your notebooks, you can catch UX issues earlier, reduce handoff friction, and build better products faster. In the next post, I'll show how to take a React component from a component library and make it available to a Jupyter notebook.