项目delay 应对_哪些项目需要应对？ 他们全部！

项目delay 应对

by Sacha Greif

由Sacha Greif

哪些项目需要应对？ 他们全部！ (Which Projects Need React? All Of Them!)

When does a project need React? That’s the question Chris Coyier addressed in a recent blog post. I’m a big fan of Chris’ writing, so I was curious to see what he had to say.

一个项目什么时候需要React？ 克里斯·科耶尔(Chris Coyier)在最近的博客文章中解决了这个问题。 我是克里斯写作的忠实拥护者，所以我很好奇他必须说些什么。

In a nutshell, Chris puts forward a series of good and bad reasons why one might want to use React (or other similar modern JavaScript libraries) on a project. Yet while I don’t disagree with his arguments, I still find myself coming to a different conclusion.

简而言之，Chris提出了一系列利弊的原因，为什么人们可能想在项目上使用React(或其他类似的现代JavaScript库)。 尽管我不同意他的观点，但我仍然发现自己得出了不同的结论。

So today, I’m here to argue that the answer to “When does a project need React?” is not “it depends.” It’s “every time.”

所以今天，我在这里争辩说，“项目何时需要React？”的答案。 不是“取决于”。 每次都是。 ”

React vs Vue vs Angular vs… (React vs Vue vs Angular vs…)

First, let’s get something out of the way: in his article, Chris picked React as a stand-in for “front-end libraries” in general, and I’ll do the same here. Plus, React is what I’m most familiar with from my ongoing work on VulcanJS, a React and GraphQL framework.

首先，让我们摆脱困境：克里斯在他的文章中选择了React作为一般“前端库”的替代品，我将在这里做同样的事情。 另外，React是我对VulcanJS (React和GraphQL框架)进行的最熟悉的工作。

That being said, my arguments should apply equally well to any other library that offers the same features as React.

话虽如此，我的论点也应同样适用于其他任何具有与React相同功能的库。

锤子的力量 (The Power of the Hammer)

“When all you have is a hammer, everything looks like a nail.”

“当你只有锤子时，一切看起来就像钉子。”

This proverb has long been used to condemn anybody trying to apply a systematic one-size-fits-all approach to every problem.

这个谚语长期以来一直被用来谴责任何试图对每个问题都采用系统的“一刀切”的人。

But let’s suppose for a moment that you did live in a world full of nails (however uncomfortable this might sound), and that your trusty hammer was able to take care of any issues you encounter.

但是，让我们假设您确实生活在一个充满指甲的世界中(这听起来可能令人不舒服)，并且您值得信赖的锤子能够解决您遇到的任何问题。

Just consider the benefits of being able to reuse the same tool every time:

只要考虑一下每次都能重用同一工具的好处：

• No time spent on deciding which tool to use.
  无需花费时间来决定使用哪种工具。
• Less time spent having to learn new tools.
  花费在学习新工具上的时间更少。
• More time to get better at wielding your tool of choice.
  有更多时间可以更好地运用您选择的工具。

So is React that tool? I think it just might be!

那么React是那个工具吗？ 我想可能就是这样！

复杂度谱 (The Complexity Spectrum)

First, let’s address the most common argument against the “React all the things!” approach. I’ll quote directly from Chris:

首先，让我们解决最普遍的反对“应对一切！”的论点。 方法。 我直接引用克里斯的话：

“A blog, for example, probably has none of the problems and fits none of the scenarios that would make React a good fit. And because it’s not a good fit, it’s probably a bad fit, because it introduces complicated technology and dependencies for something that doesn’t call for it.”

“例如，博客可能没有任何问题，也没有适合React的情况。 而且，因为它不是一个不错的选择，它可能是一个坏的配合，因为它引入了的东西，并不要求它复杂的技术和依赖“。

Fair enough. A simple blog doesn’t need React. After all, even if you need a bit of JavaScript to hook up a newsletter sign-up form, you can just use jQuery.

很公平。 一个简单的博客不需要 React。 毕竟，即使您需要一些JavaScript来连接新闻通讯注册表单，也可以使用jQuery。

What’s that? You need to use that form in multiple places on different pages? And only show it under certain conditions? And animate it, too? Wait, hold on…

那是什么？ 您需要在不同页面的多个位置使用该表单吗？ 仅在特定条件下显示？ 并为其设置动画吗？ 等等，等等...

The point I’m trying to make with this little scenario is that complexity is not an all-or-nothing, binary choice. Instead, modern websites live on a continuous spectrum that goes from static page all the way to rich single-page app.

在这种小情况下，我想说明的一点是，复杂性不是一个全有或全无的二进制选择。 取而代之的是，现代网站生活在一个连续的频谱中，从静态页面一直到丰富的单页面应用程序。

So maybe your project is comfortably nested at the “simple” end of the spectrum now, but what about six months down the road? Isn’t it better to pick a technology that leaves you room to grow, rather than one that pigeon-holes you into bad practices?

因此，也许你的项目舒服嵌套在光谱的“简单”结束了 ，但什么半年左右的道路？ 选择一种让您有成长空间而不是让您陷入不良做法的技术更好吗？

React的好处 (The Benefits of React)

“Premature optimization is the root of all evil” — Donald Knuth

“过早的优化是万恶之源” —唐纳德·克努斯(Donald Knuth)

This is another popular saying among programmers. After all, who needs hammers and nails when duct tape will do just fine!

这是程序员中另一种流行的说法。 毕竟，谁需要锤子和钉子，当胶带会很好！

But this makes the assumption that “premature optimization” is a long, arduous process with few benefits. And I don’t think this applies to React.

但这假设“过早优化”是一个漫长而艰巨的过程，几乎没有好处。 而且我认为这不适用于React。

While React may take some time getting used to, once you learn its basic concepts you’ll be just as productive as with classic front-end tools.

尽管React可能需要一些时间来适应，但是一旦您了解了它的基本概念，您将像使用经典前端工具一样高效。

Maybe more in fact, because React leverages the extremely powerful concept of components. Just like CSS encourages you to think in terms of reusable classes and styles, React pushes you towards a flexible, modular front-end architecture that has benefits for every use case, from the lowly static homepage to the interactive back-end dashboard.

也许实际上更多，因为React利用了极其强大的组件概念。 就像CSS鼓励您考虑可重用的类和样式一样，React会促使您朝着灵活的模块化前端体系结构发展，该体系结构对从低静态首页到交互式后端仪表板的每个用例都有好处。

JavaScript，无处不在JavaScript (JavaScript, JavaScript Everywhere)

We live in a JavaScript world. Or, as Chris puts it:

我们生活在一个JavaScript世界中。 或者，正如克里斯所说：

“You got Node.js on the server side. There are loads of projects that yank CSS out of the mix and handle styles through JavaScript. And with React, your HTML is in JavaScript too.

“您在服务器端获得了Node.js。 有大量的项目会通过CSS使CSS脱离混合和处理样式。 借助React，您HTML也是JavaScript。

“All JavaScript! All hail JavaScript!”

“所有JavaScript！ 都赞美JavaScript！”

Chris isn’t quite convinced, but I am. JavaScript in itself isn’t necessarily perfect, but having access to the entire modern npm ecosystem is amazing.

克里斯不太确信，但我是。 JavaScript本身不一定是完美的，但是可以访问整个现代npm生态系统真是太神奇了。

Installing a jQuery plugin used to involve finding its homepage, downloading it, copying it in your project directory, adding a <script> tag, and then hopefully remembering to check back every couple months for new versions. These days, installing the same plugin as a React package is just the matter of a single npm install command.

安装用于查找主页，下载，将其复制到项目目录中的jQuery插件，添加<scri pt>标签，然后希望记得每隔几个月检查一次新版本。 如今，安装与React软件包相同的插件只是ingle ingle npm i nstall命令的问题。

And with new libraries like styled-components, even CSS is now being dragged kicking and screaming into the future.

随着样式库组件等新库的出现，甚至CSS也被拖到了未来。

Believe me, once you get used to this world where everything is speaking the same language, it’s really hard to go back to the old way of doing things.

相信我，一旦您习惯了这个世界上一切都说相同语言的世界，那么就很难回到过去的做事方式了。

不会有人请用户！ (Won’t Somebody Please Think of the Users!)

I know what you’re thinking: so far I’ve tried to sell you on the benefits of React to developers, but I’ve carefully side-stepped any mention of the end user experience.

我知道您在想什么：到目前为止，我已经尝试将React的好处卖给您给开发人员，但是我小心翼翼地回避了任何提及最终用户体验的内容。

And that remains the key argument against modern libraries: slow, JavaScript-bloated sites that take ages just to load one of those “one weird trick” ads.

但这仍然是反对现代图书馆的关键论点：缓慢的，JavaScript膨胀的网站需要很长时间才能加载那些“一个奇怪的把戏”广告之一。

Except here’s a little secret: you can get all the benefits of React without any JavaScript at all!

除了一个小秘密： 您无需任何JavaScript就可以获得React的所有好处 ！

What I’m talking about here is rendering React on the server. In fact, tools like Gatsby (and soon, Next.js) even let you compile React components into static HTML files that you can host on, say, GitHub pages.

我在这里谈论的是在服务器上渲染React。 实际上，诸如Gatsby (以及不久之后的Next.js )之类的工具甚至可以让您将React组件编译为可以托管在GitHub页面上的静态HTML文件。

As an example, my own personal site is a Gatsby-generated React app that doesn’t load any JavaScript at all (beyond a Google Analytics snippet). I get all the benefits of using React in development (all-JavaScript, access to the npm ecosystem, styled-components, etc.) but end up with a 100% HTML-and-CSS end product.

举例来说， 我自己的个人网站是Gatsby生成的React应用，它根本不会加载任何JavaScript(除了Google Analytics(分析)代码段之外)。 我得到了在开发中使用React的所有好处(全JavaScript，访问npm生态系统，样式化组件等)，但最终获得了100％HTML和CSS最终产品。

结语 (Wrapping Up)

To recap, here are the four reasons why I think React is a valid choice for any project:

回顾一下，这是我认为React是任何项目的有效选择的四个原因：

• It’s really hard to guarantee you’ll never ever need interactive features like tabs, forms — even for the simplest of sites.

  很难保证即使在最简单的站点中，也永远不需要选项卡，表单等交互功能。

• React’s component-based approach has big benefits — even for static content-based sites.
  React的基于组件的方法具有很大的好处-即使对于基于静态内容的站点也是如此。
• Access to the modern JavaScript ecosystem is a huge benefit.
  访问现代JavaScript生态系统是一个巨大的好处。
• Modern server-rendering tools eliminate for your end user any downsides to using React.
  现代的服务器渲染工具为您的最终用户消除了使用React的任何弊端。

So what do you think, Chris? Have I made a convincing case? Or do doubts still linger in your mind?

克里斯，你觉得呢？ 我有说服力了吗？ 还是您仍然会怀疑？

And what about you, dear reader? Whether you think like Chris that every tool has its use, or whether you agree with me that the Time of the Hammer is at hand, let us know in the comments!

那亲爱的读者，您呢？ 无论您是像Chris一样认为每种工具都有其用途，还是您与我一致认为《锤子时刻》即将到来，请在评论中告知我们！

This article was originally published on CSS Tricks.

本文最初发表在CSS Tricks上 。

翻译自: https://www.freecodecamp.org/news/which-projects-need-react-all-of-them-e7ccb6629ba7/

项目delay 应对