I respect your privacy. Unsubscribe at any time.
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).
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 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, 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 and decision documents behind every part of the Epic Stack. Additionally, there’s a huge list of community-built examples that’s growing every day. You can also watch a talk about the stack on the site.
You can think of EpicWeb.dev as the primary documentation for the Epic Stack. In the Volume 1 workshop series, 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.