Oct
26
最近和不同的Native开发者与Web前端开发者之间聊天,发现大家的意识或者理念上的沟壑比我们想象中的深很多。都说大前端一家人,不过很多事情不同心共体的话,团队上细微的裂痕在项目或者组织动荡期会有非常大的风险导致团队成员的割裂。因此,需求其中的原因与寻找其中发展之道是本文讨论的关键。
鄙视链
各行各业都有鄙视链,前端也一样。广义的前端即我们本次讨论的范围,是指的GUI即图形用户界面的开发者。包括Native客户端开发者/Web前端开发者与各种工业软件/游戏/嵌入式开发者。其中行业人数最多的三块,形成鄙视链即:
游戏开发者 鄙视 Native客户端开发者 鄙视 Web前端开发者
在高阶游戏开发者与Native客户端开发者中尤甚。而相反高阶Web前端开发者其实期望吃掉前两者的领域——隔阂由此而生。
有很多人都分析过为什么会产生这个鄙视链。是技术深度?产品复杂度?从人性的角度是以上背景带来的优越感?而本文我给出的解释是——Mastery。
Mastery
Mastery这里我用来描述驾驭感。知乎上有一个问题问“为什么你喜欢手动挡的汽车”,高票回答就是提到了这个词:驾驭感。
显然游戏开发者/Native客户端开发者/Web前端开发者对前端Focus的驾驭感是完全不同的。但是这之前,我们需要解释一下前端开发者到底Focus的啥?
可以先想想前端开发者到底在干嘛——人机交互。
作为一个前端技术专家,人机交互的实现路径与结果必然是自己优先Focus的事项,这个和技术与产品无关,每个前端开发者的内心都会有这样的追求。而对人机交互的驾驭感,则是以上鄙视链产生的关键。
举个栗子:
我们有一个业务场景,是用户im表情管理,会在当前界面上展示超大量级的gif动图,并且支持拖放排序管理。现在各端把这个交互界面完成,但是发现a. 该页面占用内存极高,低端设备几乎不可用。b. 间接导致卡顿。如何优化?
一般的高级Web前端开发者会这么考虑:gif卡,能换webp么?问问产品能在浏览阶段对动图做一定裁剪损失么?能通过分步加载来降低瞬时内存抖动么?能针对不同的屏幕或者设备做降级么?
一般的高级Native开发者会这么考虑:可以通过动态解码算力换内存么?可以通过建设sd-内存缓存池来动态管理动图播放资源么?可以通过gpuimage一定程度显存换内存么?
一般的高级游戏开发者或者图形学开发者会这么考虑:可以通过ETC/PVRTC/DXT等显卡直接采样的压缩图片数据来避免位图展开占用内存么?pc可以通过微软DirectStorage或者老黄的RTX IO技术直接GPU读取硬盘来避免内存开销么?
可以注意到一般来说三者的技术控制范围是不太一样的:
高级Web前端开发者的驾驭范围始终在标准的Web浏览器能力范围内,而标准的Web浏览器能力本身难以解决的问题上,更多的是在规避问题。
一般的高级Native开发者的驾驭范围是操作系统的能力范围内。他们总是在操作系统提供的标准能力上需求方案或者规避问题。包括以上方案看似解决问题本质上还是在规避,只是资源的交换而已。而系统提供的drawimage到底干了什么,一般人也不从了解。这一点也间接证明了为啥大部分Native程序员可以接受rn/weex这样的动态化方案——毕竟绘制部分还是熟悉并可见并且可控的调用操作系统能力或者图形学能力,而类似于小程序的方案绘制部分Webcore黑盒掉了,难以接受。
而一般的高级游戏开发者或者图形学开发者熟悉作为人机交互显示部分最基础的GPU。他们的驾驭范围即GPU硬件能力范围,并且他们有能力根据不同的硬件去调整自己的路径。因为只要不是写坏了,比如这个问题提到的内存消耗本身还是得性能消耗的主体——硬件去提供能力解决。
简单的来说,这三者的最大的区别,就是他们的领域核心GUI技术的驾驭能力与范围,浏览器 < 操作系统 < 硬件。
拿结果
当然,从结果上,一般的产品以上栗子中提到的方案都是可以接受,并且肯定是组合起来看待的,甚至一般来说,真实的用户体验差距并不大。毕竟规避问题也是解决问题的一大方法。
但是,从开发者的角度,谁在解决问题,谁在规避问题一目了然,较真或者有追求的开发者必然会产生鄙视。因此,这个鄙视不是来源于技术本身的好坏,而是对应岗位核心技术驾驭能力的区别。驾驭能力弱的开发者,必然会在更多的问题上受到挑战。
同时,作为一个闭环的前端开发者,显然驾驭能力弱对应的,必然是标准化,工程化的引入,带来的是行业生产效率的提升。综合起来看结果,在GUI本身结果即质量体验一致的情况下,技术标准化的开发者必然能拿出更丰富的输出。
因此要我老实评判拿结果的能力:
Web前端开发者 鄙视 Native客户端开发者 鄙视 游戏开发者。
回到Mastery
以上讨论至少明确的一点,鄙视链的那一端,确实有更强的前端驾驭力——对应给开发者带来强大的驾驭感。
驾驭感是那么令人着迷的东西么?
驾驭感是主观带来安全感的:我做的东西质量高性能好,我自己保证!驾驭感是主观带来成就感的:我可以三下五除二搞定这玩意儿,你不能!驾驭感是主观带来贪欲的:这个我自己搞能行,这个我自己搞更好,我要制造这个一个轮子!
并且,驾驭感一旦获得,如果没有“事来则定,事去则静”的淡然心态,就再也难以放下了。它会导致开发者在寻求路线的时侯,追求“正义”而不是“正确”。
就是这么一个陷阱吧。
结论
是前端技术驾驭感导致了Native开发者与Web前端开发者的不同,并且在“正义”与“正确”之间平衡的讨论也是永无休止的。因此,我在这里给到的建议是:
a. to Web前端开发者:尝试驾驭更丰富的GUI开发方向,践行前端标准化的同时也尝试将自己转变为标准制定者,了解别人更丰富和沉醉的世界。
b. to Native开发者:先到图形学开发者的驾驭力,同时不断回头review自己走的路径是否真的正确合理,务必不要沉醉在驾驭感中。
鄙视链
各行各业都有鄙视链,前端也一样。广义的前端即我们本次讨论的范围,是指的GUI即图形用户界面的开发者。包括Native客户端开发者/Web前端开发者与各种工业软件/游戏/嵌入式开发者。其中行业人数最多的三块,形成鄙视链即:
游戏开发者 鄙视 Native客户端开发者 鄙视 Web前端开发者
在高阶游戏开发者与Native客户端开发者中尤甚。而相反高阶Web前端开发者其实期望吃掉前两者的领域——隔阂由此而生。
有很多人都分析过为什么会产生这个鄙视链。是技术深度?产品复杂度?从人性的角度是以上背景带来的优越感?而本文我给出的解释是——Mastery。
Mastery
Mastery这里我用来描述驾驭感。知乎上有一个问题问“为什么你喜欢手动挡的汽车”,高票回答就是提到了这个词:驾驭感。
显然游戏开发者/Native客户端开发者/Web前端开发者对前端Focus的驾驭感是完全不同的。但是这之前,我们需要解释一下前端开发者到底Focus的啥?
可以先想想前端开发者到底在干嘛——人机交互。
作为一个前端技术专家,人机交互的实现路径与结果必然是自己优先Focus的事项,这个和技术与产品无关,每个前端开发者的内心都会有这样的追求。而对人机交互的驾驭感,则是以上鄙视链产生的关键。
举个栗子:
我们有一个业务场景,是用户im表情管理,会在当前界面上展示超大量级的gif动图,并且支持拖放排序管理。现在各端把这个交互界面完成,但是发现a. 该页面占用内存极高,低端设备几乎不可用。b. 间接导致卡顿。如何优化?
一般的高级Web前端开发者会这么考虑:gif卡,能换webp么?问问产品能在浏览阶段对动图做一定裁剪损失么?能通过分步加载来降低瞬时内存抖动么?能针对不同的屏幕或者设备做降级么?
一般的高级Native开发者会这么考虑:可以通过动态解码算力换内存么?可以通过建设sd-内存缓存池来动态管理动图播放资源么?可以通过gpuimage一定程度显存换内存么?
一般的高级游戏开发者或者图形学开发者会这么考虑:可以通过ETC/PVRTC/DXT等显卡直接采样的压缩图片数据来避免位图展开占用内存么?pc可以通过微软DirectStorage或者老黄的RTX IO技术直接GPU读取硬盘来避免内存开销么?
可以注意到一般来说三者的技术控制范围是不太一样的:
高级Web前端开发者的驾驭范围始终在标准的Web浏览器能力范围内,而标准的Web浏览器能力本身难以解决的问题上,更多的是在规避问题。
一般的高级Native开发者的驾驭范围是操作系统的能力范围内。他们总是在操作系统提供的标准能力上需求方案或者规避问题。包括以上方案看似解决问题本质上还是在规避,只是资源的交换而已。而系统提供的drawimage到底干了什么,一般人也不从了解。这一点也间接证明了为啥大部分Native程序员可以接受rn/weex这样的动态化方案——毕竟绘制部分还是熟悉并可见并且可控的调用操作系统能力或者图形学能力,而类似于小程序的方案绘制部分Webcore黑盒掉了,难以接受。
而一般的高级游戏开发者或者图形学开发者熟悉作为人机交互显示部分最基础的GPU。他们的驾驭范围即GPU硬件能力范围,并且他们有能力根据不同的硬件去调整自己的路径。因为只要不是写坏了,比如这个问题提到的内存消耗本身还是得性能消耗的主体——硬件去提供能力解决。
简单的来说,这三者的最大的区别,就是他们的领域核心GUI技术的驾驭能力与范围,浏览器 < 操作系统 < 硬件。
拿结果
当然,从结果上,一般的产品以上栗子中提到的方案都是可以接受,并且肯定是组合起来看待的,甚至一般来说,真实的用户体验差距并不大。毕竟规避问题也是解决问题的一大方法。
但是,从开发者的角度,谁在解决问题,谁在规避问题一目了然,较真或者有追求的开发者必然会产生鄙视。因此,这个鄙视不是来源于技术本身的好坏,而是对应岗位核心技术驾驭能力的区别。驾驭能力弱的开发者,必然会在更多的问题上受到挑战。
同时,作为一个闭环的前端开发者,显然驾驭能力弱对应的,必然是标准化,工程化的引入,带来的是行业生产效率的提升。综合起来看结果,在GUI本身结果即质量体验一致的情况下,技术标准化的开发者必然能拿出更丰富的输出。
因此要我老实评判拿结果的能力:
Web前端开发者 鄙视 Native客户端开发者 鄙视 游戏开发者。
回到Mastery
以上讨论至少明确的一点,鄙视链的那一端,确实有更强的前端驾驭力——对应给开发者带来强大的驾驭感。
驾驭感是那么令人着迷的东西么?
驾驭感是主观带来安全感的:我做的东西质量高性能好,我自己保证!驾驭感是主观带来成就感的:我可以三下五除二搞定这玩意儿,你不能!驾驭感是主观带来贪欲的:这个我自己搞能行,这个我自己搞更好,我要制造这个一个轮子!
并且,驾驭感一旦获得,如果没有“事来则定,事去则静”的淡然心态,就再也难以放下了。它会导致开发者在寻求路线的时侯,追求“正义”而不是“正确”。
就是这么一个陷阱吧。
结论
是前端技术驾驭感导致了Native开发者与Web前端开发者的不同,并且在“正义”与“正确”之间平衡的讨论也是永无休止的。因此,我在这里给到的建议是:
a. to Web前端开发者:尝试驾驭更丰富的GUI开发方向,践行前端标准化的同时也尝试将自己转变为标准制定者,了解别人更丰富和沉醉的世界。
b. to Native开发者:先到图形学开发者的驾驭力,同时不断回头review自己走的路径是否真的正确合理,务必不要沉醉在驾驭感中。