专栏名称: 奇舞精选
《奇舞精选》是由奇舞团维护的前端技术公众号。除周五外,每天向大家推荐一篇前端相关技术文章,每周五向大家推送汇总周刊内容。
目录
相关文章推荐
厦门日报  ·  18条措施!证监会重磅发布 ·  19 小时前  
厦门日报  ·  刚刚,谷爱凌宣布:退出 ·  3 天前  
51好读  ›  专栏  ›  奇舞精选

答粉丝问:前端未来会如何发展?

奇舞精选  · 公众号  ·  · 2024-11-20 18:00

正文

大家好,我卡颂。

今年陆续有很多粉丝向我咨询类似 「前端未来会如何发展」 的问题。

本文将就我长期的行业观察,对以上问题做出自己的判断。

需求侧

要讨论 「前端工程师作为一种职业,未来的前景如何」 ,需要从需求侧、供给侧分别讨论。

国内软件行业的需求主要来自三方面:

  1. 2G:政府采购,比如智慧城市、政务系统、公共服务平台...

  2. 2B:企业服务,比如传统企业数字化转型、产业互联网平台...

  3. 2C:老百姓衣食住行,比如消费互联网应用...

在当前经济形势下,这三者都有所下降,这是不争的事实。

在此背景下,我们需要明确两个事实:

  1. 并不只是软件行业下降,各行各业都在下降

  2. 在普降的基础上,软件行业由于其 「规模效应」 以及 「软件分发时边际成本接近0」 的特点,相比其他行业仍有较大薪酬溢价

换言之,虽然前几年应届前端能拿20k,而当前多年经验的前端可能还不到20k。

即使这样,这个薪酬相比同工龄其他行业仍有溢价。

所以,前端工程师仍是个不错的职业,只是岗位数量比前几年会少很多。

那这不多的前端 offer ,会给到谁呢?

这就要谈到供给侧 —— 未来需要的前端技术栈,与当下是不同的。

供给侧

当前,前端行业正面临大规模的 「AI驱动的开发范式迁移」 —— 一些旧的技能不再有用,新的技能正在逐渐涌现。

举个例子,很多同学简历里会写:熟练掌握 Taro UniApp ...等的开发。

类似 Flutter Taro UniApp 这样的跨端框架对“负担不起多端程序员,但对多端应用有需求的团队”来说是刚需。

但他的缺点也很明显,比如:

  • 如果应用体量大,或者对性能要求较高时,跨端框架有明显局限性

  • 同一个跨端组件在不同端可能表现不一致

随着AI的发展, 「AI将代码改写为端的原生代码」 的成本可能比 「修复跨端框架引入的问题」 还低。

可以预见,跨端框架会越来越没价值。

甚至,最终能留存下来的跨端框架也只是套壳AI应用,而不是上述传统跨端框架中的胜出者。

“有多年跨端框架使用经验”对程序员来说本该是简历中的加分项,但AI的发展让这项技能变得无足轻重。

再举个例子:问你个问题,什么是 「前端脚手架工具」

我想你能脱口而出: vite CRA 等能初始化前端项目的工具。

但在,当开发者需要初始化项目时,当下最高效的工具并不是上述传统意义上的脚手架工具。

如果要初始化 Next 项目,首选是 v0 [1] (一个根据需求生成 Next 组件的AI应用)。

除此之外, bolt.new [2] cursor Composer 也是很好的选择。

这些AI工具才是当下及未来的前端脚手架工具。

这种 「开发范式迁移」 正悄然发生在前端开发的各个细分领域,它带来的影响是:少部分跟随浪潮升级技术栈的前端,获得了比其他同行高2~N倍的开发效率。

结合需求侧的疲软,这部分前端会抢占绝大部分前端开发 offer

前端的未来发展

当完成范式迁移后,前端的工作内容将发生两个层面的变化:

1. 核心工作:从 「实现代码」 「架构设计」

虽然AI能根据需求实现代码,但如非刻意提醒,他更多关注 「实现」 而忽略背后的 「架构」

所以,在让AI实现代码前,类似下面的问题都需要程序员明确:

  • 如何设计数据流转、状态管理

  • 根据实际情况做技术选型、规定代码组织结构

  • 项目规范、工程化流程

甚至说,对于公司的多人协作项目,在引入AI后,还要考虑:

  • AI代码的复核机制

  • AI代码的维护策略

这些工作在有AI之前,通常是前端架构师、项目主程做的,而在完成范式迁移后,将是普通前端的核心工作。

2. 进阶工作:从 「专才」 「多才」

当前端的核心工作更多聚焦在上层的 「架构设计」 时,会与上下游其他工种产生更多交集,比如:

  • 考虑 「数据流转」 时,会与后端有更多交集

  • 考虑 「体验优化」 时,会与UI有更多交集

  • 考虑 「转化效果」 时,会与产品有更多交集

这使得前端的工作范围发生延展。

当下,已经有很多前端朝着后端(全栈)发展,所以这里我举个UI的例子。

以下是传统的UI设计师工作流程:

最终交付 「带有标注的设计稿」 给到前端工程师实现。

而在前端完成范式迁移后,前端工程师不需要被动等待最终产物,在 「Figma建立设计系统」 这一步就能参与UI的工作。

在这一步中,UI会定义 「设计token」 ,这是基本的设计常量。

举个例子,设计师不会随意使用颜色值,而是从预定义的色板中选择。比如主题色可能定义为 blue-500 ,警告色为 red-500

这些就是 「设计token」

在前端工程师视角, blue-500 可能对应CSS类:

.text-blue-500 { color#3B82F6; }

在前端开发范式迁移中,有一环是:类似 TailwindCSS 这样的 原子CSS 会成为 「AI时代新的前端样式语言」

主要有4个原因:

  1. 语义性: 原子CSS 可以与 设计token 一一映射,可以作为UI与前端之间沟通的桥梁

比如,设计师视角下的按钮组件:

  • 背景色:Primary/500
  • 文字颜色:White
  • 内间距:Spacing/4 (横向), Spacing/2 (纵向)
  • 圆角:Radius/MD

前端用 TailwindCSS 实现:

<button class="bg-primary-500 text-white px-4 py-2 rounded-md">
  1. 简洁性:相比于原生CSS,原子CSS在AI生成时更省 token

比如,在实现状态样式时,原生CSS需要写 :hover{ } 选择器, Tailwind 只需要 hover: 前缀。

  1. 规律性: TailwindCSS 的类名定义有明确规则,很适合AI学习与推导,且不容易产生歧义

比如,颜色相关类名遵循 {color}-{strength} 模式 ,尺寸相关类名都是4px的倍数。

  1. 稳定性:原生CSS有 「样式优先级导致的样式覆盖」 等问题,AI在生成时也会面临这些问题

原子CSS 则规避了这些原生CSS问题。

所以,当前端的核心工作从 「实现代码」 转移到 「架构设计」 时,他可以在UI建立设计系统时参与其中。

AI可以很方便的借助 原子CSS 根据 「基于设计系统实现的设计稿」 生成前端页面。







请到「今天看啥」查看全文