Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js App Router Update

nextjs.org

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Next.js App Router Update

#71

Post by dbbk »

joshgermon wrote: post #51

What are the viable alternatives for those who don't care about the API routes but still want some level of pre-rendering / SSR? Staying in the React ecosystem that is. Remix is always touted as the alternative but it seems like a whole new approach to learn and it's own strong opinions. I've been using Next for 3+ years but I don't feel confident to start a new project today. Do I go to the dying page router? Or tra…

To be honest I think Next with the pages router is still the best option you have today.

I'm not convinced the server components experiment is going to work in the end. They might even end up abandoning it.

Re: Next.js App Router Update

#72

Post by dbbk »

OutsmartDan wrote: post #7

The new docs are extremely annoying; if you're still running a legacy app, sometimes you get put into a doc for a feature you think exists, but then you realize it's not for the right version you're running. Also the new app routers are very confusing. There are concepts of a layout, template, page, etc. While it's nice to have server rendering at this level, it's difficult to understand what is bubbling which direct…

It's crazy to me that their docs aren't versioned. Almost forces you to be constantly upgrading to the bleeding edge.

Re: Next.js App Router Update

#73

Post by beardedetim »

dbbk wrote: post #69
Escapado wrote: post #57

Lots of negativity here. I don’t share the sentiment. I have ported one project over to the app router months ago when it was still in beta with zero problems and another one is in the works using server actions and drizzle-orm to get end to end type safety. I think it’s a blast. For those complaining about the feature set growing: I think this is just a question of use-case. At my current gig we are using pretty muc…

I just looked into the Server Actions documentation. Why is there a 'use server' inside the action if it's already running on the server? What happens if this is omitted? Why is all of this stuff so opaque? https://nextjs.org/docs/app/building-your-application/data-f...

I think, if I'm recalling it correctly, that the component that is defining it in the docs can be either client or server and by marking the functiom as server only, Next knows to do magic.

Re: Next.js App Router Update

#74

Post by CharlieDigital »

paulddraper wrote: post #43
TechBro8615 wrote: post #18

Next and React have gotten way too complicated. I don't want to read twelve pages of documentation to understand how to understand the rest of the documentation. I've been coding in React for 6 years and in Next for 3 years. My next project will be in Vue.

Why?

In general, any model that uses fine grained reactivity (Vue, Preact, Solid, Svelte) will be more "forgiving" then one that uses coarse grained reactivity (React) because it triggers smaller component tree updates.

This tends to reduce certain classes of bugs like side effects from unexpected re-renders and performance issues like over rendering.

The thing with React and Next is that it's great if your team is relatively homogeneous in terms of skill and experience or you have strong systems in place to enforce practices. However, the render cycle of React and the provider pattern is prone to bugginess otherwise. A firsthand example is Algolia's React components. Look at the GH issues. We ran into tons of issues related to unexpected redraws.

Re: Next.js App Router Update

#75

Post by dbbk »

warent wrote: post #11
xyzzy4747 wrote: post #9

Earlier quoted context omitted.

You can use getServerSideProps to look at the cookies before rendering the page for a user. It’s slightly annoying though since you can’t use both getServerSideProps and getStaticProps on the same page.

Except getServerSideProps is no longer used in Next 13 and actually you have no simple access to the request object anymore. Have to write middleware for everything, it is extremely frustrating

> Except getServerSideProps is no longer used in Next 13

Yes it is?

Re: Next.js App Router Update

#76

Post by dbbk »

beardedetim wrote: post #73
dbbk wrote: post #69

Earlier quoted context omitted.

I just looked into the Server Actions documentation. Why is there a 'use server' inside the action if it's already running on the server? What happens if this is omitted? Why is all of this stuff so opaque? https://nextjs.org/docs/app/building-your-application/data-f...

I think, if I'm recalling it correctly, that the component that is defining it in the docs can be either client or server and by marking the functiom as server only, Next knows to do magic.

Next may know that but developers sure won't.

Re: Next.js App Router Update

#77

Post by mpeg »

Solvency wrote: post #39
terandle wrote: post #32

As a long term user of old school server side frameworks like PHP I very much "got" what the app router is trying to do once I used it, being able to reach into your database from any component without having to build an API layer is incredibly productive. It feels refreshingly old school and new school at the same time. My guess is the majority of the people that don't like the app router are just very used to the m…

I don't get it. Why not use simple .htaccess to map URLs to folders/files like always? Then, if you simply must use a JS framework like React...run it on those corresponding pages. Why use yet another framework (Next) on top of this to handle such a simple thing?

I’m not a next.js or react fan at all, but “like always” is a weird thing to say about a feature that is Apache only.

While Apache was wildly popular htaccess files and cgi/fcgi adapters for php, Perl and such were everywhere. These days they’ve fallen out of favor and every cloud provider has their own version of this that you can use.

But let’s not pretend this is the way things have always been done, in my career pre-cloud I’ve worked with Apache and nginx, but also with Java servers (tomcat etc), phusion, IIS and occasionally custom app servers that would speak http.

Re: Next.js App Router Update

#78

Post by anonyfox »

Anyone sharing the disappointment with NextJS, please have a second look at https://www.meteor.com/ again. It is much more powerful in terms of backend/frontend communication and reactivity, and even though there was a huge downturn some years ago, its picking up steam again. Importantly: it has been around for roughly a decade now and in most cases "just works", and you can even pick the frontend lib you like (react/vue/svelte/...) or swap it later on, so no _hard_ coupling to react. I blogged about it a while ago (https://anonyfox.com/blog/the-renaissance-of-meteor-js/) and things are getting even better now. There are still rough edges, but central points like SSR that "just works" with "useTracker" is there.

Re: Next.js App Router Update

#79

Post by samuelstros »

joshgermon wrote: post #51

What are the viable alternatives for those who don't care about the API routes but still want some level of pre-rendering / SSR? Staying in the React ecosystem that is. Remix is always touted as the alternative but it seems like a whole new approach to learn and it's own strong opinions. I've been using Next for 3+ years but I don't feel confident to start a new project today. Do I go to the dying page router? Or tra…

Check out vite plugin ssr

Re: Next.js App Router Update

#80

Post by paulddraper »

CharlieDigital wrote: post #74
paulddraper wrote: post #43

Earlier quoted context omitted.

Why?

In general, any model that uses fine grained reactivity (Vue, Preact, Solid, Svelte) will be more "forgiving" then one that uses coarse grained reactivity (React) because it triggers smaller component tree updates. This tends to reduce certain classes of bugs like side effects from unexpected re-renders and performance issues like over rendering. The thing with React and Next is that it's great if your team is relati…

If re-renders are causing bugs, you are 100% holding the tool wrong

Like having data corruption issues from GET requests.

---

I prefer explicit, but if implicit fine grained reactivity is the sole point of concern, you might be interested in React+MobX.

Post reply on HN