Hacker News Reader

Comment by nicoburns | Hacker News Reader

> 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.

View on HN

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