Almost every single piece of advice is wildly overcomplicated and ridiculous.
I do like some of the technologies proposed, but you can host this stuff on a single VM without any of the fancy frameworks, tools, or hosting options.
Kent is the only blogger that I've felt compelled to tell all my less experienced colleagues to completely ignore, and I feel entirely justified doing so whenever they bring him up.
The proliferation of his perspective has, quite literally, been a pain in my ass daily trying to re-teach misguided fundamentals. I really don't understand who the intended audience is. The expert beginner, maybe?
I'm sure he's probably a wonderful human being, however.
It's not just him and is more of a general issue with frontend "thought leadership". Most of them went into it when they were relatively early in their career. There's no 1:1 relationship between years of experience and skill/knowledge of course, but if you pick any random FE influencer on Twitter, chances are they have less experience in the field than the staff engineer in your team. Unfortunately, it shows.
They do have a lot of good advice, and I don't want to throw the baby with the bathwater. But they do get it wrong pretty often, and it does waste hundreds or thousands of hours having to go internally in an engineering org telling people "No, it's not because you read it on the internet that it's true".
A much older equivalent example was how back in the days in the Microsoft world everyone would say you HAD to use stored procedures for performance and security, ignoring prepared statements, so a lot of big companies had internal onboarding classes that always started with debunking it. Kent added a ton of confusion and did a lot of disservice to the unit testing space (the library is good, the philosophy lacks a lot of nuance), some other folks are creating a lot of chaos around SPAs/client vs SSR (they started adding nuance to that more recently), and so on and so forth.
It's part of why the JS ecosystem keeps restarting from scratch over and over instead of building on top and creating vertical innovation. We get there eventually, but it's so much slower than it needs to be.
His article is the epic antithesis of the KISS principle. Imagine being a beginner wanting to get into web app development and then finding out that the most "Epic Stack" requires you to learn 26 different pieces of technology, each with its own millions of nuances. SMH!
For one, Remix, actually. If you're "just trying to ship", the recommendation should probably be Rails, Django, or Next.js at this point. Flavour of the month technology is cool, but it's not mature enough to put in the "just ship it category."
His preferences are always bleeding edge, hip things. And that's not the kind of stuff you build on when you want to buck up and ship an idea.
It might be good stuff, but using what you know and what is stable is the only choice when you're trying to get things done. SQLite, yes. LiteFS on fly.io? Why? Just run bloody SQLite on a server and get it over with.
He historically caters to a beginner crowd, but totally skips fundamentals - then we all get know-it-alls that we have to bring back down to reality.
It's not so much the technology he likes, but the way he pitches it is extremely problematic. He pitches niche, complicated stuff and tries to pass it off as basics.
Tired of people calling Remix "flavor of the week". It's been acquired by Shopify, is actively being iterated on and is by no means another JS flavor of the week. I think it's proven itself in that sense so far.
Having worked for several years at a startup on rails, I can really confidently say the DX experience with Remix is no match..
I don't understand people in this thread complaining about niche complicated stuff when at the end of the day.. it's all just javascript, there's no magic..
The amount of abstractions, opinions, and siloed "you kinda just have to know that's the way it works" sort of knowledge that come with working with Rails is far beyond that of working with Remix. Would be curious to know how much time folks here have actually spent building with Remix. It's just good, give it a try.
Personally, I've learned a lot from Kent. I think his content is mostly quite good, I also don't find him to be someone who's sole mission is to make money and sell his product like a lot of folks in this thread have claimed. He gives a lot, for free, and contributes a lot.
Exactly what one of the creators/marketers of remix would say, with a just crated account.
Remix might be good if you want to use React, but it's ages away from what the Rails or Laravel ecosystem will provide you. Things such as official (or de facto) solutions for ORM, validation, sending (or receiving!) emails, authentication, writing custom utility commands, translations, i18n, background jobs, queues, admin dashboards, etc have a clear and either an official or de fact solution. That makes part of the "development experience" because developer experience is not just saving a script and seeing it refreshing in the browser. There's a lot more to it, like not having to reinvent the wheel at each step or tying together 10k third party libraries.
Remix, Next.js, blitz, whatever... those are all great solutions if all you have to build is a landing page with a form, or if you already have a proper backend in place, or if you have a team of several dozens/hundreds engineers and a ton of money to reinvent the wheel.
For solo or small teams or constrained budgets, nothing beats Rails or Laravel. There's a reason many of those frameworks wanna be called "Rails for JavaScript"... because none of them are anything close on their own name. Closest one is Adonis, and it's still a thousand miles behind regarding features, community, third party packages, being future proof and being battle proven.
I don't think he's straight up paid to recommend this stuff, just that as a blogger he thinks that he has pressure to blog about the latest hip things, which he probably does because he tends to blog about the latest hip things and that is what his audience expects of him. He's not a developer, he is a content creator for developers and that is a big difference, especially in a world where développées don't tend to move quickly ( or else we'd be rewriting our stacks every month to follow that flavor)
> He pitches niche, complicated stuff and tries to pass it off as basics.
I see, thanks for explaining.
> LiteFS on fly.io? Why?
He talks about this in his conference talk - to improve the UX. If you deploy to fly.io "edge" or whatever is that, you will get local reads no matter where you are.
For those that are using open source js software to build web applications and are able to pick apart and understand what each tool does, his choice of tools are actually tried and true.
Even a C# developer building with aspnet has to reach out to many of these tools: grafana, some hosting service, some log/error monitoring tool.
But at the same time, I think a lot of comments here are pointing at the glaring reminder of how obscenely complex development for the web can be in the JS ecosystem (for new or non-js devs). Why point new engs to remix, prisma, mailgun, insert 3rd party tool when it’s so much better to give them the Ruby on Rails approach? Aspnet, Ruby on Rails, and similar frameworks in all languages including JS frameworks incorporate nearly all the tools mentioned but without requiring someone to wire it up themselves (or to understand the wiring).
> But at the same time, I think a lot of comments here are pointing at the glaring reminder of how obscenely complex development for the web can be in the JS ecosystem
Absolutely agree, this has nothing to do with Kent.
> but without requiring someone to wire it up themselves
That's the whole point of the stack - that you don't need to wire all of that tech yourself.
But the whole modern development it's a nightmare as I see, or at least the advertised modern serverless development, you need to depend on:
- Some serverless hosting
- Some database provider
- Some auth provider
- Some other service, etc
In the past you just rented a simple VPS or shared hosting, setup all by yourself and have just one provider for everything, nowadays I read that auth it's very hard and you should not do it and instead use some auth provider (Auth0, etc).
I remember the good old days with php, just upload your file and it worked, now they try to replicate that experience but with dozens of providers.
The non-serverless version still works fine, even in modern JS land. The simple approach still works if you have some knowledge around setting up a server and configuring a few things.
I also think that the advice around Authentication is often misguided. For simple cases it's not that hard to add authentication without a separate service. There is too much scaring the newbies around that topic, when they are probably about as likely to mess up authentication when they try to configure an excessively complex library compared to implementing basic session authentication with the tools their framework provides.
Even in the good old days you still had a database provider (often PHP plus MySQL in the classic LAMP stack) and in some cases an Auth provider (especially if you consider classic tools like Wordpress and Drupal as Auth providers). (Relatedly, the advice about Auth is best "don't roll your own auth" and that doesn't mean that you have to use an Auth provider, but at least use a library vetted by others. I also tend to add "don't keep passwords in your database" because that is a [legal/accounting] liability issue [more than being "hard", though it can seem hard to do right], which does make it good advice to find a third-party Auth provider you trust if you must support password-based workflows. Luckily some new options and libraries for password-less Auth are becoming slowly more common.)
The great big irony here is just that "serverless hosting" is just an extremely silly new name for "shared hosting". The basic economics are the same: instead of paying for a whole server, pay for what you use, then share the remaining resources with other sites.
The new serverless hosts aren't just trying to replicate the "good old days" experience, in some cases they've inherited it. They've also just had the bad luck of hindsight from past shared hosting model problems: insecure FTP is dead (so there's much less of a feeling of "just copy the files over"), allowing direct crontab editing is known to be dangerous in shared hosts so serverless options need their own (often extremely custom) timed kickoff DSLs, hosting static files and application files in the same place is known to cause accidents so there's a greater separation in static hosting and serverless applications, and so forth. A lot of those same complications happened to a lot of the "classic" shared hosts, too. (Which is why many of those entrenched to specialize in known applications over time, cPanel anything you want as long as it is Wordpress or Drupal or one of the other six blog apps the host vetted. The disappearance of "shared hosting" wasn't just that modern development got complicated but that modern shared machine security got harder.)
"Serverless" is one of those names that kinda-sorta-almost makes sense: It's that your code runs "on no server (in particular)" rather than "on no server (at all)".
Someone stripped off that nuance in trying to come up with a concise buzzphrase for code that expects ephemeral access to an arbitrary server.
We can still do that. It still works. You can still just use rails or Laravel and deploy to heroku. Or just a single php file.
The only reason we don’t do it anymore in the cases where that would be enough and instead overengineer everything is because others will look us down.
I was convinced that he was going to sell this "Stack" for an exorbitant amount like some other Javascript influencers have done in the past. Thankfully this seems to be free at least.
I think you still have to be careful about folks selling training courses (or consulting services) to make sure that they aren't also glorifying complexity, even if they aren't trying to sell a product (or library or framework).
"You're wrong about the way you do unit test! Everything everyone is telling you is wrong! Fortunately, you can get my course that will clarify everything I just confused you about!!"
While I love testing-library, and have contributed to the sister libraries, one thing that always irked me is there was no empirical proof on why it was just better outside of handy wavy "because I said so."
"It's time to just ship" Lists 10 tools to start with.
Also, had the displeasure of using Prisma a while back. Extremely slow type generation, and complex to work with its client-server architecture. When your library requires a separate process you know you messed up.
If you want to just ship, pick up Next.js, or whatever you already know and add dependencies when you need them. Let thought leaders thought lead.
Interesting. Have you tried https://github.com/kysely-org/kysely ?
I know Prisma is an ORM and kysely is a "type-safe typescript SQL query builder" but I just wanted to know if you had the opportunity to try it and your opinion about it.
I'm searching for SQL typescript tooling for my next project.
I would recommend to use just good old database client and send your queries as text, nothing it's easier than that, every orm struggles when you want to do some relatively complex query, I struggled to do something like this with kysely `LEFT JOIN table2 ON (table1.id = tabl2.id AND table2.status = 1` was insane how complicated it was, sure you can pass raw sql, but what's the point of the orm then.
Have you tried Slonik (https://github.com/gajus/slonik)? It won't generate types from queries automatically, but it encourages writing SQL vs. a query builder and allows type annotations of queries with Zod. Query results are validated at runtime to ensure the queries are typed correctly.
It also does code generation into its own module, so good luck with hoisting in a monorepo where you want multiple independent prisma schemas. MikroORM[1] is a much better alternative to Prisma in my opinion but any ORM carries some form of baggage.
And that’s how you end with the 10 tools you started your comment with.
You can’t “just” start with next if you need authentication, translations, database acces, validations, csrf and other security protections, background jobs, permissions and a lot of other things that anything more complicated than a hello world will need.
If you want to just ship (anything more complicated than a landing page), start with Rails or Laravel.
I really do appreciate Prisma's developer experience though. Recently I've been testing out Prisma for migrations and Kysely as the actual ORM.
Prisma is generating the Kysely type definitions automatically so it is still pretty hands off without the production overhead of prisma server/client.
Kent seems like a nice guy, but every piece of his writing seems to be a massive beginner trap.
Experienced developers are not setting up brand new projects like this because it's massive overkill at the jump, but newbie devs who don't know better might try to.
I don’t know if I agree. For a toy project, sure, you don’t need anything at all except a static file host. However, many experienced devs aren’t going to sacrifice tools they know improve codebases when working on new projects at work, or starting something they think could turn into something bigger. It’s so much easier to have some of these tools available from the start, especially if this requires no extra work to setup (which seems to be the point of this anyways). IMO that includes linting/formatting, type safety, unit tests, observability with a dashboard and analytics, and at least very basic CI/CD. Things that I’d find hard to give up working in other code bases :)
Obviously there is going to be a huge amount of bike-shedding about what to use for X or if it’s useful; it’s basically impossible to avoid in this community. So I don’t know if that really detracts from the concept of having a stack with some solid defaults out of the box.
Personally, I might avoid the database/auth/payments related stuff at first, since that feels more subjective. However, tools like typescript, eslint, and prettier are practically industry standards.
It is still a pain in the ass to get a lot of the basics set up for different projects, so it’s nice to see some opinionated approaches to automating this. Compare to other languages like Rust, and the test runner, formatter, linter, dependency manager, and type safety are all built into the language tool chain. It’s so pleasant to not have to do any work to set that up, and I wish JS was more like that.
The benefits of naming stacks like LAMP and MEAN/MERN was coupling technologies that intrinsically work well together, where swapping out one would meaningfully change the whole system. LAMP without PHP would be unrecognisable, MEAN without MongoDB would feel completely different to develop for.
There’s almost nothing about the Epic stack from what I can see that wouldn’t feel roughly the same if replaced. Swap Tailwind for a different CSS framework and… it’s basically the same. Use a different validation library and it’s still the same. There are pairings within the list that complement each other relatively well, but none that are make or break in the same way as LAMP/MEAN/etc.
These stacks were useful in understanding values in an acronym, but here that requires a full blog post to lay out principles making it less memorable and, I suspect, less impactful as a result.
With “just shipping” as the stated goal, I am a big believer in using the tools you know, even if they’re not absolutely perfect or new or sexy enough to blog about.
Using things you know like the back of your hand will smooth over innumerable little snags that you’d run into if everything were new to you, and let you focus on the actual problem your software is supposed to solve. I can get a toy app live in an hour with the tools I know best, but I’m confident there’s at least one thing in this stack that I’d get stuck on for half a day, just because it’s unfamiliar.
Working with a team? Everyone throws their best-known tools in the pot and one person is directly responsible for selecting among them.
Looking at the logo wall, happily surprised that it doesn’t include React!
…then looking a bit closer to discover that once again, I’m running in to a React dev who assumes that everyone assumes that everyone uses React, thus you don’t even need to mention that a boilerplate built on React is built on React.
To be fair, they're not assuming anything, and Remix is like the first thing in the list, which is one of the major React frameworks right now. The name is not as descriptive obviously but its like someone saying SvelteKit and not mentioning Svelte proper.
Curious what alternative you believe is a better option for building applications in this day and age... Angular is basically dead and Vue abstracts too much (imo), unless you think vanilla JS is the way?
Yeah I got a kick out of that one too. I like what LiteFS is going for but it's interesting to see in a stack focused on minimizing dependencies and avoiding painful updates.
That’s been my experience with DevOps/SRE tooling as well. I think things are beginning to get a bit better (or the projects I’ve been using for a few years are finally getting stable). After getting burned multiple times by HashiCorp I am super non-1.X+-averse when it comes to picking anything.
It will never cease to amaze me how people can overcomplicate simple applications in such a fashion, particularly in JS land. I have never, and likely will never, understand the need for the addition of these bloated libraries on top of barebones React or JS which can achieve the same functionality at a fraction of the bundle size if you're a halfway competent software engineer.
I have mixed opinions seeing Tailwind on that list.
If you're not a designer, it takes a non-trivial amount of time to add the utility classes you need to get something that looks passable. Quite simply, it gives you too much control over something that just doesn't matter for an MVP.
There are great component libraries out there (I'm a fan of Chakra) that give you sane defaults so that you can get something off the ground, while not focusing on something that doesn't matter at the MVP stage.
Maybe Tailwind + Radix makes more sense after you raise funding...?
That's the niche for https://tailwindui.com - which is how the Tailwind creators make money. If you're convinced by the overall Tailwind philosophy, it's a steal at the price they charge.
Personally I feel like TailwindUI is a missed opportunity.
Their opposition to abstracted utility classes means that anything you want to do has incredibly long, unreadable classes. Its quite a bit of work to abstract away the bits that you want.
https://daisyui.com is my absolute sweet spot for abstraction. Its a bit limited, especially compared to TwUI and flowbite but its developer experience is a joy.
Couldn’t agree more. Tailwind css is great, but TailwindUI is where the wins are.
I love using it and despite being crap at design, I’ve managed to put some stuff together that I think is not half bad. (And I remain mighty impressed with their business plan, too!)
I don’t use frameworks like React or Vue because my apps are small and mostly just for me, so I wish there were component libraries out there like Chakra that didn’t require npm, yarn, or some other package manager to install, and then a framework to use. I just want to slap a CDN link in my HEAD tag of my vanilla HTML page and start using class names to create components. Ideally, these components would have behavior functionality as well so I don’t have to use another library like HTMX or Alpine.js to add it. It seems to me something like this _should_ be possible.
Disagree -- tailwind is likely the fastest way to get a barely-passable design. (Certainly faster than using an external component library then realizing ones you need are only available under the paid, "premium" collection).
And to say that design "just doesn't matter" while you're in fundraising mode, i think is also incorrect. You don't need perfect design, but it has to look pretty decent. It's in people's nature to be turned off by ugly/obsolete looking web pages.
I believe a framework like Bootstrap might be a faster approach at the beginning (honestly, it's a fair approach for the whole lifecycle of a project). You get all the building blocks to get a consistent UI working fairly quick with little to no CSS knowledge. Some times removing the unnecessary flexibility may be a boost to get things out there.
But, at the end of day, the best option will be the one you're most comfortable with.
Also, Bootstrap gives you plenty of copy-and-paste ready examples, including accessibility enhancements. Accessibility can be an after-thought to not just devs, but many designers, but Bootstrap helps put it right up front for the lazy developer.
Anecdotally, I've sometimes seen better quality websites for a lot of the little "polish" things like accessibility (which isn't really "polish", is it?) from the laziest "just use Bootstrap" developers than from the most hardworking Tailwind developer+designer combos.
OpenProps is on par with the developer experience of Tailwind in my opinion. The choice between the two more comes down to preference, class names as inline styles or a collection of Css variables
I was a little surprised by the list of tools and services included after first reading the principles for the stack (limit third-party services and only include the most common use cases)
Nothing against most of the individual tech chooses but this is a phat stack. I can’t imagine using something with so much stuff baked in, is it pluggable in any way? I guess the whole point is it’s not.
I’ve been a JavaScript developer for the last 7 years or so. Before that I was working on traditional
MVC Django apps.
This year I was moved to work on a Ruby On Rails project, given I had experience with Django (and some Laravel on the side) I was the best my company had at hand for that project.
I was reticent at first and even considered looking for a new job, but I wanted to give it a try first. HOLLY SHIT. I’m fascinated by the amount of stuff I’ve been able to do, and how simple things are. And that I can search for other Rails projects in GitHub and learn from them because they’re all using the same tools and structure. I do think we’re wasting a lot of our companies money when using this kind of hipster bullshit edge stuff which is not necessary at all like in 98% of what we usually do.
I don’t know why cloud providers haven’t jumped on RAD technologies. They could give devs a stack where all the engineers need to worry about is front-end presentation and business logic. Everything else from persistent storage, deployment, testing, scaling, disaster recovery is baked-in already.
We already have multiple "Epic Stacks". They are Rails, Laravel, Phoenix and Django. They give you everything listed straight out of the box and you don't have to deal with the trash that is the JS ecosystem. That's what makes them Epic :)
I’ll stick to rails, batteries included everything with easy to follow conventions. “It’s time to just ship” and proceeds to list like 15 different things, just lol. JavaScript must cause brain damage or something.
Hell, even LAMP is a better “just ship” than this monstrosity.
Don't mean to add 1 more to the list, but I would say tRPC is a must have for side projects for me now where I'm not requiring a publicly facing API.
The ability to just define a function on the backend, and it be callable in my frontend, with responses automatically typed is a game changer for building fast.
For me that means https://create.t3.gg/ is the current go-to for starting a new project, but it's definitely missing some pieces this stack has.
remix loaders are similar to trpc procedures and provide type safety, but you have to have a bit of a boilerplate there (15 extra characters) when you use it:
How's remix compared to nextjs? NextJs is quite well established, does Remix offer something better on top? Under which circumstances one would choose remix over nextjs?
I think one of those circumstances is when you previously worked for the company behind Remix. He is probably just really comfortable with the framework, so it makes sense for him to use it.
Remix is _really_ great if you want a traditional web application. In the tutorial they (used to?) do a bait and switch on you where at one point you realize no client side JavaScript has been running the entire time because the tutorial hadn't even talked you through how to bundle in the client side js! The idea is pretty much, use the platform.
Of course, I'm building a web app on top of it, so I want a lot of features that "the platform" doesn't necessarily support very well without client-side js to facilitate everything. And I did make an honest go of it. To me, the biggest pain point is still forms and form validation, which is notoriously painful in React land. I'm ultimately using react-hook-form and running the same schema validator client-side and server-side, which means I'm not really "using the platform" in that respect. I'd love to see an official react-hook-form type solution added to Remix.
Still, the framework has some really great, sticky conventions and it feels like they thought of almost everything. For example, the "action" and "loader" convention is awesome, nested layouts are the bomb, they encourage filenames like .server.ts to differentiate between things that can't be run client-side, heavily encourage the use of a bunch of goodies from react-router (which most people probably don't know exist) because Remix's routing is built on top of react-router... And so on.
Having used both Next.js and Remix a few times, it's difficult for me to recommend one definitively over the other; if you aren't experienced with them either one will be a learning curve. In general, I think Remix is the better framework but some shortcomings in the documentation (e.g. I found out about some new routing conventions because the old ones weren't working for me and it was confusing because the tutorial and docs seemed to use the old ones) and the relative dearth of resources online can lead to frustration. This should pretty much be a non-issue if you start a new project with one of the "stacks" that someone has developed, the blessed ones of which give you a base project that already has database, authentication, tailwinds etc configured with example routes and components.
Next is already taking some of the good ideas from Remix (nested layouts still in beta I think), and has a pretty extensive and mature ecosystem with lots of answers on SO and blogs at this point. For example, if you want free social auth you're pretty much just going to install next-auth. Still don't know exactly what I'd do in Remix for that.
The further I get into my career the less "stuff" I want to throw at solving problems. This is the antithesis of that attitude. It would take ages to learns the ins and outs of these dependencies, and some of them come with immense sets of complex dependencies.
I'm all for pragmatism and not reinventing wheels, but this stack looks like a juggernaut of eventual misery.
I thought I'd run through this just because I like Remix. It confirmed my prejudices against Fly. I've never gotten an app to deploy on Fly on the first try. There's always some error that I've got to debug and fix. I can't imagine recommending Fly as easy. Contrast to Vercel where everything just seems to work on the first try.
I would describe myself as someone 'in the trenches' of web dev as a consultant and I wanted to say that I respect this more knowing it's from Kent C. Dodds. I considered buying his React course, though I haven't, but I respect his knowledge and opinions; and for what it's worth, if Kent C. Dodds considers this to be an excellent stack, I would give it serious consideration. If you consider yourself to be an indie hacker, or follow people who do, then this deserves your consideration too, as Dodds is essentially coming from that background.
100% agree, I've always been impressed by what the projects and courses Kent puts out. I'd love to hear a podcast episode with him really diving into the choices behind everything in this stack.
The advice is, at this point, almost meme worthy. There's an infamous post from 2021 (that he may have been roasted for here):
https://kentcdodds.com/blog/how-i-built-a-modern-website-in-...
Almost every single piece of advice is wildly overcomplicated and ridiculous.
I do like some of the technologies proposed, but you can host this stuff on a single VM without any of the fancy frameworks, tools, or hosting options.
Kent is the only blogger that I've felt compelled to tell all my less experienced colleagues to completely ignore, and I feel entirely justified doing so whenever they bring him up.
The proliferation of his perspective has, quite literally, been a pain in my ass daily trying to re-teach misguided fundamentals. I really don't understand who the intended audience is. The expert beginner, maybe?
I'm sure he's probably a wonderful human being, however.