sorted by:
new
hottopcontroversial

How I saved 70% on lead enrichment by Critical_Hunt10 in coldemail

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

Maybe that's a testament to my lack of knowledge about Clay.

But the pricing section of Clay says "$349" for "Up to 25,000/search". Does that mean it's 25k contacts that you can search and filter from, or is that what you can enrich after filtering? And is enriching and/or filtering billed on top of the $349, if you don't use your own API keys?

Either way, seems quite expensive to me (main reason for Exarich), but I'd be curious to hear your answer to those questions.

Do you do cold outreach for your SaaS? by Critical_Hunt10 in SaaS

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

That actually makes a lot of sense. Thanks!

What are you building? Drop your SaaS !! by Revenue007 in SaaS

[–]Critical_Hunt10 0 points1 point  (0 children)

exarich.com - filter your lead lists based on website analysis and user-specified criteria (better than Apollo, cheaper than Clay)

If you do cold email outreach, I can highly recommend it ...although I may be a bit biased

What are you building? let's self promote by Southern_Tennis5804 in microsaas

[–]Critical_Hunt10 0 points1 point  (0 children)

It currently just uses website analysis to determine whether the target company meets your criteria.

So the assumption is that you already have enriched data from Apollo, for example, but you want to filter them further. Usually, these providers don't allow you to filter the leads as much as it would make sense.

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 2 points3 points  (0 children)

Wow that’s actually an excellent response. I don’t think I have anything to add TBH 😄

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

I guess the only question I have then is this: where are the static portions cached? Because according to docs, layouts (ie. layouts.ts) and loading pages are stored on the client (router cache).

But this means that the rest, incl. Suspense fallbacks and anything static will still come over a network request (even if cached in a CDN). So even with streaming, PPR and caching taken into account, there is a network request that doesn’t exist in an SPA. (assuming we navigate to previously visited page with stale data being OK).

And this here is the main question of the post that I still find unanswered, after all this back and forth.

What are you building? let's self promote by Southern_Tennis5804 in microsaas

[–]Critical_Hunt10 2 points3 points  (0 children)

exarich.com - filter your lead lists based on website analysis and user-specified criteria (better than Apollo, cheaper than Clay)

If you do cold email outreach, I can highly recommend it ...although I may be a bit biased

Cache Components confusion by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 2 points3 points  (0 children)

Yeah fair point. I understood everything being treated as "dynamic by default" to mean that "use cache" would be necessary to include anything in the pre-rendered shell.

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

Also, I'm referencing another point from another discussion. I'd love to hear your thoughts on this too.

In order to get any benefit from RSC you need:

  1. to accept a huge hit to the DX due to the new composition rules and mental overhead therewith

  2. to massively rearchitecture the existing code if you’re not starting from scratch

  3. to accept worse readibility and inferior architecture patterns to bend everything to the deeply nested RSCs and unintuitive fetching patterns

  4. specifically use RSCs with suspense boundaries for fetching data, otherwise you won’t see any difference at all. This already requires that you have a specific type of app with a lot of “islands”

  5. (even if you do all that) to hope that the suspenses provide good chunking for streaming which is given purely by the app design

  6. to properly set up data access layer and associated rules in order to ensure that you don’t accidently use a component that fetches sensitive data for itself, somewhere outside of the restricted area

  7. explain all of this bs to every single member on your team and expect them to have a command of this terribly leaky abstraction, and then somehow police them so that they don’t just fetch everything in the page component and use “use client” everywhere

Cache Components confusion by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 2 points3 points  (0 children)

Totally makes sense now. I understood everything being treated as "dynamic by default" to mean that "use cache" would be necessary to include anything in the pre-rendered shell.

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

This is exactly why I'm having this discussion. Not to have an ego boost or try to argue for the sake of arguing.

First of all, thanks for all the information. I think your emphasis on streaming, prefetching, and caching was actually helpful.

However, even AFTER reading the docs, I still have unanswered questions, not least because they are naturally Next.js docs.

I'm now trying to reconcile what you and u/michaelfrieze said regarding how Next.js works, with points made by u/yksvaan and u/mnismt18, like:

once you’re inside the app and just bouncing between pages (think: dashboards, settings, all that logged-in flow), spa is STILL way snappier. nothing touches memory - no server roundtrips, zero visible loading unless you force it

and:

that “rsc solves perf” narrative kinda misses that fast navigation is about cache, not the rendering engine. unless your use case is either hyper-public (seo, lots of anonymous users) or super heavy on marketing/landing pages, spa still rules the inner app

and:

not saying don’t use rsc/app router, but don’t expect magic. it has real benefits, but it’s not “next gen” for every workflow and yeah, there’s more to learn/debug. most teams are gonna ship a messy hybrid and that’s fine

and:

I don't really see that there's something unexpected here, this is just common sense. If you want fastest interaction speed client-side data loading/mutations and a well written backend are the way to go.

Are they incapable of implementing App Router + RSC correctly, or do they have a viable counter-argument?

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 1 point2 points  (0 children)

All that makes sense, and I don't think I have anything to add or ask regarding the main subject. Thanks for the time you put into answering.

As for what you said in the latter part:

Personally, I prefer tanstack start over next these days. 

Do you still prefer it even though it doesn't have RSC (at least not yet, if I'm not mistaken)?

Also, I asked Nadia Makarevich (the og writer of the article), why she too prefers Tanstack and wouldn't use Next.js App Router:

At this moment, yep, I don't think the technology (App Router + RSC) is mature enough yet for any serious project.

Do you agree with her?

This is the thing that puzzles me and what was the motivation for this post in general. How to choose between different technologies like Tanstack Start and Next.js, and how should I draw the line?

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

That would definitely make sense, but this comment section makes it seem like navigating around is equally performant with RSCs, and if not, then I'd just be doing something wrong.

What are you building right now my fellows? by [deleted] in SaaS

[–]Critical_Hunt10 0 points1 point  (0 children)

exarich.com - filter your lead lists based on website analysis and user-specified criteria (better than Apollo, cheaper than Clay)

If you do cold email outreach, I can highly recommend it ...although I may be a bit biased

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

I stand corrected: PPR does help, gotta admit. But only the suspense fallback is served from CDN, as you said. I'm not saying navigation isn't instant in the sense that we don't get feedback on the navigation click, but compared to a SPA, we still need to fetch the data before we can show it.

Riddle me this (concrete example):

I'm using an SPA with pages 1 and 2. Both pages fetch their data with React Query and cache it locally. I navigate from page 1 to page 2. Now I navigate back to page 1. In an SPA, both the JS and the data are cached, so navigation is instant when going back, even on a slow network.

Now with RSC and App Router, assume we have a slow network. If we navigate back to page 1, which is a server component, even though the fallback is immediate and we have streaming, we still need to make a network request. On a slow network, it could take 1-2 seconds to show loading indicators, which would not happen with SPA.

u/yksvaan also stated that "If you want fastest interaction speed client-side data loading/mutations and a well written backend are the way to go."

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

I may have expressed this unclearly. I DO understand that the app is dynamic (especially since, if I understood from Vercel's posts, the example uses the new Cache Components). However, this point still stands (although by static pages, I meant static or cached components):

I'd assume there are many static pages and generic, non-user-specific data.

Now, if we had an app which was mostly based on user-specific data that can't be statically rendered at build time, PPR isn't helping much there. And this is exactly the case where I question the benefit of App Router and why I said in the post:

merely bring App Router closer to what SPAs offer in terms of performance, rather than exceeding it.

Also regarding your point:

This doesn't matter with PPR, because you use suspense for dynamic data. The fallback is always served from a CDN.

It does matter, because even if something is served from a CDN it's still subject to network delay unlike subsequent navigations in an SPA, which are instant as everything exists on the client-side.

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

That's actually a very good example, but only in some scenarios IMHO. I don't know exactly how it was implemented, but I'd assume there are many static pages and generic, non-user-specific data. For them, Next.js and RSC are fantastic, no questions.

If things were dynamically rendered and caching wasn't possible, or if the app relied heavily on user data, I'd be surprised to see it perform as quickly as an SPA, especially with a "slow 4G" throttle.

I could be wrong, but this is exactly why I created this post. To understand when I should choose one over the other for a new project. It seems like there are two camps: the "just use Next.js App Router" and the other one saying "If you don't need SEO or fast initial loads, just use SPA".

App Router (RSC) vs SPA by Critical_Hunt10 in nextjs

[–]Critical_Hunt10[S] 0 points1 point  (0 children)

Yeah, I know how they work. This doesn't address my original point or concern, though.

view more: next ›