记得前端原来说的是要 结构与行为分离，但是昨天看了下vue+tsx,感觉现在行为和结构又混在一起了，有没有大佬能讲一下？

Question

记得前端原来说的是要 结构与行为分离，但是昨天看了下vue+tsx,感觉现在行为和结构又混在一起了，有没有大佬能讲一下？

Answer 1

时代变了。

以前页面简单，开发时也是先写结构，后写行为，两者分离，更好维护。
后来页面越来越复杂，于是各种工程化、组件化。
工程化下所写非所见，因此没必要再强调分离；而以组件化的视角看，大多数情况下，结构和行为是不可分离的。

看以前的实践得联系时代的背景，尤其是14年到18年的5年时间里前端发生了巨大的变化，很多以前的最佳实践都失去了原本的context

Answer 2

偏个题，以下是《React设计模式与最佳实践》的书摘，虽然讲的是react，但是与vue都是一个道理，希望对你有所帮助

---

过去的 20 年里，我们学到了十分重要的关注点分离原则，并习惯性地将其理解为从模板中
分离逻辑。我们的目标始终是将 JavaScript 和 HTML 写入不同文件。

各种各样的模板方案被创建出来，以帮助开发人员实现这个目标。

问题在于，这种形式的分离大多数情况下只是一种假象。真相是，无论 JavaScript 和 HTML
写在什么地方，它们都是紧密耦合的。

DSL（domain-specific lenguage）提供了一个功能子集，它们试图提供一门真正编程语言的功能，而又不用想语言那样完备。

样式也存在同样的问题：它们定义在不同的文件中，但模板引用了样式文件，而且 CSS 选
择器也遵循了文档标记结构，因此，几乎不可能在不影响其他文件的前提下修改某个文件。这就是耦合的定义。

这就是为何传统的关注点分离原则更像是技术分离，这种做法当然说不上不好，但没有解决任何真正问题。

React 尝试更进一步，将模板放到其所属位置，即与逻辑在一起。React 这么做的理由在于，
它建议你通过编写名为组件的小型代码块来组织应用。

框架不应该指导你如何分离关注点，因为每个应用都有自己的方式，只有开发人员才能决定
如何划分应用的界限。

组件式开发彻底改变了 Web 应用的开发方式，这也是关注点分离这一经典概念逐渐被更现
代化的架构所代替的原因。

React 所主张的范式并不新奇，也不是由 React 的开发人员所发明的，但是 React 为这个概念
的主流化做出了巨大贡献。最重要的是，不同专业水平的开发人员都能够轻松理解这个概念，它
也因此流行起来。

同时使用 JavaScript 来编写逻辑和模板不但有助于更好地分离关注点，也赋予我们更强的能
力和表达力，这正是构建复杂 UI 所必需的。

此外，开发 React 的工程师一直在社区中推广另一个概念：将样式的逻辑也放到组件中。这
个概念颇具争议，而且很难被接受。

React 的最终目标是将创建组件所用到的每项技术都封装起来，并根据它们的领域和功能进
行关注点分离。

Answer 3

放在如今，这个概念指代的东西发生了很大的变化，但其基本原则仍是关注点分离。

关注点分离其实放在任何层级都可以适用，重点是你的出发角度，如你所说的 html 和 js，从语言层面进行分离，但现在大多数的项目都采用了工程化，并以 js 为核心进行驱动，从而或者说必然会衍生出在 js 代码内部的关注点分离，比如一个很经典的，状态 (store) 和视图 (view) 的分离；再例如就算在 css 代码中，也可以进行一些相应的分离，比如 结构样式 和 视觉样式，再者动效 (动画) 样式等。

重要的是你理解这个原则的出发点，是为了更好的管理代码本身，它的应用是可以体现在非常多的方面的，千万不要硬扣概念本身的字眼。

Answer 4

可能我前端起的比较晚，没有经历过“结构和行为分离”的时代。怎么看结构和行为，决定了什么是分离什么是混在一起。
看了一些相关的文章，对于结构和行为的分离的朴素理解，差不多就是文档结构组织在html文件中，行为控制脚本组织在js文件中，表现样式表组织在css文件中。（很粗浅的了解和学习）
在这个基础上分离可以理解为前端项目总是包含html文件，js文件以及css文件，并且内容和逻辑上没有过度交叉。那么混在一起可能就像是html文档中有单独的script标签和style标签写着内嵌的代码和样式表，dom元素上还有onclick这样的直接事件绑定。（自我感觉分离和混在一起差不多是这个效果）
那么vue+tsx或者说SFC的项目到底是分离还是混沌呢。我觉得又可以从两个方面来看。
1.在开发过程中，如果不把jsx语法作为结构的直接表达，那么确实还挺混沌的，从一定程度上来说，vue还真是一个将逻辑代码映射成视图的库。反过来说，如果SFC中的template当作结构表达，只是穿插了一些逻辑控制，那么template部分，script部分以及style部分从文件角度来说有些混沌，但是在loader层面却也是一定程度上分离开了。
2.从开发结果上来说，打包或者说工程化的结果，其实还是html文件，js文件，css文件。尤其是在用到一些静态导出的时候，看起来和传统的前端项目没有什么差别。对于SPA应用来说，通过js来加载页面结构，在传统项目中，jquery也是可以拼接字符串来生成大片的页面结构。
确实是没有经历过那个理论背景，只是结合自己对一些概念和思想的理解，稍微说明一下我看待这个问题的视角。

Answer 5

前端从 JS 代码里加载另一个文件是非常不方便的。最好是安卓那样，结构放 XML 里面，然后 Java 加载它，但前端就是做不到啊。

另外分离不一定非得分两个文件。就比如 JS 代码定义了两个函数，它们就是分离的。没有问题。那我把结构写在一个字段里面，行为定义在另一个方法里，就不算分离了嘛？

Answer 6

我这段时间学习Vue3的理解是：现在要把单个业务的代码集中在一处，不要分散。（一个想法，不一定对）

Answer 7

补充一点，计算机时代的基本观念从来没有本质的变化，都是为了提高不同场景下的生产力而进行的更迭。

html/css/js 划分的技术栈，有历史原因。这种技术同样影响着思维，比如关注点分离。如果html模板技术没有价值，那么为什么Web场景下没有诞生Swing/GWT之类的技术？

Web讲究的是渐进式开发、低门槛上手、生态内在包容性，这是web的内核。所以html/css/js的关注点分离，实际上就是服务于此点。举个例子，开发一个不那么复杂的、不那么动态的组件，比如一个穿梭框，然后发现页面样式、结构有点不太对，比如想删除部分冗余的DOM结构。好吧，对照着页面效果调试结果很麻烦，甚至于会发现页面的结构，完全在代码里找不到对应的入口……这就是页面结构被脚本破坏的场景。想要改怎么办，去js代码里改吧！要是这是其他开发写的，设计模式好、命名规范、结构划分合理，那么还比较好懂。如果是个新手呢？如果是一堆浆糊代码呢？使用render遍历出一堆乱七八糟的DOM，命名还不规范，怎么搞？硬着头皮上吧……

简单场景下，对于团队的新手而言，灵活性低的模板语法、硬邦邦的关注点分离，要对团队开发更友好。而复杂、灵活、动态、高内聚的组件，可以交由经验更丰富的程序员处理，这个时候动态和灵活的价值能最大的体现。

简单场景下，完全没有必要使用js自由控制dom树的生成，更没必要一刀切地崇尚什么灵活，什么react那一套。那不是什么新时代的流行，更不是什么万金油。发明html和css的那群人，可是顶尖的程序员，这些门道他们自然门儿清。html和css的“静态”带来的优势，也是web无法被其他技术取代的重要原因之一。正因为容易简单，能吸引大部分人来释放创造力，如果上来就是一堆类包、库文件，一堆各种组件的语法，一堆render函数，我个人以为web就不会像今天这么五光十色和繁荣。

结论：区分应用场景去看待一门技术或方法，这是思考技术的起点。vue+tsx一类的语法，应对的场景是动态、复杂的组件。可以明确成本和风险。甚至有必要的话，还可以兼顾日后的技术延续性。