TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Server side rendering is now a good idea?

48 点作者 mrvenkman超过 2 年前
Thanks to the speed of the internet, I’m beginning to feel that logic on server side with PHP or other server side technology, is just as interactive as JavaScript - without the complexity of React, Angular [insert framework here] and associated package and state management.<p>Oh, and security!<p>Thoughts?

17 条评论

deafpolygon超过 2 年前
Always has been.<p>CSR solves a different set of problems. One common problem is that front-end developers don&#x27;t always have access to the back-end, nor do they always have the skills to deal with back-end. Sometimes it&#x27;s just quicker to have back-end provide the data (i.e. an endpoint), and have the front-end deal with it.<p>I think, since before CSR became the popular trend, that front-end development had fragmented and proliferated so much that it has become fairly complicated. Front-end development used to be just a web &quot;designer&quot; would design it and make the page look pretty. Toss in some JS for interactivity + animation. Once they&#x27;re done, hand it off to the web &quot;developer&quot; for hosting and integration into the web server. Now it has grown into this monstrosity where we can have the designer, UI&#x2F;UX person, front-end API, etc. With the client doing all the rendering, web pages have started to slow down. At some point, folks are like, &quot;Wait a minute! What about SSR? We can solve so much of our performance and security issues that way!&quot;<p>Trends are often cyclical, with the previous trend being replaced by old trends making fresh rounds. I suspect we will see old ideas with fresh eyes, and a new way to reason about things.
speedgoose超过 2 年前
Always has been.<p>I think that you do need interactivity through JavaScript at some point. And I find react and similar easier to maintain than an HTML&#x2F;JS soup generated by PHP, JSP, or RoR.<p>I would take a look at <a href="https:&#x2F;&#x2F;fresh.deno.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fresh.deno.dev&#x2F;</a> or <a href="https:&#x2F;&#x2F;kit.svelte.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kit.svelte.dev&#x2F;</a> or <a href="https:&#x2F;&#x2F;nextjs.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nextjs.org&#x2F;</a>
评论 #34282203 未加载
caprock超过 2 年前
You might want to look into what the creator of htmx has to say about this topic. He&#x27;s here on hn and may even show up for this thread.<p>Here are the essays:<p>* <a href="https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;</a>
评论 #34282618 未加载
sergiotapia超过 2 年前
It&#x27;s a lot simpler for sure these days. I&#x27;ve built my indie startup with Phoenix Liveview. It&#x27;s all server side rendered, with liveview sprinkling in interactivity.<p>Can you tell it&#x27;s server side rendered? <a href="https:&#x2F;&#x2F;www.gamedrop.gg&#x2F;lists&#x2F;slymilano&#x2F;exciting-game-releases-for-q1-2023" rel="nofollow">https:&#x2F;&#x2F;www.gamedrop.gg&#x2F;lists&#x2F;slymilano&#x2F;exciting-game-releas...</a><p><a href="https:&#x2F;&#x2F;www.gamedrop.gg&#x2F;game&#x2F;hogwarts-legacy" rel="nofollow">https:&#x2F;&#x2F;www.gamedrop.gg&#x2F;game&#x2F;hogwarts-legacy</a><p>I think there are similar tools in other platforms like Rail&#x27;s and Laravel.
评论 #34310664 未加载
评论 #34283059 未加载
评论 #34282890 未加载
endisneigh超过 2 年前
I&#x27;ll be a contrarian here. Client side rendering is just getting started. With faster storage for cheap and fast internet there will be less and less reason to put things in a server. Add in things like wanting end-to-end encryption, privacy issues and most things will be in the browser, imho.
评论 #34283011 未加载
评论 #34282684 未加载
comrad超过 2 年前
Oh, are we now full circle back to good old server side programming again. Just like in the 90s? I mean it&#x27;s not bad - but it&#x27;s definetly not new...
评论 #34282717 未加载
thinkmcfly超过 2 年前
It always has been the best. You can&#x27;t even scroll down on a modern js heavy site without having to wait for content to load.
sph超过 2 年前
Are you writing a media player? Are you writing an interactive application that requires little to no backend? Go client-side.<p>For everything else, meaning 99% of the projects you will ever be paid to work on, server-side framework with just a little sprinkle of JS where needed is enough and 10x more productive.
andrewfromx超过 2 年前
checkout how rails does best of both worlds with something called &quot;turbo&quot; <a href="https:&#x2F;&#x2F;www.hotrails.dev&#x2F;turbo-rails&#x2F;crud-controller-ruby-on-rails" rel="nofollow">https:&#x2F;&#x2F;www.hotrails.dev&#x2F;turbo-rails&#x2F;crud-controller-ruby-on...</a>
评论 #34281610 未加载
smackeyacky超过 2 年前
Security definitely. You are leaking far less of your web interface by rendering everything on the server. There are a lot of neat SPA out there, but anything that is doing a boring old CRUD kind of job really should be server side just to reduce the attack surface.
belmont_sup超过 2 年前
Sorta agree but not wholly surprised. We hit new problems - increased user expectations. We experiment and learn what the right dose of tech to use. When things get complex, the pendulum swings with new innovations. But it is fun to think that we had to create basic forms or ever so slightly complex forms in pure JavaScript.<p>Apps that need react and other similar frameworks are like excalidraw, linear, figma, etc. think most crud apps are fine.<p>However, react is still a great programming tool for me. I like the abstractions available with remix, next, qwik, and all that. I can still have a backend api team, and a separate web team that uses remix to consume the api. Simple models.
andrewf超过 2 年前
The speed of light isn&#x27;t getting any faster. Examples: <a href="https:&#x2F;&#x2F;www.cloudping.co&#x2F;grid" rel="nofollow">https:&#x2F;&#x2F;www.cloudping.co&#x2F;grid</a><p>I&#x27;d be wary of taking asynchronous actions and making them synchronous. For instance, if you had a list of items each with a delete icon next to it, you don&#x27;t want to turn deleting three items from click-click-click into click-wait-click-wait-click.<p>Chrome Dev Tools can simulate added latency as well as restricted bandwidth, so you can plug intercontinental latencies in and see how much a particular site is affected.<p>Some things will be fine. I&#x27;m posting this on HN from Western Australia, no problems.
评论 #34291869 未加载
timthelion超过 2 年前
With regards to security, obviously it is possible to get security wrong when exposing APIs to the front end. That said, when it comes to the risk of your server being compromised, the less code running on your server the better. So if you can move some of that code onto the client, then it is a pretty significant security win. Except for XSS and DOS attacks, client code by definition doesn&#x27;t bring any security risks. It is UNTRUSTED. So if you mess up your react code, there is very little that can go wrong. If you mess up server side code, however, you are asking for trouble.<p>I believe that minimalist, well audited REST or Websocket protocols are FAR more secure than server side rendering. How can you audit the entirety of your UI for security flaws? How can you analyze data leakage formally over such a large surface area? You cannot. But you can analyze 10 REST endpoints passing JSON. You can analyze RPC over websockets. Often times such specifications can fit on 4 sheets of printer paper. Take it on the train with you. Print out a copy and look for security flaws while you&#x27;re on the toilet. You can&#x27;t do that with server-side rendering.<p>I guess if there is not much data-flow both ways, then server-side rendering could be much more secure. For example, if you have a page live rendering stock charts on a news site. One that is complex but doesn&#x27;t allow for much configuration. Server side rendering would be more secure. However, if you are creating something like a CRDT based shared spreadsheet that supports formulas, server-side rendering could basically mean that you are giving untrusted clients the ability to run Turing complete code on your server ;) . You&#x27;ll be far better off having as much as possible on the client and as small and simple a protocol as you can manage between the front end and the back end.<p>Basically, security wize:<p>- If drawing the page requires a huge number of data points to create a visualization that the client cannot interact with much, then server side rendering reduces the attack surface (you&#x27;re just sending display information).<p>- If the page allows for a lot of user control over the data, you increase your attack surface by processing more untrusted information server side.
Alifatisk超过 2 年前
I agree with you, you can ship very interactive ui without the complexity on the frontend.<p>Have a look at stimulusreflex for example [1], the state is handled on the backend leading to you shipping less bloat to the client!<p>1. <a href="https:&#x2F;&#x2F;docs.stimulusreflex.com&#x2F;#faster-uis-smaller-downloads-and-longer-battery-life" rel="nofollow">https:&#x2F;&#x2F;docs.stimulusreflex.com&#x2F;#faster-uis-smaller-download...</a>
WhiteBlueSkies超过 2 年前
Whatever removes React is the way to go, it&#x27;s the most poorly thought of library out there.
评论 #34298697 未加载
评论 #34284403 未加载
v3ss0n超过 2 年前
Even in J&#x27;s world they are back to server side rendering, check astro
connormcd超过 2 年前
Check out APEX (apex.oracle.com).<p>Its been doing server side rendering for 20 years. If you got vaxxed in the USA, there&#x27;s a good chance you used APEX to book your appointment.