HTML + CSS: 为何始终无法摆脱?back

发布于 12 天前  108 次阅读  共 1649 字


当前,构建交互式应用程序的主流技术是 Web 技术,其中包括 HTML、CSS 和 JavaScript。过去十年,Web 技术生态发生了巨大变化,出现了许多开发框架,如 React、Vue、Svelte,以及前端工程化工具,如 Webpack、esbuild、Vite 等。然而,无论如何,它们都离不开 HTML、CSS、JavaScript 这三剑客。 尽管 Web 技术生态成熟、稳定,但构建跨平台应用程序仍然是一个挑战。 这也是为什么许多平台特定的框架和跨平台框架仍然受欢迎的原因。其中,最著名的跨平台框架之一是 Flutter,它部分基于浏览器引擎技术,实现了“编写一次,全端运行”的目标。而且这些框架基本上不使用 HTML、CSS 这些 Web 技术。为什么呢? HTML+CSS 之苦已久 HTML 最初是为制作可链接文档而发明的,而不是为了构建应用程序。它更像是一种标记而不是编程语言。直到 HTML5、CSS3 和现代 JavaScript 的出现,人们才开始制作真正的 Web 应用程序。 然而,即使使用现代前端框架,如 React、Vue、Angular 等,我们仍然需要编写类似 HTML 的代码,并仔细调整 CSS 样式或使用 CSS 预处理器(如 SCSS、Sass)。 这种开发方式缓慢、枯燥、乏味。 太多的人力、时间被浪费在处理 UI 细节上,使用的技术与语言并非最初为 UI 而设计。开发者经常要调整样式、处理浏览器兼容性问题、应用奇怪的 CSS 技巧、避免性能陷阱等等。 我们可以质疑,坚持使用 HTML 和 CSS 的理由是什么?为何要使用过度发展的 NPM 生态系统中复杂的工具来创建应用程序,效率低下,开发者体验糟糕。 其他非 Web 框架 除了 Web 框架,还有一些特定平台的框架,如 Windows 的 MFC、macOS 的 Cocoa、以及 UNIX/Linux 的 GTK。另外,还有一些现代的移动端框架,专门为 iOS、Android 或其他移动操作系统服务。 在跨平台框架中,值得注意的是广泛采用的 Qt 框架,主要用于桌面软件开发,但近年来也在努力向移动端与 Web 端发展,尽管成效有限。 第三种是近年来流行的全新跨端方案,如 Flutter,它在移动端表现出色,也在 Web 端和桌面端有所作为。 尽管 Web 应用比例不断增加,桌面端应用逐渐式微,但由于 Web 应用在跨端上的问题,非 Web 框架仍然有一席之地,而且具有不可替代性。 Flutter 看起来像是开发应用程序的灵丹妙药: Flutter 是声明式且反应式的。 Flutter 实现了跨平台,可以制作所有桌面、移动和 Web 应用程序。 然而,一些开发者不喜欢 Flutter,因为它引入了 Dart 这种新的、陌生的语言,以及额外的虚拟机负担。 Flutter 的真正问题在于与现有生态系统的兼容性。人们更喜欢重用已建立的资源和维护成熟的应用程序。 Design to Code 不!不再编写 HTML 了! 尽管如此,我们不得不承认,HTML+CSS 是表示 UI 的一个很好的组合,因为:

HTML 负责内容的结构,CSS 负责内容的样式。 结构和样式是解耦的,这对工程来说是有好处的。 然而,在实践中,UI 的工程有时是没有意义且不必要的。假设我们已经有了设计师提供的高保真设计原型,编码人员需要做的是:

使用代码重新实现设计原型,这在 99% 的情况下是 HTML+CSS 的事情。 为刚刚重新实现的 UI 添加业务逻辑。 第一部分总是让人头疼的源头:涉及大量的细节、耗时、需要与设计师进行讨论反复沟通,沟通成本很高,如果设计更新,代码也需要更新,也许还需要另一场 “昂贵” 的讨论。 一些开发者想出了使用编译器技术或更具体地说是转换器技术来实现设计到代码的解决方案,将整个高保真设计转换为机器生成的 HTML+CSS 代码。这个就是所谓的 Design to Code。 然而,从开发者的角度来看,Design to Code 不是一个好的技术解决方案。 Design as Code 在 VGG 所倡导的 Design as Code 工作流程中,用户可以在某种程度上抛弃 HTML+CSS。 因为设计稿完全替代了 HTML+CSS 的角色,设计就是代码。