京東單品頁前端開發那些不得不說的事兒

来源:http://www.cnblogs.com/qianduantuanzhang/archive/2017/11/13/7828118.html
-Advertisement-
Play Games

簡介： 詳情頁也叫做單品頁，功能變數名稱以「item.jd.com/skuid.html」為格式的頁面。是負責展示京東商品 SKU 的落地頁。主要任務是展示和商品相關的信息，如：價格、促銷、庫存、推薦，從而引導用戶進入購買流程。同時單品頁有很多版本。一般分為兩類。一類我們通常看到的「通用類目詳情頁」—— 所 ...


簡介：

詳情頁也叫做單品頁，功能變數名稱以「item.jd.com/skuid.html」為格式的頁面。是負責展示京東商品 SKU 的落地頁。主要任務是展示和商品相關的信息，如：價格、促銷、庫存、推薦，從而引導用戶進入購買流程。同時單品頁有很多版本。一般分為兩類。一類我們通常看到的「通用類目詳情頁」—— 所有類目都可以使用，一類是不經常看到的「垂直屬性詳情頁」—— 一些有特殊屬性的商品集合

item version
item version

 

首先。由於詳情頁大量（sku上億）、高併發（日 pv 約 5000 萬）等特性，在很長的一段時間里，單品頁面都是後端程式生成靜態頁面使用 CDN 來解決大量、高併發的問題。

其次。單品頁涉及的「三方」系統特別多，比如：促銷、庫存、合約、秒殺、預售、推薦、IM、店鋪、評價社區。而單品頁的主要任務就是展示這些系統的信息，並且適當的處理他們之間的衝突關係，而這些系統的介面一般都使用 非同步 Ajax 來完成，因為 其一 CDN 無法做到頁面的動態化，其二 一些系統的信息對實時性要求特別高（價格、秒殺），即使使用後端動態渲染也很難做到無緩存 0 延遲
基於上面兩個原因，註定了單品頁是一種重多系統業務邏輯展示型頁面。重前端頁面。我大概彙總了一下頁面上非同步介面，總共約有 30 個，頁首屏的介面特別重要，介面之間幾乎都有耦合關係

item-async-service
 item-async-service

 

前端的發展歷程

混沌時期

混沌時期的單品頁並沒有前端開發的概念。核心的功能腳本只有三個：促銷價格（promotion.js）、庫存地區（iplocation.js）、其它邏輯（pshow.js）。這三個腳本分別是三個不同團隊的同事負責維護，當時我剛進入京東的時候在 UED 部門，負責頁面腳本整體的維護工作和 pshow的開發。那時候我自己維護的 pshow.js 腳本壓縮後只有 80 kb，所有的代碼都是過程式的，沒有任何使用模式和代碼技巧，JS 最多也只被用來做個判斷渲染 DOM。那時候的前端工作內容只在 UI 層面，寫樣式和一些交互腳本

這個階段給我最深刻的感覺是單品頁後端模板很少維護（後端架構是最老的 aspx 版本）。大多數的改動都要用 JavaScript 去動態渲染。因為後端頁面是一個生成器生成的。如果頁面後端模板有改動那麼就需要全量的生成一次，過程可能需要幾個小時

初見端倪

當我接手這個項目時剛好有一次大改版，就在這時候老大說頁面上的腳本都要放在我們手裡維護。然後就是一大波的重構、重寫。基本上 pshow 被重寫了大概 80% 其它的因為業務邏輯的問題並沒有完全重寫，只是做了些代碼層面的優化

有一個模板引擎叫 [trimPath]，知道這個的估計都算老前端的了。最早的客戶端 JavaScript MVC 模式代表作品，只到現在還是使用。這個階段像評價這種完全非同步載入的模塊特別適合使用模板引擎來減少維護的工作量。這個時候雖然頁面上的代碼並不都是我們寫的，但基本上前端對頁面的 JavaScript 有了控制權，接下來的事情就是尋找機會逐個優化

這段時間是最痛苦的時候，維護的工作統一到前端。然後後端幾乎沒有變化，只是在一段時間將後臺的架構從 aspx 過渡到了 java。本質上並沒有什麼改變。前端卻做了比以前更多的事情，也是在這個時候我接手了大量的維護工作（包含全站公共庫的維護）使得我意識到了一些自動化、工程化方面的重要性，後文會主要講解，順便說下，那時候前端自動化工具 Grunt 剛面世，但是我自己卻用的是 [apache ant]，不過不久就切換到了 Grunt 來構建項目

撥雲見日

單品頁不僅重系統邏輯，也重維護
在這段時間里一方面有正常的維護類需求要做，一方面自己也不斷的學習新知識為以後的改版做鋪墊。不過就在這時單品頁有歷史意義的一次技改出現了 —— 單品頁動態化技改。

總的來說這次的改版後很多數據直接從後端讀取，不再從前端非同步獲取而且我們也做過一些非同步載入的優化，多介面 combo 從統一服務吐出給前端使用。這時前端就不用再為非同步介面的載入時苦腦了，只需要專註系統介面的邏輯

隨著這次技改，前端的代碼也迎來了模塊化的時代。我們把所有的前端代碼都進行了模塊化然後基於 SeaJS 重寫，配合 Nginx concat 功能實現了本地模塊化開發，線上服務端合併

單品頁前端模塊的結構與劃分

概覽

 

first-screen-normal-module
 first-screen-normal-module

 

上圖可以看出，基本上最核心的模塊都在首屏。每個模塊都有單獨的一/多個腳本。代碼行數（LOC）由 230+ ~ 1200+ 不等。通常來說代碼行數越多代碼複雜性就越高，邏輯越複雜。很難想象「購買方式」這種只有一行屬性選擇功能的代碼行數卻 高達 1200 多行。其主要原因就在於購買方式所在的系統和其它首屏核心系統（庫存、促銷、地址選擇、白條）都有邏輯上的耦合
看著不錯，然而在一個前端工程師眼裡至少應該是這樣的（我只取了一些典型的模塊，並不是全部）：

 

first-screen-in-fe-eye
 first-screen-in-fe-eye

 

這就可以解釋為什麼有的時候只是加一個很小的東西我們都為考慮再三然後通過 AB 測試提取相關數據，最後後再進行決策。單品頁的首屏可以說是寸土寸金

按什麼維度劃分模塊

起初我按模塊的屬性劃分，比如：核心、公共腳本、模塊腳本。但用了一段時候以後發現這樣劃分在單品這種大型系統中並不科學，因為這樣劃分出來的代碼只有劃分的人知道是什麼規則，其它人接手代碼很難快速掌握代碼架構，而且尤其在模塊比較多的時候不方便維護
後來我嘗試完全以功能模塊在頁面上出現的位置維度劃分。這樣以來維護起來方便多了，需要修改某個模塊代碼只需要對照著圖裡面標識的模塊信息就能輕易找到代碼

整體核心模塊

我們按頁面上的模塊結構首屏劃分出來這幾個核心模塊：

  • curmb - 麵包屑
  • concat - 聯繫咨詢相關店鋪信息
  • prom - 價格促銷信息
  • address - 地區庫存選擇，配送服務
  • color - 顏色尺碼
  • buytype - 合約機購買方式
  • suits - 套裝購買
  • jdservice - 增值服務
  • baitiao - 白條支付
  • buybtn - 購買按鈕
  • info - 地區提示信息

項目的整體樹形結構是這樣的：

project-structure
project-structure

模塊內部結構

比如下麵這個大圖預覽的功能，我全部放在一個文件夾裡面維護，但是邏輯上的 JavaScript 模塊是分離的，只是說文件夾（preview）就代表頁面上的某一部分功能集合

module-structure
module-structure

註意文件夾的命名有一定的規則：

模塊腳本與樣式名必須一樣

需要製作 sprite 的圖片統一放在 module/i 目錄下麵，生成的 sprite 圖片也在其中

生成的 mixin 在模塊根目錄下，便於其它樣式文件調用

我們再來看下自動生成生成的 __sprite.scss 是什麼內容：
/* __sprite.scss 自動生成 /@mixin sprite-arrow-next { width: 22px; height: 32px; background-image: url(i/__sprite.png); background-position: -0px -30px;}/ preview.scss 手動添加 */@import "./__sprite";.sprite-arrow-next { @include sprite-arrow-next;}

註意引用的 mixin 名稱和我們需要手動添加的樣式類名一致。當然也可以直接生成一個類名對應的樣式，但是靈活性不好。比如 hover 的時候是另外一張圖片就沒法自動生成了

前端技能樹

HTML

DOM 節點數

與重業務邏輯的頁面不同，重展示的頁面一般具有很高的 DOM 節點數。比如京東首頁，正常情況載入完頁面一共有 3500 多個 DOM 節點，基本上全部用於展示商品信息、廣告圖和內容佈局，頁面上的三方非同步服務也比較少。尤其像頻道頁基本上沒有什麼業務上的邏輯，全部是靜態頁面。這種頁面的特點是更新換代頻率高，一年兩三次改版很正常，CMS 做模塊化後兩天換個皮膚都是沒問題的。但是這種思路並不適合單品頁。單品頁更重業務邏輯，同時展示層 UI 邏輯也有很多關係

我自己的經驗是：頁面上的 DOM 節點數絕對不能超過 5000 個，否則頁面滾動的時候就會出現卡頓的情況，尤其是移動端
同步渲染還是非同步載入

理論情況下最好做法是後端同步動態渲染頁面，但是由於 Web 應用中很多功能都是用戶行為驅動的。同步載入不可避免的消耗了後端服務資源。比如：非首屏模塊（公共頭尾、評價）、點擊事件觸發的 DOM 內容（非同步 tab）

所以我的經驗是：能放到後端做判斷渲染的 DOM 就儘量放在後端（尤其是首屏）。這樣做的好處有四點好處

  1. 後端渲染頁面相對穩定，不像前端 JavaScript 動態渲染 DOM，可能因為腳本報錯或者不可用造成模塊都無法展示

  2. 可訪問性、SEO 及用戶體驗也比較好。不會產生腳本的渲染抖動問題

  3. 一定程度上減少了前端渲染頁面的複雜性，減少前端代碼複雜度

  4. 邏輯統一到一個地方維護起來也方便，而且後端應該為業務邏輯負責，前端應該為展示UI 交互負責

對於非同步渲染的模塊來說，後端通常需要判斷 「頁面有什麼元素」，以及元素之間的依賴對應關係；而前端需要專註於 「元素應該怎麼展示」，UI 層面的交互以及模塊與模塊之前的邏輯關係
其實更多的時候 非同步是一種沒有辦法的辦法，也就是說非同步是其它方案都解決不了的情況下才考慮的

外鏈靜態資源

儘量使用外鏈 CSS 和 JavaScript 資源，一方面便於緩存，減少服務同步輸出的資源浪費。IE 6 裡面會有一些可怪的 bug，比如有內聯樣式 style 標簽的頁面 A 如果在另外一個頁面 B 中的 link 標簽中引用，那麼這段 style 會在 B 頁面也起作用

使用雙協議的 URL

使用 //來代替http:和 https:瀏覽器會自動適應兩種協議的資源訪問，相容性較好。註意 IE 8 下使用腳本更新 src 為雙協議時會出現 bug，建議用 location.protocol來判斷然後做相容處理

刪除元素預設屬性

比如 script 標簽預設的 type 就是 text/javascript，如果 script 裡面的內容是 JavaScript 時可以不用寫 type。另外如果要在頁面裡面插入一段不需要瀏覽器解析的 HTML 片段時可以將 type 寫成 text/x-template（任意不存在的 type） 用於放置模板文件，通常用來在腳本中獲取其 innerHTML 而無任何負作用
給腳本控制元素加上類鉤子
在腳本中取頁面元素使用 J-
首碼類名，與普通樣式類分離。這樣做會生成很多冗餘的類名，但卻很好的降低了樣式和腳本的耦合，並且在重構和腳本職位分開團隊里會是一條最佳實踐

CSS

樣式分類

所有頁面只共用一個 sass Mixin，裡面包含了基礎的 sass 語法糖、常用類（清浮動、頁面整體顏色字體等）
模塊級的樣式分為兩類：

  • 與腳本無關的公共樣式，單獨在模塊文件夾中組織。比如：按鈕、標簽頁。全部放在 common 模塊中維護
  • 與腳本相關的模塊級樣式，與對應模塊腳本放在一起，可以引用 common 中的公共樣式，但不可以被其它模塊引用

雪碧圖

關於雪碧圖 我經驗是：永遠不要想把所有的圖標拼合在一起。按模塊而不是按頁面去拼 sprite 更合理，更方便維護，然後配合構建工具自動接合生成樣式文件才是最好的解決方案。當然如果你的頁面比較簡單，那這條規則並不適用。說到這個問題我就得把珍藏多年的圖片拿出來 show 一把，用事實來說明為什麼把所有圖片都拼在一張圖上就一定是對的

早期由於年輕篤信將所有的 icon 拼在一張圖上才是完美的（圖 1）

 

first-sprite
first-sprite

後來維護起來實在不方便，就把按鈕全部單獨接合起來。註意，當時的按鈕都是圖片，設計方面要求的很嚴格。加入購物車按鈕做的也非常漂亮（圖 2）

button-sprite
button-sprite

（web前端學習交流群：328058344 禁止閑聊，非喜勿進！）

然後這些都不是最典型的，下麵這個 promise icon 才是 （圖 3）

 

promise-sprite
promise-sprite

從圖裡面可以看到，這個功能在第一個版本的時候只有 7 個 icon，後來不斷增加，最多的時候達到 77 個。以至於當時每周都會添加兩個的頻率

同時這個 icon 當時接合的時候技術上也有問題：不應該把文字也切到圖片裡面，主要原因是早期 icon 比較少加上外邊框樣式對齊的問題綜合選擇了直接使用圖片

後來我就覺得這樣是不對的。然後通過和產品的溝通，說明我的考慮以及新的解決方案後得到了認同。結果就是對圖片不進行拼合，後臺上傳經過審核的不帶文字 icon，文字由介面輸出，然後在產品上做了約定：icon 最多不能超過 4 個，代碼里也做了相應限制。這樣就能保證頁面上的請求數不會太多同時方便系統維護，問題得到瞭解決

適當使用 DataURI

這個在一些小圖片場景方面特別適合，比如 1*1 的占點陣圖、loading 圖等，不過 IE 6 並不支持這種寫法，需要的時候可以加上一些相容寫法：
.ELazy-loading { background: url(data:image/gif;base64,R0lGODlhKwAeAJEAAP///93d3Xq9VAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFFAAAACwDAA0AJQADAAACEpSPAhDtHxacqcr5Lm416f1hBQAh+QQJFAAAACwDAA0AJQADAAACFIyPAcLtDKKcMtn1Mt3RJpw53FYAACH5BAkUAAAALAMADQAlAAMAAAIUjI8BkL0CoxQtrYrenPjcrgDbVAAAOw==) center center no-repeat; *background-image: url(//misc.360buyimg.com/lib/skin/e/i/loading-jd.gif);}

關於相容性

相容性可以說是前端工程師在平常開發中花費很大量無意義工作的地方。關於相容性我想說的是 如果你不願意去說服周圍的人放棄或者讓他們意識到相容性是個不可能完全解決的問題，那麼你就得為那些低級瀏覽器給你帶來的痛苦埋單

其實更好的辦法是你和設計、產品溝通然後給出一種分級支持的方案。把每種瀏覽器定義一個級別。然後在開發功能的時候以「漸進增強」的方式。通常來講我們的解決方案是在低級瀏覽器裡面保證流程正常進行、模塊可以使用，但忽略一些無關緊要的錯位、不透明等問題，在高級瀏覽器裡面需要對設計稿進行精確還原，適當的加上一些井上添花在細節。比如微小的動畫、邏輯細節上的處理等

舉個例子吧，下麵這個進度條表示預約的人數，它是介面非同步載入完才展示的。如果載入完就立即設置進度條寬度會顯得生硬無趣，但是如果加上一點動畫效果的話就好多了。然而問題又來了，如果加上動畫那麼邏輯上這個進度條應該是一點點的增加，對應的人數也應該是逐個增加。於是我就做了個優化，讓人數在這段時間內均勻的增加。這個細節並不是很容易被人發現，但是這種設計會讓用戶感覺很用心而且有意思

pingou
pingou

 

JavaScript

 

javascript-exec-sequence
javascript-exec-sequence

單品頁的腳本載入/執行順序：

  1. 等待頁面準備就緒（DOM Ready）
  2. 準備就緒後載入入口腳本（main.js），腳本負責其它功能模塊的調度，動態接合模塊通過 seajs 的 require.async
    方法非同步調用
  3. 公共模塊（common.js）負責加初始化全局變數並掛載到 pageConfig 命名空間
  4. 動態模塊數組，這個是後端通過程式判斷處理生成的一個模塊名列表。一般只包含首屏需要載入的模塊
  5. 後載入模塊（lazyinit.js）初始化，這個腳本只做一些頁面滾動才載入的模塊事件綁定。當模塊出現在視口內再使用 require.async 非同步載入模塊的資源及初始化

入口腳本

大致代碼如下

/**
* 模塊入口（1. 公共腳本 2. 首屏模塊資源 3. 非首屏「後載入模塊」）
*/
var entries = [];

// 頁面公共腳本樣式
entries.push('common');
// 頁面使用到的首屏模塊(後端開髮根據頁面不同配置需要調用的模塊)
entries = entries.concat(config.modules);
// 非首屏「後載入模塊」
entries.push('lazyinit');

for (var i = 0; i < entries.length; i++) {
    entries[i] = 'MOD_ROOT/' + entries[i] + '/' + entries[i];
}

if (/debug=show_modules/.test(location.href)) console.log(entries);

require.async(entries, function() {
    var modules = Array.prototype.slice.call(arguments);
    var len = modules.length;

    for (var i = 0; i < len; i++) {
        var module = modules[i];

        if (module && typeof module.init === 'function') {
            module.init(config);
        } else {
            console.warn('Module[%s] must be exports a init function.', entries[i]);
        }
    }
});

註意模塊路徑中的 MOD_ROOT
是提前在頁面定義好的一個 seajs path。目的是為了把前端版本號更新的控制權釋放給後端，從而解決了前後端依賴上線不同步造成的緩存延遲問題，配置腳本中只有幾個定義好的路徑：

seajs.config({
    paths: {
        'MISC' : '//misc.360buyimg.com',
        'MOD_ROOT' : '//static.360buyimg.com/item/default/1.0.12/components',
        'PLG_ROOT' : '//static.360buyimg.com/item/default/1.0.12/components/common/plugins',
        'JDF_UI'   : '//misc.360buyimg.com/jdf/1.0.0/ui',
        'JDF_UNIT' : '//misc.360buyimg.com/jdf/1.0.0/unit'
    }
});

還有一點，在測試環境的頁面中版本號（上面代碼中的 1.0.12 是一個全量的版本號）是後端從 URL 上動態讀取的（使用參數訪問就可以命中對應版本 item.jd.com/sku.html?version=1.0.12
）。這樣以來測試環境上就可以並行測試不同版本的需求，而且互不影響。當然如果不同版本的後端代碼也有修改的話這樣是不行的，因為後端代碼也需要有個對應的版本號

不過我們已經解決了這個問題。後端會在測試環境里 動態載入後端模板 並且可以做到版本號與前端一致。這樣以來配合 git 方便的分支策略就可以同時並行開發測試多個需求，不用單獨配多個測試環境。什麼？你還在使用 SVN！哦。那當我沒說過

事件處理模型

客戶端的 JavaScript 代碼基本上都是事件驅動的，代碼的載入解析依賴於瀏覽器提供的 DOM 事件。比如 onload, mouseover, scroll 等
事件驅動的的模型特別適用於非同步編程，而 JavaScript 天生就是非同步，所有的非同步操作行為都最終會在一個回調函數（callback）中觸發

比如單品頁中價格介面，載入完成後需要更新 DOM 元素來展示實時價格；地區選擇介面載入完成後會更新配送信息、庫存/商品狀態等，偽代碼如下：

/* onPriceReady 和 onAreaChange 可以認為都是一個 Ajax 非同步函數調用
 * code 1 和 code 2 執行到的時間是不確定先後順序的
 */
/* prom.js */
onPriceReady(function(price) {
    // code 1
    $('#price').html(price);
});

/* address.js */
onAreaChange(function(area) {
    // code 2
    $('#stock').html(area.stockInfo);
});

上面的兩段代碼分別在兩個腳本中維護，因為他們的邏輯相對獨立。早期並沒有關聯關係。後來需求有變，他們之間需要共用一些對方的數據（切換地區後需要重新獲取價格數據並展示）。但是物理上又不能放在一起通過使用全局變數的方式共用，而且它們都是非同步載入介面後才取到數據的，並不好確定誰先誰後（非要做到那就只能用全局變數雙向判斷）。所以這樣並不能很好的解決問題，而且代碼的耦合度會成倍增加

這時候我們引入了一種設計模式來解決這種問題，我們把這種模式抽象成了自定義事件代碼來解決這一問題。這段代碼是由 YUI 核心開發者 Nicholas C. Zakas 實現的。代碼很簡單，事件對象主要有兩個方法 addListener(type, listener)
和 fire(event)

於是我們重構了上面的偽代碼：

/* prom.js */
// 在代碼中註冊一個地區變化事件，獲取變化後的地區 id
// 然後重新請求價格介面並展示
Event.addListener('onAreaChange', function(data) {
    getAreaPrice(data.areaIds)
});

onPriceReady(function(price) {
    $('#price').html(price);

    Event.fire({
        type: 'onPriceReady',
        data: 'Any data you want'
    })
});

/* address.js */
onAreaChange(function(area) {
    $('#stock').html(area.stockInfo);

    // 在地區變化後除了做自己該做的事情以外
    // 觸發一個名為 onAreaChange 的事件，用來
    // 通知其它訂閱者事件完成，並傳遞地區相關參數
    // 這個時候在 onAreaChange Ajax 回調函數
    // 中就只需要關心自己的邏輯，其它模塊的耦合關係
    // 交給它們自己通過訂閱事件來處理
    Event.fire({
        type: 'onAreaChange',
        data: area.ids
    })
});

需要註意的一點是，必須確保事件先註冊後觸發執行，也就是說先 addListener， 再 fire

一些典型的性能優化點

基本上客戶端的 JavaScript 性能問題都來自於 DOM 查找和遍歷，在用於的時候一定要小心，可能不經意的一個操作就會損失很多性能，尤其在低端瀏覽器中。順便多說一點，現代的 JavaScript 解釋器本身是很快的，語言層面的性能問題很少遇到。DOM 查找慢是因為 瀏覽器給 JavaScript 訪問頁面提供的一套 DOM API 本身慢

  1. 緩存 DOM 查找，同時 DOM 查找不要超過 2000 個，低級瀏覽器會卡頓

  2. 不要使用鏈式調用 find，如：find('li').find('a')
    而是 find('li a')

  3. 在切換元素顯示狀態的時候，如果元素很多。優先使用 show()/hide()
    方法，而不是 css('display', 'block/none')
    前者有緩存，後者會強制觸發 reflow

  4. 給節點添加 data-xx
    屬性在存放一些數據，通過使用 jQuery 的 data('xx')
    方法取更高效，減少 DOM 屬性訪問

  5. 高密度事件（scroll, mousemove）觸發場景請使用節流方法
    6.使用事件代理，而不是直接綁定。如果不確定代碼被調用次數，可以先解除綁定再綁定具有命名空間的事件處理函數

  6. 儘量少用 DOM 動畫，使用 CSS 3 動畫代替

前端工程化

原由

前端工程化其實並不是最近兩年才有的概念。大約在 2013 年的時候 Grunt 問世的時候就已經有所涉及。這類打包工具主要的目的是自動化一些開發流程，我最早使用 Grunt 來構建代碼的時候只解決了三個問題：

  1. 合併壓縮優化樣式腳本
  2. 上線完自動備份
  3. 單個文件打包到多目錄（歷史原因一個文件線上的路徑有兩種，需要傳兩個目錄）

其實這些工具出現的原因是：當時前端領域的各種基礎設施很缺乏，而前端的工作內容又相對零散。工作時需要開很多的軟體。再加上 JavaScript 語言本身也很弱，就連包管理這種基礎的東西也沒有內置，以至於模塊化要通過一些第三方類庫來實現，比如：RequireJS, SeaJS

現狀

如今前端工程的生態環境由於 NodeJS 的出現已經變得很好了。你可以根據自己的需求選一個合適的直接用到項目裡面。像 Grunt, Gulp, browserify, webpack 等。不過要明白這些工具的出現從另一方面證明瞭前端開發天生存在很多的問題：

  • HTML 從誕生到 HTML 5 之前幾乎沒有任何變化，DOM 性能天生缺失。所以才有了 Virtual DOM 這種東西

  • CSS 只是一門描述型的語言，沒有變數、邏輯控制、語句。所以才出現了 Sass, Less 這種預編譯工具

  • JavaScript 號稱「高階的（high-level）、動態的（dynamic）、弱類型的（untyped）解釋型（interpreted）編程語言，適合面向對象（oop）和函數式的（functional）編程風格」的編程語言，但是語言本身有很多問題（ES 6 之前）。不適合大型項目的開發、沒有一些高級特性的支持、同時被其它語言詬病的 callback 風格、單線程執行等。所以才出現了像 TypeScript, Babel 這種編譯成 JavaScript 代碼的語言

這些問題幾乎都是歷史性的原因和相容性因素造成的。作為一名好的前端工程師要看清楚現狀，然後按自己項目的需求去定製一些前端工程化的方案，而不是隨波逐流。

選擇

其實現在自己開發一套前端工程化/自動化流程的成本已經很低了，你只需要學習一些 NodeJS 的知識，配合 NPM 包管理機制，隨手就搞出一個構建工具出來。因為並不需要你去實現什麼東西，所有的東西都有現成的包。腳本壓縮有 UglifyJS，CSS 優化有 CSS-min，圖片壓縮優化有 PNG-quant 等等。你只需要想清楚自己要達到什麼目的，解決什麼問題就可以抄家伙自己寫一套工作流出來

我自己的經歷也從 Grunt, GulpJS 到現在自造輪子。自己根據需求開發出來一套集成的打包工具，當然你也可以不用任何打包工具，自己寫一些 NPM Script 來完全定製化項目開發/測試/打包流程。我猜這也是為什麼現在類似 Grunt 不再那麼火，Gulp 遲遲沒有發佈 4.0 版本的原因。寫一個構建工具的成本太低了，而且這種集成的工具很難滿足差異的開發需求。

程式、設計、產品

我始終認為程式、設計是為了產品服務的。好的產品是要重視設計的，好的（前端）工程師是要有一些審美素養

其實很多時候技術解決方案都是要根據產品的定位來設計的，瞭解產品需求以後才能定製出真正合適的高效的解決方案。好比前面講到的那個 sprite 案例，如果一開始就和產品討論好方案後來也不可能有那種失控的情況發生。在產品形成/上線前期能發現問題比上線後發現問題更容易解決

這部分內容和代碼無關，就不多說了。

總結

關於單品頁的前端開發本篇文章只是冰山一角，還有很多沒有提及，每個小東西都可以單獨寫一篇文章來分享。隨後希望可以有更多的總結和分享


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • flush it! 關於數據緩衝區
    之前對python的標準輸入輸出關註不多，所以在碰到flush的時候有了諸多疑惑。 本文記錄了和flush方法相關的緩衝的相關內容，供學習參考。 數據緩衝 在電腦科學中，數據緩衝(data buffer)是一個當數據需要從一個地方移到另一個地方時，用來暫時保存數據的物理區域。常見的情況是，當輸入數 ...
  • java中的異常（一）
    java異常的概念 執行期的錯誤（javac xxx.java） 運行期的錯誤（java xxx） 這裡講的是運行期出現的錯誤 上面這段代碼的輸出結果是3 為啥12沒列印出來呢？System.out.println(arr[4])這段帶代碼想獲取數組中的第五個元素但是沒有所以報錯了直接執行了catc ...
  • Celery 源碼解析三： Task 對象的實現
    Task 的實現在 Celery 中你會發現有兩處，一處位於 celery/app/task.py，這是第一個；第二個位於 celery/task/base.py 中，這是第二個。他們之間是有關係的，你可以認為第一個是對外暴露的介面，而第二個是具體的實現！所以，我們由簡入繁，先來看看對外的介面：其實... ...
  • Java 商戶管理系統 客戶管理 庫存管理 銷售報表 SSM項目源碼
    系統介紹： 1.系統採用主流的 SSM 框架 jsp JSTL bootstrap html5 (PC瀏覽器使用) 2.springmvc +spring4.3.7+ mybaits3.3 SSM 普通java web（非maven, 附贈pom.xml文件） 資料庫：mysql 3.開發工具：my ...
  • 設計模式詳解（1）----------策略模式
    策略模式，顧名思義就是設計一個策略演算法，然後與對象拆分開來將其單獨封裝到一系列策略類中，並且它們之間可以相互替換。首先LZ舉一個例子為大家引出這一個模式。 例子：某公司的中秋節獎勵制度為每個員工發放200元，現在我們設計一個員工基類， 然後讓公司各個職位繼承它。（普通員工GeneralStaff 項 ...
  • 第5章 引用類型---JS紅寶書書摘系列筆記
    在ECMAScript中，引用類型是一種數據結構，用於將數據和功能組織在一起，描述的是一類對象所具有的屬性和方法。而對象是某個特定引用類型的實例。 一、Object類型 可以通過Object構造函數創建一個創建Object實例，但常用方式是使用對象字面量表示法，這種方式可以簡化創建包含大量屬性的對象 ...
  • css偽類的說明以及使用(css事件)
    CSS偽類的使用(css事件) 轉載請註明源地址:http://www.cnblogs.com/funnyzpc/p/7670959.html 之前有開發開發App的時候，有同事問我那個列表的條目按下去背景會變成淡黃色的效果是怎麼做的，然後我若無其事的說了句：用CSS事件啊。。。╮(￣▽￣)╭，然後 ...
  • 中英文金額大寫轉換器
    因為自己大學畢業以後一直從事網上銀行的開發工作，所以工作中經常遇到把金額轉化為大寫的情況。起初只有人民幣一種幣種，將金額數字翻譯成中文大寫的形式在各種票據中很常見，時至今日依然還在使用，在網路上很容易能找到翻譯的代碼。而最近在開發“貿易金融”的需求時，涉及到進口信用證的開立功能，而進口證的申請書中除 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類