I wrote 3,000+ words on Next.js + why Indie Hackers should use it.

Hey Indie Hackers,

My name is Drew. I use Next.js for nearly every project, both at work and on side projects.

I wrote a 3000+ word essay this weekend on why React developers should use Next.js. It was received pretty well on Twitter so I thought I'd share it here as well.


I'm adding some extra tips here for Indie Hackers that I left out of the essay.

P.s. - The first section of the post talks about React & how it became successful. If you're already sold on React, there's no need to read that section.

(use this link to skip to the Next.js section)

Extra reasons for Indie Hackers to use Next.js

1. Developer velocity is your most important metric

In order to find your way to product-market-founder fit, it is crucial you're able to iterate enough on the project. If you spend too much time configuring routers, setting up your CICD, and trying to figure out how to pre-render pages, you're not going to make it.

2. You're a one-person team (most likely)

Because you're just one person working in an app, the idea of separating an app on a frontend/backend split doesn't make sense. Put all the code in one place, access it quickly, and iterate.

3. Vercel takes care of a lot of DevOps

We're all lucky at work. Someone configured our CI/CD pipelines for us, configured the e2e tests, and automated the Lighthouse audits.

When you host on Vercel, your Next.js app gets the power of at least 2 DevOps engineers for free.

4. If you make it big, you'll need to add these features anyway

Next.js enables:

  • server-side rendering (SSR)
  • static site generation (SSG)
  • automatic code-splitting
  • TypeScript support out-of-the-box
  • 1000 other improvements the team is making all the time


If you're an Indie Hacker, maker, bootstrapper, there's one thing that's true no matter what.

You're short on time.

Next.js + Vercel helps with that.


Follow along

I'll be sending out essays and newsletters at drew.tech once a month. Subscribe to follow along. I'll also try to share most of my content on Twitter (@dbredvick) and here.

  1. 7

    You still have to buy into the idea that building your site in React is a reasonable and desirable thing to do, regardless of whether it's being built on the server or the client. Many of us see a lot of complexity here without any obvious benefit over what most bootstrappers should actually be using, which is Rails. It's at least as qualified and worthy an answer to all four of your points above, swapping out Hatchbox or Heroku for Vercel.

    Recent apps such as HEY demonstrate the absurd power, speed and simplicity of server rendered solutions that use tools like StimulusReflex, Turbolinks, Stimulus and CableReady to deliver user experiences that are more responsive than React while boasting a 7kb total code footprint.

    React-for-everything is thankfully no longer the foregone conclusion that it seemed to be even six months ago.

    1. 5

      Personally I find the entire Rails ecosystem much more complex than even SSR React or any React+X system.

      Yes Rails is much more powerful and developer friendly when it comes to backend logic, but delivering a 2020 user experience is about as simple as assembling a car from scratch.

      Stimulus & Co. is definitely going to score better metrics in all divisions (TTFP, FMP, etc.) but it dosen't feel nearly as smooth in interaction as any SPA framework.

      1. 3

        I would also add that an SPA experience is essential for mobile browsers. I don't want my mobile users loading pages from the backend as they navigate through my site.

        1. 1

          As I replied to @satvikpendem in another thread:

          For the record, humans have an extremely difficult time perceiving anything below 200ms. The over-the-wire updates coming from Hey are generally clocking around 12-35ms. It's not at all clear to me why you believe that there's a way to request the same data as a JSON string, render it, diff it and redraw it in less time than it takes to graft a string into your DOM. If you read this paragraph a few times, you'll realize that I'm stating something backed by the laws of physics.

          One thing that you might not be considering is that SPAs require recent handsets to feel fast, whereas even really old phones are pretty great at rendering HTML.

          What's not contested is that all of that heavy JS thrashing is murder on mobile battery life.

          1. 3

            You make some fair points (I took a look at your other comments too). I'm not an ideologue on this matter - I've built both SPA and non-SPA apps and overall I personally prefer SPA on mobile.

            I assume my audience to have modern handsets. And if a user loads my product site then at least all the pages are already loaded locally and ready to go even if they suddenly experience network issues - that's a big win for me and my users.

            Battery life, it can be argued, is an issue. But then that's down to efficient coding and is a solvable problem. I'm thinking of learning svelte as that's one of the things it can help with - by shifting a lot of the "what-changed" work from runtime to build-time.

      2. 2

        I guess it depends on what you're trying to do, and what sort of experience you're coming from. I admit that I don't fully appreciate the complexity comparison, because I can go from "rails new" to a deployed application with authentication and reactive, over-the-wire DOM updates in a few minutes. The whole point of Rails is that it has opinionated defaults that are quick to change out.

        You can't really compare Stimulus to React - they have entirely different functions and goals. Stimulus wraps MutationObserver to provide lifecycle hooks, and offers structure and a compositional development experience. It's got no visual aspect, so I don't know how you rate its relative "smoothness".

        Seriously though - have you tried Hey? React devs owe it to themselves to ask if maybe they don't have it all figured out.

        1. 4

          I'd argue that the tech matter less than the attention to detail.

          DHH & team always put a ton of thought into what they're building, its performance, and the overall UX.

          I'd bet a large amount of money DHH could make a performant & delightful UX in Next.js w/ React if he was the creator of Next. (as he is of Rails).

          Btw, I'm addressing web vitals performance issues at my company right now. All apps have performance problems. Doesn't matter what tech stack they're on.

          P.s. - yes, even the Rails/Stimulus app 🙂

          1. 1

            I understand what you're trying to say, but it's a reductive conclusion. Of course doing things properly is going to get better results.

            However, I reject the idea that all frameworks are created equal. There is an objective truth that some tools land you much closer to the finish line than others.

            If DHH had created Next, it would be Rails. That's the point. It would be written in Ruby, not just because that's what he likes but because of features and design decisions baked into the language. It's not just a matter of preference.

            At issue is literally the surplus obtained by leveraging better tools. You can claim otherwise as much as you want, but it's objectively not true.

            1. 3

              If you:

              • already know React
              • are familiar with JavaScript
              • and are thinking of building a SaaS

              I’m saying use Next.js instead of create react app.

              For the people that meet the above criteria, they will get much more leverage out of the tools I mention.

              Maybe in an alternate reality where they know Rails, they should instead use Rails.

              Don’t get me wrong, yes the tools objectively are different.

              That’s not what’s stopping us from shipping products, though.

        2. 1

          Hey feels very close, really good. Don't forget tho that this product is built by a team probably 20+ developers. How many indiehackers can identifiy with that?

          I grew fond of React back in 2016 after almost quitting developing entirely because of how much I hated Angular. I'm very used to it now and can probably develop any project in the same time that you would use your Rails stack.

          In the end, you should always build stuff with what you can work with at maximum speed. Just because any metric is better with X dosen't mean I'll spend a year getting into that.

        3. 1

          Turn on Javascript and use a page built with React (or any other single page app framework with client side routing) such as the Gatsby home page. You'll find that page transitions are instantaneous. Apps made with Stimulus such as Hey are not, you have to wait for new or partial page loads whereas with React apps, you don't. The user can feel the difference.

          From your comments here, it doesn't sound like you've actually used React before, or built anything substantial with it. Client side routing is worth the extra payload just because of the user experience it provides that can never be possible with only server side rendering. NextJS, while it does do SSR, preloads certain pages and makes them client side accessible and only does a full page reload for most other pages, progressive enhancement.

          1. 1

            After developing with SSR technologies since 1997 - Rails since late 2004 - I was compelled to learn React for a project in early 2018, roughly in time to be informed that suddenly Hooks was the new thing everyone had to refactor to. In early 2019, I worked on a React Native app for six months, ultimately writing a form validation component because all of the existing options were buggy AF.

            It was the trauma of working with React for a year after enjoying the creature comforts of a real framework for decades that made me feel angrier and angrier every day. I came to see the people who were coming to React - mostly junior developers who haven't had much experience with the alternatives - as delusional prisoners who have been fed lies about productivity.

            In short, you're wrong about my background and experience with the tooling. There were small aspects that I really liked; for example, I think that the Expo tooling for RN is really incredible. However, the loss of developer ergonomics (Redux? even its creator regrets it) and obsession with constant retooling in the JS ecosystem left me with a renewed passion for working in Rails. The Stimulus framework is a gift; one of the most well-designed and powerful tools I've ever encountered.

            That you'd compare Stimulus to React actually demonstrates that you're the one who hasn't used or taken the time to understand the options you have. Stimulus has no concept of rendering or any visual output whatsoever, so I don't know what you're comparing. It wraps MutationObserver to provide lifecycle methods and offers a sane, opinionated structure for creating compositional behaviours. The sad truth? You'd freaking love it, if you hadn't already decided that you're on team hating it. When have good decisions ever been made in a group? Think for yourself.

            For the record, humans have an extremely difficult time perceiving anything below 200ms. The over-the-wire updates coming from Hey are generally clocking around 12-35ms. It's not at all clear to me why you believe that there's a way to request the same data as a JSON string, render it, diff it and redraw it in less time than it takes to graft a string into your DOM. If you read this paragraph a few times, you'll realize that I'm stating something backed by the laws of physics.

            1. 1

              And yet, they feel the difference all the same. React frameworks do not work by sending JSON over the wire all the time, they send it first and have it ready to be parsed, which is very fast. The network is always slower than the CPU, which seems to be what you don't understand about physics. I ask you again to try out a React web page with client side routing and see if you feel a difference, it seems you have not done so yet by the time your comment was posted, yet you assumed that I couldn't tell the difference.

              By Stimulus, I meant the whole ecosystem that I didn't want to write out (StimulusReflex, Turbolinks, Stimulus and CableReady, as you put it), with React I can just say React and it's understood. I never said I hated it either, I've used server side rendering, and Rails even, for at least 3 different projects over time. For me, and for those types of apps, React and some API (even in Rails) would've been better than SSR.

              React Native is not really React as for the web, the mobile ecosystem works differently, as RN is just transformed into native widgets anyway so of course it doesn't really make any difference that it's written in JSX, it's just a markup language.

              If you're not going to try and experience client side routing, I can't really say anything to you. It must be felt to be believed. Otherwise it's a back and forth of "you said, I said".

              1. 1

                I'm sorry - I thought that it would be clear when I explained I had worked in both React and React Native for a year and a half that - of course - I used react-router during that time. How could you not?

                Similarly, could you please have a think about why you'd conclude that only React apps cache data locally? The whole point of what I'm saying is that we're moving the exact same data over the wire. I don't need to try client side routing because I've implemented it in React and there's no observable difference in the end result because by the time the user is clicking, it's executing the same DOM transformations in response to the same MutationObservers. It's just executing them faster because it's not going through a client-side compilation step.

                The point of React Native - which, again, I'm not a fan of - isn't that it's written in the awkward JSX syntax, but that it's part of the same React ecosystem... presumably the same motivational drive that inspired folks to move React to the server. I don't agree that just because you like pliers that you should use pliers for every task, but I understand the instinct. Pliers are rad.

                Finally, let me make my most important point: I'm not just mindlessly typing out StimulusReflex, Turbolinks, Stimulus and CableReady because I love my keyboard. They are four distinct technologies that represent a chain of decisions; lots of folks use only 1-2 of them in a project.

                I'm not describing something being marketed and sold - in fact I'm quite jealous that you can say one word and be understood - but the specific combination of the four of them that achieves something larger than the sum of its parts. See, when you say React, it's just assumed that there's a bunch of other decisions that you're going to make - about a datastore, about a server, about how you're going to exchange data with that server - that can be swapped out for other choices. It's not going to be reality changing, no matter what you plug in.

                The stack I'm using is an example of something next. I'm not here trying to attack you or your tools. There's always going to be something that comes after the thing that was created a decade ago. Those of us building it aren't ignorant to what you're using, we're using our experience with it to go further with less.

                If you can stop robotically trying to rebut everything I say, perhaps you'll instead consider that maybe I'm not wrong. If we can get to "not wrong" then you can start getting excited about the part where I'm right.

                1. 1

                  If there is no perceptible difference to you, then I can't say anything to change your mind. You simply "don't get it", as it were, and as it's a matter of qualia, not something that can be told, I can't tell it to you. There is a qualitative difference between client and server side rendering to the user.

                  I am also not attacking your tools, but I am suggesting that you are not necessarily right, even as you think you are. Of course, you could say the same to me. I don't think there is any way to change our minds as long as I believe, again, that a difference exists between SSR and CSR. You can transmit as many DOM mutations over the wire as you want, but something on the client side will always, always feel faster.

        4. 1

          This comment was deleted 2 years ago.

    2. 3

      Hey appreciate the reply!

      I make it pretty clear in the article, I’m only making the case for Next.js for people who already know and use React.

      Totally agree you shouldn’t just pick React for no reason.

      I’ve been impressed with HEY, too. I’m a paying customer.

      XYZ for everything should never be the case, React, Rails, or otherwise.

    3. 2

      This comment was deleted 9 months ago.

      1. 1

        I get that you're just trying to be funny, but it's actually folks in your demographic that we're trying to reach out to, specifically because you are stuck in a bubble that makes you feel like you've got everything figured out.

        If you try Hey and realize that a server-rendered app with over-the-wire updates with a tiny 7k JS payload is working faster and more reactively than React, you are justified in feeling like maybe there's something to what I'm saying.

        In the meantime, I wouldn't wish raw PHP with no JS on anyone; nothing about my comment suggested that. PHP should be retired, no question.

        1. 2

          This comment was deleted 9 months ago.

          1. 1

            You need to cool off, friend. Drew doesn't need you to go agro on me, and this kind of reaction just makes it look like perhaps I have a point about the bubble, with you jamming your fingers in your ears.

            My position - it's not an argument, because I don't have a horse in your race - is that however fast you are with React-based tools, it's a local maximum. You would be even faster building complex applications with today's Rails stack, which is vastly evolved from even 2018.

            If you've been working with Rails for years, talk to me about your ideas on how React would have to change to provide a UI experience that is as snappy and responsive as Hey. It's not there yet, and you can either come to terms with that now or later.

            Build bridges, don't burn them. There's a lot left for you to learn. You're clearly a smart dude, so you must already know that these things work in pendulum cycles.

            1. 2

              This comment was deleted 9 months ago.

              1. 1

                So... not a Rails developer after all. Gotcha.

                Do you talk to people like this in person?

  2. 2

    Yeah I use Next.js for all my dynamic sites now. And once you've built one site with it you can just copy-paste most of the boilerplate code for other sites.

    In terms of hosting, Vercel is great. Though if you'd rather not pay the monthly fee (e.g. if you're pre-revenue and your Git repo is closed-source) then obviously something like Google Cloud will still work pretty well with Next.js, though of course you don't get the benefit of lambdas.

    I've recently come across svelte and am considering learning that, though unless a Next.js-like framework is available I'll probably not use it for my rapid-iteration production work just yet!

    EDIT: One downside of Vercel is that because they split your routes into lambdas they don't keep persistent logs. You have to arrange your own cloud logging service. This also means you don't get to see on the server-side which requests fail, i.e. hit invalid endpoints. Whereas on gcloud you get everything since it's running as a server, so you can see failed endpoint requests too - this helped me fix some issues on my site that I didn't even know I had.

    1. 1

      Svelte & Alpinejs are on my list to fiddle with in my spare time!

      Would love to hear how you compare the two.

      1. 1

        Oh I didn't even know about alpinejs, thanks for the tip!

  3. 2

    It's a good article, but it does not mention one important thing... Or perhaps I read it too quickly.

    You are arguing that Next.js provides solutions to many problems out-of-the box which is true, but you might not have the problems in the first place.

    Not everybody is on the React train. Not everybody is starting to learn things from scratch.

    In my mind a really good article would also discuss "why not Next.js" instead of just being 100% evangelization :).

    1. 2

      Hi thanks for reading,

      I clearly state a couple places in the article I’m only arguing this for people who already know React.

      There’s even a section where I say I only use React for projects because I know it wel 🙂

      Use what helps you build quickly.

      Focus on relentlessly shipping value. Everything else is a distraction (besides sales).

  4. 1

    Awesome article, Drew. I'm part of a company that uses Next.js and Vercel exclusively for our greenfield web projects, so much that we've built our our own JAMstack starter kit around it. You article captures a ton of the reasons why, and with charts to boot :)

    Would love your thoughts on our starter kit if you get around to checking it out. It's called Bison. https://github.com/echobind/bisonapp

    Thanks for writing this!

  5. 1

    Thanks for the article.

    In the SSR section , this catched my attention :
    "Note: this works best for marketing pages and content that doesn't change from user to user."

    But isn't the whole point of react is to create apps where content change from user to user ? In that case SSR is not possible ?
    Wouldn't react be an overkill for marketing pages.

    1. 3

      Hey thanks for reading!

      I was talking specifically about using SSR only approach.

      If for each user you need to render something unique on the server side, each incoming request will be slower.

      I was talking about the architecture commonly used prior to Next.js. I mentioned this story where we did it at an old job:


      We did not SSR:

      • cart pages
      • profile pages
      • settings pages

      These do not matter for SEO and SSR provides less benefit there.

      Next magically handles this case, and makes it so we don’t have to think about this stuff as much 🙂

      Hopefully that makes sense.

  6. 1

    Good article friend, for me, is a no-brain decision using Next when working with React, same as Nuxt for Vue. There's no reason to do everything yourself(SSR, PWA(in case of Nuxt), Etc).

    The only thing I felt missing in Next is a out-of-the-box solution for Redux(or other state management library) like Nuxt has with Vuex.

    1. 1

      I’ve personally used React Context and either Apollo or SWR and it’s worked well for most small scale apps.

  7. 1

    I'm using it for https://midnight.pub and it's enabled me to do a lot.

    1. 1

      Nice! Your site loads super fast and feels snappy.

Trending on Indie Hackers
Share your product or landing page, and I'll give you product design advice 126 comments How do I transition from a wantrepreneur to an entrepreneur? 48 comments Share your project below👇 and I'll share it with 3,000 newsletter subscribers 36 comments Building a microsaas in public 18 comments App Stores are powerful search engines 15 comments Working towards an MVP 10 comments