Have you ever wondered how many hours you sink into do the same thing in multiple projects? Re-making the same decisions, configuring the same tools, and wiring together the same libraries over and over again?

Back in the day it was things like Angular or React, Webpack or browserify, JavaScript or TypeScript, ESLint or ... not.

It’s even worse when you multiply these decisions by hundreds of engineers in a single org!

There was a ridiculous amount of repetition back in my time at PayPal. Not just in the code itself, but also repeated decisions to make.

It's incredibly inefficient to have each team making the same decisions again and again with every new project. And when those decisions differed project to project, collaboration across teams and projects became a big pain.

To top it off, just the process of making decisions reduces our effectiveness and overall happiness! (Read [Your App Makes Me Fat](https://businessofsoftware.org/2023/09/kathy-sierra-your-app-makes-me-fat/)).

So I did something about it.

I made an internal utility called `paypal-scripts` that was a wrapper around Webpack, TypeScript, Babel, ESLint, and a few other tools. It provided not only a project starter, but also a reference for how to use the tools and why they were chosen. Every time a new project was started, the developers had a **solid foundation** for building on. It was a **huge success**, and eventually the scripts became the standard way for new projects across the organization.

It’s been over 6 years since creating `paypal-scripts`, and people who are still working at PayPal tell me it's still maintained and used regularly. It's hard to quantify these things, but I have no doubt that by removing research and configuration time, this project has saved PayPal **tens of millions of dollars** in developer productivity so far.

This type of decision waste isn’t unique to PayPal. It’s prevalent across the entire web developer ecosystem.

It takes a lot to build web applications that deliver the great user experiences our users and bosses expect, and there are now more options than ever to choose from in every category of web development.

I saw a need for the same consistency and thoughtful opinions for the web development community at large, beyond the reach of developers at just one company.

That’s why the [Epic Stack](https://www.epicweb.dev/epic-stack) was created: to serve not only as a project starter for hitting the ground running, but as a useful reference for building fantastic web applications.

Here are some highlights of the tools included in the Epic Stack: Remix, React, TypeScript, Prisma, Zod, Conform, SQLite, LiteFS, Resend, [Fly.io](http://fly.io/), Radix, Shadcn, Tailwind, MSW, Vitest, Playwright, Testing Library, ESLint, and Prettier.

The Epic Stack also provides built-in support for everything you'd need in an application: testing, deployment, database migration, authentication (even 2FA and 3rd party auth), permissions, and more.

I highly encourage you to read the [guiding principles](https://github.com/epicweb-dev/epic-stack/blob/main/docs/guiding-principles.md) and [decision documents](https://github.com/epicweb-dev/epic-stack/blob/main/docs/decisions) behind every part of the Epic Stack. Additionally, there’s a huge list of [community-built examples](https://github.com/epicweb-dev/epic-stack/blob/main/docs/examples.md) that’s growing every day. You can also [watch a talk about the stack](https://www.epicweb.dev/talks/the-epic-stack) on the site.

You can think of [EpicWeb.dev](https://www.epicweb.dev/) as the primary documentation for the Epic Stack. In [the Volume 1 workshop series](https://www.epicweb.dev/products/full-stack-vol-1), we're iteratively building the Epic Stack so you'll understand all the pieces at a deep level.

Regardless of whether or not you use the Epic Stack for your projects, you stand to benefit from developing a deeper understanding for all of the moving pieces in an application– not just what they are, but **how to make choices** and **defend your decisions**.

Ultimately, what makes the Epic Stack great is the same as what made `paypal-scripts` great. 

It’s not the tools themselves, but the consistency and thought that went into their selection.

Developing the skill to understand and recognize this will take you far.

Streamline web choices, build top-notch apps efficiently.

How the Epic Stack Makes You Faster

From the perspective of web standards to concerns about increasing complexity, Kent C. Dodds shares his opinions on why he won't use Next.js.

Why I Won't Use Next.js

Where you store your application data has enormous impacts on your entire application. There are implications on the entire stack based on what you decide to use here.

There are terrific solutions like MySQL and Postgres that have become the default for many people. These are fine solutions. But for most web app use cases, you could drastically simplify your life by using SQLite.

SQLite is a sql-based database with a particularly unique feature: the entire database is in a single file. Largely for this reason, many people have historically seen it as a simple database for simple use cases.

However, in recent years SQLite has received a great deal of development and attention making it a simple database for even more advanced use cases. Let’s talk about some of those advancements and why for most of us, SQLite is the best balance of trade-offs.

## Zero Latency

The fact that SQLite is a single file on disk comes with a major benefit of 0 latency which [drastically reduces the "n+1 problem."](https://www.sqlite.org/np1queryprob.html) This means that as a developer you don’t have to spend so much time worrying about reducing the number of queries you’re making to the database (which can lead to less efficient queries and certainly less efficient developers).

And latency itself is not to be underestimated. If you’re not thoughtful about the distance between your database and your application, you can easily put a baseline on your application’s performance. It’s not uncommon for the app-to-database latency to be measured in the tens of milliseconds (and sometimes even hundreds). This means no matter what you do, your page can’t load with fresh data in less than that amount of time.

I know performance isn’t the number 1 priority of all apps, but it’s pretty important for most. I’m  pretty sure even though the business executive who paid for your app and doesn’t have alternatives doesn’t like loading spinners flashing in their face for every interaction. 🌀😠

## One Less Service

One huge benefit to SQLite is the fact that it runs as an embedded part of your application. So that’s one less service to babysit. Honestly, that was my primary motivation when I decided to migrate my own website from Postgres to SQLite. I just stick SQLite in the same volume I’m mounting for other data for my application already and I’m off the races.

This saves on complexity as well as cost.

And this is multiplied by the number of instances and replication considerations, but we’re getting ahead of ourselves… Let’s get into that…

## Multi-instance replication

As a file on disk, you cannot "distribute" SQLite directly. However, this is where there have been advancements in this space. For my own applications that need multiple instances, I use [LiteFS](https://fly.io/docs/litefs):

> LiteFS is a distributed file system that transparently replicates SQLite databases. You can run your application like it’s running against a local on-disk SQLite database but behind the scenes the database is replicated to all the nodes in your cluster. With LiteFS, you can run your database right next to your application on the edge. You can run LiteFS anywhere!
> 

On top of this, LiteFS has built-in support to handle the "Read Replica Consistency" challenge. So if you need your app to run in multiple instances, you need to use one of these tools.

Another solution here is [Turso](https://turso.tech/) which uses SQLite under the hood and even has a concept called "embedded replicas" for zero latency reads. Very cool!

## Database size

Another issue people sometimes bring up is database size. However, [SQLite is capable of handling databases that are an Exabyte in size](https://sqlite.org/hctree/doc/hctree/doc/hctree/index.html) (that's one million Terabytes, or one billion Gigabytes 🤯). Most of us web developers don’t work with near that amount of data. You’ll have much different problems before database size is one of them with SQLite.

Even putting large amounts of data in a SQLite database record is pretty efficient! In fact, in some cases, [it can be faster](https://www.sqlite.org/fasterthanfs.html) to retrieve data out of a SQLite database than from the file system 😆 SQLite is an incredible feat of engineering!

## Development and Testing

I know some of you reading this right now are perfectly comfortable running `docker compose` as a regular part of your workflow before you start developing your application. But you have to admit that it’s annoying to run multiple apps at once with conflicting databases and ports. With SQLite, it’s a total non-issue. It’s just a file. So you can run multiple instances of the same app at once with no trouble whatsoever.

Also, while starting up a new Postgres database is fairly involved (there are of course tools that make it easier), SQLite has no such issue. Again, it’s just a file. Run your production migrations/seed and you’re good to go.

And this ease carries over to the testing side of things as well. When your database setup is complicated, you end up spending time evaluating ways to mock out your database at the ORM level so you can avoid having to run and connect to your database during testing and the isolation issues that can happen as a result of that.

Not a problem with SQLite. It’s just a file! Each test can have its own database with barely a thought. Just a little bit of code to create and connect the database and then your tests can run on the full database. You can definitely do this with other databases, but not as easily and efficiently as SQLite.

## Weaknesses

SQLite is not without its shortcomings. And it would be unfair of me to just talk about where SQLite shines without addressing some of those.

- SQLite does not support subscriptions which can be a limitation on certain real-time use cases. However, there are plenty of reasons to recommend against using database subscriptions for real-time use cases anyway. Scaling real-time use cases is quite challenging, and personally have really enjoyed letting [Partykit](https://www.partykit.io/) do that part for me in my apps.
- SQLite being a file on disk does make connecting from external clients effectively impossible. But with [Fly.io](http://Fly.io) at least, it’s easy to run prisma studio on the production server and proxy that for local access. If you need to connect to it from another app, then you’re out of luck and have to set up HTTP endpoints on the host app for any data you need ([for now](https://github.com/superfly/litefs/issues/326)).
- SQLite does not support plugins like [TimescaleDB](https://github.com/timescale/timescaledb) for Postgres. While time-series data is possible with SQLite, I do not have experience with this use case and can't speak to the challenges there. My intuition says it's not advisable to use SQLite for that use case, but maybe someone else can offer me more insight.
- SQLite does not support enums which means you're forced to use strings. I have mixed feelings about this, but I mostly don't like enums anyway. The main drawback to this is when it comes to the typings for the client which doesn't allow you to ensure all values of a column are only within a set of specific possible values for the string. However, with Prisma client extensions, handling this kind of enforcement at the client (and typing) level [is possible](https://github.com/L-Steinmacher/epic-stack-with-prisma-client-extensions).

## Conclusion

So, can *you* use SQLite? For the vast majority of you reading this, the answer is “yes.” Should you use SQLite? I’d say that still for the majority of you reading this, the answer is also “yes.” Though it’s complicated. As with everything in technology, there are multiple solutions that will work out. But I think you should give SQLite a serious look due to the performance, simplification, and cost benefits I’ve mentioned.

And that’s why I’m using SQLite for my own applications and why I teach you to use SQLite in the [EpicWeb.dev](http://EpicWeb.dev) series of workshops.

– Kent

Why you should probably be using SQLite

Almost every web application requires authentication and authorization.

And while it is true that not every web developer needs to build the utilities that handle them, if you don’t *understand* what’s going on behind the scenes you’re doomed to make a potentially **disastrous** mistake.

Whether you've got a team at your company that handles auth, you're using a third party service, or you're building it yourself, understanding authentication and authorization are critical to your success at keeping your user's data secure.

When I was at PayPal, we had a team that was responsible for managing authentication (thank goodness). It was a major black box for me so when it came time to add end-to-end tests to our application that required authentication. Some people would just stick the auth flow in front of all their tests and call it good. But that’s not good. That’s the path to slower and more flaky tests.

Instead, I took the time to **learn about and understand** how our app’s authentication worked so I could simulate that authenticated state in our test environment. I used utilities built by the authentication team to help through the process as well.

It’s your responsibility to learn and understand the whole stack. Not because you’re going to be working on it, but because you’ll be more capable of collaborating with those who do. That’s what **staff-level engineers** are expected do.

This is why the [Authentication Strategies & Implementation](https://www.epicweb.dev/workshops/authentication-strategies-and-implementation) workshop on [EpicWeb.dev](https://www.epicweb.dev/) is so vital. It's a whole 21 exercises long covering a wide variety of tools and techniques that you need to understand to implement auth in your web application. Topics like cookies, sessions, passwords, permissions, verifications, and oauth are all there.

HTTP Cookies have been around since the very beginning of the web. They were invented to solve the problem of **state management** in web applications. Cookies allow websites to store small pieces of data on a user's device which is then sent along with every request to the server. This enables the server to maintain session information and remember user preferences across different interactions.

Cookies have become a fundamental part of web browsing and online user experiences, facilitating various functions such as session management, tracking user behavior, and personalization. However, due to privacy concerns, the use of cookies has evolved, and modern browsers provide users with more control over cookie settings, including options to block or delete cookies. Despite this, the most secure solution for managing user sessions is still to use cookies 🍪

Honestly, if your web-based application is using anything else for user authentication information, it's very possible you've got some security vulnerabilities. At OWASP's NZDay conference, Security Specialist Mike Haworth gave a talk titled "HTML5." Among the great security related information in [his slides](https://owasp.org/www-pdf-archive/OWASP_NZDay_2011_MikeHaworth_HTML5.pdf), you'll find:

> sessionStorage for session cookie?
> • Obviously sessionStorage is accessable by JS
> – Therefore session token theft by XSS is possible.
> – Cookie w/ HTTPonly flag set is not accessible by JS
> • Use Cookies with HTTPOnly for session tokens
> • Don't store sensitive info in browser storage

And this has not changed since his talk in 2011. Steer clear of using `localStorage` or `sessionStorage` for storing sensitive data like user sessions.

Understanding web authentication and authorization is an important part of web security (it's one of [OWASP's Top Ten](https://owasp.org/www-project-top-ten/) which "represents a broad consensus about the most critical security risks to web applications"). Having a clear understanding of web auth will help you avoid making simple mistakes in your implementation.

To gain even more perspective, you’ll definitely want to check out the [bonus interviews](https://www.epicweb.dev/bonuses/interviews-with-experts) with Auth0’s [Will Johnson](https://www.epicweb.dev/bonuses/interviews-with-experts/the-future-of-authentication-with-will-johnson), PlanetScale’s [Iheanyi Ekechukwu](https://www.epicweb.dev/bonuses/interviews-with-experts/scalable-databases-and-authentication-with-iheanyi-ekechukwu), and creator of the remix-auth library [Sergio Xalambrí](https://www.epicweb.dev/bonuses/interviews-with-experts/transitioning-from-rails-to-remix-with-sergio-xalambri). Each of these developers bring their own perspectives on the past, present, and future of authentication and authorization.

[Go get started](https://www.epicweb.dev)!

– Kent

Understand Authentication

Recently for the [Call Kent Podcast](https://kentcdodds.com/calls/04/20/what-is-full-stack-for-epic-web-dev), Brian left me a message asking what "full stack" means when it comes to Epic Web.

Here's my answer:

For the the Full Stack Vol. 1 release on Epic Web, "full stack" means that you will be building an entire web application in TypeScript. From adding stylesheets and scripting to the client side, to database optimization, implementing two-factor authentication, there's a ton of ground that gets covered.

Full stack application development requires a wide variety of tools, patterns, and techniques so the workshops use a lot of tools. Folks who went through the workshops report that even though they're not using all the same tools at work, they're still using the knowledge they gained from the workshops daily.

What you learn from the EpicWeb.dev workshop series is highly transferrable. By the end of the workshop series, you should feel confident to tackle problems in full stack web development, regardless of the tools you use.

That said, let’s get specific. In Epic Web, we’re basically constructing the [Epic Stack](https://github.com/epicweb-dev/epic-stack) from scratch. So we’ll be using TypeScript, React, Remix, Tailwind, Vitest, Playwright, Zod, Prisma, SQLite, Conform, Resend, Shadcn, Testing Library, and more. I’ve hand picked each of these tools (and even helped create some of them 😅) because they are the best in the business. It’s totally fine if you’re not using the same tools– Remember, people who have already done it are using what they learned with different tools.

One topic that is not discussed in depth in the first volume is DevOps. And that’s because [EpicWeb.dev](http://EpicWeb.dev) already has this covered for free! Check out [Deploy Web Applications All Over the World](https://www.epicweb.dev/tutorials/deploy-web-applications) tutorial on Epic Web will teach you how to deploy a multi-instance, multi-region app (with distributed data too!). It acts as a great companion piece to Full Stack Vol. 1.

Other DevOps-related topics like scheduling, error reporting, and monitoring will probably be part of the second volume (which is months away).

For now, think of "full stack" as being everything you need to know to build a secure, optimized application using TypeScript and other industry standard tools.

If you have any questions you'd like answered, leave me a message for the [Call Kent Podcast](https://kentcdodds.com/calls/04/20/what-is-full-stack-for-epic-web-dev)!

–Kent

What does “Full Stack” mean for Epic Web

Building web forms is one of the more challenging problems in web development (this is both hilarious and sad). I would say the biggest reason for this is because the web browser doesn't do enough for us.

What's interesting, is the browser actually does handle forms fairly well, but for most web applications we prevent this default behavior `event.preventDefault()` because it just doesn't do enough. This means we lose out on much of the work the browser _does_ do for us, putting us at even more of a disadvantage when working with forms in the browser.

Luckily, modern frameworks are starting to improve things in this area. Instead of us having to prevent the browser's default behavior and re-implement it all ourselves, frameworks like Remix emulate the browser's default behavior, but still allow us to enhance the behavior to satisfy our user experience requirements.

As a part of [EpicWeb.dev](https://www.epicweb.dev), I'm going to teach you how to utilize this powerful capability while addressing the needs of complex forms. Let's talk about it a bit.

## Web Form Challenges

Arrays, objects, and files are all challenging to represent in an HTML form. The browser doesn't have a clear mapping of arrays and objects to form fields (and vice-versa). The browser represents these fields using the [FormData](https://mdn.io/formdata) API which works ok, but isn't really something we work with directly very often. We need some kind of transformation layer to operate between us and the form APIs.

Another challenge with web forms is validation. Especially the bits that require the server to be involved like whether a username is taken in an onboarding flow. Just managing the state involved with that can be a pain (handling race conditions, etc).

Finally, we need to be able to handle the submission of the form. This is another area where the browser does a lot for us, but we often prevent that default behavior and re-implement it ourselves and often without considering re-submissions and other edge cases that the browser has predictable and consistent behavior around.

## Modern solutions

Remix helps a great deal with the submission of forms. It allows us to feel like we're using the browser's default behavior, but easily enhance the user's experience with things like optimistic UI, pending states, and error handling.

For example, here's some code from my talk [Bringing Back Progressive Enhancement](https://kentcdodds.com/talks/bringing-back-progressive-enhancement):

```tsx
function ListItem({ todo }: { todo: TodoItem }) {
	const updateFetcher = useFetcher()
	const toggleFetcher = useFetcher()
	const deleteFetcher = useFetcher()

	const complete = todo.complete

	return (
		<li className={complete ? 'completed' : ''}>
			<div className="view">
				<toggleFetcher.Form method="post">
					<input type="hidden" name="todoId" value={todo.id} />
					<input type="hidden" name="complete" value={(!complete).toString()} />
					<button
						type="submit"
						name="intent"
						value="toggleTodo"
						className="toggle"
						title={complete ? 'Mark as incomplete' : 'Mark as complete'}
					>
						{complete ? <CompleteIcon /> : <IncompleteIcon />}
					</button>
				</toggleFetcher.Form>
				<updateFetcher.Form method="post" className="update-form">
					<input type="hidden" name="intent" value="updateTodo" />
					<input type="hidden" name="todoId" value={todo.id} />
					<input
						name="title"
						className="edit-input"
						defaultValue={todo.title}
						onBlur={(e) => {
							if (todo.title !== e.currentTarget.value) {
								updateFetcher.submit(e.currentTarget.form)
							}
						}}
						aria-invalid={updateFetcher.data?.error ? true : undefined}
						aria-describedby={`todo-update-error-${todo.id}`}
					/>
					{updateFetcher.data?.error && updateFetcher.state !== 'submitting' ? (
						<div
							className="error todo-update-error"
							id={`todo-update-error-${todo.id}`}
						>
							{updateFetcher.data?.error}
						</div>
					) : null}
				</updateFetcher.Form>
				<deleteFetcher.Form method="post">
					<input type="hidden" name="todoId" value={todo.id} />
					<button
						className="destroy"
						title="Delete todo"
						type="submit"
						name="intent"
						value="deleteTodo"
					/>
				</deleteFetcher.Form>
			</div>
		</li>
	)
}
```

### Pending UI

Let's say we want to add some pending UI to the "completed" state here. This is all we'd need to do:

```tsx
const isToggling = Boolean(toggleFetcher.submission)
```

If the toggleFetcher is currently being submitted, then we know we're in a pending state and we can style the form however we like, or render a spinner based on that and we're golden.

### Optimistic UI

That's easy stuff though. What about optimistic UI? In case you're unfamiliar, optimistic UI is a pattern that allows you to solve the problem of a slow UI based on network latency. For example, if you're on 𝕏 and you like a post, you'll notice the heart icon updates instantly even if you're on a slow connection.

Doing that is easy enough. Your action will almost always be successful. However, occasionally it will not be successful. For example, what if the post was deleted? In this situation, you need to reliably roll-back. This is what makes optimistic UI so hard and likely the reason many apps don't implement it.

Well, Remix makes this trivial in most cases as well. Because Remix manages the form submission and we have access to it, we can optimistically display the next state quite easily:

```tsx
const isToggling = Boolean(toggleFetcher.submission)
const complete = isToggling
	? toggleFetcher.submission?.formData.get('complete') === 'true'
	: todo.complete
```

The `formData.get('complete')` will read the value the user's submitting from the form:

```tsx
<input type="hidden" name="complete" value={(!complete).toString()} />
```

And that's it! The UI can just reference `complete` to know how to render properly. And because Remix handles form resubmissions and race conditions in a predictable and consistent way (modeled after the browser), we can reliably use the submission's `formData` to know what the user's trying to do and display optimistic UI based on that!

Not all optimistic UI is quite that simple, but most of it is, and it's awesome.

And then if there's an error from the server, we can retrieve that from `toggleFetcher.data` and display the error to the user... Speaking of which...

## Error handling, type safety, and accessibility

I've been in this forms game for many years and writing a function to validate every form field is a huge pain. On top of that, to make things as accessible as possible you need to also handle native HTML attributes for validation, like `required`, `max`, `minlength`, etc. And then when there is an error, properly associating that error to the relevant form field (or the form as a whole) and moving the user's focus to the field at fault is like, a whole thing.

You wind up implementing the code twice for this important reason:

Server-side validation is required to keep yourself safe. Client-side validation is required to give the user a good experience.

This is a huge pain without the right tools.

### Zod

As I've been around the block, it's become incredibly obvious that having schema-based validation is where it's at. Back in the day when I was maintaining [angular-formly](https://github.com/formly-js/angular-formly), I built my own schema-based validation library called [api-check](https://www.npmjs.com/package/api-check) (before prop-types was extracted from React). People also put together conversion libraries that would convert a json-schema into the angular-formly field template so you could have persist-able form configuration and people built their own form CMS. It was pretty cool!

Bottom line: schema validation is powerful.

This is one reason I'm bullish on using [zod](https://zod.dev/) for forms. It makes it easy to represent business logic as a validation schema that can be largely shared between the client and the server. For the pieces that don't work on both sides (like: the username/password they submitted is valid), you can have a base schema (validate the username and password fields independently) which you further refine on the server.

Here's an example of the login from the Epic Stack:

```tsx
const UsernameSchema = z
	.string({ required_error: 'Username is required' })
	.min(3, { message: 'Username is too short' })
	.max(20, { message: 'Username is too long' })
	.regex(/^[a-zA-Z0-9_]+$/, {
		message: 'Username can only include letters, numbers, and underscores',
	})
	// users can type the username in any case, but we store it in lowercase
	.transform((value) => value.toLowerCase())

const PasswordSchema = z
	.string({ required_error: 'Password is required' })
	.min(6, { message: 'Password is too short' })
	.max(100, { message: 'Password is too long' })

const LoginFormSchema = z.object({
	username: UsernameSchema,
	password: PasswordSchema,
	redirectTo: z.string().optional(),
	remember: z.boolean().optional(),
})
```

All of that logic is shared between the client and the server. But of course the logic behind the username and password being correct has to happen only on the server. So in our server-side `action`, we can do that by adding a transform to the `LoginFormSchema`:

```tsx
LoginFormSchema.transform(async (data, ctx) => {
	const session = await login(data)
	if (!session) {
		ctx.addIssue({
			code: z.ZodIssueCode.custom,
			message: 'Invalid username or password',
		})
		return z.NEVER
	}

	return { ...data, session }
})
```

If no session is created, then we add an issue to the context and return a value which will never be valid. This will cause the form to be invalid and the user will see the error message we added to the context.

Zod is an incredibly powerful tool for building validation logic.

You can learn more about how to use a zod `transform` with a form in the tip ["Use Zod for All Form Validation"](https://www.epicweb.dev/tips/use-zod-for-all-form-validation).

### Conform

But zod was not built specifically for forms and is missing a number of really critical features to make it work nicely for forms. Zod was built with objects and arrays in mind (as it should be). But form data comes from `FormData` which requires a bit of a transformation layer.

Additionally, converting the zod schema into something I can use to create my form is challenging because keeping things in sync between the native HTML attributes (like `name` and validation attributes), properly associating zod's errors to their fields, and focusing the user where they're supposed to go in the event of an error is definitely outside the scope of a more general-purpose library like zod.

This is where [conform](https://conform.guide) comes in. Conform behaves as the transformation layer between our zod schema and the form so we can generate a typesafe form with proper validation and error handling (including focus management). And then Conform allows us to parse the submitted `FormData` into the data we can use for our application.

Conform works great with Zod and Remix, and also works with other frameworks (even vanilla JS) and schema validation libraries. Here's an example of our zod `LoginFormSchema` with Conform:

```tsx
import { Form, Link, useActionData, useSearchParams } from '@remix-run/react'
import { conform, useForm } from '@conform-to/react'
import { getFieldsetConstraint, parse } from '@conform-to/zod'

// ...

const actionData = useActionData<typeof action>()
const [searchParams] = useSearchParams()
const redirectTo = searchParams.get('redirectTo')

const [form, fields] = useForm({
	id: 'login-form',
	constraint: getFieldsetConstraint(LoginFormSchema),
	defaultValue: { redirectTo },
	lastSubmission: actionData?.submission,
	onValidate({ formData }) {
		return parse(formData, { schema: LoginFormSchema })
	},
	shouldRevalidate: 'onBlur',
})
```

From there, we can apply `form.props` to our `<form>` element, `conform.input(fields.username)` will give us the props appropriate to apply to our username input (for accessibility and HTML validation attributes derived from the schema), and errors can be found in `fields.username.errors`. In the Epic Stack, we have a `Field` component that gives us a consistent way to render fields, but here's an example of how you'd render the username field without that:

```tsx
<label htmlFor={fields.username.id}>Username</label>
<input {...conform.input(fields.username)} />
<ul id={fields.username.errorId}>
	{fields.username.errors.map((error) => (
		<li key={error.code}>{error.message}</li>
	))}
</ul>
```

Here's an example of what could be rendered (copied and slightly modified from [the live site](https://www.epicstack.dev/login)):

```html
<label for="login-form-username">Username</label>
<input
	id="login-form-username"
	name="username"
	form="login-form"
	required=""
	minlength="3"
	maxlength="20"
	pattern="^[a-zA-Z0-9_]+$"
	data-conform-touched="true"
	aria-invalid="true"
	aria-describedby="login-form-username-error"
/>
<ul id="login-form-username-error">
	<li>Username is required</li>
</ul>
```

Check out those attributes! They're all derived from the zod schema. So if we added a `.optional()` to our zod schema, the `required` attribute would be removed. Isn't that awesome? No need to duplicate the rules. Which leads into the next important point...

Thanks to Remix actions, we get progressive enhancement. The form will work before the JavaScript shows up because we validate everything in the `action`:

```tsx
const formData = await request.formData()
const submission = parse(formData, { schema: LoginFormSchema })

if (submission.intent !== 'submit') {
	return json({ status: 'idle', submission } as const)
}
if (!submission.value) {
	return json({ status: 'error', submission } as const, { status: 400 })
}

const { username, password, redirectTo, remember } = submission.value
```

But most of the time, the user's experience will be enhanced by the JavaScript which includes client-side validation of the form with error handling as shown above with the `onValidate` callback.

To top it off, all of this is typesafe. If we decided to change from `username` to `email`, then we would get type warnings everywhere. From creating the form itself, to the `submission.value` in the `action`.

And conform supports all kinds of complexities with forms. You need a set of fields that represent an object? [`useFieldset`](https://conform.guide/api/react#usefieldset). You need a dynamically sized array of fields? [`useFieldList`](https://conform.guide/api/react#usefieldlist). And Conform supports file uploads without breaking a sweat as well.

Dive in deep in [the 📝 Professional Web Forms workshop](https://forms.epicweb.dev/).

## Conclusion

We've got some fantastic tools for building typesafe, progressively enhanced, accessible forms for the web. Let me know what you think when you try these tools out!


Learn how to use modern tools that offer the best user and developer experience for web forms.

Accessible, Typesafe, Progressively Enhanced Modern Web Forms

Modern web development is fantastic. There are so many great tools available!

Modern web development is exhausting. There are so many great tools available!

Each of these sentiments is true. What’s great is that most of the time, it’s hard to make a choice that is wrong. Seriously. The trade-offs of most of the frameworks and tools you could use to build your application fit within the constraints of the vast majority of apps.

Despite this, engineers consistently struggle with **analysis paralysis**. Nobody likes the feeling of having to make a decision they’ll have to live with for the foreseeable future and find out it was the wrong one. Like a hungry person getting hungrier looking over menu that’s too long and full of great options, engineers find themselves guessing and second guessing our technology choices.

On top of that, getting team of engineers running the same direction with the chosen technology can be a big challenge. There are numerous considerations, existing skills, training for new skills, the hiring pool, personal preferences and experience, and more.

Oh, and then once you’ve finally selected a web framework, UI library, testing framework, hosting provider, etc. etc. you have to wire everything together before any meaningful work can get done.

And all of this is just a **big distraction** from what we’re really trying to accomplish here: **ship a quality product**.

## It’s time to just ship

I’ve been developing modern web applications big and small for nearly a decade. In that time, I’ve worked all over the stack. Significant technical decisions I’ve made are still in use at my previous companies (like PayPal). I’ve also made a number of technical decisions that didn’t pan out very well at all and I had to pay the price.

With the help of my team, I’ve shipped web applications to millions of users all over the world as well as smaller internal apps to a handful of stakeholders. I have a solid grip on what it takes to ship excellent user experiences and make choices that keep developer velocity (and morale) high.

That’s why I’ve decided to encode my experience on how to build excellent modern web applications into **an opinionated project starter** that allows teams to ship their ideas to production faster and on a more stable foundation. And it’s called “The Epic Stack”:

![](http://res.cloudinary.com/epic-web/image/upload/v1683707705/epic-stack-logos.svg)

The primary goal of the Epic Stack is to help your team get over analysis paralysis by giving you solid opinions for technologies to use to build your web application. The Epic Stack is really two things:

1. A project starter
2. A reference implementation

For those of you starting a new project, you can use the `create-remix` CLI custom stacks feature to bootstrap your app with `npx create-remix@latest --typescript --install --template epicweb-dev/epic-stack` and you’ll be set.

But most people don't startup their computer every day and start a new project. Most of us work on an existing app. For those folks, the Epic Stack can be a great reference for configuring tools and integrating with solid libraries and services. <a href="https://github.com/epicweb-dev/epic-stack/tree/main/docs/decisions" target="_blank" rel="noopener">The Epic Stack decision documents</a> can also serve as a good place to find good arguments for the decisions and trade-offs made.

## The Epic Stack

There’s far too much for us to talk about in a single blog post, so I’ll encourage you to dive into the <a href="https://github.com/epicweb-dev/epic-stack/tree/main/docs" target="_blank" rel="noopener">docs</a> for more and [star the repo](https://github.com/epicweb-dev/epic-stack), but let’s get a high-level view of what you get when you use or follow The Epic Stack.

We’ll start with <a href="https://github.com/epicweb-dev/epic-stack/blob/main/docs/guiding-principles.md" target="_blank" rel="noopener">the guiding principles of the stack</a>:

* **Limit Third Party Services:** If we can reasonably build, deploy, maintain it ourselves, do it. This saves on cost and reduces complexity.
* **Include Only Most Common Use Cases:** As a project generator, it is expected that some code will necessarily be deleted, but implementing support for every possible type of feature is literally impossible. _The starter app is not docs_, so to demonstrate a feature or give an example, put that in the docs instead of in the starter app.
* **Minimize Setup Friction:** Try to keep the amount of time it takes to get an app to production as small as possible. If a service is necessary, see if we can defer signup for that service until its services are actually required. Additionally, while the target audience for this stack is apps that need scale you have to pay for, we try to fit within the free tier of any services used during the exploration phase.
* **Optimize for Adaptability:** While we feel great about our opinions, ever-changing product requirements sometimes necessitate swapping trade-offs. So while we try to keep things simple, we want to ensure teams using the Epic Stack are able to adapt by switching between third party services to custom-built services and vice-versa.

With that context, here are a few things you get today:

* [Remix](https://remix.run/) is the Web Framework of choice
* [Fly app deployment](https://fly.io/) with [Docker](https://www.docker.com/)
* Multi-region, distributed, production-ready [SQLite Database](https://sqlite.org/) with [LiteFS](https://fly.io/docs/litefs/).
* Healthcheck endpoint for [Fly backups region fallbacks](https://fly.io/docs/reference/configuration/#services-http_checks)
* [Grafana](https://grafana.com/) Dashboards of the running app
* [GitHub Actions](https://github.com/features/actions) with testing and deploy on merge for both production and staging environments
* Email/Password Authentication with [cookie-based sessions](https://remix.run/utils/sessions#md-createcookiesessionstorage)
* Transaction email with [Mailgun](https://www.mailgun.com/) and forgot password/password reset support.
* Progressively Enhanced and fully type safe forms with [Conform](https://conform.guide)
* Database ORM with [Prisma](https://prisma.io/)
* Role-based User Permissions.
* Custom built image hosting
* Caching via [cachified](https://npm.im/cachified): Both in-memory and SQLite-based (with [better-sqlite3](https://github.com/WiseLibs/better-sqlite3))
* Styling with [Tailwind](https://tailwindcss.com/)
* An excellent, customizable component library with [Radix UI](https://www.radix-ui.com/)
* End-to-end testing with [Playwright](https://playwright.dev/)
* Local third party request mocking with [MSW](https://mswjs.io/)
* Unit testing with [Vitest](https://vitest.dev/) and [Testing Library](https://testing-library.com/) with pre-configured Test Database
* Code formatting with [Prettier](https://prettier.io/)
* Linting with [ESLint](https://eslint.org/)
* Static Types with [TypeScript](https://typescriptlang.org/)
* Runtime schema validation with [zod](https://zod.dev/)

And that’s what we have today, here are some things that will likely find their way into the Epic Stack in the future:

* Powerful, yet simple sitemap control
* Error monitoring with [Sentry](https://sentry.io/welcome/)
* Ecommerce support with [Stripe](https://stripe.com/)
* Ethical site analytics with [fathom](https://usefathom.com/)
* Internationalization
* Image optimization route and component
* Feature flags
* Light/Dark/System mode (without a flash of incorrect theme)
* Documentation on production data seeding process

## More than a list of features

A list of features is fine, but really what you’re getting out of this is a break from analysis paralysis. You get to ship faster on top a solid selection of technologies and tools.

Additionally, my goal is to make the Epic Stack second-to-none with regard to learning resources so your entire team can all get up-to-speed on your stack quickly. And having your entire team on the same page with regard to your stack is invaluable.

And that’s what <a href="http://EpicWeb.dev" target="_blank" rel="noopener">EpicWeb.dev</a> will be all about: How your team can take the Epic Stack foundation and build a quality application on top of it.

## Conclusion

After all the time I’ve spent building web applications and learning from engineers with more experience than myself, I feel extremely confident that the Epic Stack will help tons of engineering teams focus on their core offering, move fast, and build excellent user experiences. I hope you give it a shot. Please join the community by participating in <a href="https://github.com/epicweb-dev/epic-stack/discussions" target="_blank" rel="noopener">discussions on GitHub</a> and <a href="https://kcd.im/discord" target="_blank" rel="noopener">the Epic Stack channels Discord</a>.

See you around the web!

Introducing an opinionated project starter that enables web development teams to ship their ideas to production more efficiently.

The Epic Stack

There’s this pattern I’ve been using in my apps that has been really helpful to me and I’d like to share it with you all.

Full Stack Components

The main thing that makes end-to-end type safety difficult is simple: boundaries. The secret to fully typed web apps is typing the boundaries.

Fully Typed Web Apps

Web is made up of technologies that got started over 25 years ago. Now, we are transitioning to a new and improved architecture for building web applications.

Epic Web Dev Articles by Kent C. Dodds