javascript 框架_我们仍然需要JavaScript框架吗？-CSDN博客

javascript 框架

by Luke Joliat

卢克·乔里亚特(Luke Joliat)

我们仍然需要JavaScript框架吗？ (Do we still need JavaScript frameworks?)

As a web developer, I try to assess my toolbox regularly and determine if I can do without this or that tool. Recently, I have been investigating just how easy it is to develop a complex front end application without a front end framework.

作为一名Web开发人员，我尝试定期评估我的工具箱，并确定是否可以不使用该工具。最近，我一直在研究开发没有前端框架的复杂前端应用程序有多么容易。

什么是JavaScript框架？ (What is a JavaScript framework?)

Put simply, a JavaScript framework is a tool that you can leverage to develop advanced web applications, especially SPAs.

简而言之，JavaScript框架是一种可以用来开发高级Web应用程序(尤其是SPA)的工具。

Back in the day, web developers would implement front end logic by relying heavily on vanilla JS and jQuery. But, as front end applications became more and more complex, the tools rose to meet that complexity.

过去，Web开发人员将通过严重依赖香草JS和jQuery来实现前端逻辑。但是，随着前端应用程序变得越来越复杂，工具也应运而生，以应对这种复杂性。

The frameworks that are popular today have a few core commonalities. Most front end frameworks/libraries, from Vue to React, provide some combination of the following:

当今流行的框架具有一些核心共性。从Vue到React的大多数前端框架/库都提供以下各项的组合：

Synchronization of state and view
状态和视图的同步
Routing
路由
A Template System
模板系统
Reusable components
可重复使用的组件

仍然需要框架吗？ (Are Frameworks still necessary?)

It depends on how you stress the word necessary. Many would argue that front end frameworks are not and never have been necessary. They’re very useful tools, though.

这取决于您如何强调必要的单词。许多人会认为前端框架不是必需的，而且从来没有必要。不过，它们是非常有用的工具。

So the question is: are frameworks today’s jQuery? Will the problems they solve be addressed by changes like those to the DOM API?

所以问题是：今天的jQuery是框架吗？它们解决的问题是否可以通过DOM API的更改来解决？

It’s hard to say, but advances in native JS, the web component spec, and easily configurable build tools, have made developing a SPA without a framework as easy as it has ever been.

很难说，但是本机JS的进步，Web组件规范以及易于配置的构建工具，使开发无需框架的SPA变得前所未有的容易。

To examine this further, I developed a single page application using only vanilla JavaScript, native Web Components, and Parcel. There were a handful of pitfalls and difficulties along the way that highlighted the strengths of JS frameworks.

为了进一步研究，我仅使用原始JavaScript，本机Web组件和Parcel开发了一个单页应用程序。在强调JS框架优势的过程中，存在一些陷阱和困难。

At the same time, once I passed the initial hurdles, I was surprised by how simple it was to create a single page application with just vanilla JS.

同时，一旦我克服了最初的障碍，仅使用原始JS创建一个单页应用程序就多么简单，这让我感到惊讶。

总览 (Overview)

The application is simple. It is a recipes application with basic CRUD capabilities. The user can create, edit, delete, favorite, and filter a list of recipes.

该应用程序很简单。这是具有基本CRUD功能的食谱应用程序。用户可以创建，编辑，删除，收藏和过滤配方列表。

组件 (Components)

Creating a web component is also straightforward. You create a class that extends HTMLElement (or HTMLParagraphElement and so on), and then use that class to define a custom element.

创建Web组件也很简单。您创建一个扩展HTMLElement (或HTMLParagraphElement等)的类，然后使用该类定义自定义元素。

You can also make use of lifecycle hooks such as connectedCallback, disconnectedCallback, attributeChangedCallback.

您还可以使用生命周期挂钩，例如connectedCallback，disconnectedCallback，attributeChangedCallback。

路由 (Routing)

The routing for the recipes application is also quite simple. Given a navigation event, I set the application’s content to the corresponding web component.

食谱应用程序的路由也非常简单。给定一个导航事件，我将应用程序的内容设置为相应的Web组件。

Initially, I was using an npm package called Vanilla JS Router. With the browser history API, it isn’t all that complex to implement your own in less than 100 lines of code! Note: I am not implementing really complex logic such as route guards.

最初，我使用的是名为Vanilla JS Router的npm软件包。使用浏览器历史记录API ，用不到100行的代码实现自己的代码并不那么复杂！注意：我没有实现真正复杂的逻辑，例如路由防护。

That is a quick summary. I want to keep this article to a reasonable length. I may write a follow-up post with a more thorough explanation of the application. I implemented some fun features like infinite scrolling, a custom drag and drop uploader, and more!

这是一个简短的摘要。我想使本文保持适当的长度。我可能会写一篇后续文章，对应用程序进行更详尽的说明。我实现了一些有趣的功能，例如无限滚动，自定义拖放上传器等等！

回顾性 (Retrospective)

After creating the application, I took some time to think about the pros and cons of the whole process from start to finish. I’ll start with the bad news.

创建应用程序后，我花了一些时间从头到尾思考整个过程的利弊。我将从坏消息开始。

缺点 (Cons)

规格仍在不断变化 (The spec is still in flux)

The web component spec is both old and new. It has been around for a lot longer than I had originally thought. Web Components were introduced by Alex Russell at Fronteers Conference 2011 for the first time. However, the push behind web components has really grown in the past year or two. As such, there is still a lot of turmoil in the spec. For instance, HTML imports have been abandoned, though most of the documentation/resources still reference them.

Web组件规范既旧又新。它的存在比我原先想的要长得多。 Web组件是Alex Russell在Fronteers Conference 2011上首次引入的。 但是，过去一两年中，Web组件的推动力确实有所增长。因此，规范中仍然存在很多动荡。例如，HTML导入已被放弃，尽管大多数文档/资源仍引用它们。

测试中 (Testing)

There aren’t a lot of dedicated resources for testing native web components out there. There are some promising tools such as skatejs ssr and the web component tester from Polymer. But these tools are really meant for use with their respective libraries. This presents some difficulties for use with native web components.

那里没有大量专用资源来测试本机Web组件。有一些有前途的工具，例如Skatejs ssr和Polymer的Web组件测试器。但是这些工具确实是要与它们各自的库一起使用。这给使用本机Web组件带来了一些困难。

变更检测 (Change Detection)

Having an underlying system that automatically keeps the view in sync with the data model is incredible. It is what drew many to Angular and other frameworks in the first place.

拥有一个自动使视图与数据模型保持同步的基础系统是令人难以置信的。首先，它吸引了许多人使用Angular和其他框架。

Keeping state in sync with the view is not so difficult at a small scale. But it can get out of control very quickly, and you find yourself adding tons of event listeners and query selectors.

在小范围内保持状态与视图同步并非难事。但是它很快就会失控，您会发现自己添加了大量的事件侦听器和查询选择器。

影子DOM (The Shadow DOM)

I am really torn about the shadow DOM. On one hand, I love the idea of encapsulation. It is a sensible design pattern, makes your style cascade more manageable, simplifies your concerns, and so on. However, it also presents problems when you do want certain things to penetrate that encapsulation (such as a shared style sheet), and there are ongoing debates about the best way of doing this.

我真的对影子DOM感到震惊。一方面，我喜欢封装的想法。这是一种明智的设计模式，可以使您的样式层叠更加易于管理，简化您的顾虑等。但是，当您确实希望某些东西穿透该封装时(例如，共享的样式表)，这也会带来问题，并且关于如何做到这一点的最佳方法一直存在争议。

生成DOM结构 (Generating DOM structures)

Part of the magnificence of frameworks/libraries like Angular and React is that they are masters of their DOMain. That is, they are excellent at efficiently rendering and re-rendering structures in the DOM. From the Angular University blog:

像Angular和React这样的框架/库的宏伟之处之一就是它们是DOMain的主人。也就是说，它们在有效地渲染和重新渲染DOM中的结构方面非常出色。来自Angular University博客：

Angular is not generating HTML and then passing it to the browser to have it parsed, instead Angular is generating DOM data structures directly!

Angular不会生成HTML，然后将其传递给浏览器进行解析，而是Angular直接生成DOM数据结构！

Angular for example, unlike jQuery, renders DOM data structures directly. That is, instead of passing HTML to the browser to be parsed, and then rendered into DOM data structures. This is more performant as it eliminates that parsing step. The Virtual DOM is also quite useful, as they prevent you from re-rendering everything each time you need to update your view.

例如，与jQuery不同，Angular直接呈现DOM数据结构。也就是说，与其将HTML传递给浏览器进行解析，然后呈现为DOM数据结构，不如将其传递给浏览器。由于它消除了该解析步骤，因此性能更高。虚拟DOM也非常有用，因为它们可以防止您每次需要更新视图时都重新呈现所有内容。

优点 (Pros)

On the other hand, there are some undeniable benefits to developing applications this way:

另一方面，以这种方式开发应用程序有一些不可否认的好处：

捆束尺寸 (Bundle Size)

The final product can be (emphasis on can) so much smaller and more compact than anything developed with a modern framework. For example, the final build of my fully featured recipes app was less than half the size of a fresh Angular build.

最终产品可以(强调罐头 )比用现代框架开发的任何产品都小得多且紧凑。例如，我功能全面的食谱应用程序的最终版本不到新Angular版本的一半。

Note: These are the updated, optimized bundle sizes.

注意：这些是更新的，优化的捆绑包大小。

理解 (Understanding)

If you’ve only really developed with a framework and its CLI, it can be a great exercise to make a web application without extra tools. As someone who wants to achieve a certain level of mastery (to the extent that it’s possible) of web development, it has been essential for me to get more hands-on experience with build tools, browser APIs, design patterns, etc.

如果您仅使用框架及其CLI进行真正的开发，那么在没有额外工具的情况下制作Web应用程序可能是一个很好的练习。作为一个想要掌握一定程度的Web开发(在可能的范围内)的人，对于我来说，获得构建工具，浏览器API，设计模式等方面的更多实践经验至关重要。

性能 (Performance)

What these front end frameworks and libraries are doing behind the scenes is amazing. However, you can pay a performance price if you decide to use any of them; there is no such thing as a free lunch. There are many potential performance drags at scale: whether it’s wasted re-renders, redundant listeners, deep object comparison, or unnecessary and large DOM manipulations. You can cut out a lot of complexity here by implementing things from scratch.

这些前端框架和库在后台执行的操作令人惊讶。但是，如果您决定使用其中任何一个，则可以支付性能价格；没有免费的午餐。可能存在许多潜在的性能拖累：无论是浪费重渲染，多余的侦听器，深层对象比较还是不必要的大型DOM操作。通过从头实现事情，您可以在这里减少很多复杂性。

The Angular and React teams seem aware of these pitfalls, and have provided things like shouldUpdate method overrides and onPush ChangeDetection as a means of further optimizing performance.

Angular和React团队似乎意识到了这些陷阱，并提供了诸如shouldUpdate方法覆盖和onPush ChangeDetection之类的东西，作为进一步优化性能的一种手段。

简单性和代码所有权 (Simplicity and code ownership)

You take a risk whenever you bring in 3rd party code. This risk is reduced with tried and tested libraries/frameworks, but never truly eliminated. If you can get away with writing code yourself or with your team, you can reduce that risk and maintain a codebase that you know in and out.

每当您输入第三方代码时，您都将承担风险。通过久经考验的库/框架可以降低这种风险，但从未真正消除过。如果您可以自己或与团队一起编写代码，那么就可以减少这种风险，并维护内外都知道的代码库。

笔记和有趣的花絮 (Notes and interesting tidbits)

I had a blast working with Parcel. It felt a bit more limited than Webpack at times when trying to work around certain edge cases, but I found the, ‘zero config’ tag line to hold true, for the most part.

我和包裹一起工作很开心。在尝试解决某些极端情况时，有时感觉比Webpack更为局限，但我发现“零配置”标记行在大多数情况下都适用。

It is also clear to me that many label React a ‘library’ and Vue a ‘progressive’ framework. While I understand the reasons for this, I think React, Vue and Angular solve many of the same problems. Thus, I am considering them all together under the term ‘frameworks.’

对我来说，很明显，许多公司将React称为“库”，将Vue称为“渐进式”框架。虽然我理解了其中的原因，但我认为React，Vue和Angular解决了许多相同的问题。因此，我在“框架”一词下一起考虑它们。

Why not use Stencil or Polymer? I wanted to avoid the use of packages, libraries, and frameworks as much as possible. I wanted to see how far web standards had risen to meet modern development (aside from build tools).

为什么不使用模板或聚合物？我想尽可能避免使用包，库和框架。我想看看Web标准已经上升到可以满足现代发展的水平(除了构建工具之外)。

There are I’m sure many other ways of developing a SPA or front end application in general without a major framework or library, I tried one way here, and I’d love to hear about others!

我敢肯定，在没有主要框架或库的情况下，通常可以开发出许多其他方法来开发SPA或前端应用程序，我在这里尝试了一种方法，并且我想听听其他方法！

摘要 (Summary)

A great heuristic for the decision to use or not use a framework is what I call, “the tipping point.” There comes a point as your application grows, where you end up creating your own framework in order to reuse functionality and structure. For example, you have a bunch of forms and you want to create reusable logic for reactive validation.

决定使用还是不使用框架的一种启发式方法是我所说的“临界点”。随着应用程序的增长，有一个关键点，即最终创建自己的框架以重用功能和结构。例如，您有一堆表格，并且想要创建可重复使用的逻辑以进行React性验证。

If you end up at this point, you have to decide whether or not it is worth investing the time in creating systems to accomplish what you can quickly accomplish with a framework or library. There will be different tipping points depending on what your time constraints or budget constraints are, but frameworks are still very relevant given the right scenarios.

如果到此为止，您必须决定是否值得花时间在创建系统上，以完成可以通过框架或库快速完成的工作。根据您的时间限制或预算限制，会有不同的临界点，但是在正确的情况下，框架仍然非常相关。

That said, much of what frameworks do will probably become easier to do with smaller libraries and/or native code as time goes on. Take my application as an example. At the same time, if the large frameworks and libraries remain versatile they may morph, adapt, and stick around. If not, they may end up like jQuery — a tool of the past for the most part.

也就是说，随着时间的流逝，使用较小的库和/或本机代码，许多框架所做的事情可能会变得更加容易。以我的应用程序为例。同时，如果大型框架和库仍然具有通用性，它们可能会变形，适应和粘连。如果不是这样，它们最终可能会像jQuery(大多数情况下都是过去的工具)一样。

结论 (Conclusion)

In conclusion, there are promising ways of developing complex front end applications without frameworks. However, the spec for things like web components is still evolving and there are kinks to be worked out. The frameworks still do a lot of amazing things and can make development much smoother.

总之，有一些有前途的方法可以开发没有框架的复杂前端应用程序。但是，诸如Web组件之类的规范仍在不断发展，还有一些缺陷需要解决。框架仍然可以做很多令人惊奇的事情，并且可以使开发更加顺畅。

At this time, as far as I can tell, the pros of using a framework often outweigh the cons. However, if frameworks do not start solving new problems and continuing to evolve, they will eventually fade away.

据我所知，此时，使用框架的优点通常胜过缺点。但是，如果框架没有开始解决新问题并继续发展，它们最终将消失。