6 ms·

I don't think that's a fair characterization of the "Start a New React Project" page [0]. Next.js is the first option listed and is described as a way to "creat

by bryik 4y ago

I don't think that's a fair characterization of the "Start a New React Project" page [0]. Next.js is the first option listed and is described as a way to "create React apps of any size—from a mostly static blog to a complex dynamic application." This reads to me like "Next.js can do SPAs (like CRA) plus static sites and SSR". Next.js' site even says "The core of Next.js has been designed to enable starting as a static site (or Single-Page Application)" [1]. 0 - https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project 1 - https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export

leerob 4y ago
Your understanding is correct – Next.js can do static sites, SPAs, SSR – all of them. We (just today) updated the Next.js docs linked based on feedback around this to make it more clear. Hopefully this helps, let me know if you have other feedback.
jameshart 4y ago
"The core of Next.js has been designed to enable starting as a static site" is a little contradicted by the fact static export is considered an 'advanced feature' though. That said, I'm not sure why running `next export` is considered 'advanced'.
- leerob 4y ago
  I'd say this is documentation organization "debt" – there's a bunch of "advanced" features that aren't that advanced. We're aware and fixing with the new docs -> https://beta.nextjs.org/ https://beta.nextjs.org/
  - klysm 4y ago
    The part about this that bothers me is it not being documented well is in vercels financial interest
    - freedomben 4y ago
      This is what has made me hesitant to really invest deeply in Next.js. It's just too familiar where some open source project starts. Later it attempts to monetize. Some feature in open source makes it so new monetization thing (usually cloud functionality) isn't needed, so those feature(s) get downplayed, neglected, and eventually deprecated, often with self-fulfilled prophecy/declaration of "nobody is using those" (because they were engineered that way, but that inconvenient part is never mentioned and rarely acknowledged). It's one thing not to invest in unprofitable features (that's understandable for a for-profit company), but making them difficult or more obscure to use is often a part of this pattern. I'm not saying Next.js is doing that with static export, but I'm not sure they aren't either. It fits the pattern too well. I'm still suspicious about how the Image implementation (which nearly every website needs) breaks `export` and the only solution is "roll your own image handler." I'm not sure if that fits into the understandable lack off investment or the intentional difficult/obscure.
      - leerob 4y ago
        We've made quite a few improvements to the static export with the new App Router, including support Server Components, Route Handlers, i18n routes, and more. Definitely still being invested in. My comment about documentation debt is that the entire information architecture of the Next.js docs needed some work. It's being fixed and will be stable soon. You can read more about how to use Image Optimization with a static export in the new docs: https://beta.nextjs.org/docs/configuring/static-export https://beta.nextjs.org/docs/configuring/static-export. There's a full example there with Cloudinary, but you could use any service you want.
        freedomben 4y ago
        Nice, thanks for the link. Those new docs do look great! I wanted to note that I'm not asking you to build this, I'm more sharing my use-case in case it's helpful feedback. What would really be amazing for me is a build-time image processing pipeline. Any images I use for the static site are already present in the repo (none are user-supplied or come from object storage, etc). Since all the image info is present at build/export time, it would be amazing if the image processing were done locally during the build and then the next/Image tags would instead of invoking server-side code, generate the static <img> code necessary to reference the different versions (such as srcset, sizes, etc)[1]. There is at least one open source project to do that, but at least when I last tried it, it was essentially dead on the vine. I searched around but couldn't find any solutions, which was pretty disappointing. I did end up shipping the app and just manually pipelined those images and hacked out the <img> tags instead of using the component, but if I had more than a handful in the site that wouldn't scale too well. Anyway, thanks for what you've done with next.js! it's really an incredible project and you've been an important part of moving the web forward. [1]: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
- darepublic 4y ago
  I only use next.js in the static context.
synergy20 4y ago
Vercel's next.js and sveltekit are both SSR first because that's its business needs, which has nothing to do with mine(CSR only case), and Vercel is actively pushing the SSR-can-do-it-all in the open source space, I feel it is very much short-sighted. Just use vuejs which is the only one truly never forces SSR on you if you do not want to have anything to do with it.
- Rauchg 4y ago
  I actually strongly advocate for: SSR and server is the absolute best default[1], and Next.js gives you tremendous flexibility on where to place your compute[2], including skipping SSR altogether[3], with the best-in-class static export that can actually at least put some content in your HTML instead of a blank page[4] [1] https://rauchg.com/2014/7-principles-of-rich-web-applications#pre-rendered-pages-are-not-optional https://rauchg.com/2014/7-principles-of-rich-web-application... [2] https://twitter.com/rauchg/status/1637136013083684864 https://twitter.com/rauchg/status/1637136013083684864 [3] https://twitter.com/timneutkens/status/1636693508223270912 https://twitter.com/timneutkens/status/1636693508223270912 [4] https://twitter.com/dan_abramov/status/1636827365677383700 https://twitter.com/dan_abramov/status/1636827365677383700
- chambers 4y ago
  Speaking as an engineering manager, vercel’s approach seems to cater to the last market where overengineering and complexity were status symbols that middle management was happy to pay for. When the headcount was free, there weren’t many questions from upper management why basic UIs required so much heavy lifting by (overly) experienced engineers. In the new market, there will be much more scrutiny on costs and the complexity that creates it. The prospect of hiring a “React Engineer” with 7+ years of experience to build a cookie cutter UI, will be just as questionable as forcing the front end and backend to use the same technology and framework governed by one single vendor. I predict vercel will have a rough time.
  - Rauchg 4y ago
    Interestingly, I have the exact opposite bet: “SPAs were a zero interest rate phenomenon”. Putting the burden of compute on clients, and shipping slower apps for the sake of DX and convenience. Customer-first wins. Looking forward to see how this plays out.
eric-burel 4y ago
next export, the feature that produces a "true" SPA out of a Next.js app, has been under-developed for along time. However the very newest developments in Next 13 seems to fix that, making Next.js truly versatile
- leerob 4y ago
  New docs are a work-in-progress here: https://beta.nextjs.org/docs/configuring/static-export https://beta.nextjs.org/docs/configuring/static-export

by bryik 4y ago

leerob 4y ago

Your understanding is correct – Next.js can do static sites, SPAs, SSR – all of them. We (just today) updated the Next.js docs linked based on feedback around this to make it more clear. Hopefully this helps, let me know if you have other feedback.

jameshart 4y ago

"The core of Next.js has been designed to enable starting as a static site" is a little contradicted by the fact static export is considered an 'advanced feature' though. That said, I'm not sure why running `next export` is considered 'advanced'.

leerob 4y ago
I'd say this is documentation organization "debt" – there's a bunch of "advanced" features that aren't that advanced. We're aware and fixing with the new docs -> https://beta.nextjs.org/ https://beta.nextjs.org/
- klysm 4y ago
  The part about this that bothers me is it not being documented well is in vercels financial interest
  - freedomben 4y ago
    This is what has made me hesitant to really invest deeply in Next.js. It's just too familiar where some open source project starts. Later it attempts to monetize. Some feature in open source makes it so new monetization thing (usually cloud functionality) isn't needed, so those feature(s) get downplayed, neglected, and eventually deprecated, often with self-fulfilled prophecy/declaration of "nobody is using those" (because they were engineered that way, but that inconvenient part is never mentioned and rarely acknowledged). It's one thing not to invest in unprofitable features (that's understandable for a for-profit company), but making them difficult or more obscure to use is often a part of this pattern. I'm not saying Next.js is doing that with static export, but I'm not sure they aren't either. It fits the pattern too well. I'm still suspicious about how the Image implementation (which nearly every website needs) breaks `export` and the only solution is "roll your own image handler." I'm not sure if that fits into the understandable lack off investment or the intentional difficult/obscure.
    - leerob 4y ago
      We've made quite a few improvements to the static export with the new App Router, including support Server Components, Route Handlers, i18n routes, and more. Definitely still being invested in. My comment about documentation debt is that the entire information architecture of the Next.js docs needed some work. It's being fixed and will be stable soon. You can read more about how to use Image Optimization with a static export in the new docs: https://beta.nextjs.org/docs/configuring/static-export https://beta.nextjs.org/docs/configuring/static-export. There's a full example there with Cloudinary, but you could use any service you want.
      - freedomben 4y ago
        Nice, thanks for the link. Those new docs do look great! I wanted to note that I'm not asking you to build this, I'm more sharing my use-case in case it's helpful feedback. What would really be amazing for me is a build-time image processing pipeline. Any images I use for the static site are already present in the repo (none are user-supplied or come from object storage, etc). Since all the image info is present at build/export time, it would be amazing if the image processing were done locally during the build and then the next/Image tags would instead of invoking server-side code, generate the static <img> code necessary to reference the different versions (such as srcset, sizes, etc)[1]. There is at least one open source project to do that, but at least when I last tried it, it was essentially dead on the vine. I searched around but couldn't find any solutions, which was pretty disappointing. I did end up shipping the app and just manually pipelined those images and hacked out the <img> tags instead of using the component, but if I had more than a handful in the site that wouldn't scale too well. Anyway, thanks for what you've done with next.js! it's really an incredible project and you've been an important part of moving the web forward. [1]: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
darepublic 4y ago
I only use next.js in the static context.

synergy20 4y ago

Vercel's next.js and sveltekit are both SSR first because that's its business needs, which has nothing to do with mine(CSR only case), and Vercel is actively pushing the SSR-can-do-it-all in the open source space, I feel it is very much short-sighted. Just use vuejs which is the only one truly never forces SSR on you if you do not want to have anything to do with it.

Rauchg 4y ago
I actually strongly advocate for: SSR and server is the absolute best default[1], and Next.js gives you tremendous flexibility on where to place your compute[2], including skipping SSR altogether[3], with the best-in-class static export that can actually at least put some content in your HTML instead of a blank page[4] [1] https://rauchg.com/2014/7-principles-of-rich-web-applications#pre-rendered-pages-are-not-optional https://rauchg.com/2014/7-principles-of-rich-web-application... [2] https://twitter.com/rauchg/status/1637136013083684864 https://twitter.com/rauchg/status/1637136013083684864 [3] https://twitter.com/timneutkens/status/1636693508223270912 https://twitter.com/timneutkens/status/1636693508223270912 [4] https://twitter.com/dan_abramov/status/1636827365677383700 https://twitter.com/dan_abramov/status/1636827365677383700
chambers 4y ago
Speaking as an engineering manager, vercel’s approach seems to cater to the last market where overengineering and complexity were status symbols that middle management was happy to pay for. When the headcount was free, there weren’t many questions from upper management why basic UIs required so much heavy lifting by (overly) experienced engineers. In the new market, there will be much more scrutiny on costs and the complexity that creates it. The prospect of hiring a “React Engineer” with 7+ years of experience to build a cookie cutter UI, will be just as questionable as forcing the front end and backend to use the same technology and framework governed by one single vendor. I predict vercel will have a rough time.
- Rauchg 4y ago
  Interestingly, I have the exact opposite bet: “SPAs were a zero interest rate phenomenon”. Putting the burden of compute on clients, and shipping slower apps for the sake of DX and convenience. Customer-first wins. Looking forward to see how this plays out.

eric-burel 4y ago

next export, the feature that produces a "true" SPA out of a Next.js app, has been under-developed for along time. However the very newest developments in Next 13 seems to fix that, making Next.js truly versatile

leerob 4y ago
New docs are a work-in-progress here: https://beta.nextjs.org/docs/configuring/static-export https://beta.nextjs.org/docs/configuring/static-export