发布时间：2018年8月17日 - 5分钟阅读
最近，我读到了一个人的推文，他试图在React上动脑筋（是的，还是有一大堆人在用其他东西，这完全没问题）。他的第一个论点是，回到把HTML和JS放在同一个文件里面的感觉很奇怪。我一直在那里，我想我们大多数人都是这样，所以，很自然地，我向他提出了我们喜欢的反驳论点：我们需要改变我们的思维方式，将组件视为任何应用程序的基本单位。而且，通过这样做，我们应该能够证明为什么与这个组件相关的所有东西都尽可能地接近是完全合理的。
我还抛出了一个经典。JSX其实不是HTML，而是Just JavaScript™。
虽然 "以组件为基本单位 "是一个完全合理的论点，但我记得我一开始并不相信，我花了一些时间才接受这个论点。而他也不服气，所以我发现自己试图想出其他的论点，不需要他使用这个东西几个月，才能承认那里可能有一些好处。我想证明的是，虽然基于CSS/HTML/JS的关注点分离是对网页有用的东西，但我们已经超越了这一点，我们需要一些能够实现更高层次抽象的东西。
这一切都归结于我们构建东西的方式。
我们仍然在构建网页，这是事实。但每天我们都在构建越来越多的应用程序。这些 "网络应用 "做了一大堆很酷很复杂的事情，结果，好的老式网页跟不上了。用户希望有更敏捷和类似桌面的体验。而我们（算是）做到了（我们正在努力，好吗！？）
我们中的很多人不再写普通的JS了。我们写TypeScript，SASS，LESS，"现代 "的JavaScript（我们不能发货，因为不是所有的浏览器都支持它）等等。Heck，现在甚至可以用完全不同的语言来写一个web应用程序（Elm，ReasonML和ReasonReact，Dart和AngularDart）。JS/CSS/HTML实际上已经成为编译目标。
我的意思是，你仍然可以写纯JS，在你的index.html里面扔一个脚本标签，然后启动那个服务器。它可以工作。这没什么不对。只是对于大项目来说，这不是一种舒适的开发体验。你可以这样想：你还可以写asm，它能用，而且很神奇。说到这里，你会用它来构建一个多平台的桌面音乐播放器，而不是，比方说，Java？
虽然我们还没有达到这个目标，但我相信，最终，JS将成为一个编译目标--与WebAssembly并列，我们将使用其他语言编写应用程序。
经典的基于JS/CSS/HTML的关注点分离并不适用于这些新工具，我甚至不是在谈论React vs Vue vs Angular，我说的是更深层次的东西：前端开发正在汇聚成一系列共同的概念和实践，这些概念和实践以不同的方式实现，但在概念上却有很多共同点。
几个月前，我有机会创建了Storybook for Angular的初始版本（如果你没有听说过Storybook，它基本上是一个工具，可以让你把你的UI组件渲染成一个个单独的片段，并在不需要打开你的应用程序，甚至不需要应用程序和服务器的情况下对它们进行工作，它真的很神奇），我发现，虽然使用了一套完全不同的工具和原则来实现，但基本的概念是正确的，我能够把它完成。现在已经有适用于React、Angular、Vue的Storybook版本，还有更多的版本正在开发中或处于早期alpha版本中。在这之前，我坚信概念是相似的，但现在我完全相信我们正在趋向共同点。这真是太神奇了!
那么，如果基于JS/CSS/HTML的关注点分离不能适用于我们所有的用例，那么什么可以呢？
一个(可笑的)简短(不准确和主观的)组件历史记录
以前，我曾经做过一些Visual Basic 6的开发（那是坏蛋，我知道，我知道），然后跳到C++、C#、Java等等。他们都有一些UI组件包/工具箱，你可以用它们来构建应用程序。所有这些语言都允许你使用这些小块组成界面。称它们为小部件、组件或其他东西，我并不关心。关键是我们几十年来一直用这种很好的方式来抽象这些东西。
我们在自己的平台上一直有组件：输入、按钮，甚至是臭名昭著的<marquee>。这些都是UI组件的例子，它们抽象掉了行为的复杂性，并暴露出一个我们可以用来操作它们的声明性接口。而且它们对于网页来说是有效的。但当我们开始构建Web应用时，它们就落空了。
网络平台还不够成熟，无法支持完全成熟的应用，所以我们对JS进行了黑客攻击、改造和弯曲，以使其发挥作用。我们犯了错误。我们弄得一团糟。我们需要清理我们的烂摊子，所以我们开始讨论 "分离 "我们的关注点。这个时期我喜欢称之为黑暗时代。
一路走来，我们发现我们做错了。我们尝试着去修复它。Frameworks和Libraries来了，我们把它们当作我们的救星。我们为它们而战（有些人现在仍然如此）。十字军东征之后，很多受伤的开发者回到家乡，用他们喜欢的框架来构建应用程序。但在与其他开发者战斗的过程中，他们向他们学习。他们发现并不是所有的敌人都是坏的。有些东西是可以用来改进他们的框架/库的。
文艺复兴时期
这种文化和框架的冲突带来了好的东西。我们开始分享。我们开始从一个框架到另一个框架交换想法。我们甚至尝试用标准化的方式在我们心爱的平台上创建我们自己的组件（坚持住，标准很难！）。虽然不完美，但我们的框架和库蓬勃发展，我们的社区也获得了成功。我们开始搭建桥梁，而不是拆掉它们。
我们正在接近工业时代，即革命，但我们还没有达到这个程度。目前我相信，将我们的关注点分开，采取基于组件的方法是最好的方式。这是一种抽象的形式，即使是在我们拥有的新工具（Reason和Dart，只是举几个例子）的情况下，这种形式仍然有效。更不用说外面的大多数框架和库都使用了某种基于组件的抽象机制，而且正在努力将网络组件标准化，作为平台的一部分。
所以，下一次当你看到那个狰狞的单文件组件时，也许可以给它一个机会，它可能并不像看起来那么糟糕。
声明：我不是英语母语者，所以请随时指出语法和/或句法错误。每一个尊重的评论都会被深深感激。
通过www.DeepL.com/Translator （免费版）翻译
