DEV Community: Daniel Weinmann

Introducing Flashboard: Instant Admin Panels for PostgreSQL

Daniel Weinmann — Mon, 02 Sep 2024 18:05:27 +0000

Have you noticed that building admin panels and internal tools is often neglected in favor of user-facing features? There's always too much to build and too little dev time, so it's understandable.

But at Seasoned, we hate offering a subpar experience to our clients' internal team while providing an amazing UX to the final users. Yet, we also refuse to make our clients pay for a custom admin panel when the end-user is the priority.

That's how Flashboard was born. We made building admin panels instantaneous so we don't have to choose between internal teams and the end user. And now that we have it, we decided to share it with you all!

Flashboard is available today for anyone to use. Connect to your PostgreSQL database, select the tables and fields you want to manage, and that's it! You're up and running within seconds.

Check out this quick demo:

I like what I see, but is it safe?

Yes! Your database credentials are encrypted with a key only you own. Even our team can't access them, let alone potential attackers.

OK, but can I test it without connecting to my real database?

Yes, you can. There's an option to "Create a demo panel" to play around with a demo database.

Nice, how much does it cost?

It's free! 🎁

And we plan to maintain the free plan in the long run. We'll explore charging for advanced features soon, but right now everything is free.

Play around with it at getflashboard.com

Molecules of business logic from tiny atoms

Daniel Weinmann — Tue, 25 Jun 2024 17:32:07 +0000

Some people asked me how to design their business logic after reading my article on keeping your business code separate from the rest. Here's an example of how we do it.

Imagine we have an online shop with a page for our Magical T-Shirt. On that page, we want to show all the product variants (small, medium, large) plus product information, like name. Your customer has applied a coupon code to their cart, so we must also show the discounted price.

Functions with a verb in their name

At Seasoned, we prefer functions with verbs in their name to classes and objects. So the first thing we'll do is create a function called getProductPageData that gathers all the information we need.

It will look completely different by the end of this article, but this is how it starts:

function getProductPageData(productId: string, couponCode: string) {
  // This would come from your database
  const product = { id: productId, name: 'Magical T-Shirt' }

  // This would come from your database
  const variants = [
    { productId, sku: 'small', name: 'Small', price: 8.99 },
    { productId, sku: 'medium', name: 'Medium', price: 10.99 },
    { productId, sku: 'large', name: 'Large', price: 12.99 },
  ]

  // This would come from your database
  const coupon = { code: couponCode, discount: 10 }

  return {
    product,
    coupon,
    variants: variants.map((variant) => ({
      ...variant,
      priceWithDiscount: variant.price * (1 - coupon.discount / 100),
    })),
  }
}

A folder dedicated to business logic

This code lives in a business folder and it should not have any knowledge about the framework you're using. Ideally, it should work as well for a mobile app as it does for a website. All the code dealing with platform-specific APIs or framework-specific implementation should live elsewhere.

Dealing with errors

Our getProductPageData function could fail. For instance, every query we make to our database can throw an error. So far, our code does nothing to deal with that.

Instead of adding multiple try/catch statements, we'll establish a pattern to deal with exceptions. For that, let me introduce you to Composable Functions, a library we created to make function composition easy and safe.

Composable functions do much more, but they help us deal with errors by doing the try/catch for us and returning the result in a type-safe way. Imagine this silly function call:

const getLength = (text: any) => text.length

getLength(null)
// TypeError: Cannot read properties of null (reading 'length')

If you wrap it with composable, it will never throw an error. Instead, it will return the result with the exception, like:

const getLength = composable((text: any) => text.length)

const result = await getLength(null)
// result equals
// {
//   success: false,
//   errors: [<Error object>]
// }

If it succeeds, it will return the result of the function inside data:

const getLength = composable((text: any) => text.length)

const result = await getLength('abc')
// result equals
// {
//   success: true,
//   data: 3,
//   errors: []
// }

This pattern forces us to remember to deal with errors. To access result.data, we must first check if result.success is true. Otherwise, TypeScript will give us an error.

This is how our getProductPageData function looks like when wrapped with composable:

const getProductPageData = composable(
  (productId: string, couponCode: string) => {
    // This would come from your database
    const product = { id: productId, name: 'Magical T-Shirt' }

    // This would come from your database
    const variants = [
      { productId, sku: 'small', name: 'Small', price: 8.99 },
      { productId, sku: 'medium', name: 'Medium', price: 10.99 },
      { productId, sku: 'large', name: 'Large', price: 12.99 },
    ]

    // This would come from your database
    const coupon = { code: couponCode, discount: 10 }

    return {
      product,
      coupon,
      variants: variants.map((variant) => ({
        ...variant,
        priceWithDiscount: variant.price * (1 - coupon.discount / 100),
      })),
    }
  },
)

Extracting smaller functions

Over time, as we get to know our needs for reusing specific parts of code, we start to extract smaller functions. However, be careful not to extract them too early, as the wrong abstraction is worse than code duplication. In other words, avoid hasty abstractions and only extract smaller functions when the right abstraction emerges.

In our example, let's imagine we have to get product info in multiple places of our codebase. We also need to list a product's variants, get coupon info, and apply a discount to a list of variants on several occasions for different business purposes.

With that, the following tiny atoms of business logic emerged:

const getProduct = composable(({ productId }: { productId: string }) => {
  // This would come from your database
  return { id: productId, name: 'Magical T-Shirt' }
})

const getVariants = composable(({ productId }: { productId: string }) => {
  // This would come from your database
  return [
    { productId, sku: 'small', name: 'Small', price: 8.99 },
    { productId, sku: 'medium', name: 'Medium', price: 10.99 },
    { productId, sku: 'large', name: 'Large', price: 12.99 },
  ]
})

// Usually, this type would come from your database lib
// You don't need to understand it now, but it's the type for
// an individual variant.
type Variant = UnpackData<typeof getVariants>[number]

const getCoupon = composable(({ couponCode }: { couponCode: string }) => {
  // This would come from your database
  return { code: couponCode, discount: 10 }
})

const applyDiscountToVariants = composable(
  ({ variants, discount }: { variants: Variant[]; discount: number }) =>
    variants.map((variant) => ({
      ...variant,
      priceWithDiscount: variant.price * (1 - discount / 100),
    })),
)

Aside

— Why are we using a single object as the argument for our small functions? Why is it { productId }: { productId: string } instead of simply productId: string?

— Thank you for noticing! We'll get to that soon :)

Using our atoms

Now let's rewrite getProductPageData to use these atomic functions instead of duplicating their code. An initial version looks like this:

const getProductPageData = composable(
  async (productId: string, couponCode: string) => {
    // Notice that composable functions are always async
    const productResult = await getProduct({ productId })

    if (!productResult.success) {
      throw new Error('Could not find product')
    }

    const product = productResult.data

    const variantsResult = await getVariants({ productId })

    if (!variantsResult.success) {
      throw new Error('Could not find variants')
    }

    const variants = variantsResult.data

    const couponResult = await getCoupon({ couponCode })

    if (!couponResult.success) {
      throw new Error('Could not find coupon')
    }

    const coupon = couponResult.data

    return { product, coupon, variants }
  },
)

Well, it's not looking that good yet. The good part is that composable functions force us to deal with error cases, so we had to make all the checks above. But there is a better way. If we rewrite the function to use fromSuccess, it looks much cleaner:

const getProductPageData = composable(
  async (productId: string, couponCode: string) => {
    const product = await fromSuccess(getProduct)({ productId })
    const variants = await fromSuccess(getVariants)({ productId })
    const coupon = await fromSuccess(getCoupon)({ couponCode })

    return { product, coupon, variants }
  },
)

It's starting to look better! fromSuccess does the check and throws the error for us when a function fails.

Going molecular

We could consider our work done with the code we have so far. It is doing what it is supposed to do, it's broken down into tiny atoms of business logic, and it's dealing with errors properly.

But we believe there's an even better way to bond our atoms. Right now, they're not truly bonded. They are being used separately, one at a time, and we're manually piecing together their results. If we use function composition, we can bond our atoms to create molecular functions.

Before we get back to our online shop, let's go over the basics of composition with our silly getLength example from the beginning of the article.

Imagine you want to get the length of a string but return it as a string. This is the result we're expecting:

const result = await getLengthAsString('abc')
// result equals
// {
//   success: true,
//   data: '3', ⬅️ Notice this is a string 👀
//   errors: []
// }

Our initial implementation of getLengthAsString could be:

const getLengthAsString = 
  composable((text: string) => String(text.length))

But we already have a numberToString composable function that converts a number to a string, so we want to use it:

const numberToString = composable((number: number) => String(number))

const getLengthAsString = composable((text: string) =>
  fromSuccess(numberToString)(text.length),
)

Now it's time to add composition. For composing functions, we need combinators. Combinators are functions that receive composable functions as input and return another composable function.

We're going to talk about a few combinators in this article, and the first one is pipe. pipe creates a chain of composable functions that will be called in sequence, always passing the result of the last function called as the input to the next.

Here's our getLenghAsString using pipe:

const getLength = composable((text: string) => text.length)
const numberToString = composable((number: number) => String(number))
const getLengthAsString = pipe(getLength, numberToString)

const result = await getLengthAsString('abc')
// result equals
// {
//   success: true,
//   data: '3', ⬅️ It is a string 🎉
//   errors: []
// }

Why is it better this way?

There are a few reasons why the version with pipe is better than the one with fromSuccess:

First, it's easier to change. Want to return both the numeric and the string versions of the result? Just add a map to the composition:

const getLengthAsStringAndNumber = pipe(
  getLength,
  map(numberToString, (result, input) => ({
    asNumber: input,
    asString: result,
  })),
)

const result = await getLengthAsStringAndNumber('abc')
// result equals
// {
//   success: true,
//   data: { asNumber: 3, asString: '3' },
//   errors: []
// }

Notice how we didn't have to change anything in our atomic functions. They remained the same. Only the composition (our molecule) changed.

Second, it's easier to test. You can write one set of tests for getLength, another one for numberToString, and just enough tests on getLengthAsString to make sure the composition worked.

Lastly, all compositions are type-safe from end to end. For example, if we try to pipe a function that returns a string into a function that expects a number, the composition will fail.

Back to our online store

Now it's time to create our getProductPageData with compositions. Here's one way of doing it:

const getRawData = collect({
  product: getProduct,
  variants: getVariants,
  coupon: getCoupon,
})

const getRawDataWithDiscount = map(getRawData, (data) => ({
  ...data,
  discount: data.coupon.discount,
}))

const getRawDataWithDiscountedVariants = sequence(
  getRawDataWithDiscount,
  applyDiscountToVariants,
)

const getProductPageData = map(
  getRawDataWithDiscountedVariants,
  ([{ product, coupon }, variants]) => ({ product, coupon, variants }),
)

It looks daunting, I know. But let's walk through it together, one step at a time.

First, we collect all the raw data we need on getRawData. This function receives { productId: string; couponCode: string } and returns an object with product, variants, and coupon.

Then we map the raw data on getRawDataWithDiscount. This function receives the same { productId: string; couponCode: string } input and returns an object with product, variants, coupon, and discount.

The reason we add the discount to the root of our object is because our applyDiscountToVariants takes a list of variants and the discount as input, not the coupon. In the real world, it's very common to have an atomic function that does what you need but require you to "massage your input" a little in before you can call it.

Next, we sequence getting the raw data with discount and applying the discount to our variants on getRawDataWithDiscountedVariants. It also receives { productId: string; couponCode: string }. Then, it returns a tuple with the result of getRawDataWithDiscount as the first element, and the result of applyDiscountToVariants as the second.

Finally, we map the result of getRawDataWithDiscountedVariants to get rid of the tuple and return an object with the final data structure we want on getProductPageData.

Calling our function

Now you can call your business function from the outside world. This usually means calling it from inside a controller, a loader, or any other method for gathering data.

const result = await getProductPageData({
  productId: '123',
  couponCode: '10OFF',
})

if (!result.success) {
  // 🚨 Any errors thrown in any of the composed functions
  // will be on result.errors
  result.errors.forEach(error => console.log(error))

  return
}

console.log(result.data)

// {
//   product: { id: '123', name: 'Magical T-Shirt' },
//   coupon: { code: '10OFF', discount: 10 },
//   variants: [
//     {
//       productId: '123',
//       sku: 'small',
//       name: 'Small',
//       price: 8.99,
//       priceWithDiscount: 8.091000000000001
//     },
//     {
//       productId: '123',
//       sku: 'medium',
//       name: 'Medium',
//       price: 10.99,
//       priceWithDiscount: 9.891
//     },
//     {
//       productId: '123',
//       sku: 'large',
//       name: 'Large',
//       price: 12.99,
//       priceWithDiscount: 11.691
//     }
//   ]
// }

As you can see, this version of getProductPageData receives an object with the product id and the coupon code instead of two arguments like we had on our initial version.

We commonly do that because it makes it easier to compose the functions. That's why our atomic functions also receive an object. For example, on getRawDataWithDiscountedVariants we can get the result of getRawDataWithDiscount and pass it to applyDiscountToVariants without transforming it, even if returns an object with more keys than what applyDiscountToVariants needs.

If our atomic functions expected multiple arguments instead of an object, we could transform our data at every stage to be exactly what the next function needs. But I think this is a good pattern that leads to more readable compositions.

Thinking in composition

It takes a while to adjust our thought process to think of compositions instead of a sequence of function calls and if statements. To be honest, I'm not totally there yet. But the more I use composition, the more I write code that's maintainable and easy to test.

It will take you and your team some time and learning curve but once you start thinking in compositions, you can skip the intermediate functions above and write your compositions inline:

const getProductPageData = map(
  sequence(
    map(
      collect({
        product: getProduct,
        variants: getVariants,
        coupon: getCoupon,
      }),
      (data) => ({
        ...data,
        discount: data.coupon.discount,
      }),
    ),
    applyDiscountToVariants,
  ),
  ([{ product, coupon }, variants]) => ({ product, coupon, variants }),
)

That's it. I hope this method of writing business code helps you give business logic the priority it deserves and create more resilient codebases 🤓

Let me know how it works for you!

A feature needs a strong reason to exist

Daniel Weinmann — Wed, 12 Jun 2024 19:33:22 +0000

We're working on a product with an amazing UI for managing projects. Think Trello but different 🙃

It offers drag and drop, in-place editing, keyboard navigation, etc, all with optimistic UI. The code is well-written and fairly organized, but it is inherently complex.

Recently, we wanted to add a "select multiple tasks and drag them all together" functionality. Before jumping into the code, we did some shaping to devise a solution that would not conflict with all the other user interactions we have.

Then it was time to do a spike to understand how hard it would be to build it. Before I even started coding the prototype, I knew it would make our codebase much more complex. We already have a lot of state management for the drag and drop, in-place editing, and optimistic UI. Adding another layer of state on the same UI would make it exponentially harder to grasp.

There is nothing inherently wrong with adding complexity. If the benefits outweigh the costs by a good margin, we're all for it. The problem in this case is that there is not yet a strong reason for this feature to exist.

The idea came up when we realized we had some time on our hands and wanted to use it to build something. And we feel this feature will be very useful in some cases. But if we're being honest, we still don't know how much so.

There is no user feedback indicating they're losing time dragging multiple tasks one by one. We only have our own experience with the app and a hunch. Nothing wrong with that either. Many of the best features out there were based on hunches and zero user feedback.

Still, something felt off while spiking. It doesn't feel like this hunch is worth the added complexity at this point. Maybe as we frame the problem better, it will.

That's the beauty of a method like Shape Up. It provides great checkpoints where we can decide whether to go ahead with a project or not.

If the stages of development (framing, shaping, building) were not that clear, we might have moved forward with this feature and ended up with a much more complex codebase without a strong reason for it.

Keep your business code separate from the rest

Daniel Weinmann — Mon, 10 Jun 2024 18:28:10 +0000

One of the best things you can do for a codebase is to keep the business logic separate from everything else.

Imagine you have an app from 20 years ago, written in an old framework no one uses anymore. Thousands of people rely on it for their jobs, because it is the only app that deeply understands how this particular industry works.

The user experience could be so much better but the app works and no competitor beat them yet. Now you're tasked with bringing this giant to the modern days by adopting current technologies to improve the overall experience.

You take a quick look at the code, and being a seasoned dev with a sharp sword, you prepare for war. You know it's going to take your team a long time and it's going to be messy. Why?

Because most of your time will be spent untangling the logic that needs to stay from the parts that need to go. And what needs to stay is the business logic. The rest is old framework code no one cares about.

Now, while you untangle this mess, are you going to leave another one for future generations? Of course not. Because you know the current framework you're using now will undoubtedly be replaced by something else in a decade or so, you will do your best to keep the business code separate from everything else.

To do so, ask yourself the following question at all times:

If I were to migrate to a completely different framework tomorrow, would I be able to take the business logic with me?

If the answer is "yes", you're writing code that lasts. If not, you're borrowing from the future and some refactoring is in order.

Get out of state management hell with automatic revalidation

Daniel Weinmann — Tue, 09 Jan 2024 20:47:41 +0000

React Router and Remix introduced automatic revalidation of data after mutations. I believe this is a paradigm shift and boosts productivity like nothing else available today.

In this article, I'll show you step-by-step why this matters and how to get out of what I call "state management hell" with the help of React Router or Remix.

Imagine you have a React SPA with a top bar. It shows the avatar of the signed-in user in the right corner or a "Sign in" button if there's no current user.

Your login page lives at "/sign-in" and includes the top bar and a form with email and password right below the top bar. After a successful login, the user is redirected to the home page at "/".

Now, imagine you are not using a library to handle routing. You have a simple router component that monitors the window's location and decides what to render based on that.

Because you know all pages will render the top bar, it lives in a separate component that is rendered higher in the hierarchy before your router component.

What happens after a successful login? The router component detects the change in the location and renders the homepage component. But there's something wrong.

Since the top bar is above the router in the render hierarchy, it will not be re-rendered. Thus, the user avatar will not appear, and the UI will be stale. You have to reload the page to see the avatar. I bet you're thinking of an app with this kind of bug right now 🙃

There are several possible solutions to this problem, and we'll talk about how React Router and Remix address this in a minute. But before that, let's look at the most common approach today: centralized app state.

You add the current user state to a React Context or state management library, read from it on the top bar, and write to it after a user signs in. Done. No big deal, right?

Wrong. It's a huge deal. You now have to make sure all devs in your team keep the structure of the state in mind and remember to update it when necessary.

More importantly, you must spend a lot of time designing the state. In the example above, we only need to know the current user. But a real app has hundreds or thousands of pieces of data as part of the state.

You have to constantly make the trade-off between separation of concerns and centralization in state design. If you put everything in one place, the devs need to keep a big structure in mind at all times.

If you have separate states (auth, clients, orders, etc), the team should remember which states to update after each mutation. Damned if you do, damned if you don't.

As apps grow, most bugs are related to state management. Diagnosing, fixing, or preventing them becomes costly, with the application state adding a ton of cognitive load to teams.

New features take longer to be delivered and often break unrelated functionalities. Separate teams need to coordinate closely even when working on different domains.

This is what I call state management hell!

Enters automatic revalidation

So far, we've been only talking about the state that lives in the browser. But if our app needs to store and fetch data from any kind of server, it also has a state on the server side.

In our example with a centralized state, both the browser and the server need to know who's the current user. Once we sign the user in, the server stores its state somewhere, and the React SPA somewhere else.

And then, every time we change the server state, we also have to update the browser state. Having two sources of truth is the origin of our state management hell.

Whenever we have two sources of truth, synchronization issues emerge over time. But unfortunately, we cannot avoid having separate browser and server states in today's world.

Due to the nature of web browsers, the only way to have a single source of truth is to do a full page refresh every time we make a change to the state. If we do that, the state lives 100% on the server.

But it's the 2020s, and we need a better UX than that. That's where abstractions like libraries and frameworks are useful. If we can't avoid having two sources of truth, let's at least hide this complexity from developers most of the time.

That's what automatic revalidation does. It lets us code as if there were a single source of truth, even though behind the scenes, there are two.

Let's walk through our example again, but now it uses React Router 6.4+ or Remix. Our top bar is rendered by a root route that will have all other routes nested inside of it.

Instead of relying on our custom application state, we'll use a loader on the root route to fetch the current user from the server and display it on the top bar.

Then, on the sign-in route, we'll use a Form and an action to sign the user in. The action does the authentication and redirects to the home page.

Because we used an action, React Router knows we are probably changing something on the server state. Then it does something magically simple: it runs all loaders on the page again.

That makes the root route re-fetch the current user from the server and re-render, now with the correct avatar at the top bar.

By assuming that if we're running an action we probably want to re-fetch all data on the rest of the page, Remix and React Router are solving our problem in the best way possible: by making it disappear!

Of course, there are exceptions. Sometimes our loaders take too long to run, and we want more granular control over what gets revalidated.

All of that and more is covered by both frameworks. Think of automatic revalidation as an excellent default that you can use for 90% of use cases and override whenever you need to.

But even if you have to do a little state management for 10% of your use cases, you're out of state management hell. Welcome!

Why React Router's new data APIs boost productivity

Daniel Weinmann — Thu, 21 Dec 2023 21:13:22 +0000

We've been using Remix at Seasoned for about two years now. And we consistently found that our teams are more productive with it.

In the past year or so, we also worked on a big React Router SPA to leverage the new data APIs. And the impact was very similar: a huge improvement in our team's throughput!

In this article, I'll share why React Router made that happen. There are many other benefits to adopting loaders and actions in your SPA, like page speed and better UX. But I'll focus on developer productivity today.

Before using the new data APIs, about two-thirds of our time was dedicated to managing our data fetching/mutation state. There are two main reasons for that:

When managing state at the component level, we need to check if the data was already fetched, render a pending UI if not, and render our component when the data is ready. A similar approach is necessary for dealing with errors. For every component.
Whenever we mutate data, we need to manually invalidate any state that became stale due to the changes. It's very hard to remember which states to invalidate at each mutation, and most of our bugs had to do with someone forgetting to revalidate something. And because we didn't know which component invalidated which state after each mutation, it took us a long time to diagnose these issues.

These challenges are not solved by TanStack Query (FKA React Query), SWR, and most similar libraries. But React Router 6.4+ makes them disappear!

Here's how we solved them with React Router:

When you use a loader, your component is only rendered after the data is fetched. So you don't have to worry about pending UI. In our app, we rely on a global pending UI for most interactions, and that's it. For dealing with errors, we rely on error elements and response-throwing to keep our component focused on the happy path.
React Router revalidates all loaders on the current route after each action, so we don't have to do any state management for mutations. Zero.

By eliminating these two problems, we reduced the cognitive load of our devs by an order of magnitude, I believe. Having to think so much about our app's state was slowing us down. And if you're not taking advantage of the data APIs yet, I bet it's dragging you down too!

The software development paradigm for the 2020s

Daniel Weinmann — Tue, 19 Dec 2023 15:43:10 +0000

It's hard to see among all the new frameworks promising the world, but a new software development paradigm emerged in the last few months. And it makes building software better and cheaper.

Please follow me as I try to lay it out in a non-technical way, as well as its ramifications for businesses.

What do I mean by paradigm?

A paradigm is a way to see the world that creates distinct patterns from the ones that existed before. In software development, this usually means that a new generation of coders will see things in a different light and create technologies we couldn't anticipate.

Before frameworks like Ruby on Rails or Laravel existed, devs felt it was common sense to organize things in a way that looked chaotic after we got used to the new paradigm they introduced.

Before React popularized reactive programming and made it the norm for frontend work, we were all used to working 10x more to ensure a great user experience.

The current status quo

Since the 2010s, the most common paradigm has three main characteristics:

It relies on a separation between the backend and frontend, with each of them commonly having separate teams and tech stacks. That was not the norm in the 2000s when frontend and backend coexisted within the same codebase.
It expects rich user interfaces with real-time updates, no full-screen refreshes, and complex interactions. That was virtually impossible before the 2010s, but we got used to it fast.
Developers spend the bulk of their time on synchronization between what the client knows (e.g., a web browser, a mobile app, an IoT app) and what the server knows (i.e., our backend, typically in the form of a REST or GraphQL API). Whenever the client wants to make a change, it has to inform the server, show a loading indicator, and then update the whole app based on the response from the server.

A new paradigm emerges

I'll save the story about how we got to it for another article, but here are the characteristics of the new paradigm:

It expects even richer user interfaces than the current status quo.
It doesn't require separation between backend and frontend work but allows for it when necessary. Going one step further, it facilitates the integration of backend and frontend code in the same codebase, ideally the same files.
It automatically synchronizes what the client and the server know for most cases while still allowing for manual synchronization when needed. That is the disruptive innovation right there. Anyone who has tried to automate this while still maintaining rich UIs knows how big of a challenge this is. But we finally got there.

Remixing our stack

I'm sure someone will point out an obscure technology that implemented something similar before. But, for me, credit for this innovation goes to Ryan Florence and Michael Jackson, creators of Remix.

While React's server-side rendering capabilities and frameworks like Next.js had already solved the synchronization between client and server when loading information, Remix was the first to solve it when changing information. And when I said that devs spend the bulk of their time syncing client and server, most of the work happens when we need to change something rather than when loading data.

But, just like fish might not know what water is, it might take us a while to recognize the importance of this innovation. For most devs today, this synchronization doesn't feel like unnecessary work: it just feels like work.

But as people realize this is a paradigm shift, many other frameworks and libraries will introduce their version of this innovation. And a new generation of engineers will look at us in bewilderment when we tell them we used to have to do all this.

Opportunities for businesses

This new paradigm is not conceptual. It's already brilliantly implemented in Remix. Right now, companies who adopt Remix can expect:

At least 3x in productivity while building better apps: we've measured this at Seasoned for six months and consistently delivered better software faster.
Happier, more engaged developers: the unexpected relief from not having to do gruntwork they weren't even aware of is life-changing for devs.
More flexible teams: all your devs can now work on the same tech stack without separating backend and frontend. Even if you have specialization in your team, it's not mandatory, and there's a lot of overlap between functions.
A passionate untapped talent pool: more devs are dying to work with Remix than there are Remix positions. That will not last, but if you get onboard early, you'll have an unfair advantage for a while.

(Originally posted on August 17, 2022)