Comment by drewpc | Hacker News Reader

Comment by drewpc | Hacker News Reader

Not the OP nor the post's author. We have a similar stack (React + NextJS + TypeScript + Mobx) but use a traditional REST API using Django Rest Framework. There are some interesting topics in the post and in these comments that I figured I could expand on:

1. The primary reason we chose NextJS (with SSR) was to be able to write a declarative React component that is run on the server and the client. For example a button to follow or unfollow a page (think: like/unlike in social media). In the previous generation of our application, we wrote the button in PHP that rendered HTML and toggled UI state on the front end using JS/jQuery. That meant writing the button logic (and HTML/CSS) in two places instead of one. Now, we have a single React component that renders itself based on state; it's the same component on the server and client.

2. I don't understand the extra work to avoid SSR. SSR is great and can be used behind authentication--there's no actual need to work around it. Additionally, in a NextJS application, SSR is only used on the first page load. When you click from page to page, it's all client-side transitions.

3. @yashap said "The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack." Agreed. Same here. It's wonderful. In particular Mobx. A lot of the comments seem to say "I expected the article to talk about how to maintain state in a React application"--that's how. Use Mobx. No matter what reactive JS framework you're using, use Mobx to maintain "global" state.

4. The discussion of "why move to NextJS when my Webpack config from 6 years ago works just fine" is a good one. Two big reasons we moved to NextJS (away from a Webpack config from 7 years ago) were: the handoff from server -> client is more seamless and the developer experience with hot module reload for server + client sides was worth it. Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense.

> Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense.

Doesn't NextJS do the same? The alternative to compare to would be a plain setup without any heavyweight boilerplate. These days you could you esbuild, but a webpack config can be ~50 lines and quite simple if you build it up from scratch.

Next.js is rewriting its core with a Rust-based compiler. SWC (JavaScript and TypeScript compiler written in Rust) will replace two toolchains used in Next.js: Babel for individual files and Terser for minifying output bundles.

Happy to expand on this more if you want.

https://news.ycombinator.com/item?id=28609125

Not the original commenter but would appreciate more on this. If you can be bothered, could you also expand a bit on how Next.js works under the hood when it comes to forcing CSR à la

  {typeof window === 'undefined' ? null : children

On a related note, thanks for what you do for Next in the discord.

The easiest way to force CSR would be to render nothing on the server, `useEffect` and then render everything on the client. This could be at the top level of your application. But, I'm guessing most folks don't actually want that. It's typically a better user experience to serve some loading state/skeleton pre-rendered from the server, followed by loading data client-side (instead of full CSR). If you have NPM packages or code that can only execute on the client-side, you can also use next/dynamic to load specific components in client-side only.

https://nextjs.org/docs/advanced-features/dynamic-import

Read @leerob's answer first. Additionally, the notion of "forcing" CSR might be a misnomer. The way I understand it, NextJS always prefers CSR; the server renders HTML on first page load and the NextJS framework attaches JS stuff to the page on render to handle the client-side interactivity. So, if you turn off JS on your browser and load the page, everything works out of the box (page renders HTML, links work, etc). There are ways to specify server-only data requirements.

Once the client-side JS has taken over, the `next/link` component [1] is used to render and listen to events when a user clicks on a link. That component tells `next/router` to render the page that was clicked on. All of this happens on the client by default. If JS is disabled on the client, then the HTML rendered by the `next/link` component on the server is a simple `<a/>` tag and a normal browser page load occurs.

[1] https://nextjs.org/docs/api-reference/next/link

That'll be nice!!

Yes, NextJS does the same. After re-reading my comment, I don't think I was clear: our reasons for moving to NextJS were the two mentioned, not because it was less complicated than our Webpack config from 7 years ago. It's not less complicated, it's different. NextJS does some weird things under the hood to make it seamless (like CRA does) but it can make things even more complicated to go with nonstandard Webpack rules or Babel presets/plugins. Overall, I think any JS application written in this day and age is going to be a tooling nightmare--NextJS included. In our case, it's not bad enough to force us away from JS (or TypeScript) yet.

Reply on news.ycombinator.com