6 ms·

I've only very recently heard of Next.js, what is the ideal use case for it?

dbbk 5y ago
If you have a simple marketing or brochure site, and want to use React, it’s pretty much a no brainer. Anything more complicated eg a dashboard app, you’re going to be fighting it a lot.
- thesandlord 5y ago
  I do not agree with that assessment at all. Next.js is great for making SPAs and full web apps. I've made three (profitable) projects with Next.js and never felt like I had to fight it
  - dbbk 5y ago
    Really? I've made multiple attempts and always get stuck as soon as you have nested layouts or routes, which dashboards nearly always do (with master/detail views for instance).
    - dfabulich 5y ago
      "Nested layouts" just sounds like nested React components. React is kinda weird… you have to do subcomponents the "React way" and I think a lot of folks struggle with that; it can feel like fighting. But I don't think Next makes that any easier or harder. I don't know what you mean by "nested routes." Routes are just URLs that map to files. You can create a directory with files, and, uh, subdirectories with files, if you want…?
      - jamil7 5y ago
        I’m guessing they mean pieces of state based on urls, like which tab is active here or is a modal open or closed kind of thing.
      - dbbk 5y ago
        In Next, every route blows away the DOM and starts over. You can’t have nested routes like you can in React Router, where say you have different layout shells for logged out / logged in views, and then master/detail views where you navigate down a hierarchical navigation.
        ranza 5y ago
        Well you sort of can. Just have a [view].js file, where the view variable will be the component. So you can have {view === 'details' && <Details />}
  - tablef 5y ago
    Do you have any public project template repos?
  - gherkinnn 5y ago
    The key is being page-based. If you can use the browser and URLs as a state machine for your application, Next is excellent. Its dynamic routing is a breeze to work with. However, if you build an application where that browser-as-state-machine doesn't hold up, you're better off somewhere else.
    - thesandlord 5y ago
      Yeah, you have to follow their design pattern / scaffolding very closely. The tradeoff is less flexibility for faster dev cycles.
  - steve_adams_86 5y ago
    Likewise, I've found it great at allowing you to embed complex logic into dumb content. What we needed was convention to deliver static content easily without needing to build it ourselves. But we also needed it to stay out of the way of our business logic. Overall, Next has done a stellar job of that. It allows us to build the stuff that matters to us while leaving what Next is great at to Next and its maintainers. The vercel platform has also been great for us when staging deployments. It's a little slow, but the integration and ease of use again lets us focus on our own business. I don't care to build out staging infrastructure for mostly static content. It's well within everyone's ability on this team, but it's time consuming in investment and maintenance. Recouping that cost is what Next has been great for, from end to end.
steve_adams_86 5y ago
It's a fairly guard-railed, easy to deploy, React-based static site generator with dynamic content capabilities as well. It's generally great software. My team uses it for https://instantdomainsearch.com https://instantdomainsearch.com and we get good performance and developer experience overall. To me it feels like the React "happy path" at the moment if you need a static or partially dynamic site/web application. I suppose the ideal use case is essentially any site you want to serve statically but maintain with React. This could be a blog, graphic design portfolio, or even a small store. It makes it easy for us to embed our React-based search application inside of a site with static content beside it that's easy to maintain and create. Yeah, we could do this without next, but it provides some convention and well-made tools that generally make the job easier.
- notjustanymike 5y ago
  I've only ever used Gatsby with this, how does it compare?
  - steve_adams_86 5y ago
    Good question. Our migration was fairly direct. We did it in around a week with some cleanup in the following week. There were analogous conventions throughout just about the entire migration, so they're very similar. One thing we liked was better TypeScript support. We're big on types and proper support, and most of our company is based on TypeScript and Rust. Gatsby can use TS, but you need to set it up and we came across the odd hiccup in the tooling. Next supports this off the shelf and so far, it shows. We haven't had any issues with compilation anywhere in the pipeline or other tooling. The way Next handles dynamic pages is different, and in my opinion nicer. It also supports something they call incremental static generation which allows pages to be served statically, but incrementally updated as dependent data changes. For example, you know the team in the lead will be the same for thousands of requests, so you might as well serve that statically until the leading team changes. Next will manage that content update for you while serving the content statically for as long as possible. When we migrated, Gatsby didn't support this feature. Next handles pages differently in general. It maps your directory structure under /src/pages, so that /src/pages/hello-world.tsx will be yourwebsite.com/hello-world. It allows for dynamic content using a convention in which file names can represent a variable, where src/pages/foo/[bar].tsx will make it so [bar] is a variable in the query intercepted by getServerSideProps when you visit yourwebsite.com/foo/whatever. Otherwise I think the main snag we had with Gatsby was that the team was slower to address issues, introduced bugs more frequently, and we began to see that it was impeding our progress. Our software was working independently of Gatsby and wasn't the issue, and no matter how closely we worked with the maintainers, we couldn't move the needle on any blocking issues. With Next it has been a much different story. Issues are unblocked routinely and the maintainers seem much more engaged and productive. There's more, but those are the main differences that come to mind.
gherkinnn 5y ago
As Next ambiguously puts it: "The React Framework for Production" [0] It's excellent for building page-based sites and apps and comes with lots of nifty features that just seem to work. And, the most part, it's just out of your way. Regarding the ideal use, I'd say any project that benefits greatly from (partially) pre-rendered content and statically generated pages is best served by Next and its data fetching [1]. I can't think of a FE-based solution that is anywhere near as good. It's also the only sane way to work with the insanity that is JAM stack [2]. Whatever you do, it's a safe bet. 0 - https://nextjs.org https://nextjs.org 1 - https://nextjs.org/docs/basic-features/data-fetching https://nextjs.org/docs/basic-features/data-fetching 2 - https://jamstack.org https://jamstack.org
- anichhangani 5y ago
  sounds similar to aspnet razor pages. is it?
  - RobertKerans 5y ago
    Looking at the razor pages overview & that seems a very reasonable comparison (now you mention that, see PHP, in the form of "just chuck a few files on a server that understands them and off you go, dynamic website")
- blowski 5y ago
  Worth adding that Next is to React what Nuxt is to Vue, though if you don’t know what Nuxt is, that won’t help.
  - gherkinnn 5y ago
    And what Svelte Kit is to Svelte. ;)
unknown_error 5y ago
We're using it to build a headless Jamstack (headless CMS backend, React frontend). Next.js makes the frontend a lot nicer to work with, especially if you want to deploy to a serverless config. Out of the box, it handles things like: * Data pre-fetching (Next talks to the CMS during build instead of via a clientside request during load), then inlines the JSON response into the page so the React components have access to their initial load data (like the first page in a gallery, or the first set of blog posts) as soon as the page loads. No AJAX required. It's FAST for visitors. * Handles page routing (like /blog/my-post or /products/24453) by mapping CMS entries into page templates * Makes the developer experience a lot nicer, with preconfigured but extensible webpack, sass, tailwinds etc. support. Also extends the create-react-app dev server to support all the next features so you can get a good preview of how something works before you build for production * Adds a bunch of optimizations (CSS, web fonts, tree-shaking) for faster performance * Has optional modules you can use (authentication, ecommerce, AMP, etc.) * It renders React + the data into straight HTML+CSS (again, fast) and that means some React components also work without Javascript enabled Additionally, if you host on Vercel*, you get some additional features: * Automatic image optimizations (auto-generated srcsets, webp, blurry lazy loads, etc. on the CDN) * Incremental static regeneration: A backend server monitors the CMS for changes every X seconds, then rebuilds only the affected page (in a few seconds) instead of the whole project * Complex rewrite rules that would normally be difficult with a static site. Not as powerful as .htaccess or Varnish rules, but good enough for simple cases In general, the upside is that it turns React from a feature library to a more fully-featured web app framework. Still not as powerful as Angular, but hits that sweet spot where you can easily spin up a website with Next.js in a few minutes, and not have to worry about scaffolding or be overwhelmed by having to get a PhD in Angular before you can start using it. The downside is that its primary maintainer, Vercel, also runs a hosting service. There is an inherent conflict of interest there because some Next.js are Vercel-only, and these are NOT clearly labeled in the docs. You just have to find out, upon deployment, that some features just invisibly break with no error or warning if you try to self-host or host elsewhere. Everything magically works on Vercel, but it's a crapshoot anywhere else. And it's only getting worse as they keep iterating features like next/image or Next Live but only with Vercel support. Edit: Sorry about the formatting. I don't know what formatting engine HackerNews uses but it's awkward.

dbbk 5y ago

If you have a simple marketing or brochure site, and want to use React, it’s pretty much a no brainer. Anything more complicated eg a dashboard app, you’re going to be fighting it a lot.

thesandlord 5y ago
I do not agree with that assessment at all. Next.js is great for making SPAs and full web apps. I've made three (profitable) projects with Next.js and never felt like I had to fight it
- dbbk 5y ago
  Really? I've made multiple attempts and always get stuck as soon as you have nested layouts or routes, which dashboards nearly always do (with master/detail views for instance).
  - dfabulich 5y ago
    "Nested layouts" just sounds like nested React components. React is kinda weird… you have to do subcomponents the "React way" and I think a lot of folks struggle with that; it can feel like fighting. But I don't think Next makes that any easier or harder. I don't know what you mean by "nested routes." Routes are just URLs that map to files. You can create a directory with files, and, uh, subdirectories with files, if you want…?
    - jamil7 5y ago
      I’m guessing they mean pieces of state based on urls, like which tab is active here or is a modal open or closed kind of thing.
    - dbbk 5y ago
      In Next, every route blows away the DOM and starts over. You can’t have nested routes like you can in React Router, where say you have different layout shells for logged out / logged in views, and then master/detail views where you navigate down a hierarchical navigation.
      - ranza 5y ago
        Well you sort of can. Just have a [view].js file, where the view variable will be the component. So you can have {view === 'details' && <Details />}
- tablef 5y ago
  Do you have any public project template repos?
- gherkinnn 5y ago
  The key is being page-based. If you can use the browser and URLs as a state machine for your application, Next is excellent. Its dynamic routing is a breeze to work with. However, if you build an application where that browser-as-state-machine doesn't hold up, you're better off somewhere else.
  - thesandlord 5y ago
    Yeah, you have to follow their design pattern / scaffolding very closely. The tradeoff is less flexibility for faster dev cycles.
- steve_adams_86 5y ago
  Likewise, I've found it great at allowing you to embed complex logic into dumb content. What we needed was convention to deliver static content easily without needing to build it ourselves. But we also needed it to stay out of the way of our business logic. Overall, Next has done a stellar job of that. It allows us to build the stuff that matters to us while leaving what Next is great at to Next and its maintainers. The vercel platform has also been great for us when staging deployments. It's a little slow, but the integration and ease of use again lets us focus on our own business. I don't care to build out staging infrastructure for mostly static content. It's well within everyone's ability on this team, but it's time consuming in investment and maintenance. Recouping that cost is what Next has been great for, from end to end.

steve_adams_86 5y ago

It's a fairly guard-railed, easy to deploy, React-based static site generator with dynamic content capabilities as well. It's generally great software. My team uses it for https://instantdomainsearch.com https://instantdomainsearch.com and we get good performance and developer experience overall. To me it feels like the React "happy path" at the moment if you need a static or partially dynamic site/web application. I suppose the ideal use case is essentially any site you want to serve statically but maintain with React. This could be a blog, graphic design portfolio, or even a small store. It makes it easy for us to embed our React-based search application inside of a site with static content beside it that's easy to maintain and create. Yeah, we could do this without next, but it provides some convention and well-made tools that generally make the job easier.

notjustanymike 5y ago
I've only ever used Gatsby with this, how does it compare?
- steve_adams_86 5y ago
  Good question. Our migration was fairly direct. We did it in around a week with some cleanup in the following week. There were analogous conventions throughout just about the entire migration, so they're very similar. One thing we liked was better TypeScript support. We're big on types and proper support, and most of our company is based on TypeScript and Rust. Gatsby can use TS, but you need to set it up and we came across the odd hiccup in the tooling. Next supports this off the shelf and so far, it shows. We haven't had any issues with compilation anywhere in the pipeline or other tooling. The way Next handles dynamic pages is different, and in my opinion nicer. It also supports something they call incremental static generation which allows pages to be served statically, but incrementally updated as dependent data changes. For example, you know the team in the lead will be the same for thousands of requests, so you might as well serve that statically until the leading team changes. Next will manage that content update for you while serving the content statically for as long as possible. When we migrated, Gatsby didn't support this feature. Next handles pages differently in general. It maps your directory structure under /src/pages, so that /src/pages/hello-world.tsx will be yourwebsite.com/hello-world. It allows for dynamic content using a convention in which file names can represent a variable, where src/pages/foo/[bar].tsx will make it so [bar] is a variable in the query intercepted by getServerSideProps when you visit yourwebsite.com/foo/whatever. Otherwise I think the main snag we had with Gatsby was that the team was slower to address issues, introduced bugs more frequently, and we began to see that it was impeding our progress. Our software was working independently of Gatsby and wasn't the issue, and no matter how closely we worked with the maintainers, we couldn't move the needle on any blocking issues. With Next it has been a much different story. Issues are unblocked routinely and the maintainers seem much more engaged and productive. There's more, but those are the main differences that come to mind.

gherkinnn 5y ago

As Next ambiguously puts it: "The React Framework for Production" [0] It's excellent for building page-based sites and apps and comes with lots of nifty features that just seem to work. And, the most part, it's just out of your way. Regarding the ideal use, I'd say any project that benefits greatly from (partially) pre-rendered content and statically generated pages is best served by Next and its data fetching [1]. I can't think of a FE-based solution that is anywhere near as good. It's also the only sane way to work with the insanity that is JAM stack [2]. Whatever you do, it's a safe bet. 0 - https://nextjs.org https://nextjs.org 1 - https://nextjs.org/docs/basic-features/data-fetching https://nextjs.org/docs/basic-features/data-fetching 2 - https://jamstack.org https://jamstack.org

anichhangani 5y ago
sounds similar to aspnet razor pages. is it?
- RobertKerans 5y ago
  Looking at the razor pages overview & that seems a very reasonable comparison (now you mention that, see PHP, in the form of "just chuck a few files on a server that understands them and off you go, dynamic website")
blowski 5y ago
Worth adding that Next is to React what Nuxt is to Vue, though if you don’t know what Nuxt is, that won’t help.
- gherkinnn 5y ago
  And what Svelte Kit is to Svelte. ;)

unknown_error 5y ago

We're using it to build a headless Jamstack (headless CMS backend, React frontend). Next.js makes the frontend a lot nicer to work with, especially if you want to deploy to a serverless config. Out of the box, it handles things like: * Data pre-fetching (Next talks to the CMS during build instead of via a clientside request during load), then inlines the JSON response into the page so the React components have access to their initial load data (like the first page in a gallery, or the first set of blog posts) as soon as the page loads. No AJAX required. It's FAST for visitors. * Handles page routing (like /blog/my-post or /products/24453) by mapping CMS entries into page templates * Makes the developer experience a lot nicer, with preconfigured but extensible webpack, sass, tailwinds etc. support. Also extends the create-react-app dev server to support all the next features so you can get a good preview of how something works before you build for production * Adds a bunch of optimizations (CSS, web fonts, tree-shaking) for faster performance * Has optional modules you can use (authentication, ecommerce, AMP, etc.) * It renders React + the data into straight HTML+CSS (again, fast) and that means some React components also work without Javascript enabled Additionally, if you host on Vercel*, you get some additional features: * Automatic image optimizations (auto-generated srcsets, webp, blurry lazy loads, etc. on the CDN) * Incremental static regeneration: A backend server monitors the CMS for changes every X seconds, then rebuilds only the affected page (in a few seconds) instead of the whole project * Complex rewrite rules that would normally be difficult with a static site. Not as powerful as .htaccess or Varnish rules, but good enough for simple cases In general, the upside is that it turns React from a feature library to a more fully-featured web app framework. Still not as powerful as Angular, but hits that sweet spot where you can easily spin up a website with Next.js in a few minutes, and not have to worry about scaffolding or be overwhelmed by having to get a PhD in Angular before you can start using it. The downside is that its primary maintainer, Vercel, also runs a hosting service. There is an inherent conflict of interest there because some Next.js are Vercel-only, and these are NOT clearly labeled in the docs. You just have to find out, upon deployment, that some features just invisibly break with no error or warning if you try to self-host or host elsewhere. Everything magically works on Vercel, but it's a crapshoot anywhere else. And it's only getting worse as they keep iterating features like next/image or Next Live but only with Vercel support. Edit: Sorry about the formatting. I don't know what formatting engine HackerNews uses but it's awkward.