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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

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

312 点作者 lambtron超过 2 年前

63 条评论

WuxiFingerHold超过 2 年前
There are only few use cases, where the new kind of SSR (with hydration) is worth it. An example are e-commerce sites where you want the customer to see all your great products as soon as possible and then some seconds later to be able to interact with your side fluently to buy something. These kind of scenarios paired with low end devices are the only proper use case. And I say consciously &quot;only proper&quot; because SSR comes with downsides as well:<p>- SSR is always slower than static sites<p>- SSR is often slower than CSR - especially when using a small and fast framework like Solid, Svelte or Vue3<p>- When rendering on the edge and using a central API (e.g. for the DB) SSR is always slower when interacting with the site than CSR because of the extra hop from your central API to the edge to the browser instead of from the central API directly to the browser<p>- SSR is always more complex and therefore more fragile, however this complexity is handled by the frameworks and the cloud providers<p>- SSR is always more expensive - especially at scale.<p>- Traditional SSR with html templates will scale your site much better, simply because traditional languages like Go or Java or C# are scaling much better than NodeJS rendering the site via JS<p>We owe the technology of the &quot;new&quot; SSR and genius stuff like islands many very smart and passionate people.<p>Overall, this article not balanced at all. It is pointing out only some potential benefits. It simply is a marketing post for their product.
评论 #34655673 未加载
评论 #34652623 未加载
评论 #34651818 未加载
评论 #34653948 未加载
silver-arrow超过 2 年前
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.<p><a href="https:&#x2F;&#x2F;htmx.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;</a>
评论 #34648839 未加载
评论 #34647790 未加载
评论 #34647286 未加载
评论 #34648007 未加载
评论 #34648464 未加载
评论 #34650887 未加载
评论 #34662432 未加载
bigmattystyles超过 2 年前
If you don&#x27;t do server side rendering, you don&#x27;t (almost) automatically get a set of nice REST endpoints that return JSON&#x2F;XML&#x2F;ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties. Obviously, you want the standard DDoS and security protections, but this fact alone, has turned me off server side rendering alone. Isn&#x27;t it also nice from a computation cost standpoint to let the client do the rendering? I suppose UX could suffer and for external facing apps, this is likely of the utmost importance. Happy to be educated if I&#x27;m unaware of something else.
评论 #34648196 未加载
评论 #34651016 未加载
评论 #34648495 未加载
评论 #34651368 未加载
评论 #34648201 未加载
评论 #34647983 未加载
评论 #34649385 未加载
recursivedoubts超过 2 年前
I may be misunderstanding this, but isomorphic SSR sounds an awful lot like the Java Server Faces concept of a server side DOM that is streamed to the client. JSF was largely dropped by java developers because it ended up scaling poorly, which makes sense since it violates one of the main constraints that Roy Fielding proposed for the webs REST-ful architecture: statelessness.<p>An alternative approach is to retain the statelessness of the first option they outline (I don&#x27;t understand why it isn&#x27;t &quot;true&quot; SSR): use normal, server-rendered HTML, but improve the experience by using htmx (which I made) so that you don&#x27;t need to do a full page refresh.<p>This keeps things simple and stateless, so no server side replication of UI state, but improves the user experience. From what I understand of the isomorphic solution, it appears much simpler. And, since your server side doesn&#x27;t need to be isomorphic, you can use whatever language you&#x27;d like to produce the HTML.
评论 #34646283 未加载
评论 #34647234 未加载
评论 #34647995 未加载
评论 #34649686 未加载
BackBlast超过 2 年前
&gt; Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded.<p>If you can reasonably cache the response, SSR wins on first page load, no question. On the first page dynamic render &quot;it depends&quot;, can be SPA or SSR. 2nd page render a well built SPA just wins.<p>&quot;it depends.....&quot; Server CPU cores are slower than consumer cores of similar eras. They run in energy efficient bands because of data center power concerns. They are long lived and therefore are often old. They are often segmented and on shared infrastructure. And if the server is experiencing load, seldom an issue on the client&#x27;s system, you have that to deal with also. Your latency for generating said page can easily be multi-second. As I&#x27;ve experienced on many a dynamic site.<p>Using the client&#x27;s system as a rendering system can reduce your overall cloud compute requirements allowing you to scale more easily and cheaply. The user&#x27;s system can be made more responsive by not shipping any additional full page markup for a navigation and minimizing latency by avoiding network calls where reasonable.<p>On dynamic pages, do you compress on the fly? This can increase latency for the response. If not, page weight suffers compared to static compressed assets such as a JS ball that can be highly compressed well ahead of time at brotli -11. I never brotli -11 in flight compression. Brotli -0 and gzip -1.<p>This is for well built systems. Crap SPAs will be crap, just as crap SSR will similarly be crap. I think crap SPAs smell worse to most - so there&#x27;s that.<p>&gt; Compatibility is higher with server-side rendering because, again, the HTML is generated on the server, so it is not dependent on the end browser.<p>If you use features the end client doesn&#x27;t support, regardless of where you generate the markup, then it won&#x27;t work. Both servers and clients can be very feature aware. caniuse is your friend. This is not a rule you can generalize.<p>&gt; Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase.<p>Meh. Debatable. What&#x27;s hard is mixing the two. Where is your state and how do you manage it?<p>If you&#x27;re primarily a backend engineer the backend will feel more natural. If you&#x27;re primarily a front end engineer the SPA will feel more natural.
评论 #34650289 未加载
评论 #34652060 未加载
评论 #34672093 未加载
cutler超过 2 年前
What on earth does this tangled mess &quot;simplify&quot;? I&#x27;ve been at it with web dev for over 20 years and I was left scratching my head. The trouble with going down the JS rabbit hole is that you lose perspective on simplicity. **d help us if this becomes the new hotness. Oh, wait it already is. Oh well, until next month ...
评论 #34650701 未加载
评论 #34650599 未加载
Glench超过 2 年前
Shoutout to Sveltekit which does SSR and client-side navigation by default! <a href="https:&#x2F;&#x2F;kit.svelte.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kit.svelte.dev&#x2F;</a>
评论 #34656084 未加载
eric4smith超过 2 年前
Most SPA is totally unnecessary and a big waste of time.<p>People are worrying about the speed of SSR when they should be worrying about the developer time on the client which is several orders of magnitude more.<p>I think people have fallen in love so much with complex Javascript frameworks that they’ve forgotten how easy it is to get to an MVP with SSR.<p>Speed is important.<p>Speed of development is even more important for businesses in this era who have to get to revenue faster.<p>And that’s why things like Phoenix LiveView and its counterparts in other languages is catching on so quickly.<p>People are getting fatigued with the latest flavor of the month JS framework.<p>But what do I know… I’m just a lowly “developer” working for crumbs. Never even finished a CS degree. Sigh.
评论 #34650284 未加载
评论 #34652681 未加载
underbluewaters超过 2 年前
Mindshare will go towards rendering javascript components on the server since that&#x27;s another complex problem that&#x27;s fun to solve. That&#x27;s good! We shouldn&#x27;t have to give up the productivity gains of tools like React to improve time-to-interactive and other performance stats.<p>That said... I&#x27;m not going to pretend it&#x27;s an urgent need and will wait for these tools to mature.
w4eg324g超过 2 年前
Idk Im not so much into web development but isn&#x27;t ssr rendering much more expesive? I just move all the processing&#x2F;calculation to my&#x2F;server side instead of the clients. This means for a business with many clients I have to pay for the stuff that the clients themselves could have done instead...
评论 #34648004 未加载
评论 #34648233 未加载
评论 #34648198 未加载
评论 #34648781 未加载
xrd超过 2 年前
I&#x27;ve been using svelte for years and love it.<p>I&#x27;ve been using sveltekit for years and still struggle with it.<p>With sveltekit, I&#x27;m never really sure when to use prerender. I&#x27;m never sure how and where my code will run if I switch to another adapter.<p>With pure svelte, my most ergonomic way of working is using a database like pocketbase or hasura 100% client side with my JavaScript, so the server is a static web server. It&#x27;s got real time subscriptions, graphql so my client code resembles the shape of my server side data, and a great authentication story that isn&#x27;t confusing middleware.<p>I&#x27;m sure SSR is better for performance, but it always seems to require the use of tricky code that never works like I expect it to.<p>Am I missing something?
评论 #34648975 未加载
gwbas1c超过 2 年前
Does anyone know the stats about what&#x27;s being served?<p>For things like blogs, server-side HTML with a sprinkle of client-side Javascript (or WASM) makes a lot of sense.<p>But for applications, where you&#x27;re doing, you know, work and stuff, in-browser HTML makes a lot more sense.<p>The thing is, as a developer, most of the <i>work</i> is in applications. (It&#x27;s not like we need to keep writing new blog engines all the time.) Thus, even though most actual usage of a browser might be server-side HTML, most of our development time will be spent in in-browser HTML.
brundolf超过 2 年前
I love Deno, I hope it succeeds, but I&#x27;m disappointed to see them so confidently publishing a broad assertion like this that&#x27;s very weakly argued, and heavily biased towards promoting their own position in the stack<p>&gt; Compatibility is higher with server-side rendering because, again, the HTML is generated on the server, so it is not dependent on the end browser.<p>Excuse my bluntness, but this is complete nonsense. Browser incompatibility in 2023 is mostly limited, in my experience, to 1) dark corners of CSS behavior, and 2) newer, high-power features like WebRTC. #1 is going to be the same regardless of where your HTML is rendered, and if you&#x27;re using #2, server-side rendering probably isn&#x27;t an option for what you&#x27;re trying to do anyway. I can confidently say browser compatibility has roughly <i>zero</i> effect on core app logic or HTML generation today.<p>&gt; Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase.<p>This, again, is totally hand-wavy and mostly nonsensical. It&#x27;s entirely dependent on what kind of app, what kind of features&#x2F;logic it has, etc. Server-rendering certain apps can definitely be simpler than client-rendering them! And the opposite can just as easily be true.<p>&gt; Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded.<p>This is only partly true, and it&#x27;s really the only partly-valid point. Modern statically-rendered front-ends will show you the initial content very quickly, and then will update quickly as you navigate, but there is a JS loading + hydration delay between seeing the landing page content and being able to interact with it at the beginning. You certainly don&#x27;t need &quot;a desktop...with a wired internet connection&quot; for that part of the experience to be good, but I&#x27;m sure it&#x27;s less than ideal for people with limited bandwidth. It&#x27;s something that can be optimized and minimized in various ways (splitting code to make the landing page bundle smaller, reducing the number of nested components that need to be hydrated, etc), but it&#x27;s a recurring challenge for sure.<p>The tech being demonstrated here is interesting, but I wish they&#x27;d let it stand on its own instead of trying to make sweeping statements about the next &quot;tock&quot; of the web trend. As the senior dev trope goes, the answer to nearly everything is &quot;it depends&quot;. It shows immaturity or bias to proclaim that the future is a single thing.
评论 #34648217 未加载
评论 #34648388 未加载
0x445442超过 2 年前
The problem is more fundamental and it’s this; web apps are broken and have been from the beginning. They were created to solve the problems related to software distribution and updates but these problems were solved in the early 2000s when broadband became prevalent and it was no longer painful to download large software packages.<p>The early straw man was that downloading apps was too daunting a task for users and yet some how they managed to download and update email clients, word processors, iTunes and ironically browsers themselves.<p>Since I began my career in 1995 I’ve seen application architecture pundits proclaim the correct way to develop applications go from thick client native to thin client native to thin client web to thick client web back to thick client native (iOS &amp; Android) and now, according to the article back to thin client web. I’ll submit the best model is thick client native using the “web” as a communication backbone for networked features.
dragonelite超过 2 年前
And the cycle starts anew...
gavinray超过 2 年前
The article seems to contradict itself:<p>The first example shows the server rendering a handlebars template and then sending that as a response to the client -- it&#x27;s then stated that this &quot;isn&#x27;t true SSR&quot;<p>Then the same thing is done without a template language, using strings instead, and this is some different kind of SSR altogether and the &quot;true SSR&quot;.<p>Which also seems to insinuate that only JS&#x2F;TS are capable of SSR?<p><pre><code> 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&#x27;re also using render within the client to render updates.</code></pre>
评论 #34647934 未加载
评论 #34647858 未加载
rbanffy超过 2 年前
My first contact with HTTP and HTML forms was an immediate throwback to my mainframe experience. The browser was like a supermodern 3270 terminal, getting screens from the server, sending data back, getting another screen and so on.<p>There were a number of products that allowed a web app to maintain a 3270 connection to the mainframe and render the terminal screens as an HTML form. Fascinating stuff.
klysm超过 2 年前
It’s also totally fine to not SSR if the benefits aren’t important to you.
advisedwang超过 2 年前
This is why I&#x27;m really excited about htmx [1]. No need to write isomorphic javascript at all. You can still use server side templates but have interactive web pages.<p>[1] <a href="https:&#x2F;&#x2F;htmx.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;</a>
评论 #34647839 未加载
评论 #34646929 未加载
评论 #34648165 未加载
评论 #34646886 未加载
Existenceblinks超过 2 年前
There are 2 things that are orthogonal in current trend. This SSR buzz is not actually selling Server Side Rendering, they are selling &#x27;one language to rule them all&#x27; (they call this dumb name &quot;isomorphic&quot;).<p>Therefore, they are not solving all the problems of client-server + best UX constraints. Basically the problems we have all this time comes from:<p><pre><code> 1) There&#x27;s a long physical distance between client and server 2) Resource and its authorization have to be on server. 2) There&#x27;s the need for fast interaction so some copy of data and optimistic logic need to be on client. </code></pre> The &quot;isomorphic&quot; reusable code doesn&#x27;t solve [latency + chatty + consistent data] VS [fast interaction + bloat client + inconsistent data] trade-off. At this point I don&#x27;t know why they think that is innovation.
评论 #34648646 未加载
blank_fan_pill超过 2 年前
IME the big gains nearly always come from how data is surfaced and cached from the storage layer.<p>You may get some nominal gains from sending less JS or having the server render the html, but IME the vast majority of apps have much bigger wins to be had further down the stack.
nubinetwork超过 2 年前
&gt; JavaScript got good<p>&quot;A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.&quot; - would like to have a word with you...
gfodor超过 2 年前
If you’re interested in server side rendered multiplayer 3D worlds, my project webspaces[1] lets you render HTML and get a 3D World.<p>[1] <a href="https:&#x2F;&#x2F;webspaces.space" rel="nofollow">https:&#x2F;&#x2F;webspaces.space</a>
评论 #34646997 未加载
ArcaneMoose超过 2 年前
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&#x27;s browser to handle the compute &quot;for free&quot;.
评论 #34646671 未加载
评论 #34645992 未加载
评论 #34646145 未加载
评论 #34656138 未加载
评论 #34647549 未加载
albertopv超过 2 年前
&quot;A fully server side rendered version with isomorphic JS and a shared data model&quot;<p>Seriously, how did we get there? Having dealt with jsp, jsf (myfaces, trinidad, adf...), asp.net, asp mvc, angular, plain html&#x2F;css&#x2F;js, how is is possible for FE web dev to be such a mess? So much complexity, for what? How many have to deal with millions of visit per day? Or even month? It seems to me history is quickly forgotten and new generations know very little about the past.<p>Keep it simple, please.
amadeuspagel超过 2 年前
You can do HTML templating directly in JS using tagged template literals[1], and a library to deal with problems like XSS attacks[2].<p>[1]: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;JavaScript&#x2F;Reference&#x2F;Template_literals" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;JavaScript&#x2F;Refe...</a><p>[2]: <a href="https:&#x2F;&#x2F;workers.tools&#x2F;html&#x2F;" rel="nofollow">https:&#x2F;&#x2F;workers.tools&#x2F;html&#x2F;</a>
pookha超过 2 年前
WASM-side rendering. :)
评论 #34647022 未加载
koromak超过 2 年前
I feel behind here, my company doesn&#x27;t do any SSR and theres basically no way we could port it over. Definitely missing out on some key concepts.<p>I could build some SSR apps on my own but like, the real hard stuff about development comes &gt;1 year in when you start running into those deep complexity issues. Can&#x27;t really simulate that in a tiny pet project.
szastamasta超过 2 年前
I think that biggest issue with page size is not due to client side rendering, but rather thanks to bundling and idea that you need to download the same minified Lo-Dash on each and every page. Why can’t we just use public CDNs is beyond my understanding.<p>I really like client side apps. They are so much more responsive. The only problem is with bundle sizes.
评论 #34646500 未加载
评论 #34649035 未加载
slimebot80超过 2 年前
Note: Remix is not built on React, as the article states.<p>Of all the new ways of thinking, Remix is the leader in <i>not</i> promoting a specific paid delivery platform. So in that sense I can see why people might want to mitigate its advantages by trying to tie it to React.<p>(having said that, Shopify might tie it down more, but I see no evidence so far)
评论 #34652678 未加载
ravenstine超过 2 年前
The future of the web is most web developers losing their jobs for failing to be good stewards of their platform.
评论 #34650879 未加载
评论 #34651002 未加载
评论 #34648658 未加载
floodfx超过 2 年前
If you are looking for server-side rendering that enables rich, react-like user experiences, check out LiveViewJS (<a href="http:&#x2F;&#x2F;liveviewjs.com" rel="nofollow">http:&#x2F;&#x2F;liveviewjs.com</a>). Supports both Deno and Node runtimes.<p>(Full disclosure: am author)
anonymousDan超过 2 年前
Is SSR still much better for seo?
评论 #34646111 未加载
评论 #34646089 未加载
评论 #34652252 未加载
评论 #34650933 未加载
ChrisMarshallNY超过 2 年前
Anyone remember There? It&#x27;s still around[0], but I don&#x27;t know how active it is.<p>I&#x27;m pretty sure it relied on in-browser XSLT to do a lot of its magic.<p>[0] <a href="https:&#x2F;&#x2F;there.com" rel="nofollow">https:&#x2F;&#x2F;there.com</a>
JohnFen超过 2 年前
If web sites have to so dynamic, I much prefer that the computation involved is done on their machine than on mine. I simply don&#x27;t trust random web sites enough to let them run code on my machines.
评论 #34645657 未加载
FpUser超过 2 年前
The future is not to stick to a single religion but to apply one&#x27;s brains when architecting solution as it all depends on multiple factors and there are no silver bullets in this universe.
henning超过 2 年前
<p><pre><code> But all that code is necessary to make our sites work the way we want. </code></pre> It&#x27;s necessary to make shitty websites that are impossible to load on slow&#x2F;flaky connections.
zeroonetwothree超过 2 年前
&gt; Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded.<p>I don&#x27;t see why we should assume the server is faster at processing the input data into HTML than the client is. It could very easily be that the client device does this faster. SSR additionally prevents progressive rendering, since you must generat eall the HTML ahead of time, which can make pages feel slower. Also HTML+JS data size can be larger than data+JS size (and you &#x2F;may&#x2F; need the data anyway for the SSR version to do hydration). Of course all this varies, which is why it&#x27;s silly to claim a general principle.
评论 #34656190 未加载
ericls超过 2 年前
The claim that server side rendering is faster than client side rendering is interesting.. How come one machine(the server), is better than 1000 machines(the client)?
评论 #34651746 未加载
pictur超过 2 年前
It is tragicomic that the slogan &quot;We should do things on the server instead of the browser&quot; is becoming popular again as browser technologies evolve.
MentallyRetired超过 2 年前
It depends on what you&#x27;re building. Choose the best tool for the job. Every time. Don&#x27;t just default to your favorite.
gardenhedge超过 2 年前
I use Remix for this. Remix is 4 things:<p>A compiler<p>A server-side HTTP handler<p>A server framework<p>A browser framework<p>You can actually use Remix as just a server-side framework without using any browser JavaScript at all.
benatkin超过 2 年前
Haha. Lolnope.jpg
beej71超过 2 年前
&quot;But all that code is necessary to make our sites work the way we want.&quot;<p>Yes, but, on the other hand, is it?
trollied超过 2 年前
“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that.<p>I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.
评论 #34646120 未加载
评论 #34645946 未加载
评论 #34646076 未加载
评论 #34646549 未加载
评论 #34646141 未加载
评论 #34645936 未加载
评论 #34646303 未加载
评论 #34646355 未加载
评论 #34646152 未加载
评论 #34647745 未加载
评论 #34646083 未加载
评论 #34646452 未加载
评论 #34646081 未加载
mikece超过 2 年前
And the future beyond that will be client-side rendering. In the beginning everything was rendered on the mainframe; then CICS allowed partial screen updates and even dynamic green screen design. Then the early web where everything was server which made the job of web indexing much easier. Then we moved back to rich client apps -- applets, flash, eventually SPAs -- with no way for search engines to easily index things. A best of all worlds scenario is a rich UI that only needs to make API calls to update the display, keeping performance fast and content flicker-free (and the server-side API could have an agreed upon standard for being indexed -- or submitting updates for indexing -- to search engines).<p>There is no truly perfect scheme, only ways in which we think we can improve on the status quo by swinging the pendulum back and forth.
评论 #34645947 未加载
评论 #34645439 未加载
评论 #34646846 未加载
runako超过 2 年前
In theory, the &quot;modern&quot; frontend frameworks could be useful for a subset of applications. In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them.<p>If I gave this as an example, people would say I&#x27;m being unfair to the front-end folks. But since Deno posted it, I think it&#x27;s fair say that it&#x27;s overkill to use a front-end framework like React (mentioned as a comparator in TFA) to implement add to cart functionality on an e-commerce site. And that for users with slow browsers, slow&#x2F;spotty Internet, etc., an architecture that uses a heavy front-end framework produces a worse overall experience than what most e-commerce sites were able to do in 1999.<p>Edit: IMHO all of this is an artifact of mobile taking a front seat to the Web. So we end up with less-than-optimal Web experiences due to overuse of front-end JS everywhere; otherwise shops would have to build separate backends for mobile and Web. This, because an optimal Web backend tends to produce display-ready HTML instead of JSON for a browser-based client application to prepare for display. Directly reusing a mobile backend for Web browsers is suboptimal for most sites.
评论 #34646918 未加载
评论 #34646855 未加载
评论 #34646825 未加载
评论 #34646942 未加载
评论 #34646794 未加载
评论 #34646841 未加载
computing超过 2 年前
&quot;The future of the Web is what suits our business model&quot; &#x2F;s<p>But in all seriousness, the web has websites, it has apps, it has games. Pick a tool that&#x27;s appropriate for the job and forget about what is the past&#x2F;present&#x2F;future.
评论 #34646167 未加载
评论 #34646512 未加载
lbriner超过 2 年前
The thing that went wrong with front-end frameworks imho was that instead of being what was promised: you could update UI elements with NO NEED to contact the server at all, only posting back when something needed persisting, instead it became an excuse that every action on the front-end needed to call an API or 3 so we&#x27;ve ended up with over-complicated apps that instead of not relying on the backend are relying on it more than ever.<p>Any little glitch, slowdown or unavailability is affecting you not only once on page load but potentially with every single interaction. To make it worse, a lot of backend interactions are not made interactively or synchronously where the user might expect to wait a little while, they are made in the background causing all manner of edge cases that make apps somewhere from very slow to virtually unuseable.<p>I guess it&#x27;s that old adage that people will make use of whatever you offer them, even if they go too far.
评论 #34648395 未加载
Animats超过 2 年前
I&#x27;m always amused to hear web types speak of grinding HTML, CSS, and JavaScript down to somewhat simpler HTML, CSS, and JavaScript as &quot;rendering&quot;. Rendering, to graphics people, is when you make pixels.
评论 #34647734 未加载
评论 #34647908 未加载
评论 #34647911 未加载
tlarkworthy超过 2 年前
It&#x27;s obviously nonsense. The lowest latency cache and state storage is clientside. You can piss around with multi regions and SSR to minimize latency but that&#x27;s just placing a lot of regional caches <i>near</i> your users. The nearest place is in their actual browser -&gt; offline first is the future
评论 #34646884 未加载
评论 #34646738 未加载
评论 #34646854 未加载
seydor超过 2 年前
I think it&#x27;s a bit ridiculous to call it &quot;server side rendering&quot;. It is called HTTP
评论 #34646186 未加载
评论 #34646388 未加载
评论 #34646698 未加载
评论 #34648047 未加载
评论 #34648414 未加载
rafaelturk超过 2 年前
Can someone explain me: Deno is becoming such a confusing framework, initially NodeJS alternative now it seems to me that is trying to compete with NextJs?
评论 #34646350 未加载
评论 #34646881 未加载
jhp123超过 2 年前
&gt; Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded.<p>but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work, probably an absolute increase because some logic is duplicated. If there is a speed improvement it is because the server has more clock cycles available than the client, but this is not always true.<p>&gt; Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase.<p>Huh? It takes less code to build a string in a datacenter than it does in a browser?
评论 #34646455 未加载
评论 #34646348 未加载
评论 #34646514 未加载
评论 #34646839 未加载
评论 #34646257 未加载
评论 #34646862 未加载
flippinburgers超过 2 年前
The &quot;modern&quot; state of the web. I miss old school html with little to no javascript. It is all java in the browser all over again. Or flash. Same old same old. Very few websites need any of this stuff. It is just a bunch of junior devs wishing they worked for FB I guess ergo them guzzling react like there is no tomorrow.
评论 #34648351 未加载
andrewstuart超过 2 年前
I really don’t like server side rendering.<p>I like my react apps to be static files served from a plain HTML server.
评论 #34646892 未加载
评论 #34647568 未加载
评论 #34646865 未加载
pcmaffey超过 2 年前
Client-side rendering needs to rebrand as local-first. Then the cycle will start anew.
评论 #34646890 未加载
EVa5I7bHFq9mnYK超过 2 年前
Next step: server rendered PNGs. Browser not required.
评论 #34648405 未加载
rado超过 2 年前
npm install common-sense
评论 #34645852 未加载
评论 #34645568 未加载
评论 #34646010 未加载
评论 #34646505 未加载
EugeneOZ超过 2 年前
No. Because HTML is not the future of the Web.
评论 #34649349 未加载
brap超过 2 年前
&gt;ctrl+f “State”<p>&gt;ctrl+f “Effect”<p>&gt;0 results<p>I only skimmed through the post, but seems like it’s ignoring the main reasons why CSR is needed?
cyanydeez超过 2 年前
Am fairly certain the move back to the server has more to do with the development of heavy AI data modelling that can&#x27;t be offloaded to the client.<p>Don&#x27;t believe the tech itself is Anything but a sign of where the utilities are moving
bool3max超过 2 年前
&quot;Server-side rendering&quot; is destined to rule the future purely because of <i>control</i>. In the future consumer devices will be simplified, much more streamlined, and completely locked down. They will be used for the single purpose of displaying streamed, pre-packaged, pre-layed-out content from servers.