I changed my mind about writing new JavaScript frameworks | Hacker News Reader

I changed my mind about writing new JavaScript frameworks

whitep4nth3r.com

21 pointskiyanwang8 comments

I'm confused by this

> What’s more, static site builds in both Next.js and Gatsby can’t make use of server-side rendering functionality.

I haven't used Next.js but I heard that it supports server side rendering, so I assume you can use it kind of like Rails?

Is the issue with Next.js that you would have to remember to use <a> instead of <Link>? That sounds like not a big deal.

Yeah, Next.js supports both. And the <Link> tag is not required, it's simply recommended, as the Link tag has built-in prefetching, so users will feel a small performance boost from local links that use it.

Use a <Link /> if you want prefetching and client-side transitions, use just an <a /> if you want to opt out of that.

It also sounds like the author is complaining about Next.js/Gatsby not having an option that doesn't even make sense in the first place. "static site builds in both Next.js and Gatsby can’t make use of server-side rendering functionality" - What does this even mean? Of course a static site build won't have SSR.

It is confusing because between all the different levels of being static or server side rendered or client side rendered, next.js can pretty much do (and potentially mix) them all, right?

I'm quite confused on _why_ they want next to act like this? You can use anchor tags to force a browser navigation, but what does it get you? You're still loading JS bundles and it's not like <Link /> breaks anything like history or open in new tab. People put turbolinks in their rails app to get something that works half as well.

You could also use unstable_disableRuntimeJs on some pages and your <Link /> will still fully degrade to act like a completely server rendered page.

> static site builds in both Next.js and Gatsby can’t make use of server-side rendering functionality.

Which is why they're called static builds?

Next.js supports ISR, which is a great way to hydrate pages without causing too much overhead.

That Javascript can be used to build 100% server-side apps, 100% client-side apps, and anything in between makes it really hard to parse the messaging/intent sometimes in posts like this.

The irony of this title just hits the spot.

The author's opinion seems to come down to how different JS frameworks support SSR, which is a very specific problem. Outside of SSR, which is primarily meant to appease The Google, I think said opinion would be diminished because most JS frameworks are redundant in every other domain.

Reply on news.ycombinator.com