CSS 框架或 CSS 网格:我的项目应该使用什么?

已发表: 2022-03-10
快速总结↬你有没有考虑过 CSS Grid 是否真的可以取代对 CSS 框架或第三方组件库的需求? 在此过程中,Rachel Andrew 发现了人们使用第三方框架的一系列原因以及这样做的积极和消极方面。

在我最常被问到的问题中,有各种各样的问题,“我应该使用 CSS Grid 还是 Bootstrap?” 在这篇文章中,我将看看这个问题。 您会发现使用框架的原因是多种多样的,而不仅仅是围绕使用该框架中包含的网格系统。 我希望通过解开这些原因,我可以帮助您做出自己的决定,即最适合您正在开发的站点和应用程序以及与您合作的团队。

在本文中,当我谈论框架时,我描述的是第三方 CSS 框架,例如 Bootstrap 或 Foundation。 您可能会争辩说这些确实是组件库,但许多人(包括他们自己的文档)会将它们描述为一个框架,因此我们将在这里使用它。 重要的因素是这些是您在外部开发的东西,与您的具体问题无关。 使用第三方框架的替代方案是编写自己的 CSS——这可能涉及开发自己的内部框架,使用一堆通用文件作为起点,或者将每个项目创建为新事物。 所有这些事情都是根据您自己的特定需求而不是非常通用的需求来完成的。

为什么选择 CSS 框架?

使用 Grid 还是框架的问题是有缺陷的,因为 CSS Grid 不是 CSS 框架所做事情的直接替代品。 对该主题的任何探索都需要考虑我们的框架 CSS Grid 将取代什么。 我想首先找出人们选择使用 CSS 框架的原因。 所以我转向推特并发布了这条推文。

很多回应。 正如我所料,使用框架的理由远不止它包含的网格系统。

跳跃后更多! 继续往下看↓

框架为您的团队提供现成的文档

如果您正在与许多其他开发人员一起开发一个项目,那么您创建的任何内部系统都需要包含文档以帮助您的团队成员有效地使用它。 创建有用的文档本身就是一项耗时的、熟练的工作,而且大型框架做得很好。

Bootstrap 文档主页截图
引导文档。 (大预览)

框架文档一次又一次地出现,许多经验丰富的前端开发人员加入并解释这就是他们推荐和使用 CSS 框架的原因。 我有时会听到人们使用框架的意见,因为他们并不真正了解 CSS,但是,许多回复的人对我来说都是专业的 CSS 开发人员。 我敢肯定,他们有时会对框架做出的选择感到沮丧,但是,该选择的积极方面超过了这一点。

在线社区:轻松获得帮助

当您决定使用特定工具时,您还会获得一个用户社区来寻求帮助。 除非您有一个非常明确的 CSS 问题,并且可以生成一个简化的用例来演示它,否则就 CSS 寻求帮助可能会很困难。 如果您想询问如何构建某个组件,尤其如此。 使用框架可以为您的问题提供一个起点; 通常,您将询问如何修改或设置特定组件的样式,而不是从头开始。 这是一个更容易问的事情,也是一个更容易回答的事情。

网格系统

尽管我们有 CSS Grid,但许多人回答说他们决定使用框架的主要原因是网格系统。 当然,其中许多项目可能早在 CSS Grid 可用之前就已经开始了。 然而,即使在今天,对向后兼容性或团队对新布局方法的理解的担忧可能会导致人们决定使用框架而不是采用原生 CSS。

项目交付速度

一般来说,选择一个框架可以更快地交付您的项目,特别是如果该项目非常适合框架做事的方式并且不需要大量定制。

在为新想法开发 MVP 的情况下,框架可能是一个很好的选择。 您将有很多事情要花时间,并且仍在根据项目需求测试假设。 能够使用框架开发第一个版本可以帮助您更快地将产品呈现在用户面前,并节省大量时间来开发您决定不使用的东西。

另一个速度和一堆现成的组件非常有用的地方是为站点或应用程序开发后端管理系统时。 在您只需要创建几个管理屏幕的情况下,框架可以节省大量时间来设置表单字段和其他组件的样式! Bootstrap 和 Foundation 的仪表板主题甚至可以提供有用的起点。

Foundation 仪表板套件的屏幕截图
仪表板组件的集合可以更快地构建应用程序的管理员。 (大预览)

我不是设计师!

这就是我过去选择 CSS 框架的原因。 我不是设计师,如果我必须同时设计和构建某些东西,我会花很长时间尝试做出我完全没有资格做出的设计决策。 有资金为每个副项目聘请设计师会很不错,但是,我没有,因此框架可能意味着交付与不交付之间的区别。

处理 CSS 错误和浏览器兼容性问题

提到的比我想象的要少,可能是框架作者已经处理了浏览器问题,这是由于实际的错误或缺乏对某些功能的支持。 然而,这仍然是许多人做出决定的一个因素。

帮助响应式设计

这出现了几次; 人们之所以选择一个框架,是因为它具有响应性,或者我为他们做出了关于断点的决定。 我认为有趣的是,这特别是选择使用框架的一个因素。

为什么不使用框架?

选择框架的积极原因之一是人们在选择时遇到的一些问题。

覆盖框架代码的难度

许多人评论说,覆盖框架中使用的代码可能变得很困难,如果框架不需要大量覆盖,框架是一个不错的选择。 如果有大量的自定义设置,那么易用性的好处以及团队中了解如何使用框架的每个人都可能会失去。

所有网站最终看起来都一样

所有网站开始看起来都一样的责任已经直接归咎于众所周知的 CSS 框架。 我看过一些网站,我确信使用了某个框架,然后发现它们是自定义 CSS,因此在这些框架中做出的设计选择非常普遍。

覆盖已经提到的框架样式的困难是使用特定框架开发的网站看起来相似的很大一部分原因。 这不仅仅是一个创造性的问题,作为一些网站的用户,这些网站都选择了相同的框架,却觉得它们都是一样的,这可能会很奇怪。 在传达你的品牌,并让良好的用户体验成为其中的一部分时,在选择框架的通用选择时,你可能会失去一些东西。

继承整个世界的 CSS 问题

无论是前端还是后端,任何寻求成为主流的工具或框架都必须解决尽可能多的问题。 除非该工具与解决一个特定用例紧密耦合,否则它将包含许多非常通用的代码,以及解决您没有并且永远不会遇到的问题的代码。

您可能很幸运,只需要在最新的浏览器中查看您的完整体验,从而在 Internet Explorer 或旧版 Chrome 中获得更有限的体验。 使用具有大量内置支持(可追溯到 IE9)的框架会导致大量额外代码——尤其是考虑到最近 CSS 布局的改进。 它也可能会阻止您发挥创造力,因为框架中的所有内容都假定了这种支持要求。 使用 CSS 可能的事情可能会受到框架的限制。

例如,流行框架中的网格系统没有跨行的能力,因为在网格布局之前的布局系统中没有任何概念或行。 CSS 网格布局很容易做到这一点。 如果您被绑定到 Bootstrap Grid 并且您的设计师提出了一个包含跨行元素的设计,那么您将无法实现它——尽管您的目标浏览器可能支持 Grid。

性能问题

与上述相关的是使用相当通用的代码所固有的性能问题,而不是针对您拥有的确切用例进行优化的东西。 在尝试提高性能时,您会发现自己与框架的决定发生了冲突。

技术债务增加

虽然框架可能是让您的初创公司快速起步的好方法,并且在做出决定时您确定会替换它,但是否有计划实现这一目标?

学习框架而不是学习 CSS

在与会议和研讨会与会者交谈时,我发现许多人只使用过框架来编写 CSS。 鉴于当今 Web 平台的复杂性,我想这将是许多人的途径,通过这些工具之一进入 Web 开发并没有错。 但是,它可能会成为限制职业生涯的选择,尤其是当您基于技能的框架失宠时。

没有 CSS 知识的前端开发人员应该让公司担心。 如果您的团队实际上不了解如何在没有它的情况下使用 CSS,那么离开该框架将变得非常困难。 虽然这并不是不使用框架的真正理由,但在使用框架时要牢记这一点。 当离开的那一天到来时,您会希望团队准备好接受新事物,而不需要记住(或第一次学习)如何编写 CSS!

选择不考虑最终用户

Nicole Sullivan 在我提出问题的前几天问了几乎相同的问题,因为我正在考虑写这篇文章,尽管她正在考虑将前端框架作为一个整体而不仅仅是 CSS 框架。 Jeremy Keith 指出,与最终用户有关的答案恰好为零。 对我的问题的回答也是如此。

在我们快速建立网站的竞赛中,作为网站的设计者和开发者,我们希望为自己创造尽可能好的东西,我们是否忘记了我们这样做是为了谁? 框架开发人员做出的决定是否与您正在构建的站点用户的需求相匹配?

我们可以用“Vanilla” CSS 替换框架吗?

如果您正在考虑更换您的框架或开始一个没有框架的新项目,您可以考虑哪些事情来简化该过程?

了解您需要框架的哪些部分

如果您要使用自己的 CSS 替换框架的使用,一个好的起点是审核您对当前框架的使用。 弄清楚你正在使用什么以及为什么。 考虑如何在新设计中替换这些东西。

在考虑是选择框架还是编写自己的框架时,您可以遵循类似的过程。 您可以合理地期望这其中的哪些部分需要? 它在多大程度上符合您的要求? 您是否会导入大量代码,可能会要求访问者下载但从不使用?

创建文档化模式库或样式指南

我非常喜欢使用模式库,您可以在 Smashing Magazine 上阅读我关于我们使用 Fractal 的帖子。 模式库或样式指南可以创建文档以及所有组件。 我的所有项目都是从模式库中的 CSS 开始的。

作为编写文档的人,您仍然需要编写文档,但是,我知道通常最难的事情是知道从哪里开始以及如何构建文档。 模式库通过将文档与组件本身的 CSS 一起保存来帮助解决此问题。 这种方法还可以帮助防止文档过时,因为它们与所引用的组件紧密相关。

开发自己的 CSS 代码指南

整个团队的一致性非常有用,如果没有框架,可能没有任何东西可以规定这一点。 特别是对于较新的布局方法,通常有几种方法可以构建模式,如果每个人都选择不同的方法,那么可能会出现不一致。

更好的寻求帮助的地方

除了向 Stack Overflow 方向派人外,似乎很少有地方可以在 CSS 上寻求帮助。 特别是对于初学者来说似乎很少有地方可以接近。 如果我们要鼓励人们远离第三方工具,那么我们需要满足对来自这些工具周围社区的友好、有用的支持的需求。

在公司内部,更有经验的开发人员有可能成为新团队成员的 CSS 支持。 如果从框架转向您自己的解决方案,明智的做法是考虑可能需要哪些培训来帮助弥合差距,尤其是当人们过去需要帮助时习惯于使用第三方工具提供的帮助时.

非设计师的风格指南或起点

我纠结于诸如“我应该使用哪种字体?”、“标题与正文的关系应该有多大?”、“可以使用阴影吗?”之类的问题。 我可以轻松地编写 CSS — 如果我知道我要做什么! 我真正需要的是一些规则来制作一个不糟糕的设计,某种排版起点,或者一组基本指南将取代在很多情况下能够使用框架的默认值。

教育人们了解现代浏览器互操作性的现状

我发现,多年来一直沉浸在基于框架的开发中的人,通常对浏览器互操作性的看法已经过时了。 在 CSS 跨浏览器工作方面,我们的情况从未像现在这样好。 可能是某些浏览器不支持一种新的闪亮的 CSS,但总的来说,CSS(当支持时)不会充满奇怪的错误。 例如,在几乎所有情况下,如果您在一个浏览器中使用 CSS Grid,您的 CSS 将在另一个浏览器中以完全相同的方式工作。

如果试图向那些相信框架可以使他们免于浏览器错误的团队成员证明不使用框架的理由,那么这一点可能是一个有用的问题。 浏览器兼容性问题是真实存在的,还是基于过去的担忧?

我们会看到一种新的框架吗?

让我感兴趣的是我们的新布局方法是否有助于引入一种新的工具和框架。 我们是否会看到利用新布局方法的工具,允许更多的创造力,但仍然给团队和个人一些不可否认的优势,这些优势来自对我的推文的回应。

也许通过依赖新的布局方法,而不是内置的网格系统,新式框架可以轻得多,成为有用组件的集合。 然后它可能能够摆脱非常通用代码中固有的一些性能问题。

框架可以帮助的一个领域是帮助为不支持更新布局方法的浏览器创建可靠的后备,或者通过将真正可靠的可访问性嵌入到组件中。 这可能有助于为考虑互操作性和可访问性的工作方式提供指导,即使对于那些没有将这些事情放在首位的人也是如此。

我认为简单地将 Bootstrap Grid 切换为 CSS Grid Layout 并不能实现这一点。 相反,提出新框架的作者也许应该看看这里列出的一些原因,并尝试以新的方式解决它们,使用我们在 CSS 中的新功能来做到这一点。

应该使用框架吗?

您和您的团队需要自己回答这个问题。 而且,尽管人们可能试图让你相信,但没有普遍的正确或错误答案。 您的项目只有正确或错误。 我希望这篇文章和对我最初问题的许多回答可以在你思考这个问题时给你一些讨论的东西。

请记住,答案会随着时间而改变。 这可能是一个有用的思想实验,不仅要考虑您现在需要什么,首先要为网站进行开发,还要考虑网站的生命周期。 你认为这仍然会在五年内出现吗? 那么你的选择是积极的还是消极的呢?

记录您的决定,不要害怕重新审视它们,并确保您和您的团队在您决定使用的任何框架之外保持您的技能。 这样,您将处于一个很好的位置,可以在未来继续前进,并为项目的下一阶段做出最佳决策。

我希望在那条推文中开始的对话继续下去。 在评论中让我们知道您的故事——他们很可能会帮助其他人试图找出最适合他们的项目的东西。