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

Server-side rendering is a better choice for many applications (2020)

timr.co

Post reply on HN
Print view View original

241–250 of 286 posts

Re: Server-side rendering is a better choice for many applications (2020)

#241

Post by listenallyall »

phendrenad2 wrote: post #210
afavour wrote: post #208

Earlier quoted context omitted.

Yeah, no. Don’t get me wrong, I’m very unhappy with the state of today’s JS ecosystem but if you’re building a project of any complexity ditching absolutely everything that can help you along the way is not going to work out. Nor is it going to work out for the person taking over the code from you. Every now and then I’ll be putting together a tiny landing page type thing and write it all in vanilla JS and it’s bliss…

Most people overuse frontend state. It seems like every new React programmer goes through a phase where they think that everything needs to be in state, especially things that never change.

Or for "state" that is already saved on, or known by, the server -- or will be sent to the server for persistence.

Re: Server-side rendering is a better choice for many applications (2020)

#242

Post by tedunangst »

MatthiasPortzel wrote: post #171
ninkendo wrote: post #115

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

Hitting the “Reply” button on HN takes you to a new page with a textbox, taking over 500ms and a complete page reload. On some websites, that amount of latency is acceptable. But that could be instantaneous.

Gives you more time to think about your reply. The fact that people on other sites comment in less than 500ms could be considered a negative.

Re: Server-side rendering is a better choice for many applications (2020)

#243

Post by granshaw »

cpursley wrote: post #229
granshaw wrote: post #203

Earlier quoted context omitted.

Just use Rails

These days it’s hard to justify Rails over Phoenix for fresh projects.

Fine then, Phoenix :) But yeah Go is not a good ecosystem for comprehensive web development

Re: Server-side rendering is a better choice for many applications (2020)

#244

Post by threatofrain »

mvdtnz wrote: post #238
threatofrain wrote: post #176

Earlier quoted context omitted.

Since JS people target multiple browser versions and vendors, building is basically a requirement.

Builds are absolutely not a requirement for targeting multiple browser versions and vendors.

It's the other way around. Having multiple targets increases the motivation to use build systems.

Re: Server-side rendering is a better choice for many applications (2020)

#245

Post by mvdtnz »

threatofrain wrote: post #244
mvdtnz wrote: post #238

Earlier quoted context omitted.

Builds are absolutely not a requirement for targeting multiple browser versions and vendors.

It's the other way around. Having multiple targets increases the motivation to use build systems.

Why would that be the case?

Re: Server-side rendering is a better choice for many applications (2020)

#246

Post by la_fayette »

traverseda wrote: post #216
la_fayette wrote: post #212

Earlier quoted context omitted.

To be clear, there is a difference between SSR and SSG. SSG is something like PHP, which generates the full page HTML in the backend. I think HN is SSG? Many news websites or wordpress blogs also fall in this category...

I've never heard the term SSG before. Apparently stands for "static site generating" and is a `next.js` thing. No, hacker news is not a static site. It just makes use of caching HTML on unchanged pages, and as I understand it that cache is often bypassed for logged in users. This is why sometimes when hackernews is overloaded you can still view the site in private browsing, since you're not logged in it hits the cach…

Ok, it seems I mixed up the acronyms, I thought SSG stands for server-side generated.

What I actually mean is, that there is a difference between SSR with react, which requires some kind of rehydration on the client, in contrast to a website generated by, e.g., PHP on the server, which doesn't require this.

The PHP website doesn't require the client to rehydrate and produces less load on the client. With the disadvantage, that a subsequent page view requires again a full load, while the SSR loaded react page, doesn't require that.

I didn't check the HN code yet, but it feels like a server- side generated website and not a SSR delivered react (or similar js framework) website...

Re: Server-side rendering is a better choice for many applications (2020)

#247

Post by bofadeez »

halfmatthalfcat wrote: post #217
bofadeez wrote: post #207

Earlier quoted context omitted.

The argument that 'simplistic' technologies don't scale is dismissive of the robust, enterprise-level applications that have been successfully built without heavy frontend frameworks. It's not the tool that scales; it's the architecture and the development practices.

> enterprise-level applications that have been successfully built Who? When? Where? I refuse to believe this assertion. Are we talking past or present? The whole reason why these frontend focused frameworks exist is because either the existing solutions (pure html, even with preprocessors like handlebars, pure vanilla JS, lower level libs like jQuery) did not scale to meet demand or existing frameworks (JSP, PHP, etc…

Your skepticism about the viability of enterprise-level applications built without heavy frontend frameworks reveals a narrow understanding of software history and architecture. Let's not forget that companies like Amazon, Google, and eBay built scalable, complex systems long before React or Angular were even conceived. Amazon's initial architecture was famously built on Perl, and Google's original frontend was simple HTML and JavaScript. eBay was initially built using Java Servlets and JSP, and it scaled to handle millions of transactions. These are not 'imaginary success stories'; they are well-documented cases that prove scalability is not solely the domain of modern frontend frameworks.

Your assertion that older frameworks 'became a mess at scale' is a sweeping generalization. Any technology can become a mess if not properly managed; that's not a failing of the technology but of the architecture and development practices. PHP, for instance, powers Wikipedia, one of the top-ten most visited websites in the world, and it handles this scale quite well.

The emergence of frontend frameworks was not solely because 'existing solutions did not scale'; it was also driven by the industry's evolving needs for richer user experiences and faster development cycles. These frameworks solve specific problems but come with their own trade-offs, including complexity and steep learning curves. To dismiss alternative approaches as unscalable without evidence is not just intellectually lazy; it's a disservice to the field of software engineering, which thrives on diverse solutions to complex problems.

Re: Server-side rendering is a better choice for many applications (2020)

#248

Post by slaymaker1907 »

bob1029 wrote: post #206
robertoandred wrote: post #122

Earlier quoted context omitted.

Server-side rendering can absolutely be slow, and client-side can absolutely be fast. It's all dependent on the quality of the developer.

Server-side has the best chance of providing an ideal experience in the worst case situation: The user's very first visit to the website on a mobile device in a crappy network environment. Information-theoretic, there is no way you can beat SSR in this scenario. You will not win against a machine that returns a complete HTML document on the very first request if your users only receive hints regarding where to actual…

Even that really requires some nuance. If most of your site is static with a small amount (in terms of data) dynamic content, it could easily be faster to split things up into 2 phases: load the static part and then do a single REST request to get the dynamic part for client side rendering. The first time the user ever visits your page, it will take a small hit compared to SSR, but in subsequent visits the browser can easily cache the static part so it only needs to query for cache coherence (which should be very cheap in terms of throughput) and obviously the REST query for the dynamic parts.

If you do SSR, the client is much more limited in terms of caching because the page contents is not constant. In my opinion, SSR is actually more for slow CPUs than for slow networks since you can make the network usage for client side rendering very efficient as well, but client side rendering will always be worse in terms of client CPU.

Re: Server-side rendering is a better choice for many applications (2020)

#249

Post by flimsypremise »

candiddevmike wrote: post #162
flimsypremise wrote: post #137

This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…

> So, given that the frontend build is baked into _any_ application build, if you decide to do template rendering in any language other than JS/TS, you are adding another build to your project. That means you need to configure that build for all environments, configure CI, and support that build going forward. Save yourself the trouble and just render everything server-side in JS. You had me until the last part which…

You render server-side in JS/TS. You can use the same components, same tests, same code running on the server and client. That's the whole advantage.

Re: Server-side rendering is a better choice for many applications (2020)

#250

Post by garbageoverflow »

karmakaze wrote: post #116
ninkendo wrote: post #115

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

Mostly true--the hn.js would indicate otherwise: function vote (id, how, auth, _goto) { ... $('unv_' + id).innerHTML = unv; new Image().src = vurl(id, how, auth, _goto); }

Sorry, could you point me to the piece of code that requests all comments via an API and renders them accordingly?
Post reply on HN