React or Retool?

Twenty years later, developer tools have evolved by leaps and bounds. Today, tools and techniques like hot module replacement, deploy previews, and even AI-powered pair programmers have become commonplace, eliminating hours of toil for developers. Getting a website in front of a customer was once an arcane task that required days of work; today, thanks to improved web hosting services, web frameworks, and an Internet stuffed full of helpful tutorials, it’s the end of a programmer’s first day of learning to code.

We think Retool is part of this sea change in developer tools. By providing higher-level primitives and visual development tools purpose-built for CRUD apps and business software, it’s possible to dramatically increase the amount of custom software you can build. Combined with other emergent developer tools, Retool makes individual developers faster and more productive than ever.

While the promise of developer tools has never been greater, selecting the right tool for the task at hand has become increasingly difficult with so many powerful options. At Retool, we often help technical leaders decide how and when the Retool platform might fit into their technology stack, and understand how it works alongside the web development tools and platforms they already use. The answer is usually not “stop what you’re doing and use Retool for everything.” As with most questions in software development, the real answer is usually “it depends.”

In this blog post, we’ll examine the relative strengths and weaknesses of using Retool or more common web development tools (like React, which we’ll use occasionally as a proxy for your favorite front- and back-end web development frameworks). When deciding how to build the internal tools your teams need, there are important trade-offs to consider. Thankfully, using React or Retool is not a binary choice—for most non-trivial internal applications, assume you’ll use both software developed in Retool and custom-built web app components. The real trick is planning for how React and Retool will work together, not deciding whether to use one or the other.

Let’s start exploring how we can turn “React or Retool?” into “React and Retool.”

Let’s begin by describing the relative strengths and weaknesses of Retool and custom web app development in Django, ASP.NET MVC, Next.js, or your own favorite framework. We’ll start on the Retool side, where you might be less familiar with the package of trade-offs.

What Retool does well

Speed and iteration
The primary value of using Retool is how much faster it is than traditional web application development. It replaces hundreds (thousands?) of lines of boilerplate HTML, CSS, and JavaScript (none of which is specific to your problem domain) with a visual development environment, a standard component set, and intelligent defaults for common behavior in data-driven apps. For the CRUD apps and business software use cases Retool is built for, you can create working software an order of magnitude faster.

Orchestrating multiple data sources
Most internal apps serve as a way to manipulate or visualize data across multiple sources from a single pane of glass. Retool is built with this in mind, making it easy to configure your data sources and share/reuse data access logic across applications.

Domain-specific platform features
Because Retool assumes that you’ll be building internal tools, it also provides application services like authentication/SSO, audit logging, role-based access controls, and other features that make it easier to build for these use cases.

Batteries included
Retool provides an opinionated, all-inclusive set of developer tools and frameworks that all work together. Backend workflows, scheduled tasks, a PostgreSQL database, a native mobile app framework, and more are all available out of the box in Retool. Assembling these framework pieces from scratch in a traditional web application project would require pulling together (and managing dependencies for) hundreds of disparate tools.

What Retool does less well

Differentiated visual design
Retool’s built-in UI component set provides a clean look and feel by default, but won’t be differentiated for your company or brand without some additional work. That being said, we’ve been floored by what some customers have been able to build as branded external apps in Retool.

Complex user interactions
More elaborate user interactions (like drag-and-drop or touch gestures) are more difficult to implement in Retool and usually require using a custom component.

Responsiveness
Designing responsive layouts is difficult in Retool today. While it’s possible to conditionally show or hide component trees on mobile devices, these features are less powerful than the CSS media queries you’d have available in a pure HTML/CSS web app.

Complex component trees
For a variety of reasons, we recommend splitting up Retool apps into many smaller apps that all work together within the same nav structure. Very large, monolithic apps with complex component hierarchies can sometimes cause performance problems and be difficult to work on with a large team.

Now that we’ve explored some of the pros and cons with Retool, let’s explore the strengths and weaknesses of custom software development (which most developers probably understand well), with an eye toward comparing it to Retool.

What custom web apps do well

Pixel-perfect design
When you develop web applications from scratch, you have full control over the layout, styling, and interaction events in the UI. This level of control is useful for consumer-facing applications where your brand needs strong differentiation.

Complex user interactions
Having low-level access to APIs for animation and events enables developers to build complex interactions, like drag-and-drop, CSS animations, and touch gesture support. The more unique the user interaction, the more low-level API access you’re likely to need.

Full control of the stack
When you control every aspect of how your application is executed and deployed, you can deploy in any environment and work with any requirements or legacy systems your software needs to interact with.

Robust tools and workflows
Writing and deploying code has been done by developers in roughly the same way for decades. This means that the workflows (git flow) and tools (*nix utilities and IDEs) available to developers are plentiful and robust.

What custom web apps do less well

Development speed
New features in a custom web application are typically developed in sprint or release cycles that span days or weeks, making progress on traditional custom software costly.

Reinventing the wheel
Custom web applications often reinvent features that are not specifically scoped to their problem domain, like access controls, API gateways, and task scheduling. That, or they must include a complex web of dependencies to power those features.

Complexity
Even in well-written applications, there’s a tremendous amount of complexity beyond the actual business logic for the software being developed. Custom software stacks have hundreds of dependencies and frameworks that developers need to understand and keep up to date. Creating and maintaining custom software also requires hiring for specific technical skills that are expensive and relatively scarce.

Maintenance
A custom web application requires constant maintenance and monitoring. Without dedicated resources for keeping an application up to date, orphaned web apps become ticking time bombs, where problems and outages become difficult to recover from. No on-call engineer wants to figure out how an internal tool’s codebase works on the fly, in response to an incident, because of murky internal ownership.

Now that we have a rough understanding of what each development approach does well, we can consider one with the other, and better understand the cost of Retool as an abstraction layer for web development.

Custom web applications tend to be good at making hard problems solvable, but they also introduce enough overhead that solving smaller problems can become cost prohibitive. Retool inverts this, making relatively easy problems (like building CRUD apps and admin panels) trivial and fast, at the cost of easily supporting high-end complexity in the final solution.

The tension between power and productivity is common in software development, where developers often need to consider the costs and trade-offs of a layer of abstraction. In our case, the abstraction layer is Retool, and the layer being (mostly) abstracted away is web development as we normally do it in HTML/CSS/JavaScript (and the supporting cast of tools and frameworks). While there are certainly other reasons for doing so, developers will often choose to adopt an abstraction layer to increase their productivity—like outsourcing infrastructure to AWS, or payments to an API vendor like Stripe.

If an abstraction layer is working well, it improves productivity in the task it was designed to perform, especially for common use cases. As the complexity of a use case increases, the abstraction layer usually breaks down, sometimes becoming a drag on productivity relative to using the underlying software layer.

For some software and some abstraction layers, this inflection point may never come. Many web applications will never outgrow AWS or process so many payments that they should abandon Stripe. But for other abstraction layers (often those in pure software, like an object-relational mapper or cross-platform development tool), that inflection point usually comes sooner or later in a non-trivial project. Because of this dynamic, Retool has been designed with extension points and escape hatches that developers should expect to use for complex use cases. This means you never really have to choose between “React” (the custom web development stack you’ve become accustomed to) and Retool.

With the right plan and architectural approach, developers can realize the benefits of using Retool without giving up the flexibility of custom web app development, should that approach be required. I’ll call this approach a “hybrid architecture,” within which there are two primary configurations: using Retool as the primary UI and authentication provider, or using a custom web application as the primary UI and authentication provider. Let’s take a look at how and when you might want to use either approach in an internal tools project.

In this configuration, your end users sign in to Retool and access apps through the Retool UI. If you’re a Retool customer today, this is most likely how you use the platform. End users sign in to Retool using its built-in authentication or your company’s SSO, and you manage user access control with Retool’s built-in features for doing so.

When developing in this configuration, you should attempt to follow Retool development best practices, and keep individual Retool applications coherent and tightly scoped. When you feel that the business logic or UI you need to create exceeds what’s easily achievable in Retool, it’s likely time to create (or build on top of) a custom web application to supplement your Retool application(s).

In this scenario, you’ll integrate with your custom web application in a few ways. For more complex business logic, you can integrate a REST API or GraphQL layer from your custom web app as Resources in Retool. These resources can be configured to use custom authentication.

For complex UI components, you have two main extension points available in Retool apps. You can either embed a full HTML page in an iframe within a Retool app, or you can create a custom component that can optionally use scripts and stylesheets hosted or generated by your custom web app. The Retool application can then communicate with the client-side code running within the iframe to pass data back and forth.

When you’d want to consider this approach

This architectural approach is attractive if you’re reasonably confident that your need to develop custom UI components will be rare, or if your team lacks UI development capability. It’s not uncommon for Retool to act as the front-end development platform of choice for a technical team of mostly backend developers. (Note that this approach exposes your entire UI and UX to end users through Retool, which may make it a bit harder to have a strongly branded UI for an external audience.)

In this configuration, you also get to benefit from the maximum number of Retool platform features, like built-in authentication and access controls. If most of your data sources are exposed with modern interfaces (like REST or GraphQL APIs), it’s likely you could integrate them easily as a resource in Retool.

It’s also possible to implement a hybrid architecture where a custom web application acts as your primary UI and authentication provider, which then integrates with UI components and backend services developed and maintained in Retool. Your end users would visit and authenticate with your custom web app in a way that you control fully, end-to-end. Once authenticated, your end users would interact with UIs that are either built in Retool, or built custom within your web application.

Your web application would integrate with Retool in a few ways. For front-end components, you would use the new Retool Embed product to integrate Retool apps within your application. Your application would establish identity and permissions for the front-end Retool component using a server-generated token—if you’ve used other client-side SDKs that leverage JWT tokens, this pattern should be reasonably familiar. To leverage back-end services created in Retool Workflows (even just as a way to access Resources configured in Retool), you can make HTTP requests to workflows using their webhook URLs.

When you’d want to consider this approach

This is a “have your cake and eat it too” approach to melding Retool and custom web application development. You do retain much of the overhead and responsibility of building and maintaining a web application, which is a serious cost. However, you also maintain maximum control over which parts of your user experience are managed by custom code and which are outsourced to Retool. While there are many possible applications for this approach, we’ve seen early Retool Embed customers outsource small (or large) chunks of their application to Retool, like external partner portals and settings UIs.

You can also migrate to this architecture, which offers more granular control, from the Retool-first configuration described earlier. If you create many small Retool apps, an important best practice, you’ll find it easier to integrate these small apps into a React or other custom UI later on, should it be necessary to do so. Also, any Workflows or backend services you develop to support your Retool-centric app stack can be reused in this configuration.

There’s a time and place for every developer tool, and building real production software requires an understanding of the trade-offs between different architectural approaches. Retool offers a huge increase in productivity for internal apps and business software that’s focused on data and workflows. But as with any software abstraction layer, it’s possible you might reach the boundaries of what you can productively accomplish in Retool alone.

Fortunately, you can plan ahead for this inflection point. With the right architectural approach, you can use Retool when Retool works, and custom code when more granular control is necessary. Most non-trivial applications will probably call for some flavor of the hybrid approaches described here. Equipped with one (or eventually both) of these strategies, you can confidently embark on your next internal tools project, without worrying that you’ll paint yourself into a corner.

We'd love to hear about your experiences using Retool in a hybrid architecture. Join us on Discord to chat about it in real time, or post about your experience in our community forums. Thanks in advance for sharing your insights!