來自NPM聯(lián)合創(chuàng)始人的預言：前端未來會這樣

大家好，我卡頌。

在WWC22[1]上，NPM聯(lián)合創(chuàng)始人（當前是Netlify的數(shù)據(jù)分析師）「Laurie Voss」發(fā)表了對「web開發(fā)」未來發(fā)展方向的預測演講。

本文讓我們來看看這位有26年web開發(fā)經(jīng)驗的數(shù)據(jù)分析師，會帶來哪些洞察。

太陽底下無新鮮事
未來5年「web開發(fā)」會如何發(fā)展，在說出自己的預測前，「Laurie」先表示：「在座各位，很可能討厭我的預測」。

因為他自己就不待見這個預測結(jié)果。

那么他預測的依據(jù)是什么呢？簡單來說就是：

太陽底下無新鮮事

作為一個有26年web開發(fā)經(jīng)驗的數(shù)據(jù)分析師，「Laurie」總結(jié)了技術(shù)發(fā)展的模型。

簡單來說，一項技術(shù)的生命周期會經(jīng)歷一個輪回：



提出解決思路
最初，人們在項目開發(fā)時遇到一個問題，有部分人開始嘗試解決這個問題。

一旦某個人提出一個讓人覺得「這個思路很棒」的解決方案，當遇到類似問題時大家就會嘗試用自己的理解將這個解決方案落地。

比如，當Dan提出Redux模型時，社區(qū)還沒有更好的狀態(tài)管理解決方案，于是這個方案被廣泛接受，涌現(xiàn)出很多「基于Redux模型的狀態(tài)管理方案」。









這是個不斷重復造輪子的過程（也是很多KPI項目的源頭）。

找出最佳實踐
隨著這套解決方案不斷實踐，會逐漸產(chǎn)生「最佳實踐」。

當「最佳實踐」產(chǎn)生后，開發(fā)者通常會覺得無聊，因為在這個方向沒有什么可探索（可造輪子）的了。

這時候，某個無聊的程序員會想：我可以制造一個「大而全」的框架/系統(tǒng)/產(chǎn)品，一勞永逸的解決這類問題。

也就是說，將最佳實踐「商品化」。

最佳實踐的商品化
「商品化」過程通常是很激烈的，會有很多團隊/公司/個人參與其中，提出自己的產(chǎn)品，并抨擊競爭對手在某些方面的不足。

比如，各種前端框架，可以認為是前端工程師這類消費者消費的商品。

消費者有自己的偏好，可能有人喜歡Vue，有人喜歡React。但作為商品，最終會產(chǎn)生一個事實上的贏家。

這是一個不變的經(jīng)濟規(guī)律 —— 要達到某個目的，可能有很多產(chǎn)品可供選擇，但一旦其中某款產(chǎn)品被更多人選擇：

作為老板，可以更容易招到「會用這款產(chǎn)品的程序員」

作為程序員，可以更好利用這個產(chǎn)品的社區(qū)生態(tài)

這又會反過來使得該產(chǎn)品被更多人選擇，最終馬太效應（強者愈強）產(chǎn)生。

比如，與Wordpress同時期出現(xiàn)的，還有很多博客建站產(chǎn)品。



但到2022年的今天，全世界43%的網(wǎng)站是Wordpress驅(qū)動的。第二名與他的差距恐怕都不是一個數(shù)量級的。

抱怨基礎欠缺
當某一產(chǎn)品成為主流后，就會聽見一種聲音：不要光會用產(chǎn)品/系統(tǒng)/框架，你還得理解背后的原理。

當「Laurie」剛當開發(fā)時，主流的標記語言是[SGML](https://www.techtarget.com/whatis/definition/SGML-Standard-Generalized-Markup-Language#:~:text=SGML%20(Standard%20Generalized%20Markup%20Language "SGML")%20is%20a%20standard%20for%20how,It%20is%20metadata.) (Standard Generalized Markup Language，標準通用置標語言)

HTML僅僅是SGML的一個微小子集，特點是規(guī)范比較松散，但比較易學。

如果你在當時使用HTML，資深工程師會告誡你：不要光會用HTML，還得理解背后的SGML，要不然是做不長久的。

大規(guī)模應用
當某個產(chǎn)品成為絕對主流，被大規(guī)模應用，以至于成為事實上的「基礎設施」后，下一代技術(shù)人很可能不會再接觸上一代人所謂的「原理知識」。

比如現(xiàn)在，HTML已經(jīng)成為前端基礎設施了，誰還記得SGML呢？

另一個例子，現(xiàn)在的老前端，很多都用過jQuery。






在前端框架興起之前，大家都用jQuery操作DOM。面試時也會考察jQuery源碼。

畢竟，大家都認可 —— 原生JS才是基礎。

jQuery中的選擇器太好用，以至于主流瀏覽器都將他內(nèi)置了，這就是querySelector的選擇器語法。

最終，querySelector成為選擇DOM時事實上的標準。誰會在意背后的原理呢？

回到原點
最后，在基于新的「基礎設施」的開發(fā)中又會遇到新的問題。于是，一切又回到了起點。

比如，最初開發(fā)者使用JSP、PHP開發(fā)前端頁面。

后來有了CSR。

再后來為了解決CSR的各種問題，有了SSR。

但從實現(xiàn)原理來說，JSP、PHP不就是SSR么。

Laurie的預言
最后，基于上述輪回模型，「Laurie」提出了對「web開發(fā)」的預言。

在21年的一次調(diào)查中顯示，有68%的開發(fā)者使用React開發(fā)頁面。

「Laurie」表示：在他的職業(yè)生涯中，能達到jQuery那么大的使用規(guī)模，React是唯一一個。

沒準兒未來React會被作為基礎設施在瀏覽器中直接實現(xiàn)（就像jQuery的選擇器一樣）。

但不是以「直接集成React本身」的方式，可能是將當前還不太好用的Web Components重新設計為類似React Component的形式。

在當前，有很多新的框架基于React實現(xiàn)，比如Astro、Remix、Next.js、Solid.js。

這些框架的開發(fā)者假設自己的用戶已經(jīng)會用React、喜歡用React（否則也不會用他這款框架），這從側(cè)面反映了React已經(jīng)被作為前端基礎設施。

如果接受了這個設定（React會作為前端基礎設施），那么我們就回到了輪回模型的起點。

有什么事情是當前開發(fā)者用React反反復復實現(xiàn)，又覺得很無聊的事呢？

一個答案是：寫組件。

所以，「Laurie」認為：未來5年，基于「React組件」的可視化編輯器會成為主流。

類似React Bricks[2]這款產(chǎn)品：



屆時，一部分開發(fā)者負責實現(xiàn)各種功能的React組件，這類組件被稱為Bricks（磚塊）。

而大部分開發(fā)者則基于磚塊，用可視化編輯器拖拽實現(xiàn)不同頁面。

這類開發(fā)者甚至不會接觸到HTML，在他們的基礎設施中，最小的單位是磚塊（React組件）。

事實上，早期的瀏覽器（由「Sir Tim」開發(fā)的WWW）就是用拖拽、輸入等方式實現(xiàn)的富文本編輯器。



呵，太陽底下無新鮮事。

總結(jié)
如果你看到這個預測后覺得挺討厭的 —— 就這？

就像文章開篇就提到的，「Laurie」自己也討厭這個預測。

但歷史一次次證明，曾經(jīng)被討厭的設計，最終很可能變成主流（比如2013年時，前端們對待JSX的態(tài)度）。

26年前的開發(fā)者會認為只會HTML，不會SGML是不靠譜的。

10年前的開發(fā)者會認為只會jQuery，不會原生JS是不靠譜的。

現(xiàn)在的開發(fā)者會認為只會前端框架，不懂實現(xiàn)原理是不靠譜的。

那有沒有一點可能，5年后的開發(fā)者會認為只會拖拽生成頁面，不懂開發(fā)組件是不靠譜的？

參考資料
[1]
WWC22:
https://www.youtube.com/watch?v=hWjT_OOBdOc

[2]
React Bricks:
https://reactbricks.com/

作者：卡頌


歡迎關(guān)注微信公眾號 ：魔術(shù)師卡頌