Hacker News Reader

Comment by synergy20 | Hacker News Reader

Vercel's next.js and sveltekit are both SSR first because that's its business needs, which has nothing to do with mine(CSR only case), and Vercel is actively pushing the SSR-can-do-it-all in the open source space, I feel it is very much short-sighted.

Just use vuejs which is the only one truly never forces SSR on you if you do not want to have anything to do with it.

View on HN

Speaking as an engineering manager, vercel’s approach seems to cater to the last market where overengineering and complexity were status symbols that middle management was happy to pay for. When the headcount was free, there weren’t many questions from upper management why basic UIs required so much heavy lifting by (overly) experienced engineers.

In the new market, there will be much more scrutiny on costs and the complexity that creates it. The prospect of hiring a “React Engineer” with 7+ years of experience to build a cookie cutter UI, will be just as questionable as forcing the front end and backend to use the same technology and framework governed by one single vendor.

I predict vercel will have a rough time.

Interestingly, I have the exact opposite bet: “SPAs were a zero interest rate phenomenon”. Putting the burden of compute on clients, and shipping slower apps for the sake of DX and convenience. Customer-first wins.

Looking forward to see how this plays out.

SPAs are faster than SSR because you can choose whether to incur network latency or not.

For example, let’s consider a site with two pages. In the SSR case, if I click the link to page 2, then I have to wait a whole network roundtrip for the page to appear.

In the SPA case you can decide when you want to load the content for page 2: with page 1 (if it’s a small amount of content), if the user scrolls to a certain point, … it’s completely up to you. You can cleverly hide the latency so that when the user does navigate to page 2, it’s instant.

You can do what you described with Next.js and latest React easily. In addition, it will also help with SSR where it makes sense for speed and performance.

Building site with Next.js makes it simple to get a good perceived performance, the framework handles it out of the box.

MPAs can do the same trick. Use JavaScript to add a <link rel=prefetch> element to prefetch a URL. Or just serve your server-side rendered page with this element included to prefetch the next page. When the user navigates to the next page, it’s instantly shown.

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

Nope, you do a bit of DHTML to update the only section that matters.

Isn’t DHTML just 00s speak for SPA? Not much difference between an accordion and react router, except the history API.

For selective Ajax calls actually, not a full dynamic site rendered on the client to display static text.

Vercel is I think going to have a great time of it. Setting up code pipelines, and the devops time needed for it, compared to just having it deploy from github, and having sane logging?

Only people who haven't had to set all this up themselves think Vercel isn't amazing.

It is handling a LOT of devops heavy lifting for you.

I actually strongly advocate for: SSR and server is the absolute best default[1], and Next.js gives you tremendous flexibility on where to place your compute[2], including skipping SSR altogether[3], with the best-in-class static export that can actually at least put some content in your HTML instead of a blank page[4]

[1] https://rauchg.com/2014/7-principles-of-rich-web-application...

[2] https://twitter.com/rauchg/status/1637136013083684864

[3] https://twitter.com/timneutkens/status/1636693508223270912

[4] https://twitter.com/dan_abramov/status/1636827365677383700

Reply on news.ycombinator.com