如何看待百度要求内部全面停止使用 React / React Native?
百度要求内部全面停止使用 React / React Native 的决定，无疑是前端和移动开发领域的一件大事，也引发了广泛的讨论和猜测。要深入理解这一决策的背后原因和影响，我们需要从多个层面进行剖析。
1. 表面原因与官方声明：技术演进与生态自主
官方声明往往是决策的初步解释，通常会提及以下几点：
技术演进与自研体系： 百度作为一家拥有深厚技术积累的公司，一直致力于构建和完善自身的研发体系和技术生态。在某些阶段，引入成熟的第三方框架（如 React）能够快速构建产品，但长期来看，为了更好地掌控技术路线、优化性能、降低依赖，以及为未来的技术创新预留空间，自研技术栈往往是更优的选择。百度可能会强调其自研的UI框架、组件库或者其他底层技术，以替代 React 的功能。
性能优化与定制化需求： 尽管 React 以其虚拟 DOM 和高效的更新机制著称，但在某些特定场景下，为了极致的性能优化或满足高度定制化的需求，原生或更底层的实现可能更具优势。百度作为一家体量巨大的互联网公司，其产品线众多且对性能有着极高的要求，这可能促使他们寻求更直接、更可控的性能调优方案。
生态自主与风险控制： 依赖外部开源框架虽然能带来便利，但也意味着对框架的更新迭代、社区维护以及潜在的安全漏洞承担一定的风险。当一个框架的生态发展方向与公司战略不符，或者出现某些不确定的因素时，自主掌控技术栈可以有效降低这些风险。例如，如果 React 的许可协议发生变化，或者社区维护出现问题，都会对百度造成影响。
2. 深层原因与潜在考量：战略、成本、人才
除了官方声明中的技术原因，更深层次的考量可能涉及战略、成本和人才等多个方面：
战略聚焦与核心竞争力构建： 百度在人工智能、搜索、云计算等领域投入巨大，希望构建核心竞争力。过度的技术栈分散，尤其是在前端和客户端开发领域，可能会稀释其在核心技术上的投入和精力。通过统一和自研技术栈，可以集中资源，打造更加统一、高效的开发体验和技术生态，为核心业务提供更强的支撑。
研发成本与效率的权衡： 虽然 React 和 React Native 能够提高开发效率，但长期来看，对于一个大型企业而言，维护和升级一个庞大的第三方框架生态，也需要投入大量的研发资源和人力成本。自研技术栈在初期可能需要更大的投入，但如果能够实现高效的跨项目复用、统一的开发规范，并更好地集成公司内部的其他技术体系（如服务器端渲染、CDN 优化等），长期来看可能带来更高的ROI。
人才培养与技术栈的统一： 大型企业在招聘和培训人才时，通常倾向于拥有统一的技术栈。如果内部存在多种前端框架（React, Vue, Angular 等）以及多种客户端开发框架（React Native, Flutter, 原生开发等），会增加招聘、培训和团队管理的复杂性。统一技术栈有助于降低人才流动的壁垒，提高团队的协作效率，并培养一支更精通特定技术的专业团队。
对某些商业模式或许可协议的顾虑： 尽管 React 的 MIT 协议非常宽松，但某些公司可能会对开源项目的许可协议保持谨慎，尤其是当其商业模式与开源项目的潜在风险相关联时。尽管对于百度来说，这种可能性较小，但也不能完全排除。
社区发展方向与百度需求的脱节： 随着 React 和 React Native 的发展，社区的关注点和发展方向可能并不总是与百度的具体需求完全契合。例如，React Native 在某些场景下可能存在性能瓶颈，或者在某些平台特性支持上不如原生开发。百度可能觉得自研能够更好地满足其在特定场景下的需求。
对字节系技术栈的“反制”或“差异化”： 近年来，字节跳动及其旗下的产品（如抖音、头条）在移动端和前端开发领域大量使用了 React Native 和 Web 技术，并取得了巨大的成功。百度作为字节跳动的竞争对手，可能会有意识地避免与字节系的技术栈过于同质化，从而寻求技术上的差异化和自主性。这可能是一种战略上的考量，目的是构建自己独特的技术护城河。
3. 影响与挑战：短期阵痛与长期收益
这一决定将对百度内部以及整个前端和移动开发社区产生显著影响：
短期阵痛与迁移成本：
现有项目迁移： 对于大量基于 React 和 React Native 开发的现有项目，迁移到新的技术栈将是一项艰巨的任务。这涉及到代码重写、测试、部署等多个环节，需要投入大量的时间、人力和资金。
开发效率的暂时下降： 新技术栈的引入初期，团队需要时间学习和适应，可能会导致开发效率的暂时下降。
人才招聘的挑战： 如果百度内部不再培养或招聘精通 React/React Native 的人才，而转而招聘和培养掌握自研技术栈的人才，可能会面临一定的人才招聘和储备挑战。
长期收益与机遇：
技术自主可控： 能够完全掌握核心技术，拥有更大的灵活性去优化和迭代，降低外部依赖风险。
性能和体验的提升： 如果自研技术栈能够更好地满足性能和定制化需求，可能会带来更优质的用户体验。
技术生态的统一与协同： 统一的技术栈有助于构建更一致的开发体验，促进内部技术交流和知识共享，形成更强的技术合力。
人才队伍的专业化： 专注于特定技术栈的培养，可以打造一支在特定领域更专业的研发团队。
为未来技术创新奠定基础： 自主掌控技术栈，更有利于百度根据自身的业务需求和发展方向，进行前瞻性的技术探索和创新。
4. 应对策略与发展方向
面对这一决策，百度内部以及受到影响的开发者可能需要采取相应的应对策略：
对百度的影响： 需要制定详细的迁移计划，评估迁移成本和风险，并做好内部资源的调配。同时，需要加大对自研技术栈的投入，吸引和培养相关技术人才。
对前端开发者： 对于正在使用 React/React Native 的开发者，需要密切关注百度的官方动态，了解其自研技术栈的具体内容和学习资源。同时，保持开放的心态，学习新的技术，提升自己的技术广度和深度，增强自身在不同技术栈下的适应能力。
对开源社区的影响： 百度作为科技巨头，其技术选择对开源社区具有一定的影响力。这一决策可能会促使其他公司重新评估其技术栈的选择，也可能促使社区对 React 和 React Native 的某些方面进行反思和改进。
总结
百度要求内部全面停止使用 React / React Native 的决定，是一个复杂的战略性和技术性决策，其背后可能包含着对技术生态自主、性能优化、研发成本、人才战略以及竞争格局等多方面的考量。虽然短期内会带来一定的迁移阵痛和挑战，但从长远来看，百度可能希望通过此举来构建更自主、更可控、更具竞争力的技术体系，以支撑其在人工智能和互联网领域的持续发展。对于整个行业而言，这一事件也再次引发了对技术选型、生态建设和企业战略之间的深度思考。
网友意见
前一阵收到Apache的通知，要求所有Apache项目禁止使用带Facebook BSD+PATENTS License的项目，并限时完成替代，估计好多人要加班了，幸好我们没用。现在抵制这个License的公司越来越多，加班的苦逼工程师也越来越多。。。
其实这个License不光React用，大家可以看看Facebook的开源项目，很多都带了这个PATENTS文件：
这License思路很清奇，它带来的风险不是一般的专利风险，也就是你用了React有可能被Facebook告你专利侵权。而是只要你在用React，Facebook侵权你的专利你也不能告他，而且不只是跟前端相关的专利，而是包括了你拥有的所有专利。否则在你提起诉讼的瞬间，你就失去了使用React的授权。
但是如果Facebook抄袭了你的产品，你又不能马上放弃React怎么办？当然是选择原谅他啦。
Facebook说这个PATENTS是防护性的，只是为了防止有刁民诬告Facebook。但是被Facebook从头抄到脚的Snapchat有句mmp不知当讲不当讲。结合前一阵爆出来的Facebook用“Early Bird”系统来发现可能对Facebook业务产生威胁的创业公司，然后尝试收购或者模仿它们来把它们挤出市场，是不是细思恐极。
Facebook's new 'early bird' spy tool is just the tip of the iceberg
Facebook的这个License其实开了一个很不好的头。大公司可以通过在开源软件里塞私货来妨碍小公司崛起，进一步巩固自己的垄断地位。个人认为这种污染开源精神的行为很不好，希望Facebook能浪子回头，改用Apache2.0这种开放友好的License。
工作关系，精通美国专利法，在前东家后台支持过几次前两年美国公司最大规模专利诉讼。这里友善的的告知大家，本题里为facebook洗地那几个回答里涉及专利法的内容都是错的离谱的。
如果你在一个有国际化目标的公司工作，公司有出海的计划，而公司内部形成了使用react的风气，项目中大量使用，那很遗憾，你们公司所有各国专利事实上全部免费赠予facebook使用。
整个事情的逻辑很简单，举个例子来说明：公司各项目前端各类东西全部用react来玩，用户体验一流效果美观，人人夸奖。突然一天，发现自己最核心的、和web/UI/react完全无关的大批核心专利被facebook拿去商用、给facebook带来巨大商业收益并且进而和你们产生直接商业竞争，此时怎么办？起诉facebook？别逗，facebook根据协议，在你提出诉讼的那刻自动撤回所有react相关专利授权，你们所有基于react的系统同时侵权滥用facebook的react专利。前端的东西不那么好藏对吧？facebook马上拿了证据去联邦法院、甚至各主要国家法院，要求关停你所有侵权的基于react的服务。届时你能有什么话说？公司前台商用的系统只得被动地从react全部立刻迁移出去，换到没有和react关系的平台上，出海阻碍、项目成本、损失、诉讼风险谁来扛？
以百度为例，按照react目前协议，要想不让facebook事实上免费大胆用自己人工智能、自动驾驶方面获颁的专利，唯一选择就是不让公司的前端用react。这笔帐，真的不难算。
上面有小白给facebook洗地，说facebook是防御性的使用这些条款，只要你不去告facebook专利侵权就没事。这个逻辑思维能力真的不适合写软件。为什么某公司会告facebook？告facebook什么？这两个问题不复杂，真的要说清。是告facebook专利侵权对吧？当你们公司选择react来构建大量系统的前台，facebook上来什么也不干，先让你用公司全部专利做抵押，这叫防御？拿到你们的专利抵押，facebook可以直接免费大胆商用你们的专利，而你们却不能轻易起诉，因为一旦你们起诉，你们的react系统就是人质，facebook马上可以反诉你们侵权，请问这叫防御？最悲惨的，你以为你react粉，积极内部推广react，残酷的事实是，你内部react系统越多，迁移成本越高时间越广，被人霸占专利的风险越高：因为他们手里人质更多。
还有一个洗地说法是很多别的美国公司诸如netflex、微软、苹果也用react。拜托，那些美国公司手里和facebook业务相关的专利你去看看，微软、苹果怕和你facebook打专利官司？Imagination说苹果一做GPU，就踩专利地雷阵，结果大家都看到了。微软的专利portfolio蓝星无敌，谁碰谁出局。netflix核心竞争力最根本的是手里的内容也就是片源，也不大搞别的互联网项目，BATJ肯把业务覆盖面缩到netflix一样窄，再来对比谈用react的风险才有意义。
这个事情要特别当心，react前端的东西，detectability没的说，这不同于你后台某服务器程序用了某某专利、某某库，只要你自己不去开源，别人无法发现难以证明。而且和一般的patent retaliation clause不一样，react这事情反复报道，涉及的react专利清晰明确，到时候扯皮的机会也没有。用某某库的时候retaliation clause要当心，自己被公司授权去开源某项目，license里的patent grant clause要当心。
评论里有人反复用“案例”来质问，基本是主张防范是浪费，要出事了用事故说明问题，这逻辑本身就不对。RocksDB以前也同样的BSD+Patent协议，知道自己后台系统用的，别人用了facebook也无法知道更无法证明，钓鱼成功概率接近零就自觉改了协议，（在改协议的时候有意或者无意的把LevelDB的协议去掉被老对头lmdb作者抓现行）。反观react，受关注更多，却死活不改协议，为什么？同一个公司，都是火热的两个开源项目，同样的协议上的问题，如此大的区别对待，还不够说明facebook在react协议上有小算盘？
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有