當前位置:首頁 » 網頁前端 » react移動web
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

react移動web

發布時間: 2022-07-17 08:54:37

① reactjs適合移動端的web頁面開發嗎

我認為React是適合移動端,而不適合pc端的。

pc端使用React需要重做很多已有組件,包括但不限於highCharts圖表類、dataPicker基礎組件。
移動web app恰恰是不需要這類復雜的組件的,這給寫移動端項目重寫組件帶來了機會。
pc端要seo,移動端基本不需要,所以用這種數據後載入的框架有了可能。
然後,用webpack編譯出來的基礎庫React + es6 + Route + rex + tappable,minify之後大概200k不到,gzip之後50k左右。所以明確的說,是適合移動端的。

後各位都不使用緩存么?不管是用etag或者Expires的強緩存,還是用localStorage做緩存。第一次訪問的50k基礎庫,都不是2g用戶
的致命傷,2g致命傷是一個RTT的時間巨長。用React基本沒有操作需要zepto了,少了13k gzip之後的zepto,也少用一個模板引擎。
我承認用了es6之後代碼編譯會顯大,但明顯這十幾k並不是阻止用React的理由。
大家可以試用一下微信錢包裡面的城市服務的首頁,剛剛做了React的嘗試,基本能做到秒出,以後會推到其它的微信商業項目中。

② reactjs適合移動端的web頁面開發嗎

看了一遍樓上所說的,都點了反對。很想問一下大家是想當然的,還是試用過了。我認為React是適合移動端,而不適合pc端的。pc端使用React需要重做很多已有組件,包括但不限於highCharts圖表類、dataPicker基礎組件。移動web app恰恰是不需要這類復雜的組件的,這給寫移動端項目重寫組件帶來了機會。pc端要seo,移動端基本不需要,所以用這種數據後載入的框架有了可能。然後,用webpack編譯出來的基礎庫React + es6 + Route + rex + tappable,minify之後大概200k不到,gzip之後50k左右。所以明確的說,是適合移動端的。 然後各位都不使用緩存么?不管是用etag或者Expires的強緩存,還是用localStorage做緩存。第一次訪問的50k基礎庫,都不是2g用戶的致命傷,2g致命傷是一個RTT的時間巨長。用React基本沒有操作需要zepto了,少了13k gzip之後的zepto,也少用一個模板引擎。我承認用了es6之後代碼編譯會顯大,但明顯這十幾k並不是阻止用React的理由。大家可以試用一下微信錢包裡面的城市服務的首頁,剛剛做了React的嘗試,基本能做到秒出,以後會推到其它的微信商業項目中。

③ reactjs適合移動端的web頁面開發嗎

先說意見,當然適合。
關於說React庫大的,只說一句……React可以服務端渲染……
其實最大的一個問題還是,為啥用React?
咱目前項目也是React的,雖然不是移動端,個人所覺得React最大的好處就是省去了細粒度操作的繁瑣,又有大工程項目的可維護性。所以用React的前提是,是做一個web
app。
不過目前移動端網頁的需求感覺很多都是展示類型的靜態頁面,所以這種用React顯然是沒啥必要。
所以如果是『頁面開發』,自己覺得沒必要。光說平台不說具體需求什麼的,標准耍流氓嘛。

④ reactjs適合移動端的web頁面開發嗎

react是適合移動端頁面開發的,react是一個用於構建用戶界面的JavaScript庫,適合的場景是將後端復雜的數據顯示在復雜前端復雜的界面上,是非常適合做移動端頁面的。
1、聲明式
React 可以非常輕松地創建用戶交互界面。為你應用的每一個狀態設計簡潔的視圖,在數據改變時 React 也可以高效地更新渲染界面,以聲明式編寫UI,可以讓你的代碼更加可靠,且方便調試。
2、組件化
創建好擁有各自狀態的組件,再由組件構成更加復雜的界面,無需再用模版代碼,通過使用JavaScript編寫的組件你可以更好地傳遞數據,將應用狀態和DOM拆分開來。

⑤ reactjs適合移動端的web頁面開發嗎

1.適合。
2.React最大的好處就是省去了細粒度操作的繁瑣,又有大工程項目的可維護性。
所以你用React的前提是,你是做一個web
app。
3.不過目前移動端網頁的需求感覺很多都是展示類型的靜態頁面,所以這種用React顯然是沒啥必要。
所以如果是『頁面開發』,我覺得沒必要。

⑥ reactjs適合移動端的web頁面開發嗎

先說意見,當然適合。

關於上面說React庫大的,我只說一句……React可以服務端渲染……

其實最大的一個問題還是,為啥用React?

我目前項目也是React的,雖然不是移動端,我所覺得React最大的好處就是省去了細粒度操作的繁瑣,又有大工程項目的可維護性。所以你用React的前提是,你是做一個web app。

不過目前移動端網頁的需求感覺很多都是展示類型的靜態頁面,所以這種用React顯然是沒啥必要。

所以如果是『頁面開發』,我覺得沒必要。光說平台不說具體需求什麼的,標准耍流氓嘛。

⑦ 如何使用react和webpack

  • webpack是一個前端資源模塊化管理和打包工具,說白了就是方便我們管理自己的常用的一些代碼,比如你開發中用到sass以及jade同時用到es6,開發時你不可能改動某個地方就挨個命令去轉換在到瀏覽器去看效果,那樣效率是非常低的。所以webpack幫我們省去了那些多餘的步驟。

  • 基本入門

  1. 入口文件配置(entry);

  2. 輸出配置(output);

  3. 載入器配置(mole);

  4. 其他配置(resolve);

  • build存放編譯後的文件,development存放react代碼的文件夾,components存放react組件的文件夾,node_moles存放安裝的依賴。

⑧ reactjs適合移動端的web頁面開發嗎

React是適合移動端,而不適合pc端的。
原因:
1、pc端使用React需要重做很多已有組件,包括但不限於highCharts圖表類、dataPicker基礎組件。
2、移動web app恰恰是不需要這類復雜的組件的,這給寫移動端項目重寫組件帶來了機會。
pc端要seo,移動端基本不需要,所以用這種數據後載入的框架有了可能。
3、用webpack編譯出來的基礎庫React + es6 + Route + rex + tappable,minify之後大概200k不到,gzip之後50k左右。所以明確的說,是適合移動端的。
4、不管是用etag或者Expires的強緩存,還是用localStorage做緩存。第一次訪問的50k基礎庫,都不是2g用戶的致命傷,2g致命傷是一個RTT的時間巨長。用React基本沒有操作需要zepto了,少了13k gzip之後的zepto,也少用一個模板引擎。
5、用了es6之後代碼編譯會顯大,但明顯這十幾k並不是阻止用React的理由。
可以試用一下微信錢包裡面的城市服務的首頁,剛剛做了React的嘗試,基本能做到秒出,以後會推到其它的微信商業項目中。