4 ms·

Agreed. I'm a big fan of Next.js and haven't had any major problems with it. While there have been some quirks and nuances I had to learn[0] it still provides t

by leerob 8y ago

Agreed. I'm a big fan of Next.js and haven't had any major problems with it. While there have been some quirks and nuances I had to learn[0] it still provides the easiest platform for SSR out of the box. [0]: https://leerob.io/blog/things-ive-learned-building-nextjs-apps/ https://leerob.io/blog/things-ive-learned-building-nextjs-ap...

chatmasta 8y ago
I'm evaluating next.js for a new project. But coming from create-react-app, I'm a bit skeptical of these "frameworks" that seem to provide little benefit beyond developer tooling (i.e. setting up webpack, hot reload etc). create-react-app was great in the beginning, but months later was really annoying. I get the feeling next.js could end up like that. At least you can eject from CRA. I'm curious if anyone has gone the "roll your own" route with SSR + react, starting with a simple approach and adding complexity only as it becomes necessary. Has anyone done this and maybe also used next.js? I would love to hear a comparison, because at the moment I'm unconvinced next.js is really necessary if you know what you're doing, or you intend to maintain the project for more than 2 years.
- davidjnelson 8y ago
  The spectrum chat team, which GitHub acquired, wrote that they wish they had started with next.js https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/ https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/
  - mxstbr 8y ago
    That's my blog post! If you have any questions let me know.
- lioeters 8y ago
  I'd highly recommend trying out Next.js. Once you've got the framework-specific concepts, it's quite refreshing to base an app on. There are plenty of "escape hatches" to customize webpack, babel, server-side API, etc. That said, I don't use it much anymore - I rolled (and continue to use) my own SSR, adding features as I needed them: taking care of async server-side actions like fetching data; rendering the app; passing initial state to client; dynamic chunk-splitting of routes; a way to export all app routes to static files.. There are many moving parts and "tricks" I had to discover - like, how to bundle client/server bundles with webpack (chunk-split on client, all bundled together on server), creating script tags on server to fetch route-specific chunks faster on initial page load.. So, unless you're into understanding and building/customizing every feature, your time might be better spent letting Next.js provide all that as a foundation. It's well-organized and documented, so I think it would be valuable for teams working together also.
- pcmaffey 8y ago
  I had that exact experience with Next. Ended up hating it for a variety of reasons (routing, file structure, build) and fortunately no longer have to support that project. Now I roll my own. I pre-render with react-snap, use react-imported-component for code-splitting and hydration. The pre-rendered static HTML pages are everybit as good as SSR. It adds an extra few seconds to the build process, but with Netlify's CI, I push to Github and its live once I'm back from the kitchen.

by leerob 8y ago

chatmasta 8y ago

I'm evaluating next.js for a new project. But coming from create-react-app, I'm a bit skeptical of these "frameworks" that seem to provide little benefit beyond developer tooling (i.e. setting up webpack, hot reload etc). create-react-app was great in the beginning, but months later was really annoying. I get the feeling next.js could end up like that. At least you can eject from CRA. I'm curious if anyone has gone the "roll your own" route with SSR + react, starting with a simple approach and adding complexity only as it becomes necessary. Has anyone done this and maybe also used next.js? I would love to hear a comparison, because at the moment I'm unconvinced next.js is really necessary if you know what you're doing, or you intend to maintain the project for more than 2 years.

davidjnelson 8y ago
The spectrum chat team, which GitHub acquired, wrote that they wish they had started with next.js https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/ https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/
- mxstbr 8y ago
  That's my blog post! If you have any questions let me know.
lioeters 8y ago
I'd highly recommend trying out Next.js. Once you've got the framework-specific concepts, it's quite refreshing to base an app on. There are plenty of "escape hatches" to customize webpack, babel, server-side API, etc. That said, I don't use it much anymore - I rolled (and continue to use) my own SSR, adding features as I needed them: taking care of async server-side actions like fetching data; rendering the app; passing initial state to client; dynamic chunk-splitting of routes; a way to export all app routes to static files.. There are many moving parts and "tricks" I had to discover - like, how to bundle client/server bundles with webpack (chunk-split on client, all bundled together on server), creating script tags on server to fetch route-specific chunks faster on initial page load.. So, unless you're into understanding and building/customizing every feature, your time might be better spent letting Next.js provide all that as a foundation. It's well-organized and documented, so I think it would be valuable for teams working together also.
pcmaffey 8y ago
I had that exact experience with Next. Ended up hating it for a variety of reasons (routing, file structure, build) and fortunately no longer have to support that project. Now I roll my own. I pre-render with react-snap, use react-imported-component for code-splitting and hydration. The pre-rendered static HTML pages are everybit as good as SSR. It adds an extra few seconds to the build process, but with Netlify's CI, I push to Github and its live once I'm back from the kitchen.