在前端对年度结果 的讨论突然成为讨论的主题 。 我将补充自己的意见，并且很高兴听到其他人的意见。
在我看来，谈论现代网络上发生的事情是有意义的，无论是从外部还是从内部来看，这是完全不同的。 是的，“内部”有多个层次。 “它们再次使布局复杂化”的观点一方面是绝对正确的，另一方面又是错误的和堕落的，但“不阻止我们构建抽象概念”的观点也是无效的。
当有人抱怨现代网络变得过于复杂时，每次我想提醒这个人，这个现代网络他都相信他的钱可以通过网上银行和购买表格，社交网络中的个人信件以及即时通讯工具的网络版本进行，和云中的个人文件。 他很可能真的希望这些系统的开发过程复杂，困难，但可靠且不会失败。
图片来源
在现代的前端和他的朋友们的带领下，他们对事物的了解远不止从外部看起来。 这些是经典的网站和SPA，以及电子应用程序，cordova，NativeScript，React Native甚至Flutter上的移动应用程序。 这是一个复杂的基础架构，具有CDN，地理分散服务，JS上的聊天机器人，甚至是机器学习工具，用于优化组装甚至布局生成 。
在网络本身上，出现了非常复杂的解决方案，这些解决方案以前只能在桌面模式下工作。 我本人有几年前曾在浏览器中接触过成熟的基因组浏览器的开发-我从事提供性能和60FPS的工作，这是一个足够大但可以解决的问题。 即使在5年前，也没有人想到过基因组浏览器不能安装在功能强大的计算机上，并且该解决方案使医生和研究人员甚至可以从平板电脑或轻型笔记本电脑上进行基因组研究。
怎么了
目前，HTML + CSS + JS捆绑包在构建接口方面是最强大的工具之一-不仅是因为其功能强大，而且还基于其上构建的许多解决方案-CSS框架，可视组件库，大量服务和SAAS的接口。 就潜在受众和可访问性的开发时间效率而言，Web技术领先于移动和桌面解决方案。 现在，它已分为三个区域：
- 开发具有部分动态内容（画廊，弹出窗口等）的全静态和半静态站点
- 在服务器框架（Django，Rails）上开发“经典” Web应用程序
- Web客户端开发
他们每个人都有完全不同的特异性。
JS开发确实很痛苦，因此解决方案开始出现，解决了这一难题。
如果看一下它们，您会发现一些非常有趣的东西：首先，诸如jQuery和CoffeeScript之类的解决方案开始出现，从而减少了该语言的冗余性和冗长性。 但是它们很快消失了，取而代之的是工具，这些工具使尽可能高效地重用代码，静态检测错误并构建有效的抽象成为可能，“隐藏”了简单明了的接口背后的各个复杂性级别。
出现了GraphQL，它解决了描述，记录和维护REST的复杂性问题。 出现了TypeScript和Flow，从而解决了缺少键入的问题。 出现了新的语言实体，使您可以有效地使用异步操作，类和数据流。 WebAssembly出现了，它使您可以重用其他语言的代码并快速进行操作。
所有这些解决方案都针对同一件事：重用代码和建立“扁平”团队的潜力。 他们解决了这个问题，以便采用别人的代码并开始使用它。
这清楚地证明了Web正在朝着大型团队的方向发展，它已经成为“成人”解决方案的平台。
进一步发生的一系列事件变得更加明显：React Native，NativeScript，Dart + Flutter和其他用于在本机平台上重用代码的解决方案。 这是非常重要的一点：由于缺乏在网络上使用其他语言的能力，公司开始微调其流程以寻找“银色子弹”，这将使他们大大减少开发成本和为所有客户提供新功能的时间。 对于任何项目来说，快速发展都非常重要，高级专家开始团结起来，寻找机会在JS上有效地工作。
顺便说一下，出于同样的原因，模板引擎开始部分消失：使用另一种语义证明比使用熟悉的HTML和JS中的小扩展（Angular，Vue）或仅使用一种描述布局的语言（React，Flutter）无效。 无法扩展，需要向开发人员介绍新语言，平台濒临死亡，分散的风险，导致他们开始偏爱试图尽可能接近HTML / DOM平台的框架模板。
但是，除了有效地编写代码外，还存在用于同步命令的“系数”。 如果该语言允许您超快速地工作，但是同时在两个开发人员之间同步单个功能会带来可怕的痛苦，那么它很可能仍然是一个利基市场。 因此，许多语言功能和解决方案专门针对减少同步问题和不存在问题。 他们降低了这个“系数”，它表示有多少个初级人员可以同时控制中间人，以及由主要开发人员可以控制多少个中间人。 在此类功能的最新示例中，es6 import可以部分解决循环依赖问题，而prettier则允许您在git代码中获得预期的，非常合适的合并，无论开发人员如何编写它。 它应该不漂亮，应该很好地同步。
结果，在短短几年内，网络作为平台已被大公司和认真的团队接管，这就是为什么大多数人都经历过“ javascript疲劳”的原因。 顺便说一下，以Chromium为代表的Google在网络上几乎垄断的主要主张在于，他们将所需的东西推向了Web平台和JS的功能（尽管这通常与大多数公司的需求相吻合）。
结果，一方面，我们获得了一个非常令人愉悦的平台，可以在任何地方重用代码，其语法使您可以使用大型平面命令。 但是...
一切变得复杂，每个人都感到困惑
没有人知道该怎么办。 实际上，这是什么问题？ 在这三个不同的类别中。
- 开发具有部分动态内容的完全静态和接近静态的网站：这种类型的应用程序的特征是HTML作为入口点，最大的下载速度和可选的JS
- 在服务器框架（django，rails）上开发“经典” Web应用程序：这些解决方案目前的特点是以HTML为切入点进行加载，但其着眼于代码重用，DRY和后端集成，而不是最大的下载速度。 JS代码部分是由框架生成的（通知，表单，turbo链接等），部分则需要自己编写
- Web客户端应用程序开发。 此处发生了意外情况：HTML代替了入口点，同时成为了应用程序清单和呈现平台，而JS成为了“入口点”。
我的入口点是什么意思：这是一个特定实体，其负载等于向产品用户的最小交付量。 如果用户需要显示信息，那么我们需要HTML + CSS，如果运行应用程序，则需要从HTML运行的JS。
为了使所有人完全困惑，出现了第四类：
同构应用
在Web开发中，“同构”下的含义通常是指可以在服务器和客户端上都可以使用的东西。 在这种模式下，react，angular，vue.js上的应用程序都可以工作，并且有现成的框架-例如Next和Nuxt 。
两项任务都与它们有关：Web应用程序应尽快将其初始状态传递给用户，并充当应用程序。 换句话说，他们必须同时提供HTML和JS作为两个入口点，一个入口用于内容，一个用于应用程序。 这产生了两个相互矛盾的段落：一方面，传递的数据量必须最少，另一方面，需要代码重用。 对于JS，这可以通过webpack块，代码拆分和动态代码加载（留给JS使用的模板）来解决，但CSS仍然存在。 最重要的是-我们不想向用户传递一个额外的字节。 然后有人想到了这样的想法：此类应用程序确实有两个入口点。 它们可以作为两个自治实体进行处理。
由此诞生了CSS-in-JS概念，它专注于两个独立的过程：为静态内容生成CSS文件，以及在组件旁边保存样式。
一切都留给了JS。
现在，在JS中，您可以找到样式，布局和实际代码。
现在一切都在js中，这很好
值得再次离题-现在到杂货店。
对于开发中的任何产品来说，能够向另一个方向“移动”是很重要的。 它作用于任何级别：
因此，几乎所有具有在服务器上呈现的风险的Web项目，都必须重构组件，将其从一个模板引擎转移到另一个模板引擎，这种风险是试图避免风险的。
当只有一个平台，其中一些实体可以廉价地转换为其他实体时，开发速度非常快。
在对angular / react / vue的应用程序中，情况确实如此。 他们很难理解。 当然，它没有Angular 1那样复杂，但是无论如何-了解它们的路径很长，而且六个月的在线课程不足以理解它们。 但是，它们提供了一个机会，可以在几个小时内完成几周之前和几天内完成的工作，而过去则需要几个月的时间。
然而，相反的情况也是如此-许多人不需要它们，但因为它们是“时尚的”而被使用。
当Web和移动应用程序组的基础架构设计师和布局设计师交谈时，这对他们来说真是太难了。 现在，这些方向是如此不同，以至于除了JS之外，它们在知识上没有交集。
下次您要说“网络变得非常复杂和肿”时，请考虑设计和制作google收件箱邮件客户端（包括根据字母包含的智能实体），Web IDE（例如Cloud9或Internet银行）有多困难。 。
但是，如果编码人员来找您，并开始谈论他需要做出反应的事实，因为他需要严格的键入和修饰符来配置目标网页的布局，请不要屈服于说服力。