在2019年建立一个无依赖网站
经过几年的基本无视后，我最近决定是时候刷新我的个人站点了 。 先前的迭代结合了Gulp和Bower，并结合了Susy（网格系统的Sass库）（版本2，而不是最新的版本3）。 我上一次进行此操作的时间大约是2015年，可以说我的工具已经过时了。 这只是不会在2019年削减。
我不想花很多时间为我打算成为一个非常简单的单页网站配置一套新工具。 我不打算使用Javascript，尽管我不会排除这种可能性（作为渐进增强）。 我想尽快建立并发布我的网站，以便在人们想知道我在做什么的情况下向他们指出。 但我也希望能够相对轻松地进行维护–必要时添加额外的演讲，文章和个人简介。 对我来说很重要的一点是，在不远的将来重新访问该站点将不需要对一组复杂的工具进行全新的重新配置-我不想花一个小时来更新依赖关系，然后再进行任何操作实际工作。 我希望我的工具摆脱困境，以便我可以专注于自己喜欢的事情：HTML和CSS。
核心是建立网站所需HTML文件和CSS文件。 （当然，CSS文件是可选的！但是，没有一个网站，您想要建立的网站并不多。）但是，我上一次没有任何工具构建网站的时间大概是五六年前。 我已经非常依赖Sass了，并发现编写没有CSSCSS将非常令人沮丧。 但是，在过去的几年中，CSS取得了长足的发展。 现在，我们有了CSS变量（或自定义属性），使我们可以在整个CSS文件中存储和重用属性值。 我们还有CSS Grid Layout规范，这使构建布局变得异常简单–不再需要为网格系统导入类似Bootstrap的依赖项，并且您可以切掉很多CSS（尽管有一些后备功能，必须为较旧的浏览器编写）。
不仅如此，代码编辑器也突飞猛进。 使用VS Code，可以很容易地在文件或项目中搜索关键字，查找和替换值以及对代码进行整理。 大量的扩展允许自动完成，自动格式化甚至从编辑器中选择颜色等功能。
因此也许编写原始CSS毕竟不会那么麻烦。 我决定尝试以HTML，CSS和其他方式构建我的网站。
当然，我不得不放弃自动化工具的一些优势。 我无法缩小文件，延迟加载图像或注入关键CSS，所有这些都会带来性能优势。 但总的来说，我可以接受，因为该网站还是轻量级的。 我没有使用任何全角图像，并且正在使用的图像已被合理压缩，因此它们的文件大小很小。 实际上，使用Google的Lighthouse工具进行分析时，它的性能得分为100％-比我以前建造的任何产品都要好！
系统的方法
我的第一口电话是语义HTML。 我希望该网站尽可能地易于访问。 这也为设计提供了便利，它非常简单和简约，没有多余的混乱。 我感兴趣的一件事是网格系统。 许多站点默认使用12列布局，这当然具有其优势。 但是我一直喜欢使用不对称网格的想法，这种网格感觉很新鲜而且与众不同。 我在网站的每个部分都使用了相同的非对称网格，并为我工作过的文章，演讲活动和网站的链接块嵌套了两列或三列网格。
CSS
我真正想念Sass的一件事是能够将文件分成多个部分。 即使具有现代编辑器的所有优点，将所有CSS都写在一个文件中也不是最简单的体验。 在我HTML和CSS文件中，我都小心翼翼地使用间距和注释对相关样式进行了分组，以使查找相关块更加容易。 我使用BEM命名我CSS类，这对此有所帮助。
我发现，系统地思考很适合单一CSS文件的方法。 我没有使用CSS重置（例如Normalize），通常我几乎不会考虑它。 我依靠默认样式（例如，仅在默认设置看起来不合适时才更改字体大小），并配置了一些全局和基本级别的规则，然后仅在需要使用类似于Harry Roberts ITCSS方法的内容时才覆盖。 我仅在必要时添加类，并仔细命名它们以确保它们在一定程度上可重用。 我尽可能地利用了级联和继承，让CSS为我完成了艰苦的工作。 这与原子CSS方法（我在上一份工作中一直使用Tailwind在一年中的大部分时间中一直使用）形成了鲜明对比，该方法偏向于继承而不是继承。
对于一个非常大的站点，可能是我采用的系统方法不太实用，并且存在一些性能缺陷，但这在这里是理想的。
缺点
除了局部，我真的很想念Sass的嵌套。 我不主张过多地使用嵌套，但是当涉及到媒体查询， 功能查询和伪选择器时，毫无疑问，嵌套使编写CSS更加容易管理。 我也错过了能够在媒体查询中使用变量的功能，而CSS变量却无法做到这一点。 简而言之，在我的工作中有很多理由要继续使用Sass，而且我还不打算暂时放弃它。
建立网站的这种简化方法显然不会使自己适应动态内容。 一些人建议使用静态站点生成器。 我完全意识到SSG的好处（此博客使用了一个），但这是一个故意的决定，在这种情况下不使用它。 关键是要以尽可能少的工具来快速构建，并且我认为保持如此小的站点的最新状态并不困难。 整个站点的设计和构建花费了大约四个小时的时间–我认为配置SSG会花费大量时间。
就是说，我不会排除将来使用SSG的可能性，以后我可能会考虑添加动态内容。 无需手动更新即可获取博客文章和演讲活动，这将是很好的。
使用代码编辑器
我使用VS Code，一个Twitter用户推荐了一个扩展，该扩展允许您在编辑器中将Sass编译为CSS ，而无需构建管道。 这是一个启示，因为我之前从未真正将其视为代码编辑器可以做的事情。 它让我想起了Codekit，这是我几年前用来编译Sass的GUI工具，尽管在此时我不打算将Sass添加到我的个人站点，但肯定会在某些时候尝试一下。 VS Code的强大功能令人印象深刻。 它也可以对我的开发过程有所帮助：
片段
在VS Code中，您可以定义可重用的代码段，这些代码段将用作较大代码块的快捷方式。 如果我要处理多个页面，我想必须确保我的页眉和页脚HTML各处都相同，这会让我有些头疼。 我可以创建一个代码段，然后仅需几次按键就可以使它们填充任何新HTML页面。
尽管我在网站的第一个迭代中没有使用任何代码段，但我认为它们对于媒体查询也非常有用。 我可以为常见的断点设置一些代码片段，并节省很多时间来输入内容。 我真的很想将这些介绍给我的工作流程。
编辑器缩小
还提供了一些扩展程序，可以通过简单的快捷方式来缩小CSS，HTML和JS 。 最小化这些对性能可能会有所帮助，并且我可以想象，如果我CSS文件增加，这将非常有用。
结论
我觉得很多人会很快将其视为完全反工具，而不是完全拒绝。 在很多情况下，我们作为一个行业开发的复杂工具是很好且必要的。 我完全意识到我在这里采用的方法不太可能扩展到一个非常简单的网站之外。
构建过程有明显的好处，这也是我们作为开发人员如此依赖NPM，Webpack，Gulp，Babel等等的充分理由。 但是，尽管我不建议您按照与我的网站相同的方式来构建所有网站，但我认为我们经常感到assuming愧，因为我们的工具是某些方面的很好的解决方案，但它们自动地是所有方面的解决方案。 用一个著名的说法来形容：“当您唯一的工具是锤子时，一切看起来就像钉子”。 有些网站根本不需要我们习惯的那种复杂工具，如果没有它们，它们会更高效，更容易构建。
我有几个自由客户，需要重建他们的（小型）网站，我已经在考虑这种方法可能会足够好，而以前我不会考虑。 而且，我将确信我编写的代码是可维护的，并且如果需要，我可以轻松添加更多工具。
如果您有任何类似的想法（或者您强烈不同意！），并且对于在不增加依赖项的情况下加快开发过程的方式提出任何建议，我将很乐意听到。 当我在推特上发布关于网站重建的推文时，它成为了我最受欢迎的推文。
我只使用HTML，CSS和其他任何东西重建了我的个人网站，只是为了看看在2019年是否有可能，事实证明那完全是????♀️ https://t.co/2Hv5qQfw5s
-Michelle Barker（@ mbarker_84） 2019年3月17日
当使用可以想象的最基本技术构建网站时，这确实具有革命性意义。