Live data from Hacker News

Next.js 14

nextjs.org

31–40 of 157 posts

Re: Next.js 14

#31
post #18

Fuck next.js. Honestly. Check out how it bundles and sends the entire react-dom library twice to every user on every page view https://github.com/vercel/next.js/issues/51508 . Fuck 1MB of JS to render a static HTML page. Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all. Fuck spending 3 hours working out why you’re not able to use relative imag…

This comment reminds me of GatsbyJS. Same issues and we all know what happened…

Re: Next.js 14

#32

The general direction React (+ Next) is going worries me a bit at times. I might be too conservative, but I want my JS on the frontend and not hot loaded from the server. For this reason I'm much more excited about Vite/Bun/Dino/etc. Also thank god for shit like Preact.

> I want my JS on the frontend and not hot loaded from the server

I'm fascinated by this. Literally, in every other HN thread in existence, you find stadiums of people shouting that they hate slow-loading SPA pages, and that all the work should have been done on the server, as God intended. Only on the release of Next.js 14, of all things, do you find people saying that actually SPAs are great and SSR is a regression!

Re: Next.js 14

#33
One weird issue I had with next 13 was radio button groups did not work. The suggested fix from a core next contributor and fb employee was to "Upgrade to a canary release"...

I get that you are building all these new cool features, but that cannot put basic functionality and backwards compatibility at risk. Radio buttons have been around forever, I'd assume that they are being used by tons of websites all ove the place. Yet hydration of SSR radio buttons was not being done properly and so you could not set a default value for your radio button...

This kinda shit is just basic. You can't add new features at the expense of basic functionality.

Re: Next.js 14

#34

The general direction React (+ Next) is going worries me a bit at times. I might be too conservative, but I want my JS on the frontend and not hot loaded from the server. For this reason I'm much more excited about Vite/Bun/Dino/etc. Also thank god for shit like Preact.

What does vite/bun/deno has to do with keeping JS on the frontend?

Re: Next.js 14

#35
post #18

Fuck next.js. Honestly. Check out how it bundles and sends the entire react-dom library twice to every user on every page view https://github.com/vercel/next.js/issues/51508 . Fuck 1MB of JS to render a static HTML page. Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all. Fuck spending 3 hours working out why you’re not able to use relative imag…

I'll do you one better: use hyperwave. https://github.com/tireymorris/hyperwave

It allows you to build full-SSR apps with Tailwind and JSX, has support for SQLite and HTMX, and is in general a great return to how web dev used to be / should be.

Re: Next.js 14

#36
post #18

Fuck next.js. Honestly. Check out how it bundles and sends the entire react-dom library twice to every user on every page view https://github.com/vercel/next.js/issues/51508 . Fuck 1MB of JS to render a static HTML page. Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all. Fuck spending 3 hours working out why you’re not able to use relative imag…

> This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

This is gold level comedy. I am not sure how no one in the tech industry is seeing this.

Re: Next.js 14

#38

Really not interesting for us. Makes what’s simple simpler and what’s hard harder. Sure for a quick prototype website with 10min only that would help, but any decently sized app that needs auth/localization/high performance in memory/offline/optimistic updates/batch fetching … all become way harder. It feels like react unchained from Meta’s constraints and it looses its appeal.

Which part of this release do you find more difficult? For applications that need those dynamic constraints, like auth and personalization, we’re working to make this even easier starting this this version.

This version also includes stability for Server Actions, which includes a hook useOptimistic for optimistic updates.

I agree the offline story isn’t great today and we could do better there.

Re: Next.js 14

#40
post #25

I've been out of the web-dev game for a while, and have been pretty blown away by how much has changed. Suddenly, it seems like everything is a 1-page application, SSR, and doing a lot more on the client than I was used to back when jQuery was the standard. Next.js seems like a pretty beginner-friendly way to get a lot of the "new stuff" without having to learn the multiple technologies in a MERN stack. On the other…

That would be Remix: https://remix.run

See: https://www.epicweb.dev/why-i-wont-use-nextjs

Post reply on HN