5 ms·

Migrating to Next.js from Create React App

49 points by omarfarooq 5y ago

vjeux 5y ago
The title should be changed from “from React.js” to “from create-react-app”. Next is still based on React.js.
- lioeters 5y ago
  Indeed the title as it is doesn't make sense. The original is: "Migrating from Create React App".
  - omarfarooq 5y ago
    Titled updated.
    - zkldi 5y ago
      This still isn't correct - vanilla react.js is not create-react-app at all.
      - deleted 5y ago
        [deleted]
      - deleted 5y ago
        [deleted]
  - dang 5y ago
    Fixed. Thanks!
presentation 5y ago
I just did a migration for a pretty large CRA app to Next.js, and it wasn't particularly simple. A lot of stuff changes - for instance `react-router` is common in CRA but NextJS has its own routing system and link components, `loadable-components` is what we used in CRA for code-splitting but instead Next has `next/dynamic`, managing the `head` also changes... these differences pile up. I ended up making contexts that contained generic cross-platform implementations of stuff like links and dynamic components, that shared code could consume in order to function on both CRA and NextJS simultaneously - this made it possible to move things incrementally.
- terandle 5y ago
  What were the benefits you saw after moving to next.js? Personally I'm still using CRA unless I need SSR as I prefer react-router to file based routing.
  - presentation 5y ago
    Our site went from largest content display of several seconds to <1s. Also we don't need to use Prerender anymore to give real HTML to dumb crawlers that don't run JS.
- rattray 5y ago
  Any chance you could share some of those? Have looked at doing the same thing for a few apps and the risk/difficulty of trying to do it in One Big Pull Request was too much each time...
  - presentation 5y ago
    There’s some stuff that is specific to our site (we have custom link components for instance) but yeah I can post it somewhere. I’ll put together a post when I have some spare time.
- sergiotapia 5y ago
  I'm migrating away from clientside entirely. Back to server side rendering; it's been cool but I'm just tired of it. You have to do so much crap to get stuff running nicely and it's all very brittle. code splitting, routers, changes to <head>, links, permissions, etc. I'm hitting the reset button and going all in with server side render templates again. Going to PETAL stack.
splch 5y ago
I'm looking forward to "Migrating to NewerAndHeavierFramework.js from OldAndHeavyFramework.js"
fictionfuture 5y ago
Next is nice and all but FactorJS V3 is looking awesome. Check it out if you haven't seen and don't mind Vue
- yawnxyz 5y ago
  Better than Nuxt? I've never heard of Factor, and checking now, but can't (superficially) grok the differences
- afloatboat 5y ago
  I wanted to check out Factor a couple of weeks ago and got stuck on the installation step, an error about it using esmodules for lodash if I remember correctly. The docs were behind an authwall and there was a forum full of spam and one thread with the same issue 4 months old and one reply 2 months old by a user who had the same issue and no resolution. All in all that was a poor experience for me. Granted, it was under development but it doesn’t seem like there was much community at the time and no clear development path either. I checked the site again after your comment and it seems they’ve launched now so I’ll check again, although I’m mostly interested in a headless CMS which isn’t what Factor is trying to be. As for Next, I’ve played around with it and I liked the built-in support for Head, Image and Link. The SSR and lazy loading is amazing and should be the default for every tool, I hate that CRA does not support this out of the box. I was surprised when I tried to export my test and I couldn’t find an output folder though, and even more surprised and disappointed when I found you had to do `next build && next export` which immediately threw an error because the default loading behaviour of the Image component relies on Vercel hosting to work.
brundolf 5y ago
There are some things I don't love about Next - its TypeScript declarations aren't great, it has a fair share of "magic behavior", and it truly is a "framework" where some features won't work until Next adds explicit support for them. But it is insanely productive if you want to do a mixture of static rendering/server rendering/client rendering. The abstraction leaks here and there, but mostly it holds up, and more importantly almost all of your code can be shared. If you want to do just one of the three, there are better options. But if you're doing client-side + one or both of the other two then it's amazing, and I don't know of anything better.
- revicon 5y ago
  I’m curious why Nextjs is needed. I’ve started just building dynamic websites rendered on the server serving the content I need search engines to be able to crawl and then I drop a js file on each page which instruments whatever components I want to use react for on top of the already rendered html page. It’s worked very well for me so far, I have webpack build one JS file for each page I want to instrument and then I write react just like I usually do. Maybe my use case is different from what Nextjs is built for.
  - meowtimemania 5y ago
    I think the reason to use next is so you don’t have to set all the stuff up yourself. Server side rendering with react and setting up webpack can be really time consuming, that’s why I use nextjs
  - gherkinnn 5y ago
    The fact that I don’t want to roll my own framework. What are the chances that I build something that is on par with something stable worked on by dozens? There’s a slew of features that I have zero interest in building, maintaining, and fixing while I could build the actual product instead.
  - brundolf 5y ago
    With Next I can take a single component and move it from client, to server, back to client, to static rendering. Or do all three on different pages that reference the same child component. Or have it static-render and then get automatically hydrated with client-side rendering when needed. Going between each of these modes for a given top-level page is a matter of changing a few lines of code; child components will Just Work(TM) in all of the above contexts without modification. None of this is impossible to do yourself, but Next makes it absolutely breezy, plus additional features like hot-reloading during dev, code-splitting on a per-page basis, and prefetching of those split bundles. You can also do crazy stuff like statically render all your pages so that the first page the user hits (regardless of which one it is) will get fetched as HTML, but then have all further navigation happen totally on the client side, where the same React code is getting run on the client that was used to statically render all the HTML at build time, so there's no worry about inconsistency. Frankly, in a hand-rolled site I wouldn't even bother doing some of the fancier stuff Next does, even if I knew how and knew it would be beneficial, because it would just be so darn complicated. But when it's this effortless, I can casually do it wherever it makes sense to (or experiment to find out whether or not it makes sense to!).
victorbstan 5y ago
I’m migrating to post.js after next.js
- leerob 5y ago
  Would you mind sharing more?
rhapsodic 5y ago
"Vanilla" React.js??? Is this what it's come to?
haywirez 5y ago
Had several requests lately for the exact opposite pattern — migrating bloated Next.js projects to vanilla React SPAs. Razzle[0] seems like a workable alternative if you need static exports for optimizations such as link unfurling. Still looking for something that isn't based on Webpack (ideally esbuild or swc)— would appreciate links in replies. [0] https://razzlejs.org/docs/static-export https://razzlejs.org/docs/static-export
- wereHamster 5y ago
  Unlikely that Next.js itself caused the bloat. The same could happen with any framework, and just migrating to another one won't fix the underlying problem. Next.js may switch away from webpack (to swc) at some point in the near future (they recently hired the developer of swc).
  - leerob 5y ago
    More details on SWC transition here: https://nextjs.org/blog/next-11-1 https://nextjs.org/blog/next-11-1. There will be an opt-in flag in 11.2.
- lioeters 5y ago
  Razzle is what I used for a year or more, before moving over to Next.js. It's a solid static site generator and builder of full-stack applications. Razzle is a far more hands-off approach, one of those tools that get out of your way, and disappears when you're using it. That has great value because it doesn't dictate how you write your application. In contrast, Next.js is a framework, with its own universe of conventions, conveniences, ways to do things. It has a lot more functionality out of the box. Excellently documented, too. I'd say Next.js provides great value in a team environment, to have a common, consistent and simple build configuration as well as application structure. There's much to love about Next.js, but the only thing that bugs me is how they do opt-out telemetry. I have a postinstall script that runs "npx next telemetry disable", but it feels dirty. --- As for "bloated Next.js projects", surely that's not the fault of the framework. It does its best to produce a lean production build, so the bloat is up to the user. (Unless you mean the size of the node_modules folder during development.)
ManuelKiessling 5y ago
If SEO demands are the driving factor for your core architecture decision, then surely your users are not in the driver’s seat.
- leerob 5y ago
  This is why Core Web Vitals are great. They help make your site fast for your users _and_ help improve SEO. A better solution than AMP: https://vercel.com/blog/core-web-vitals https://vercel.com/blog/core-web-vitals
pjmlp 5y ago
Interesting how JavaScript frameworks keep rediscovering server side rendering.

49 points by omarfarooq 5y ago

vjeux 5y ago

The title should be changed from “from React.js” to “from create-react-app”. Next is still based on React.js.

lioeters 5y ago
Indeed the title as it is doesn't make sense. The original is: "Migrating from Create React App".
- omarfarooq 5y ago
  Titled updated.
  - zkldi 5y ago
    This still isn't correct - vanilla react.js is not create-react-app at all.
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
- dang 5y ago
  Fixed. Thanks!

presentation 5y ago

I just did a migration for a pretty large CRA app to Next.js, and it wasn't particularly simple. A lot of stuff changes - for instance `react-router` is common in CRA but NextJS has its own routing system and link components, `loadable-components` is what we used in CRA for code-splitting but instead Next has `next/dynamic`, managing the `head` also changes... these differences pile up. I ended up making contexts that contained generic cross-platform implementations of stuff like links and dynamic components, that shared code could consume in order to function on both CRA and NextJS simultaneously - this made it possible to move things incrementally.

terandle 5y ago
What were the benefits you saw after moving to next.js? Personally I'm still using CRA unless I need SSR as I prefer react-router to file based routing.
- presentation 5y ago
  Our site went from largest content display of several seconds to <1s. Also we don't need to use Prerender anymore to give real HTML to dumb crawlers that don't run JS.
rattray 5y ago
Any chance you could share some of those? Have looked at doing the same thing for a few apps and the risk/difficulty of trying to do it in One Big Pull Request was too much each time...
- presentation 5y ago
  There’s some stuff that is specific to our site (we have custom link components for instance) but yeah I can post it somewhere. I’ll put together a post when I have some spare time.
sergiotapia 5y ago
I'm migrating away from clientside entirely. Back to server side rendering; it's been cool but I'm just tired of it. You have to do so much crap to get stuff running nicely and it's all very brittle. code splitting, routers, changes to <head>, links, permissions, etc. I'm hitting the reset button and going all in with server side render templates again. Going to PETAL stack.

splch 5y ago

I'm looking forward to "Migrating to NewerAndHeavierFramework.js from OldAndHeavyFramework.js"

fictionfuture 5y ago

Next is nice and all but FactorJS V3 is looking awesome. Check it out if you haven't seen and don't mind Vue

yawnxyz 5y ago
Better than Nuxt? I've never heard of Factor, and checking now, but can't (superficially) grok the differences
afloatboat 5y ago
I wanted to check out Factor a couple of weeks ago and got stuck on the installation step, an error about it using esmodules for lodash if I remember correctly. The docs were behind an authwall and there was a forum full of spam and one thread with the same issue 4 months old and one reply 2 months old by a user who had the same issue and no resolution. All in all that was a poor experience for me. Granted, it was under development but it doesn’t seem like there was much community at the time and no clear development path either. I checked the site again after your comment and it seems they’ve launched now so I’ll check again, although I’m mostly interested in a headless CMS which isn’t what Factor is trying to be. As for Next, I’ve played around with it and I liked the built-in support for Head, Image and Link. The SSR and lazy loading is amazing and should be the default for every tool, I hate that CRA does not support this out of the box. I was surprised when I tried to export my test and I couldn’t find an output folder though, and even more surprised and disappointed when I found you had to do `next build && next export` which immediately threw an error because the default loading behaviour of the Image component relies on Vercel hosting to work.

brundolf 5y ago

There are some things I don't love about Next - its TypeScript declarations aren't great, it has a fair share of "magic behavior", and it truly is a "framework" where some features won't work until Next adds explicit support for them. But it is insanely productive if you want to do a mixture of static rendering/server rendering/client rendering. The abstraction leaks here and there, but mostly it holds up, and more importantly almost all of your code can be shared. If you want to do just one of the three, there are better options. But if you're doing client-side + one or both of the other two then it's amazing, and I don't know of anything better.

revicon 5y ago
I’m curious why Nextjs is needed. I’ve started just building dynamic websites rendered on the server serving the content I need search engines to be able to crawl and then I drop a js file on each page which instruments whatever components I want to use react for on top of the already rendered html page. It’s worked very well for me so far, I have webpack build one JS file for each page I want to instrument and then I write react just like I usually do. Maybe my use case is different from what Nextjs is built for.
- meowtimemania 5y ago
  I think the reason to use next is so you don’t have to set all the stuff up yourself. Server side rendering with react and setting up webpack can be really time consuming, that’s why I use nextjs
- gherkinnn 5y ago
  The fact that I don’t want to roll my own framework. What are the chances that I build something that is on par with something stable worked on by dozens? There’s a slew of features that I have zero interest in building, maintaining, and fixing while I could build the actual product instead.
- brundolf 5y ago
  With Next I can take a single component and move it from client, to server, back to client, to static rendering. Or do all three on different pages that reference the same child component. Or have it static-render and then get automatically hydrated with client-side rendering when needed. Going between each of these modes for a given top-level page is a matter of changing a few lines of code; child components will Just Work(TM) in all of the above contexts without modification. None of this is impossible to do yourself, but Next makes it absolutely breezy, plus additional features like hot-reloading during dev, code-splitting on a per-page basis, and prefetching of those split bundles. You can also do crazy stuff like statically render all your pages so that the first page the user hits (regardless of which one it is) will get fetched as HTML, but then have all further navigation happen totally on the client side, where the same React code is getting run on the client that was used to statically render all the HTML at build time, so there's no worry about inconsistency. Frankly, in a hand-rolled site I wouldn't even bother doing some of the fancier stuff Next does, even if I knew how and knew it would be beneficial, because it would just be so darn complicated. But when it's this effortless, I can casually do it wherever it makes sense to (or experiment to find out whether or not it makes sense to!).

victorbstan 5y ago

I’m migrating to post.js after next.js

leerob 5y ago
Would you mind sharing more?

rhapsodic 5y ago

"Vanilla" React.js??? Is this what it's come to?

haywirez 5y ago

Had several requests lately for the exact opposite pattern — migrating bloated Next.js projects to vanilla React SPAs. Razzle[0] seems like a workable alternative if you need static exports for optimizations such as link unfurling. Still looking for something that isn't based on Webpack (ideally esbuild or swc)— would appreciate links in replies. [0] https://razzlejs.org/docs/static-export https://razzlejs.org/docs/static-export

wereHamster 5y ago
Unlikely that Next.js itself caused the bloat. The same could happen with any framework, and just migrating to another one won't fix the underlying problem. Next.js may switch away from webpack (to swc) at some point in the near future (they recently hired the developer of swc).
- leerob 5y ago
  More details on SWC transition here: https://nextjs.org/blog/next-11-1 https://nextjs.org/blog/next-11-1. There will be an opt-in flag in 11.2.
lioeters 5y ago
Razzle is what I used for a year or more, before moving over to Next.js. It's a solid static site generator and builder of full-stack applications. Razzle is a far more hands-off approach, one of those tools that get out of your way, and disappears when you're using it. That has great value because it doesn't dictate how you write your application. In contrast, Next.js is a framework, with its own universe of conventions, conveniences, ways to do things. It has a lot more functionality out of the box. Excellently documented, too. I'd say Next.js provides great value in a team environment, to have a common, consistent and simple build configuration as well as application structure. There's much to love about Next.js, but the only thing that bugs me is how they do opt-out telemetry. I have a postinstall script that runs "npx next telemetry disable", but it feels dirty. --- As for "bloated Next.js projects", surely that's not the fault of the framework. It does its best to produce a lean production build, so the bloat is up to the user. (Unless you mean the size of the node_modules folder during development.)

ManuelKiessling 5y ago

If SEO demands are the driving factor for your core architecture decision, then surely your users are not in the driver’s seat.

leerob 5y ago
This is why Core Web Vitals are great. They help make your site fast for your users _and_ help improve SEO. A better solution than AMP: https://vercel.com/blog/core-web-vitals https://vercel.com/blog/core-web-vitals

pjmlp 5y ago

Interesting how JavaScript frameworks keep rediscovering server side rendering.