大家好！现在，我将告诉您一个奇怪的故事。 有一次，我住在一个公寓里，其中一楼有一间带跑步机的健身室。 在我年轻的时候，我积极地参加体育运动，然后我设法了解跑步过程中发生的状态，被称为“第二风”：这是当你突然开始受到不懂疲劳的神灵的启发时。 呼吸，心pal和身体运动会产生一些特殊的共鸣，使您成为一辆正在行驶的汽车。 我认为，您不喜欢跑到这一步的感觉越明亮。 因此，我每天走过跑步机，并认为记住年轻人会很好。 好吧，我记得。 跑步机对此有所帮助，它使您可以微调速度并达到所需的节奏。 在大街上，我无法做到这一点：很难以均匀的速度在城市中奔跑，地形和障碍物相互干扰。 一段时间后，我搬到普通公寓（没有健身室），开始考虑购买自己的跑步机。
是的，当然，您可以购买最近的体育俱乐部的订阅，但是我和许多IT同事一样，是一种社交恐惧症。 如果不是，甚至是社会变态者。 运动对我来说是一个私密的过程。 好吧，利用任何空闲时间进行培训也很诱人：“极客的健康”以及所有这些……简而言之，我查看了在线商店的报价，阅读了评论，想知道您可以在这项业务上花费多少，如何用噪音来解决问题，以及在何处放置此较大的bandura ……然后我落入一根普通的跳绳的手中，我对自己说：好吧，他在这里是没有太多痔疮的有氧运动的好选择！ 您所需要的只是高高的天花板，而...没什么了：为了有节奏地，均匀地跳上跳绳，您需要能够做到。 我们回到关于跑步机的想法还是……等一下，为什么不尝试在地方跑步？ 哦，好吧，太简单又愚蠢了。 但是我尝试过。 你知道吗？ 太好了！ 感觉几乎与我在跑步机上所经历的感觉相同，只是一切都变得简单了很多：您紧紧握住健身手环，戴上香肠音乐的耳机，打开计时器，然后开始！ 是的，有细微差别，但请相信我，它们是微不足道的。 结果，我已经对这个话题感到厌烦了一段时间，以至于我想加入同样疯狂的人的教派。 您问我：您总体上在说什么，这些都与Web开发有什么关系？
这就是
考虑用于现代前端开发的流行技术堆栈：
打字稿+ LESS / SCSS / PostCSS + React + Redux / Mobx + Webpack实际上，现在这是一定的标准。 通过分析空缺来验证这一点很容易。 今年任何可能性最高的新项目，都将以类似的清单启动。 这是一组经过时间考验的好
跑步机 。 让我们一起浏览此列表，看看如果使用“就地运行”方法，还剩下什么。
打字稿
奇妙的事情。 任何曾经为网络编写过严肃内容的人都会理解这一点。 通常，在有关初学者使用TypeScript的文章中，举一些例子，他们谈论一些非常简单而平淡的事情，例如将带类型的参数传递给函数或保存JavaScript的类型转换的变迁。 但是，TS的功能比编译阶段的类型检查更强大，更深入，它可以在整个项目中带领开发人员“手牵手”，从而促使人们不再陷入困境。 但是TS有其缺点：如果没有Transpail，它就无法在浏览器中运行，其语法在我们眼中是“涟漪”。 当您使用前端时，您的工作流程通常涉及检查代码在浏览器中的运行方式，您需要不断访问本机运行时。 总体而言，重建项目以反映变更的时间损失可能是巨大的。 即使您拥有所需的一切，也会对其进行缓存和优化。 怎么办 我的选择：使用JS + JSDoc。 是的，TS Static Analyzer支持
JSDoc格式。 同时，您可以直接在浏览器中查看代码，并充分利用文明的好处。 描述类型和其他提示的块未与代码混合使用，并且具有明显的边界，对我个人而言，这有助于“对角地”阅读代码。 如果使用VS Code，则可以通过在代码的开头添加// // @ ts-check行来尝试这种方法。 如果您需要对旧版浏览器的支持，则当然仍需要从ES6 +进行编译，但仅适用于生产版本。 结果，您可以简化运行时的调试（这样就不会节省组装过程中没有错误和警告的情况），并节省了大量时间。
LESS / SCSS / PostCSS
在这个集合中，我最喜欢的是LESS和PostCSS。 我喜欢LESS，因为它的语法更“本机”，并且相对容易开发环境所必需的依赖项。 PostCSS通过SVG和Track前缀帮助创建了各种技巧。 如前一段所述，缺点是需要不断重新编译。 好吧，依赖本身。 但是，在我们的2018年中，我们拥有原生CSS变量这样的奇妙东西！ 这是一个非常强大的功能，没有预处理器可以与之相比：您可以在运行时直接重新定义变量！ 这打开了一个新的可能性的世界。 例如，您可以非常简单地“即时”更改整个应用程序及其各个模块的主题。 从字面上看，用户可以使用一些颜色选择器为应用程序粘贴外观，为此，您无需保留具有预编译样式的单独程序包，也无需为JS加上其他逻辑。 以及更多，更微妙和具体。 我选择原生的现代CSS。 但是如果您需要支持IE11，那么就很
难过 。
反应
React给我们带来了模块化分解的新概念，它很好地满足了客户端开发的需求，因为组件的结构重复了演示的结构，简化了感知并为开发人员带来了秩序。 我认为，这就是为什么他变得如此受欢迎，这就是他感谢他的原因。 但是，现在，React越来越多地获得了货运狂热的特性：人们开始将其拖入项目只是因为“每个人都这样做”。 这是很糟糕的，因为工程选择，尤其是在如此重要的问题上，应尽可能有意识。 为了提高认识，您需要了解React充满缺陷。 对我来说，首先，这是在本机DOM之上的抽象太厚了，并带来了大量需要处理的自身细节，而不是直接解决问题。 如果您的工作比平常的模具要简单一些，这尤其令人感到沮丧。 您可以谈论这个话题很长时间，还记得JSX，VDOM等，但是对于我们来说，主要的问题是：替代方法是什么？ 不，不是Vue。 而且不是，尤其是Angular。 对我来说，这些是Web组件：一组标准的
CustomElements +
ShadowDOM +
ES Modules +
HTML Templates 。 怎么了 因为这些是Web平台本身（而不是meta平台和JS附加组件）支持的标准。
您可以将代码分成整齐的块，并使用本机模块随意组织。 是的，所有现代浏览器都支持模块，并且在开发过程中无需重建。 是的，您可以将样式和模板分别存储在模块中。 是的，您可以专门为这些文件启用语法支持，并将它们作为本机HTML和CSS使用。 Web组件的生命周期将帮助您组织渲染和更新，而无需不必要的解析和更改DOM的结构。 ShadowDOM使您摆脱繁琐的BEM，而不必担心样式的封装。
ShadowDOM对CSS变量透明，并允许您从任何适当的嵌套级别向内传递参数。 这使您可以试验参数设计并执行许多其他技巧。 Web组件完全可以使用普通的DOM API，而又可以使用完整的html元素：所有标准方法都在您手中。 您可以使用自定义属性来传递参数和显示设置（尽管与React不同，您只能传递字符串和布尔值，但是对我来说这根本不是问题）。 您的代码将变得更加轻松快捷。 相信我，我已经能够比较。 有点伤心：对于大多数用户而言，一切都可以在本地运行，但是有些用户需要使用
polyphiles 。 如果您的统计信息和目标受众（主要是关于现代浏览器的信息）可以随意进入该主题，那是值得的。
Redux / Mobx
更复杂。 一方面，有很多文章列出了优点和缺点，并比较了存储状态的不同方法。 而要具体-您需要一个特定的案例。 原来，这个话题困扰了我很长时间：我遇到了处理复杂的结构化数据的非常复杂的任务。 好吧，总的来说：在实践中从未接近现实的数据很简单，可以通过清晰的通用层次结构方便地进行标准化。 通常，这是一些棘手的图形，要求您最初在系统中放置最大的灵活性。 在这件事上，我是自行车制造的忠实拥护者，但我不会不分青红皂白地向所有人推荐自己的方式。 我绝对可以建议的是，不要轻视现代计算机科学的基础知识，不要阅读有关图论，集合论，混沌论的流行科学。 而且，我并不是在谈论某种顽固的话题：最笼统的想法可能非常有用，并且可以以正确的方式“清醒头脑”。 在简单的情况下，您将可以编写带有二十一点和订阅的状态存储库，而这比研究流行的库的文档困难得多。
Webpack
当然，我们可以完全放弃组装系统。 但是，解决实时代码中的导入链并不是最快的事情。 因此，我们仍然需要生产版本的捆绑包。 好吧，再一次地进行缩小/混淆，再加上一个紧凑的爸爸dist ...这就是我们离开Webpack的原因。 但是我们只需要他几个配置最少的模块，就不需要开发人员的监视和重建。 就个人而言，我的构建配置看起来非常紧凑，不需要大量的依赖关系。 最近，我经常听到有关新的Parcel生成器的消息，它的简约概念非常吸引我，但是据我所知，它不适用于ES模块，在我看来，它是一个文件。 希望这会改变。
结果如何
我经常听到这样的观点，即如果您写“香草”，您将不可避免地遇到这样一个事实，即您的项目很快就会变成没有面条的稀饭。 我来打招呼：首先，如果需要的话，也可以用还原剂和还原剂来煮粥（我已经看够了）。 其次，如果您使用模块，JSDoc和良好的OOP做法，那么一切都会很好。 因此，我们得出以下结论：
JS + CSS + Web组件+ Webpack在五个“跑步机”中，我们只剩下一个，重量很轻。 这足以感觉到“背后的翅膀”。
PS我决不肯定我的方法会适合所有人。 我请您至少将此机会视为思考我们认为理所当然的机会。