如何看待React Router創始人鬧翻並另立門戶推出Reach Router？

06-07

如題，請問大家如何看待這件事情？
以前也經常發生這種團隊分裂的事情，比如Node.js的分支io.js，創始人或者核心成員一言不合就另立門戶，在開源項目中如何處理這種事情？

我覺得這個問題應該改成「如何評價阮一峰老師的腦補水平」？

鬧翻了另起門戶？阮老師，您平時除了翻譯四手英文資料之外，是不是還寫霸道總裁言情小說？

我認為您的套路就是翻譯三分之一，腦補三分之一，然後再花三分之一的時間想個標題。當然不管我們怎麼說您也不會改的。這樣寫標題點擊量高啊，您說對嗎？

我截個5月29號的圖給您看吧。期待您的新微博——「React Router創始人分家之後重歸於好，兄弟之情如膠似漆」？

沒事，react router每次更新都相當於另立門戶，我已經習慣了

面向堵氣編程

阮老師是我見過腦補能力最強的前端段子手。

react-router 是我見過代碼最噁心的 react 項目。

都是 market 界的大咖，做前端太可惜了。

react全家桶果然不省心

老實說，這router就是個毒瘤，趕緊死，代碼看了都臟眼睛，哪還有空管它的維護團隊，愛咋咋地。

——————

想了一下感覺還是正面回答一下問題。維護團隊爆發矛盾，社區分裂，沒想像中影響那麼大，也沒什麼好處理的，本身別人就是無償在維護代碼，別人想怎樣就怎樣，覺得不爽不靠譜那就把它換了，或者fork出來，自己維護，代碼的世界哪有那麼墨跡，討論來討論去，就一句話，代碼誰寫？別人不寫，那就你寫，多大的事。

另外還是忍不住再黑一波，這工具就一路由，寫得還很雜亂，特性又多又臃腫，這種庫從歷史角度來看，就很容易死，因為這種華而不實的庫本身就是一群伸手黨捧起來的，我敢說大部分人已經搞不清這庫最新版本的特性了，大部分就是跟著文檔的一些簡單場景搞些代碼，要是場景複雜，那些亂七八糟的特性就廢了一大半，剩下那麼幾個沒什麼屌用的特性還拖著一整個超複雜的抽象模型，然後自己就要開始想辦法繞，典型的被垃圾工具綁架，這種玩意，即便真的死了，又有什麼可惜的。

想起了玉伯在&<&<前端模塊化開發那點歷史&>&>中講到 FlyScript 作者 khs4473 和 RequireJS 作者 James Burke 有過一些爭論。khs4473 做了自我閹割，將 GitHub 上的 FlyScript 項目和官網都清空了，官網上當時留了一句話，模糊中記得是

我會回來的，帶著更好的東西。

這中間究竟發生了什麼，不得而知。後來玉伯有發郵件給 @khs4473 詢問，khs4473 給了兩點挺讓人尊重的理由，大意是

我並非前端出身，RequireJS 的作者 James Burke 比我更懂瀏覽器。
我們應該協同起來推動一個社區的發展，即便它不是你喜歡的。

------------------------------------------ 分割線-------------------------------------------------

最近的 deno issue 事件也反映了目前前端圈開發人員對這種情況的反感.

Ryan Florence二月就宣布離開React Router:

https://medium.com/@ryanflorence/goodbye-react-training-react-router-hello-workshop-me-totalreact-com-8cf66e993e3c?

medium.com

2. 5.29為React慶生

https://twitter.com/ryanflorence/status/1001535095168159745?

twitter.com

3. 3月初第一次commit，5.31正式宣布reach-router

https://twitter.com/ryanflorence/status/1002218160517300224?

twitter.com

4. 一些區別

Next Generation Routing for React?

reach.tech

輪子年年有，今年特別多。

前端界每隔幾個月就要重新實現一遍已經有的功能小部分是有效的大部分就是為了賭氣