## 前端技術選型分析
得益于node的作為前端工具的強有力的生產力,近兩年前端web技術獲得突飛猛進了的發展,各種自動化工具,前端框架越來越流行。
網頁正變得的復雜起來,越來越變得像一個網絡應用程序了。
各種新技術如雨后春筍般的涌現出來,在新技術的浪潮中讓我們顯得有些不知所措,現在設計網頁不得不重新考慮設計了,主要有兩種選型方向:
1. 響應式
2. 單頁應用
* * * * *
### 首先說響應式
你真的需要響應式嗎,先來看優缺點,傳統網站在手機上面體驗如噩夢,需要專門為手機甚至不同設備都單獨開發一套模板,這樣在大公司,沒個團隊維護相應的模板時不是問題,但是對于初創企業,小團隊而言,維護多套模板成本比較大,如果能用一套模板,能夠自動適應不同設備的屏幕尺寸那就好了,不經節省了人力,也增加了用戶體驗,頁面在不同尺寸下杜能較平滑的過度,能打造出比較好的用戶體驗。但是響應式網頁對開發人員的要求比較高,代碼質量要求更高,而且由于響應式網頁在設計時專門針對不同尺寸屏幕寫了不同的樣式,并且做了優化,所以較單獨的模板來說網頁體質會稍微大一點,所以性能上有一定的損耗。
分析完優缺點后,那么問題來了,我的網頁適合設計成響應式的嗎?
響應式網頁的技術決定了哪些類型的網頁適合用響應式技術來設計,通常來說頁面結構簡單,交互功能少,的頁面適合響應式設計,比如企業官網,新聞閱讀類網頁,這類網頁主要是展示型的,而不是重邏輯交互型的,而頁面結構復雜,業務邏輯偏重,交互功能多的頁面則不適合響應式設計,比如電商的商品詳情頁,購物車頁面等等,這些頁面業務邏輯較重,結構,功能度比較復雜,并且交互功能多,所以響應式設計則會很麻煩,所以不適合做響應式設計,最好手機版和電腦版各自單獨開發一套專門模板,但是請注意,平板和手機上面其實體驗差不多的,所以做手機模板時可以考慮兼顧一下平板,帶點簡單的響應式也可以,這樣就不需要單獨為平板設計一套模板了,總之靈活運用才是最好的。
* * * * *
### 再說單頁應用
什么樣的應用適合單頁呢,單頁的特點很明顯,那就是很想一個應用程序,而不是傳統的網頁跳來跳去的白屏,如應用般流暢的操作大大的提高了用戶體驗,所以優點還是比較明顯的,一般創業公司的項目很適合,體驗做得好的話,會給用戶很酷,眼前一亮的感覺,但是也有缺點,由于使用了前端框架,打包工具生成的代碼,所以第一次訪問比較慢,但之后的所有操作都會很快,因為不在請求模板了,之后的所有操作都是請求數據,而沒有刷新。至于擔心內存泄露的問題,其實也沒有必要了,成熟的前端框架考慮的很全面, 并且現代瀏覽器也不是那么傻,所以完全不用擔心這個問題,不要有傳統網頁開發時的根深蒂固的觀念,總想著F5刷新了。
單頁這么好,那么是不是所有網頁都適合使用單頁開發呢,其實不是的,單頁有一個致命的問題不能夠忽視,那就是沒辦法做SEO了,因為單頁內容都是js運行時自動生成的,并且使用前端的路由,所以頁面信息無法被搜索引擎抓了,所以需要考慮SEO的站點,比如新聞站,下載站這樣重SEO的站點就不需要考慮了,一些偏后臺,功能結構復雜,偏向于組件化的系統可以采用單頁開發,其實不要以為頁面結構復雜就不適合單頁了,要知道單頁最適合的地方就是大型的應用,因為實際開發中你就知道,越是在復雜的系統中采用單頁框架開發,你的代碼量就越少,這時越能體現出單頁框架的威力。
還有向移動端,H5網頁,創業項目類等都適合使用單頁開發,尤其是組件式開發,后期維護方便太多了。
但是單頁也不是萬靈藥,總結出來的規律就是,網頁頁面不會太多的適合單頁,而那些臃腫,頁面數量太多的程序則不那么適合單頁了,一般頁面數量在50個以內的可以適合單頁,頁面數量超過50個則不太適合了,不過也是可以靈活運用的,單頁也可以與傳統頁面相互結合使用,比如支付寶下面的四個菜單,可以分為四個入口,沒個入口里面就是單獨的單頁,可以采用類似這種模式。總之沒有死的規則,需要靈活運用才能達到最好的設計。
> 如果項目臃腫,比如商城項目,想要單頁的體驗,但是用單頁做又不合適,不想太激進,那么可以考慮嘗試一下[SUI Mobile](http://m.sui.taobao.org/)也是不錯的選擇,現在很多商城項目用SUI Mobile的還比較多,原因不外乎SM相對于react的學習成本來說還是要低很多,但卻能帶來和react基本相同的的單頁用戶操作體驗,所以性價比還是非常高的,尤其適合現有項目的遷移,先向SM遷移,等以后再慢慢轉向react這種真正的單頁也不遲。
* * * * *
### 擴展
- [有PC版的網站如何做一套手機版的網站出來](https://segmentfault.com/q/1010000004043075)
- [移動前端開發之 viewport 的深入理解](https://segmentfault.com/p/1210000007532296)
- [【全解析】屏幕尺寸,分辨率,像素,PPI之間到底什么關系?](http://www.chinaz.com/manage/2015/0902/441624.shtml)
- [Electron開發跨平臺構建流程設計](http://mp.weixin.qq.com/s/Yv1ss1X1K-QG9fEXGjZ_zw)
- [如何利用 Electron 開發一個桌面 APP](https://mp.weixin.qq.com/s/BCouOyCRUhjF5stVyK8IsA)
- [漸進式Web應用(PWA)入門教程(上)](https://mp.weixin.qq.com/s/LRxyuLe8cCE_S917yOkMbA)
- [Flutter - 極速構建漂亮的本地應用](http://doc.flutter-dev.cn/)
> Flutter 是谷歌的移動端 UI 框架,可在極短的時間內構建 Android 和 iOS 上高質量的原生級應用。 Flutter 可與現有代碼一起工作, 它被世界各地的開發者和組織使用, 并且 Flutter 是免費和開源的.
- [Xamarin.Forms 簡介 - Xamarin | Microsoft Docs](https://docs.microsoft.com/zh-cn/xamarin/xamarin-forms/get-started/introduction-to-xamarin-forms)
> Xamarin.Forms 是本機支持的跨平臺抽象 UI 工具包,讓開發人員能夠輕松創建可在 Android、iOS、Windows 和通用 Windows 平臺之間共享的用戶界面。使用目標平臺的本機控件即可呈現用戶界面,從而讓 Xamarin.Forms 應用程序為每個平臺保留相應的界面外觀。本文介紹了 Xamarin.Forms 以及如何開始使用它編寫應用程序。
[BAT等國內知名的互聯網公司是怎么做到前后端解耦的?](https://www.wukong.com/question/6524835292317221127/)
* * * * *
[Elm + Rust 開發桌面應用](https://github.com/huytd/kanban-app)(英文)

目前,使用 Web 技術開發桌面應用,主要通過 Electron。它的缺點是,有時你只是想要在桌面上展示一個網頁,不需要跟本地文件系統交互,但是不得不把整個 Chromium 瀏覽器和 V8 引擎包含在這個應用里面,導致不管邏輯是否復雜,任何一個 Electron 應用都至少有幾十MB的大小。
這個項目展示了另一種開發桌面應用的可能。它的原理是,任何操作系統都有自己的 WebView,也就是說可以在應用程序里面調用 WebView 展示網頁。那么可以使用 Rust 語言打包 WebView,而 JS 腳本部分交給 Elm 語言生成。由于 WebView 是系統提供的,所以打包出來非常小,一般只有幾百KB,資源占用也很少。
[每周分享第 5 期 - 阮一峰的網絡日志](http://www.ruanyifeng.com/blog/2018/05/weekly-issue-5.html)
* * * * *
無需托管的小型網頁
[前谷歌設計師推出微網站建造工具 一切內容藏于URL中](https://www.toutiao.com/a6574896150887793155/?tt_from=weixin&utm_campaign=client_share×tamp=1530863184&app=news_article_lite&utm_source=weixin&iid=33124962994&utm_medium=toutiao_android&wxshare_count=1)
[alcor/itty-bitty: Itty.bitty is a tool to create links that contain small sites](https://github.com/alcor/itty-bitty)
* * * * *
[華為發布UI+ 鼠標拖一拖搞定App界面開發](https://www.toutiao.com/a6576490739025314307/?tt_from=weixin&utm_campaign=client_share×tamp=1531286912&app=news_article_lite&utm_source=weixin&iid=33124962994&utm_medium=toutiao_android&wxshare_count=1)
* * * * *
update:2018-1-7 21:03:17
- 開始
- 微信小程序
- 獲取用戶信息
- 記錄
- HTML
- HTML5
- 文檔根節點
- 你真的了解script標簽嗎?
- 文檔結構
- 已經落后的技術
- form表單
- html實體
- CSS
- css優先級 & 設計模式
- 如何編寫高效的 CSS 選擇符
- 筆記
- 小計
- flex布局
- 細節體驗
- Flex
- Grid
- tailwindcss
- JavaScript
- javascript物語
- js函數定義
- js中的數組對象
- js的json解析
- js中數組的操作
- js事件冒泡
- js中的判斷
- js語句聲明會提前
- cookie操作
- 關于javascript你要知道的
- 關于innerHTML的試驗
- js引擎與GUI引擎是互斥的
- 如何安全的修改對象
- 當渲染引擎遇上強迫癥
- 不要使用連相等
- 修改數組-對象
- 算法-函數
- 事件探析
- 事件循環
- js事件循環中的上下文和作用域的經典問題
- Promise
- 最佳實踐
- 頁面遮罩加載效果
- 網站靜態文件之思考
- 圖片加載問題
- 路由及轉場解決方案
- web app
- 寫一個頁面路由轉場的管理工具
- 談編程
- 技術/思想的斗爭
- 前端技術選型分析
- 我想放點html模板代碼
- 開發自適應網頁
- 后臺前端項目的開發
- 網站PC版和移動版的模板方案
- 前后端分離
- 淘寶前后端分離
- 前后端分離的思考與實踐(一)
- 前后端分離的思考與實踐(二)
- 前后端分離的思考與實踐(三)
- 前后端分離的思考與實踐(四)
- 前后端分離的思考與實踐(五)
- 前后端分離的思考與實踐(六)
- 動畫
- 開發小技巧
- Axios
- 屏幕適配
- 理論基礎
- 思考
- flexible.js原理
- 實驗
- rem的坑,為什么要設置成百分比,為什么又是62.5%
- 為什么以一個標準適配的,其它寬度也能同等適配
- 自適應、響應式、彈性布局、屏幕適配
- 適配:都用百分比?
- 番外篇
- 給你看看0.5px長什么樣?
- 用事實證明viewport scale縮放不會改變rem元素的大小
- 為什么PC端頁面縮放不會影響rem元素
- 究竟以哪個為設備獨立像素
- PC到移動端初試
- 深入理解px
- 響應式之柵格系統
- 深入理解px(二)
- 一篇搞定移動端適配
- flex版柵格布局
- 其他
- 瀏覽器加載初探
- 警惕你的開發工具
- JS模塊化
- webpack
- 打包原理
- 異步加載
- gulp
- 命名規范
- 接口開發
- sea.js學習
- require.js學習
- react學習
- react筆記
- vue學習
- vue3
- 工具、技巧
- 臨時筆記
- 怎么維護好開源項目
- 待辦
- 對前端MVV*C框架的思考
- jquery問題
- 臨時
- 好文
- 節流防抖