DEV Community: BearStudio

Building a Full-Stack App Shouldn’t Feel Like Starting From Zero Every Time

Ivan Dalmet — Tue, 02 Dec 2025 16:45:06 +0000

At BearStudio, we start new web projects pretty often.
And every time, the beginning felt the same: we spent hours assembling the foundation before we could build anything meaningful.

Spin up a React and TypeScript project.
Add routing.
Choose a pattern for data fetching and mutations.
Set up authentication.
Install Prisma and wire migrations.
Bring in Tailwind.
Pick or build UI components.
Add linting, tests, CI, Docker.

By the time everything was in place, we still hadn’t shipped a real feature.
None of this was particularly difficult.

It was just repetitive, and it drained energy before the interesting work began.

That is what pushed us to create Start UI (web), an open-source full-stack starter.
Repo: https://github.com/BearStudio/start-ui-web

Why TanStack Start?

When we explored TanStack Start, it matched the kind of developer experience we were looking for: explicit, modern, type-safe, and not overloaded with abstractions.

It provides a clean foundation for routing, data loading and actions, while letting you stay close to the underlying React and server patterns. It gives structure without locking you in.

TanStack Start does not try to solve everything, and we like that.
It keeps the fundamentals simple and leaves room for architectural decisions. This is where our own stack comes in.

Where oRPC Fits In

For client-server communication, we use oRPC.
It is not part of TanStack Start. It is a separate choice that gives us:

fully typed procedure calls
clearer separation of concerns
no duplicated types
predictable request and response flows

oRPC handles the application logic boundary, while TanStack Start takes care of routing and UI composition.
The two work well together without stepping on each other.

The Setup Pain We Wanted to Remove

We did not create a starter because boilerplate is fun.
We created it because every project kept hitting the same repetitive hurdles.

Trying to rebuild a project structure we had already solved.
Rewriting authentication flows that barely changed from one project to another.
Configuring Prisma and handling migrations by hand.
Keeping server and client types aligned without manual duplication.
Rebuilding the same UI primitives again.
Delaying tests until later and regretting it.
Preparing Docker for the hundredth time.

Each problem is small on its own.
Together, they slow down the moment a project starts to feel real.

What Start UI (web) Gives You From Day One

The goal is simple. When you create a new project, you should be ready to build features almost immediately.

You start with a clean React and TypeScript structure.
Routing is set up with TanStack Start.
oRPC gives you fully typed API procedures.
Authentication is handled by Better Auth, already configured.
Prisma is wired with schema and migrations.
Tailwind is installed, and shadcn/ui gives you a solid set of components on day one.
Unit and E2E tests run out of the box.
ESLint, Prettier and CI are ready.
Docker works for local and production environments.
Storybook is included with a minimal design system.

Nothing in this stack is here to constrain you.
It is here to remove the repetitive parts so you can focus on what actually matters.

Why It Matters

The first days of a project should feel exciting.
But when the setup phase drags on, that excitement fades quickly.

Start UI (web) helps keep that momentum.
It removes the tedious work so you can see real progress sooner and maintain it.

Who This Helps

This starter works well for:

agencies and teams who frequently start new projects
freelancers looking for a reliable baseline
developers exploring TanStack Start in a real context
anyone who wants to skip boilerplate and build faster

It is not a framework.
It is not rigid.
It is a solid foundation you can build on.

Open Source and Continuously Improved

We use Start UI (web) internally and refine it every time we hit a real-world need.
You can explore it here:
https://github.com/BearStudio/start-ui-web

We are trying to reach 2000 stars before Christmas.
If it helps you or sparks ideas, a star would mean a lot.

Thanks for reading. If you want to discuss TanStack Start, oRPC, Better Auth or anything else, we are always happy to chat.

Hi, do you know Rust?

Yoann Fleury — Mon, 20 Oct 2025 06:56:23 +0000

This blog post is the translation of a french blog post I wrote for the BearStudio's blog

This article title sums up what my colleagues hear from me almost every day:

// Detect dark theme var iframe = document.getElementById('tweet-1475382332651675650-861'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1475382332651675650&theme=dark" }

In this article, I’m sharing a list of resources for learning the Rust language (and I don’t mean the video game of the same name 😄).
There’s no “Hello World” here, no lessons on conditionals or loops or borrowing or backend development, just a curated collection of useful learning resources.

What is Rust?

Rust is a programming language that continues to gain traction in the development world (it is, for instance, the second official language of the Linux kernel).

It contains concepts that are interesting to explore even if you don’t use it daily.

Rust is highly present in the systems ecosystem, which is why we find many alternatives to classic command-line tools:

bat as an alternative to cat
fd as an alternative to find

Rust is also used server-side — for example, the Bitwarden web services have a Rust implementation

But it doesn’t stop at backend programming. Rust also enables:

WebAssembly development
GUI development (for example: egui)

At BearStudio, more and more people are showing interest in the language, so I thought I’d compile the resources I discovered while learning it (learning which is still ongoing).

Happy reading, and enjoy discovering Rust!

Discovering the power of a low-level language with the comfort of a high-level one

To get started with Rust, the best resource is still The Rust Book.

Even though it’s theoretical, it helps you grasp Rust’s key concepts before really diving into code.

The early chapters aren’t the most exciting — they cover concepts also found in other languages — but starting from chapter 4, which introduces ownership, things get much more interesting.

To practice alongside your reading, I recommend cloning and working through:

https://github.com/rust-lang/rustlings

It offers many small exercises that help you get familiar with reading and writing Rust while following The Rust Book.

If you prefer an online introduction, here is a course from Microsoft:

https://learn.microsoft.com/en-us/shows/beginners-series-to-rust/

If you’re ready to invest financially into a more advanced form of learning, you can check out https://www.rustadventure.dev/ by Chris Biscardi.

You can also progress with structured exercises via https://exercism.org/ and benefit from mentoring provided by the community.

And if you like the community aspect, you can join the official Rust Discord:

https://discord.gg/rust-lang

Want to start learning Rust without installing anything locally? You can try Tour of Rust:

https://tourofrust.com/

It lets you learn Rust directly in your browser using the official online playground.

And to stay informed about everything happening around Rust, I recommend the newsletter This Week in Rust:

https://this-week-in-rust.org/

Every week, it provides a curated list of links and resources to discover new projects, learn new concepts, or explore new dependencies.

To go further

Why did we create ui-state?

Ivan Dalmet — Thu, 16 Oct 2025 14:05:20 +0000

This post is a translation of the original article on our website

Why did we create ui-state, a TypeScript library to manage ui state display? It all started after reading an excellent article by Dominic Dorfmeister, aka TkDodo (we also recommend checking out his other posts on his blog).

In the article Component Composition is great btw, TkDodo highlights a recurring problem: managing UI states (loading, error, empty, success, etc.) in a way that is readable, maintainable, and type-safe without making your component structure explode.

The typical starting point.
You start by writing a simple component:

export function ShoppingList() {
  const { data, isPending } = useQuery(/* ... */)

  return (
    <Card>
      <CardHeading>Welcome 👋</CardHeading>
      <CardContent>
        {data?.assignee ? <UserInfo {...data.assignee} /> : null}
        {isPending ? <Skeleton /> : null}
        {data
          ? data.content.map((item) => (
              <ShoppingItem key={item.id} {...item} />
            ))
          : null}
      </CardContent>
    </Card>
  )
}

At first glance, everything seems to "work."

But things get messy quickly:

Can we have both data and isPending at the same time?
Does the absence of data mean an error or an empty list?
What happens if data is present but empty?

You end up juggling several flags (isPending, data, isError, etc.) that can make two parts of the UI appear simultaneously, when that wasn't the intent.

It becomes hard to read, test, and maintain.

TkDodo's proposed solution

TkDodo suggests a clearer refactor based on early returns:

function Layout(props: { children: ReactNode; title?: string }) {
  return (
    <Card>
      <CardHeading>Welcome 👋 {props.title}</CardHeading>
      <CardContent>{props.children}</CardContent>
    </Card>
  )
}

export function ShoppingList() {
  const { data, isPending } = useQuery(/* ... */)

  if (isPending) {
    return (
      <Layout>
        <Skeleton />
      </Layout>
    )
  }

  if (!data) {
    return (
      <Layout>
        <EmptyScreen />
      </Layout>
    )
  }

  return (
    <Layout title={data.title}>
      {data.assignee ? <UserInfo {...data.assignee} /> : null}
      {data.content.map((item) => (
        <ShoppingItem key={item.id} {...item} />
      ))}
    </Layout>
  )
}

This version is much clearer, each state corresponds to a single render.

But there's a tradeoff: You have to extract the layout into a separate component, and what if you don't want the entire screen to change?
Layout is duplicated in every branch. You also need to extract typing logic for the Layout props. And if you want part of the interface (like a header or sidebar) to remain constant between states, or certain Layout parts to depend on the state, your code structure starts to grow complex again.

What we wanted: a single, well-typed, active state, reusable anywhere

At BearStudio, we wanted to keep the same core principles:

Only one active state at a time
Exhaustive type safety
Readable display logic

…but without breaking up the JSX or restructuring the entire render around state cases.

We wanted to be able to say:

"Give us the current state, we'll handle it. Just make sure we cover every case."

That's why we created ui-state

With ui-state, you transform the response from a useQuery (or any data source) into a single, explicit state, based on a single call to getUiState.

import { getUiState } from '@bearstudio/ui-state';

export function ShoppingList() {
  const query = useQuery(/* ... */);

  const ui = getUiState((set) => {
    if (query.status === 'pending') return set('pending');
    if (!query.data || query.data.content.length === 0) return set('empty');
    return set('default', { data: query.data });
  });

  return (
    <Card>
      <CardHeading>
        Welcome 👋 
        {ui
          .match(['pending', 'empty'], () => '')
          .match('default', ({ data }) => data.title)
          .exhaustive()}
      </CardHeading>
      <CardContent>
        {ui
          .match('pending', () => <Skeleton />)
          .match('empty', () => <EmptyScreen />)
          .match('default', ({ data }) => (
            <>
              {!!data.assignee && <UserInfo {...data.assignee} />}
              {data.content.map((item) => (
                <ShoppingItem key={item.id} {...item} />
              ))}
            </>
          ))
          .exhaustive()}
      </CardContent>
    </Card>
  );
}

What we gain from this:

A single, well-defined state, always up to date.
Type exhaustiveness via .exhaustive() ensures no case is forgotten.
Automatic type narrowing from TypeScript — for example, data is no longer optional since we've verified its existence.
Full rendering freedom, without restructuring JSX around states.
Better testability, you can test each UI state independently.

Same concept as in TkDodo's article, but no need to split into multiple components or wrap your entire JSX around state handling.

You keep clear logic and intact composition.

🔗 GitHub: https://github.com/BearStudio/ui-state