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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

SimpleSSR: Server-Side Rendering at Scale

136 点作者 momonga超过 6 年前

20 条评论

tylerjwilk00超过 6 年前
I may get hate for this but watching JavaScript development mature makes me feel like I am taking crazy pills. So much shit was figured out decades ago but it&#x27;s like everyone is just learning this shit for the first time. I don&#x27;t know if it is because the standard library is so lacking or that it&#x27;s been historical a client side only language but it makes me feel completely disillusioned with programming. It&#x27;s like we&#x27;re not progressing at all, merely learning that same shit over and over again each generation in a series of cycles.<p>Or maybe I&#x27;m just too old and need to get off my own lawn.
评论 #18319826 未加载
评论 #18318825 未加载
评论 #18319164 未加载
评论 #18319769 未加载
评论 #18320409 未加载
评论 #18319767 未加载
评论 #18319068 未加载
highwind超过 6 年前
You can&#x27;t beat serving useful data to the user on the first payload (base HTML), no matter how fast or clever client-side rendering gets.
评论 #18317648 未加载
评论 #18317642 未加载
BigJono超过 6 年前
I&#x27;m seeing a lot of posts about NextJS here...<p>Adding a (huge) abstraction on top of another (huge) abstraction to solve a problem introduced by the first abstraction is rubbish software engineering. It&#x27;s one of the oldest anti-patterns in the book.<p>I get that these libraries provide some utility beyond their core purpose, and that it&#x27;s a bit more nuanced than A -&gt; B -&gt; A, but I&#x27;m highly suspicious of people that recommend these libraries without giving much context behind it.
评论 #18318896 未加载
toolz超过 6 年前
disclosure: I&#x27;m the biased author<p>texas <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;dgmcguire&#x2F;texas" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;dgmcguire&#x2F;texas</a> is a library that brings development back to the server. You can integration test without headless browsers, get SPA-like UX without writing a line of JS and basically just write SSR apps with only adding a few lines of code to make you apps realtime and SPA-like.<p>It works by leveraging persistent connections (websockets) first page load is entirely SSR and subsequent updates are SSR, but only by V-DOM diffing html fragments, sending only the minimum amount of patch data over the wire.<p>Your apps will be faster, your development process will be faster with less code and removing all kinds of complex tooling.<p>Here&#x27;s a todoapp that does all rendering SSR <a href="https:&#x2F;&#x2F;warm-citadel-23442.herokuapp.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;warm-citadel-23442.herokuapp.com&#x2F;</a> - you can see just how fast it is even on a free tier of heroku - open it up in multiple clients and you&#x27;ll see that all operations are realtime broadcasted too and believe it or not there&#x27;s only like 3 lines of code you write to make that happen (plus all the code necessary to get a normal SSR app running)
评论 #18318622 未加载
评论 #18318848 未加载
评论 #18349861 未加载
评论 #18318440 未加载
评论 #18318957 未加载
评论 #18319863 未加载
评论 #18318865 未加载
kenOfYugen超过 6 年前
I can&#x27;t say I fully comprehend the SSR vs SPA war. Both concepts are definitely being misused&#x2F;overused, one is &quot;dated&quot; and the other &quot;modern&quot;, but surely the middle ground where best usage of both can be attained is prefered. I don&#x27;t know of any terms that mediate the opposition other than perhaps &quot;hydration&quot;?
评论 #18318208 未加载
friedman23超过 6 年前
I&#x27;ve been using Next.js and SSR with react is dead simple. I use React even when building standard web pages because the React way of doing things makes more sense to me as a programmer than the html&#x2F;css&#x2F;js way of doing things.<p>I like building composable building blocks with self contained state. The old model of separate html, css, and js never worked well for me.<p>My main complaint with React SSR is that it almost forces on me the requirement of using Node for the backend. I&#x27;d prefer to use a language like python.
评论 #18319980 未加载
shaunpersad超过 6 年前
Gatsby.js (and some other recent tools) makes the SSR vs. SPA argument moot. There&#x27;s no need to pick one when you can have both.<p>Disclaimer: I&#x27;m not affiliated with Gatsby.
评论 #18318873 未加载
评论 #18318910 未加载
scottmf超过 6 年前
React SSR is not a problem, and I can get quicker TTFB than I ever remember getting with even a simple RoR app (300+ms yikes).<p>I can also work faster with the React ecosystem (and find it much more enjoyable) than RoR and SSR makes the end result the same anyway.<p>People like component-based frameworks and modern JavaScript (and its supersets). Things are different now. Deal with it!
评论 #18317890 未加载
评论 #18317970 未加载
评论 #18324941 未加载
评论 #18318648 未加载
评论 #18318438 未加载
评论 #18318087 未加载
nemanja超过 6 年前
Upcoming Phoenix LiveView is actually pretty viable for SSR -<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Z2DU0qLfPIY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Z2DU0qLfPIY</a>
quantummkv超过 6 年前
I really don&#x27;t get this whole SSR thing. You take a framework designed explicitly for dynamic client side code and use it to make a glorified old school framework (insert your choice of RoR, Django, Laravel, etc).<p>Why does anyone think this is a good idea? You end up re-implementing Rails on a foundation of quicksand and manage to throw the excellent standard libraries that come with those languages out in one stroke.<p>Is this a result of too much kool-aid? Or have we ended up with hippie bootcampers without a shred of knowledge in high level positions? It&#x27;s depressing to watch really.
评论 #18319252 未加载
SomeCallMeTim超过 6 年前
On-demand Server Side Rendering should be killed for 98% of applications.<p>SSR-&gt;static hosting + client framework is the future.
RantyDave超过 6 年前
I can&#x27;t help feeling that edge rendering is greatness personified ... but that it&#x27;s perhaps not any more useful than just server side rendering. An edge renderer is still going to have to either access a model&#x2F;controller held centrally (getting our latency times up again) or use some godforsaken distributed&#x2F;replicated state that&#x27;s a bitch to debug. Perhaps an edge renderer can hold open a connection to the central logic and knock a hundred millis or so off the set up time as a result, but none of the proposed models for doing this would seem to support that. They don&#x27;t seem to support stateful <i>anything</i>.
dmcbrayer超过 6 年前
Yeah this is a little too on the nose.
评论 #18317755 未加载
mosselman超过 6 年前
The number of use cases that people implement with SPAs is huge while the number of use cases where a SPA is actually better than just rendering some HTML can be counted on one hand.
iamgopal超过 6 年前
My golang template render in tens of ms. About same time my slow computer browser take for spa.
wishinghand超过 6 年前
For those saying to forgo Next.js and to also serve templates from a non-Node server, how are sub-views handled? Same as JavaScript but the AJAX call returns a sub-template and data?
CharlesW超过 6 年前
&gt; <i>Is this a joke? Sort of, not really.</i><p><i>&quot;SimpleSSR: Don&#x27;t do SSR&quot;</i> is as humorous as <i>&quot;SimpleC++: Don&#x27;t use C++&quot;</i>. I&#x27;m guessing it&#x27;s funny to SSR haters? (Related question: Are &quot;SSR haters&quot; a thing?)<p>So is the essence of this particular hot-take that it&#x27;s better to render pages per-request with Ruby or PHP than to serve a rendered result that has no additional per-request overhead?
评论 #18317846 未加载
评论 #18318076 未加载
arborsoftware超过 6 年前
NextJS - GG
philippz超过 6 年前
After reading all the comments here... &quot;TRY ALL THE NEW FANCY FRAMEWORKS&quot;
stanislavb超过 6 年前
Let&#x27;s make SSR great again
评论 #18317747 未加载