首页 >web前端 >js教程 >如何避免前端技术让我们感到不满

如何避免前端技术让我们感到不满

Patricia Arquette
Patricia Arquette原创
2025-01-11 16:27:44869浏览

How to avoid frontend tech making us resentful

关于前端变得多么令人困惑和难以承受的文章有很多(请参阅 JavaScript 框架 - 进入 2025 年的概述),我相信这与对前端的激励有很大关系。不同的各方,我讨论如何填补现有的漏洞,并创建一个更健康的生态系统。

开发人员的现实

当前端开发人员考虑不同的技术时,他们需要一种方法来说服利益相关者(包括业务人员和他们的开发同行),而做到这一点的唯一方法是构建事物并对其进行测量,从而证明其好处和效果管理期望。 (驱动因素可能是需要构建全新的东西,改进已经存在的东西,或者甚至可能只是证明不需要改变,并且在外部各方的情况下,通过替代方案无法获得任何好处正在给公司施加压力以考虑它。)

一个例子可能是正在考虑使用更多 React Server 组件的开发人员(重点不是 RSC 本身,也可以是其他东西、另一个框架或另一项技术)。他们需要调整其架构以包含服务器,采用新的编程模式,考虑使用这些新路由器和指令的文件组织,推理所有这些限制,教育人们所有这些,协调内部最佳实践和需求,与客户交谈并更新 SLA 和文档,...这一切都非常昂贵且风险很大,因此不能轻易做出决定。

(比较不同技术和进行架构迁移的艰苦且成本高昂的过程是全球很多团队正在经历的事情。想想有多少博客文章和视频是关于失败的承诺的一项技术(您不需要 Next.js – 为什么我们从 Next 迁移到 React 作为最新的技术之一)。)

然而,在开始构建 POC 后很快,开发人员意识到很多技术产品都是通过“相信我们,兄弟”的说法来宣传的。

框架厨房中出现的每一项新技术都讲述了一个伟大改进的故事,并通过相当可塑性的演示来展示它们。但现实往往要混乱得多,收益微乎其微,但实验和迁移成本却非常高。每个公司和每个团队面临的挑战是重新发明轮子,并想出方法来证明他们的特定案例确实有一些实用性。需要大量的资源和内部专业知识来全面、详尽地考虑和测试各种选项。

当一家公司将 Yet Another™ 功能宣传为“The Now Best Thing Ever™”(正如 Trust Me Bro™ 的声明所示),让开发人员购买该产品并投入使用时,前端生态系统的健康动态就会受到损害。努力迁移到上面,却发现,确实,难题很难解决,ROI也没有。随着时间的推移,多次这样被烧伤会导致怨恨、倦怠以及对未来风险的整体厌恶。

正在构建这些很酷的新技术的公司(它们真的很酷!)对人们感到不满感到惊讶,并且似乎不考虑这些努力所需的工作量以及可验证的讲述方式的不可访问性现实的期望可能是什么。这一切看上去都很不诚实。

我们认识到构建这些新技术的公司有责任证明他们的技术有效,不仅通过广告,而且还为开发人员提供工具来指导他们的决策并确认自己的利益.

工具

那么,这些工具实际上是什么样子的?

这些工具将持续报告开发人员关心的指标(可以客观衡量),与开发人员正在做出的更改进行整体组合和关联,以帮助他们了解权衡:

  • 捆绑包大小(每页和共享捆绑包的详尽报告,深入了解延迟加载(交互时)和/或自动加载(服务工作人员、预加载和其他预热)的其他捆绑包)
  • 网络指标(通过更多的序列化,很高兴知道客户端上的实际节省是多少,以及它如何影响服务器和客户端之间的通信)
  • 时间分割和性能(包括服务器和客户端,例如渲染内容需要多长时间以及服务器与客户端上的内容量、网络延迟和传输等)
  • 网络生命力(我们是否需要对网页的不同部分进行更细粒度的分割,以逐步加载和呈现?仅针对初始加载的一次性指标就足够了吗?)
  • 整个项目级别的所有这些不同指标之间的趋势(随着时间的推移)和相关性(以便团队可以跟踪事情的进展情况,并避免因性能随着时间的推移而下降或引入边缘情况而感到不愉快的惊讶仅在某些地方和某些页面)

这里提到的事情是任何团队都会关心的同样的事情,但是获得这些见解的工具似乎很难设置并且令人费解,并且在处理表现得像黑色的框架时有时实际上是不可能的盒子。

激励措施

这种工具不一定需要由自己开发这些新技术的同一家公司提供,但也可以由不同的公司构建(可能已经有类似考虑的暗示?Evan You - Vue, Vite、VoidZero 和 JavaScript 工具的未来,否则我可能会误解 Evan 所说的内容)。然而,我相信构建一些新技术的同一家公司应该提供工具来验证其收益,因为激励措施在他们一边:

通过构建这样一个工具来透明地报告各种指标和各种实现之间的差异,构建新技术/框架的公司可以首先在内部验证进度和声明,并帮助自己了解权衡,然后优化正确的指标。通过这种方式,它可以使公司保持负责任和诚实。因此,整个改进反馈循环可以在内部发生,甚至在到达公众之前就可以发生。

到那时,公司也可以向公众提供这些相同的工具,从而避免任何虚假声明和失望的风险,并为每个人提供在自己的项目上简单地为自己验证事情的能力。反过来,这会产生更多的信任和感激。

构建技术的公司也最有能力为其构建工具 - 它最了解其 API 和功能,以及需要开放多少或多少才能使工具发挥作用(这是另一种方式以保持公司诚实和公平)。

最终,如果公司希望通过付费工具来扩展其业务模式,它可以这样做。 (目前,类似的方法通常通过与客户公司签订合同和直接参与来体现,但是,工具可以使整个事情更加自助,这可以使所有各方受益。)

结论

我们正处于一个技术竞争的时代,没有单一的最佳解决方案,而且越来越大的项目的架构迁移并不便宜。为了能够明智地做出决定和采取行动,需要一种更全面的工具和报告,能够持续指导和评估决策、变更和权衡,而不仅仅是在一切完成后进行报告。

构建这些新技术和框架的公司将从此类工具中受益最多,并且最有能力构建它。

以上是如何避免前端技术让我们感到不满的详细内容。更多信息请关注PHP中文网其他相关文章!

声明:
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn