客户端渲染 服务端渲染_这就是赢得客户端渲染的原因

客户端渲染 服务端渲染

A decade ago, nearly everyone was rendering their web applications on the server using technologies like ASP.NET, Ruby on Rails, Java, and PHP.

十年前，几乎每个人都使用ASP.NET，Ruby on Rails，Java和PHP等技术在服务器上呈现其Web应用程序。

Then handy libraries like jQuery showed up, and suddenly server-side rendering everything didn’t necessarily make sense anymore. jQuery was followed by a long list of client-side libraries like Backbone, Knockout, Angular, Ember, and React. With each iteration, client-side rendering grew easier and more powerful.

然后出现了像jQuery这样的方便的库，突然在服务器端呈现所有内容已不再有意义。 jQuery之后是一排客户端库，例如Backbone，Knockout，Angular，Ember和React。 在每次迭代中，客户端渲染变得更加轻松和强大。

This style goes by many names: Single page apps, SPAs, JAM stack…call it what you will. The point is, today, client-side rendering has become the de-facto way to build rich web applications…But why?

这种样式有很多名称：单页应用程序，SPA， JAM堆栈 …随便叫什么。 关键是，今天，客户端渲染已成为构建富Web应用程序的实际方法……但是为什么呢？

大家好，让我们一起努力吧 (Hey Everyone, Let’s Do It The Hard Way)

There’s no denying that client-side rendering is harder to do well. You have to think about bundling, transpiling, linting, cache busting, and so much more. Doing client-side right is so hard that I walk through over 40 decisions you need to make to get all this right in my new Pluralsight course.

无可否认的是客户端呈现是很难做的很好 。 您必须考虑捆绑，转码，整理，缓存破坏等等 。 正确地执行客户端方面的工作非常困难，以至于我要逐步完成40项决策，才能在我的新Pluralsight课程中做到所有这些。

So why are we subjecting ourselves to such pain? Because client-side rendering offers a long list of benefits that server-side rendering just can’t touch.

那么，为什么我们要承受这种痛苦呢？ 由于客户端渲染提供了很多好处，因此服务器端渲染是无法触及的。

Here’s why client-side rendering won.

这就是赢得客户端渲染的原因。

无需重新加载整页 (No Full Page Reload Required)

With traditional server-side rendering, the server responds by generating and returning a completely new page for every interaction. This often slows load time, uses more bandwidth, and creates a less responsive user experience.

使用传统的服务器端渲染，服务器通过为每次交互生成并返回一个全新的页面来做出响应。 这通常会减慢加载时间，使用更多带宽，并导致响应速度较慢的用户体验。

Client-side rendering avoids making unnecessary requests for a full page when only a portion of the page has changed. This is especially helpful in a world that’s increasingly browsing via mobile networks with high latency.

客户端渲染避免了仅更改页面的一部分时对整个页面进行不必要的请求。 在当今世界越来越多地通过具有高延迟的移动网络进行浏览的情况下，这尤其有用。

延迟加载 (Lazy Loading)

Client-side rendering supports lazy loading sections of your application to save bandwidth & speed initial load. For example, you can load additional records, images, and ads as the user scrolls down, or as the user changes their search parameters, all without performing a full postback.

客户端渲染支持应用程序的延迟加载部分，以节省带宽并加快初始加载。 例如，您可以在用户向下滚动或用户更改搜索参数时加载其他记录，图像和广告，而无需执行完整的回发。

丰富的互动 (Rich Interactions)

Client-side rendering supports rich, animated interactions, transformations, and transitions. Fade a row out on delete, or fade a dialog into view. Sure, you can sprinkle such goodness into a server-rendered application, but this often leads to maintaining the same template on both the client and the server, or managing the complexity of weaving JavaScript interactions in with a server-side framework.

客户端渲染支持丰富，生动的交互，转换和过渡。 在删除时淡出一行，或将对话框淡入视图。 当然，您可以将这种优点撒到服务器呈现的应用程序中，但这通常导致在客户端和服务器上都维护相同的模板，或者管理将JavaScript交互与服务器端框架结合在一起的复杂性。

廉价托管 (Cheap Hosting)

Hosting static files is typically cheaper than hosting traditional server-side technologies like ASP.NET, PHP, or Ruby. You don’t need much horsepower to serve a static file. Serving static files is so cheap in fact, that a variety of solid free options exist including Surge, Firebase, and Netlify.

托管静态文件通常比托管传统的服务器端技术(例如ASP.NET，PHP或Ruby)便宜。 您不需要太多的精力来提供静态文件。 实际上，提供静态文件非常便宜，以至于存在各种固态免费选项，包括Surge ， Firebase和Netlify 。

使用CDN (Use a CDN)

A static front-end can be hosted via a content delivery network (CDN). CDNs deliver improved performance by globally distributing assets as well as improved scalability by removing load from your webserver. The aforementioned static hosts utilize a CDN.

静态前端可以通过内容分发网络(CDN)托管。 CDN通过在全球范围内分配资产来提高性能，并通过减轻Web服务器的负载来提高可伸缩性。 前述静态主机利用CDN。

轻松部署 (Easy Deployments)

Static files are easy to deploy. You don’t necessarily need to perform a monolithic build to generate new binaries when a small change occurs. And with some of the aforementioned services like Surge and Netlify, you can easily create automated deployments via their provided CLIs. When you do so, you don’t risk breaking any of your back-end - it’s handled completely separately.

静态文件易于部署。 当发生微小变化时，您不必执行整体构建即可生成新的二进制文件。 借助上述某些服务，例如Surge和Netlify，您可以通过其提供的CLI轻松创建自动化部署。 这样做时，您不必冒任何后端折断的风险-完全分开处理。

强制分离问题 (Enforced Separation of Concerns)

Many teams struggle with keeping data access and business logic out of the user interface. With client-side rendering, separation of concerns is programatically enforced. There’s no way to directly hit the database. You have to make a call to a separate service. This helps foster a service-oriented mindset on development teams since there’s no way to make a short-cut and call the database directly from the UI.

许多团队努力将数据访问和业务逻辑限制在用户界面之外。 通过客户端渲染，以编程方式实现关注点分离。 无法直接访问数据库。 您必须致电一个单独的服务。 由于无法捷径直接从UI调用数据库，因此这有助于在开发团队上树立面向服务的思维方式。

学习一次，随处书写 (Learn Once, Write Everywhere)

Imagine you’re a new graduate. What is the only language that will allow you to build web applications, APIs, mobile applications, and desktop apps? JavaScript. Increasingly, that’s precisely what new grads are reaching for. Why should a new grad learn a dedicated server-side technology when JavaScript runs everywhere?

想象你是一个新毕业生。 什么是允许您构建Web应用程序，API，移动应用程序和桌面应用程序的唯一语言？ JavaScript。 越来越多地，这正是新毕业生所要达到的目标。 当JavaScript随处可见时，为什么新毕业生应该学习专用的服务器端技术？

This is why it will continue to swallow the world.

这就是为什么它将继续吞没世界的原因。

JavaScript is like Visa. It’s everywhere you want to be.

JavaScript就像Visa。 它无处不在。

适用于Web，本机移动和桌面的相同UI技术 (Same UI Technology for Web, Native Mobile, and Desktop)

Imagine you want to build a SPA-style web application, a native mobile app, and a desktop app. Today’s modern JavaScript frameworks allow you to use the same UI technology for all three scenarios.

假设您要构建SPA风格的Web应用程序，本机移动应用程序和桌面应用程序。 当今的现代JavaScript框架允许您针对所有三种情况使用相同的UI技术。

For instance, you can use Angular, Ionic, and Electron, to work in Angular for all three targets. Or, you can use React, React Native, and Electron to work in React for all three targets. And the resulting applications will run on iOS, Android, Windows, and macOS. Sure beats learning Objective-C, Swift, Java, C#, WPF and more to support all these platforms!

例如，您可以使用Angular，Ionic和Electron在所有三个目标的Angular中工作。 或者，您可以使用React，React Native和Electron在所有三个目标的React中工作。 最终的应用程序将在iOS，Android，Windows和macOS上运行。 当然，要学习支持所有这些平台的Objective-C，Swift，Java，C＃，WPF和更多内容，不胜枚举！

Edit — I had a point here about Progressive Web App support but was incorrect. You don’t need to do client-side rendering to build a PWA.

编辑 -这里我对渐进式Web应用程序的支持有一点，但不正确。 您无需进行客户端渲染即可构建PWA。

所以。 许多。 自由。 (So. Much. Free.)

JavaScript moves so fast that the hardest part of client-side rendering is choosing how you’re going to get it done. The number of free options is simply overwhelming and growing fast.

JavaScript动作如此之快，以至于客户端渲染中最困难的部分就是选择如何完成它。 免费选项的数量简直是压倒性的并且正在Swift增长。

Yeah, it’s a great problem. And there’s no need to pay for the libraries, frameworks and editors your team needs. I walk through and set up dozens of useful free tools in “Building a JavaScript Development Environment”. (free trial)

是的，这是一个很大的问题。 无需为团队所需的库，框架和编辑器付费。 在“ 构建JavaScript开发环境 ”中，我逐步学习并建立了数十个有用的免费工具。 ( 免费试用 )

服务器端渲染是否有意义？ (Does Server-Side Rendering Make Sense Anymore?)

Sure. But in far fewer situations than before.

当然。 但情况比以前少得多。

If you need interactivity and can’t rely on JavaScript, then obviously client-side rendering is out.

如果您需要交互性且不能依赖JavaScript，则显然客户端渲染已不可用。

If you’re building a mostly static site, server-side rendering might be easier. Though awesome tools like Jekyll, Gitbook, Gatsby, and countless alternatives are encroaching on this area too. And since tools like these just generate static HTML, you don’t have to worry about SEO impacts either.

如果您要构建一个主要是静态站点，则服务器端渲染可能会更容易。 尽管诸如Jekyll ， Gitbook ， Gatsby之类的强大工具以及无数替代品也正在蚕食这一领域。 而且由于此类工具仅生成静态HTML，因此您也不必担心SEO的影响。

SEO is a common selling point for server-side rendering, but the advent of isomorphic/universal rendering in libraries like React has addressed this concern as well. Universal rendering used to be hard, but modern tools like Zeit’s next.js finally make this trivial as well!

SEO是服务器端渲染的常见卖点，但是在类似React的库中，同构/通用渲染的问世也解决了这一问题。 通用渲染曾经很难，但是像Zeit的next.js这样的现代工具最终也使它变得微不足道！

Given all the advantages above, I struggle to find good reasons to do traditional server-side rendering anymore.

鉴于以上所有优点，我很难找到充分的理由再进行传统的服务器端渲染。

Sure it’s still hard to do well. But for all the reasons above, client-side rendering won.

当然，仍然很难做好。 但是由于上述所有原因，客户端呈现才成功。

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect at VinSolutions, a Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

Cory House是JavaScript，React，干净代码，.NET等课程的多本课程的作者，并且还提供了有关Pluralsight的更多课程 。 他是reactjsconsulting.com的首席顾问， VinSolutions的软件架构师，Microsoft MVP，并且在软件开发方面对国际软件开发人员进行了培训，例如前端开发和简洁编码。 Cory在Twitter上以@housecor表示关于JavaScript和前端开发的推文 。

翻译自: https://www.freecodecamp.org/news/heres-why-client-side-rendering-won-46a349fadb52/

客户端渲染 服务端渲染