Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2024 前端预测 #53

Open
campcc opened this issue Jan 11, 2024 · 0 comments
Open

2024 前端预测 #53

campcc opened this issue Jan 11, 2024 · 0 comments

Comments

@campcc
Copy link
Owner

campcc commented Jan 11, 2024

原文链接:Frontend predictions for 2024
作者:Whatever, Jamie

对于前端来说,这是不平凡的一年。我们见证了对服务器端渲染(SSR)市场的争夺和创新的热潮;人工智能的不断渗透;网络渲染器和 JS 引擎的迅猛发展;一大批有志之士试图将知名品牌从宝座上拉下;以及其他各个领域的动向。

在预测新一年的传统占卜之前,让我们回顾一下今年到目前为止的大杂烩。

2023 年回顾

SSR

SSR 并不是什么新鲜事物。PHP 已经提供了整整 28 年,如果它足以支持 Neopets(还有,虽然有点勉强,Facebook),那么它可以说足以应对任何事情了。

但是 Vercel 一直在大力推动它。它已经成为一些前端开发领域最有影响力人物的公会之家,很难忽视他们的叙述(例如,当他们谈论 Server Actions 时,Twitter 上一周都充斥着相关的 Meme),你应该使用 SSR,而且更重要的是通过他们的服务来实现。

现在 SSR 领域重新得到了关注,每个人都想分一杯羹。长期在这个领域工作的 Ruby on Rails 群体一直在尝试用他们的无构建工作流(与 Vite 的无打包工作流相呼应,尽管两者都有一些强有力的反对意见)来吸引用户。HTMX 也是同样的主张者,再次通过应用 Memes 来宣传 —— 一个人真正需要的只是一个 HTTP 服务器来传输 HTML 文件。尽管 React 和 Svelte 现在对 Vercel 的成功有了既得利益(核心团队成员在那里工作),但 Vue 是个例外,他的 Nuxt 仍然坚持社区驱动。

即使是移动领域也受到了影响。正如我在今年早些时候的文章《期待 React Native 中的新事物》中提到的,Szymon Rybczak 一直在开发 React Native 的 Async 组件和 React 服务器组件,而 Expo 一直在推动 Expo 路由。移动端是否需要服务器端渲染(SSR)仍有待商榷,但你总能指望 Evan Bacon 和 Nate Birdman 来为每一方辩论。

是否会有其他不使用 Node.js 的后端的公司采用这种做法,还有待观察。

AI

在这个领域里,人们急于寻找各种方法,任何方法,将 AI 产品化为前端工作流的一部分,因此出现了很多盲目的尝试。与此同时,一个挥之不去的问题始终悬而未决:“机器会取代我们的工作吗?”

今年,我敢肯定地说,“人工智能的不可阻挡进程”在你失去前端工作的原因列表中排名相对较低。但这个行业的市场潜力已经非常真实。

ChatGPT 和 GitHub Copilot 现在已成为橡皮鸭编程和代码生成的日常伴侣工具,而微软今年对它们背后的公司 OpenAI 进一步投资了 100 亿美元。虽然只有巨头们才有希望与这些工具竞争(谷歌有 BardGemini;Meta 有 LLaMA,尽管是与微软合作构建的;亚马逊有 Q;苹果肯定也在研究一些东西,像 ml-ferret 和 ml-explore 这样的工具列表开始在他们的 GitHub 上出现),但在它们之上构建的仍然是一个相当大的行业。

我们已经看到 tldraw 将草图转换成代码,Vercel 的 v0 将描述转换成 UI 组件。Figma 也能对设计做同样的事情。这开始让人觉得,仅仅使用人类的能力来开发东西似乎有点傻。然而,也有人担心最终结果可能比真正的东西要马虎,例如在可访问性方面。更不用说供应商面临的劫持问题了。

浏览器引擎、JS 引擎和运行时环境

在浏览器引擎方面,新的 Ladybird 浏览器吸引了 31 万美元的资金,这导致了全职雇佣 Andrew KasterAlexander Kalenik 来工作;Servo 网页渲染器享受了一年的 Igalia 工程服务;我们甚至还有一个全新的独立浏览器引擎 Shadow,竟然是用 JS 编写的!看来,创建一个新的网络浏览器毕竟并非不可能。

关于 JS 引擎,Hermes 确实在大展身手 —— 我们看到了 Static Hermes 模糊了原生代码和 JS 之间的界限,随着即将到来的稳定 ABI 和 ES6 支持,它变得更加灵活;然而,一些硬件平台挑战仍然存在,比如支持 Intl,以及 Date 运行非常缓慢。但即便它克服了这些问题,它也需要保持警惕,因为 QuickJS 项目已经复苏,而且实际上在调用 C 函数方面比调用 JS 函数还要快!与此同时,Shadow 也开始了自己的 JS 引擎项目 Porffor,这将值得关注。

在运行时方面,我们不得不提到给 Node.js 带来压力的新兴挑战者 Bun,它已经引起了极大的关注。虽然 Bun 很快就被商业技术栈采纳,但它为自己设定了很高的标准,并不得不放慢功能开发的步伐,以解决日益增多的问题。同时,它还必须迅速应对人们对 Windows 支持不足的批评

跨平台框架

今年 React Native 的工作岗位是 Flutter 的 6 倍,加上 Hixie 和 Tim Sneath 离开了 Google,后者甚至开始推广 SwiftUI,Flutter 开发者面临前所未有的生存危机,感觉就像是被 Google 抛弃的阴影逼近。

与此同时,React Native 没有显示出放缓的迹象,亚马逊宣布它已成为他们几个旗舰应用的技术选择。DX 随着 Software Mansion 展示了他们的新 IDE,以及 Meta 从 Flipper 迁移到 Chrome Devtools,已经突飞猛进地改善。Expo 也做了太多值得一提的事情,尤其是通过 Expo Modules 革命性地改变了对原生 API 的访问,并且继续他们关于代码共享和 SSR 的故事,这一点通过 Expo Router 实现(如前所述)。而 Meta 和 Microsoft 向 Web 一致性的进军,从 DOM 遍历 到 事件循环,跟进这一进程非常令人兴奋。

其他框架也在采取行动,Tauri 正在与 Servo 合作,而 Dioxus 承诺将启用 Rust 创建 GUI 应用程序,并提供类似 React 的 DX。它建立在 Taffy 布局引擎之上,这是 Yoga 的一个非常有前途的继任者,可能很快就会提供 C 绑定,使其能够在更多的上下文中使用。我还一直听到围绕 Kotlin Multiplatform 的持续热议,尽管没有什么具体的突出之处。

我也有很多关于 NativeScript 的看法(作为 TSC 的一员),但我可能会在接下来的一周里单独写一篇文章,发表在我的 NativeScript is Dead 通讯或者 NativeScript 博客 上,所以请耐心等待!

UI 框架

所有大玩家仍然逍遥法外,尽管有些政变尝试过。今年的热议似乎始于 Solid 从 Chrome 团队 那里获得了 30,000 美元的资金,并使 Signals 普及。

Web Components 也经历了复兴,从前几年的质疑中恢复过来,用于从 DocuSeal 到 Photoshop 的应用程序交付。正如 Alex Russell 在 2021 年所说:

好的好的,但除了 Google、MSFT、Adobe、ING、Comcast、EA、Ubisoft、GE、Nintendo、Blizzard、SpaceX、Salesforce 和 Internet Archive……真的有人在使用 Web Components 吗?

Svelte 不甘于因 API 不足 而在构建上遇到许多麻烦,采取了反击措施,用符文重新思考反应性,并因宣布 Dominic Gannaway 与 Rich Harris 合力全职开发 Svelte 而引起相当大的兴奋。

但他们不是唯一在重新思考响应性的人。Meta 对 React Forget 提供了一个令人期待的更新,看来大家对此充满了期待。

在幕后,HTMX 那种令人耳目一新的审慎推广却难以忽视,尽管它可能是最糟糕的框架,但在这个构建工具日益复杂的时代,它正变得越来越引人注目。

构建系统

说到这个,我们已经看到下一代构建工具,即 SWC 和 Esbuild 的使用率上升,而且,你相信吗,甚至还有更多的打包工具与之搭配使用。Rome 倒下了,Biome 崛起;去年 Turbopack 宣称自己是 Webpack 的继任者(用一些毫不掩饰的对 Vite 不利的基准测试),但今年 Rspack 了冲了进来。与此同时,Metro 仍然是 React Native 的首选工具,胜过其他替代品。

开发工具(简要)

不满情绪已经酝酿。Eslint 对维护格式规则感到厌烦,其他人对 Prettier 填补这一空缺的速度感到不满,甚至悬赏 2 万美元来取代它(Biome 获胜)。

在另一个方面,Bun 向我们展示了包安装可以比我们假设的快得多,尽管使其成为可能的二进制锁文件有重大的缺点。

2024 年预测

那么,现场已经布置好了,我的塔罗牌、甲骨和星图也准备就绪,让我们来占卜一下 2024 年前端的发展吧。

每个人都想拥有整个技术栈

似乎不仅仅是想要推翻现有工具,还想要拥有软件堆栈的整个垂直领域。Bun 想成为你的运行时环境、编译器、包管理器、HTTP 服务器和测试运行器,即使这意味着会造成生态系统的碎片化

我们之前在 Rome 也遇到过这种情况。每个人都在尝试找到一种方法来从开源软件中获利,但由于从一群小气鬼那里赚钱并不顺利,看起来目前风险投资圈流传的最佳想法就是先拥有一切,等到市场被占领后再慢慢解决其他问题。

没有哪家公司比 Vercel 更能体现这一点,他们为一切都提供产品。托管、域名注册、边缘功能、数据库、分析、为所有主要 UI 框架提供的 SSR 集成、部署小工具 等等。他们尽可能多地自主创新(我们已经看到了用于打包的 Turbopack、用于管理单体仓库的 Turborepo 和用于生成图像的 Satori),并且包装他们无法自创的任何东西。

那么 Vercel 下一步会做什么呢?我认为他们的选择包括:

  • 剔除中间商。 他们包装了像 Upstash 这样的许多服务,但通过自行开发解决方案可以提高利润空间。
  • 为他们的技术栈打造更多独特的东西。 Vercel 的价值主张是“你可以自己搭建这些东西,但我们让它变得轻而易举”,但如果改变为“你无法自己搭建这些东西”,他们会更有吸引力。
  • 将人们困在他们的技术栈中。 这绝对是三个选项中的超级坏蛋选择,但是深化是一个经过尝试和测试的保留策略(参见 Atlassian 和 Microsoft)。

所以,虽然都很模糊,但我相信,通过这些因素的某种组合,他们(有意识或无意识地)最终会执行 Meta 的剧本,打造一个如此引人入胜的技术栈,以至于它能创造基于该技术的工作,并吸引用户为其贡献,以推动它进一步发展。

有谁能挡住他们的路?Biome 的位置不错,但是没有原始罗马项目所拥有的 450 万美元资本,要成为一个严肃的竞争者。Bun 有资本(700 万美元),但鉴于他们在解决大约 2000 个问题上的资源分配非常紧张,我认为 CI 工具市场将是他们明年更现实的目标。Deno 在 2022 年筹集了 2100 万美元,似乎正在小心翼翼地用 Deno Deploy 和 Deno KV 这样的东西进入市场,但离回答整个技术栈还远着呢。这就留下了我心目中的风险投资支持的 Y-combinator 创业公司(我们所知的一切),Expo

在最初几年专注于通过广泛的 SDK 建立用户基础后,Expo 已经转向了他们的盈利阶段,推出了Expo 应用服务。再结合 Expo 路由,一个强有力的挑战者出现了,因为他们在 Vercel 相对薄弱的领域——移动端拥有一些专长。为什么要在 Next.js 上构建,而不是选择 Expo 路由,并免费获得原生移动应用?对于 Sanket Sahu 来说,这是一个有说服力的论点。

尽管 Expo 拥有这种令人羡慕的战略位置,但还有很多工作要做。他们还没有那种“万能产品”,因此用户可能会发现自己需要链接外部服务来补充某些功能。React Native 堆栈的 SSR 功能也仍有空白,所以他们别无选择,只能自己解决这些问题。Vercel 在这里受益,因为他们与 React 核心团队(雇佣了像 Sebastian MarkbågeAndrew Clark 这样的关键人物)有着密切的联系,以影响 React 的发展方向。不过,也许是 React 影响了他们

无论谁占上风,作为最终用户,我有一些愿望。虽然我欢迎简化和统一事物的尝试——正如前端在过去几年变得荒谬复杂一样——但这绝不应以牺牲锁定为代价。技术栈应该始终赋予用户保留他们喜欢的部分并替换掉他们不喜欢的部分的能力。

EDIT: 发布这篇文章后,我惊讶地收到了 Vercel 的 CEO Guillermo Rauch 的直接消息,他澄清了他们的预期方向,并为我的愿望带来了一些希望:

喜欢你的预测。我能告诉你的是,我们在 2024 年实际上会进一步增强生态系统的能力。更多像 Upstash 这样的选项,更多 API 钩子将其他集成和初创企业带入我们的生态系统。圣诞快乐!

网络将变得更加多元化

随着苹果在 App Store 上对网络引擎的守门人政策终于将在 2024 年 3 月 5 日结束,Safari 团队不得不认真起来以保护他们的市场份额。我确实认为苹果不会轻易放弃,我们甚至可能再次看到 Safari 的崛起,或许苹果会在 ML/AI 领域吸引人们,并利用 iPhone 硬件的特殊优势。

我对 Servo 明年能否挑战桌面空间持怀疑态度,因为它在 CSS 测试中的通过率仍然是中等水平的 61.8%,在 WPT 测试中的通过率是 55.4%,但它的 WebView 可能会在特定用途的应用中找到用武之地。实际上,随着 Android 和 Tauri 出现在发展路线图上,似乎他们确实在倾向于嵌入式角度,并且目前还没有特别计划围绕 WebView 创建一个浏览器。

瓢虫浏览器继续给人留下深刻印象,它参与 2023 年 Web 引擎黑客马拉松活动标志着它是一个严肃的参与者(我认为)。我认为挑战现有浏览器还为时尚早,但我确实在为它们加油,特别是因为它们寻找规范漏洞使所有浏览器受益。

随着 Manifest V2 即将被弃用,Chrome 自食其果,但看来这还不足以改变市场份额。相反,随着苹果的门户政策结束,他们反而可能获得更多。iOS 垄断的破裂将会是动荡的,因为开发者必须在更多的移动目标上测试行为,而且存在只在 Chromium 上测试所有习语的诱惑。由于像 Twitter 这样的重要网站已经开始屏蔽他们不愿支持的浏览器,我担心会回到“最佳观看效果在 Netscape Navigator 上”的日子。

同时,这对 Firefox 来说是一个绝佳的机会。垄断初期的打破对于形成声誉至关重要,而 Firefox 不受广告巨头的商业利益束缚,因此他们可以在广告屏蔽和隐私方面进行竞争。如果 Firefox 能够在 YouTube 上屏蔽广告而 Chrome 不能,那对某些人来说就足够了。不过,从我看到的没有安装广告屏蔽器的用户数量来判断,也许像苹果的更新诱惑“只给他们更多表情符号”可能是一个更好的方法。

AI 刚刚起步

OpenAI 到目前为止一直主宰着海洋,尽管途中发生了叛变,但从这里开始应该是一帆风顺的。他们一直将航向设定在 AGI 上,有些人认为 GPT-4 是通往那里的一个路标,但我认为 2024 年将主要围绕其他舰队最终出现在地平线上。

虽然每个巨头都涉及多个市场领域(例如,它们中的大多数都提供广泛的云服务),但谷歌在搜索方面的存在感更强,Meta 更关注语言分析,亚马逊在购物方面的动机更强,而苹果则有更多的消费设备可以利用。因此,他们可能各自专注于与他们最相关的领域。

我的目光却聚焦在苹果公司。他们凭借深远的预见性一直在推进自己的棋子,多年来已经开始出货带有专用机器学习处理器的设备,但这一切仍然只感觉像是发射前的倒计时。

他们跟上了新兴技术的步伐,推出了个性化语音模型 Personal Voice,因为个性化语音模型正流行,并且在 LLMs 证明了其潜力后,对预测性文本输入进行了改进,所以他们有一个将经过验证的 AI 技术带入消费者手中的主题。据报道,他们在受限设备上运行LLMs方面取得了突破,并且正在开发一个名为“Ajax”的生成式 AI 模型,以与 GPT-3.5 竞争。考虑到他们近年来作为一个注重隐私的公司进行了品牌重塑,我认为他们将是第一个提供免费、无限使用、可选离线、设备上、注重隐私的LLMs的公司。这可能是 Siri 一直以来所缺少的要素。

大型 UI 框架将长期存在

虽然我很喜欢为弱队加油,但我认为除非有 FAANG 公司推出新框架,否则我们不会看到 React 及其朋友们被取代。不过,鉴于几个主要框架的核心团队成员都在同一个屋檐下,如果我们看到 Vercel 推出一个全新的、从零开始构建的、集各家之所长的框架来利用 SSR,我其实也不会感到惊讶。

移动开发不会有太大变化

我认为本地开发者会继续进行本地开发,而且通常开发者会坚持使用他们已经在用的框架,就像忠诚的选民一样。毕竟,在这么大的领域里,要说服人们改变阵营需要很大的推动力。此外,尽管 DX 已经改进,但场景并没有根本改变(自从像 SwiftUI 和 Catalyst 这样的 SDK 级别添加以来就没有)。可能主要需要关注的是 Expo Router,挑战在于说服开发者为 web + native 而不是仅为 web 创建应用程序。哦,当然还有 NativeScript!

结论

这是多事之秋的一年。随着 SSR 和 AI 被前所未有地大力推动,以及 JS 生态系统从工具到引擎本身的蓬勃发展。明年,我预计会看到更多工具和框架的整合,更多行业力量的争夺,以及 AI 在我们日常流程中的更多参与。最后,我们可能还会看到更多向农业的转型,因为开发者们集体放弃了跟上这个不断变化的场景。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant