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

The future (and the past) of the web is server side rendering

deno.com

Post reply on HN
Print view View original

141–150 of 371 posts

Re: The future (and the past) of the web is server side rendering

#141

Post by greg_tb »

silver-arrow wrote: post #123

Much more prefer the htmx way of SSR parts of the page dynamically. Also, totally server-side agnostic, so we can use what we prefer. Clojure in our case. https://htmx.org/

Completely agree.

For me the biggest advantage is eliminating the need to learn, debug, and maintain components on an additional frontend framework (Angular/React/Vue).

I just built a rough toy project [0] that was my first time with FastAPI and HTMX and it was fun and fast.

[0] https://www.truebuy.com/ (like rotten tomatoes for product reviews but just for TVs right now)

Re: The future (and the past) of the web is server side rendering

#143

Post by linkjuice4all »

ushercakes wrote: post #34
anonymousDan wrote: post #27

Is SSR still much better for seo?

Yeah, big time. It's faster, so crawlers give you better scores for page speed, which is important. Secondly, it automatically renders all of your content, vs if you dynamically load content, the crawler may just see a page with a "Loading" element and never actually view the content itself. Google argues that it is able to handle javascript heavy client side code in it's crawlers, but the data seems to show otherwis…

Perhaps the best method is a mix of static or SSR content for the content-heavy stuff that you want indexed and SPAs for the truly dynamic experiences. This is easier said than done but there’s a good chance your marketing team is separated from “product” anyway. Marketing can continue to use WordPress or some other CMS with a static export or SSR and product gets the full app experience stuff.

It’s mentioned in other threads that SSR is more expensive as your scale - so you might as well make the “outside” layer of your site light weight and static/SSR for fast client loading and then give them the full SPA once they’ve clicked through your landing pages.

Re: The future (and the past) of the web is server side rendering

#144

Post by kitsunesoba »

Havoc wrote: post #90
trashburger wrote: post #25

Earlier quoted context omitted.

The problem with this idea is that the user's browser's compute is not "free". Offloading the computing means the users have a worse experience, which will affect your userbase and page rankings.

>Offloading the computing means the users have a worse experience Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device

Depends on the complexity of the page. A lot of sites with heavier JS and SPAs eat a lot of memory which can cause problems for users of the many laptops out there with 4/8GB of RAM, as well as many smartphone users who have 2GB of RAM or less. In the case of the latter visiting a heavy website can be enough to prompt the OS to kill some other app to make memory available, which means in that situation one's site is in direct competition with other things the user may be needing more than the site.

Re: The future (and the past) of the web is server side rendering

#145

Post by dbbk »

ArcaneMoose wrote: post #24

The issue I have with SSR is that it offloads processing power onto the server. That means I have to pay more as the host instead of relying on user's browser to handle the compute "for free".

So just cache it and then have it be processed once every minute or whatever.

Re: The future (and the past) of the web is server side rendering

#146

Post by dbbk »

andrewstuart wrote: post #67

I really don’t like server side rendering. I like my react apps to be static files served from a plain HTML server.

Depends what you're building. If it's a dashboard app gated behind a user login, sure, have it be a static HTML file. SEO is irrelevant and you wouldn't be server rendering anything anyway.

If it's a public site and you want people to find it (ie SEO) you really should be server rendering and caching on a CDN.

Re: The future (and the past) of the web is server side rendering

#147

Post by spiffytech »

arcanemachiner wrote: post #132
spiffytech wrote: post #42

Earlier quoted context omitted.

The rise of metaframeworks is interesting because it brings nuance to this. The line between site and app can be blurry. For example, my app has a main screen that needs to be client rendered. It also has a user settings screen that could be implemented as a traditional server rendered page with no JavaScript, except it's a lot more practical to build everything inside the same project and technology. Apps and their…

Pardon my ignorance, but what do you mean by metaframework? I just learned about Astro the other day. It allows you to blend components from SPA frameworks together. Is that what you mean?

'Metaframework' is a term for frameworks that wraps React or Vue or similar. Next.js, Nuxt, Gatsby, etc. I think Astro is considered a metaframework too.

They're sometimes called stuff like "a React framework", depending on whether the speaker considers React a library or a framework.

Re: The future (and the past) of the web is server side rendering

#148

Post by [deleted] »

greg_tb wrote: post #141
silver-arrow wrote: post #123

Much more prefer the htmx way of SSR parts of the page dynamically. Also, totally server-side agnostic, so we can use what we prefer. Clojure in our case. https://htmx.org/

Completely agree. For me the biggest advantage is eliminating the need to learn, debug, and maintain components on an additional frontend framework (Angular/React/Vue). I just built a rough toy project [0] that was my first time with FastAPI and HTMX and it was fun and fast. [0] https://www.truebuy.com/ (like rotten tomatoes for product reviews but just for TVs right now)

[deleted]

Re: The future (and the past) of the web is server side rendering

#149

Post by cyral »

unity1001 wrote: post #92
cyral wrote: post #36

Earlier quoted context omitted.

> Well done, modern devs! A plain .html file does that And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloade…

> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place And that's what most of the web needs - few use cases require having to manipulate every bit of the dom to send constant updates to the end-user. Social networks, financial sites, banks, betting sites etc. The rest do not need t…

I love nothing more than clicking “remove from cart” and having the whole page refresh and lose the info that was already typed

Re: The future (and the past) of the web is server side rendering

#150

Post by gavinray »

The article seems to contradict itself:

The first example shows the server rendering a handlebars template and then sending that as a response to the client -- it's then stated that this "isn't true SSR"

Then the same thing is done without a template language, using strings instead, and this is some different kind of SSR altogether and the "true SSR".

Which also seems to insinuate that only JS/TS are capable of SSR?

  Server-side rendering! Well, kinda. While it is rendered on the server, this is non-interactive.

  This client.js file is available to both the server and the client — it is the isomorphic JavaScript we need for true SSR. We’re using the render function within the server to render the HTML initially, but then we're also using render within the client to render updates.
Post reply on HN