Hacker News Reader

Comment by brundolf | Hacker News Reader

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.

View on HN

I agree wholeheartedly here. Server side rendering is incredibly difficult to do right, and while Next has some idioms that I find a bit unwieldy, they work well. It's also insanely customizable which I quite enjoy.

Lee from the Next.js team here. Could you share what features you’d like to see? Is there a GitHub issue or more information about the TypeScript declarations? Thank you!

There aren't currently any actual features I'm missing; I find Next tends to get updated pretty promptly. I just remember at least one case where Webpack or React or something had a feature I wanted to use and there's always this question of "well but does it work in Next yet?", and there was a GitHub ticket for it but the answer was "not yet". Such is often the cost of using an all-inclusive framework.

As for the TypeScript types, there are just several parts that are not as thoroughly typed as they could be; there are some `any`s, and just yesterday I got bit by passing an invalid event name to router.events.on(). The first argument is typed `string` when it could have been a union type with the exact event names that are valid, which would have caught the error before it got to our QA environment. Just stuff like that.

I should note that we aren't on the latest version of Next, so it's possible the situation has improved. And assuming it hasn't, I've thought about submitting a PR myself with some improvements to the declarations.

Overall, though, it's a great framework!

We've landed the TS improvments you're looking for!

https://github.com/vercel/next.js/pull/26456

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.

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

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.

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

To be blunt, because I want to spend time creating value for my customers instead of doing all of what you're doing.

Some people here get upset when you say ‘just use Rails or Django and stop futzing around.’ Shrug.

Reply on news.ycombinator.com