但凡從事互聯(lián)網(wǎng)的人基本都會寫幾行 html，用過 Word 的人用 Dreamweaver 也能做出規(guī)整的頁面，所以大部分人會很自然地認(rèn)為“頁面的開發(fā)沒什么技術(shù)含量，很簡單”。不僅有這種普遍的認(rèn)知，對從業(yè)者來說也有很多疑惑：做頁面前端實(shí)現(xiàn)，沒問題；兼容性，小 case；圖片集成，一直都在用……還能有什么問題？瓶頸啊、天花板啊、轉(zhuǎn)型啊、出路啊就在從業(yè)者中廣泛討論。是不是真的沒什么問題了呢？網(wǎng)易郵箱前端技術(shù)中心也設(shè)立好幾年了，似乎有著討論不完的話題，也經(jīng)常會有一些新的想法讓大家為之一振。那么頁面開發(fā)還有哪些要求，還要做些什么，這里面的水有多深，讓我們舀舀看。

在不同的時期對頁面前端的看法似乎是多變的。在互聯(lián)網(wǎng)早期的時候，小車還是比房子貴的，燒餅和粉絲還只是用來吃的，菊花還只是用來泡茶的。那時的頁面設(shè)計(jì)風(fēng)格相對單一，對應(yīng)的頁面需求比較簡單，并且當(dāng)時的瀏覽器也基本是 IE6 的天下，javascript 也只是網(wǎng)頁的代名詞，HTML 頁面本身沒有引起太多人的關(guān)注，似乎只要能用 div 甚至 table 加 css 輔助把圖片定好位，把頁面內(nèi)容預(yù)留好就 OK 了，并且這種觀念存在了很長一段時間。隨著頁面內(nèi)容的豐富，設(shè)計(jì)風(fēng)格的發(fā)展，交互復(fù)雜性的增加，AJAX 的應(yīng)用，瀏覽器的更新?lián)Q代，又讓大家重新對最基本的頁面本身重視起來。然后熱議的就是瀏覽器的兼容性，碰到問題最熱衷的就是滿網(wǎng)絡(luò)搜索 hack，順便再罵罵 IE6、7……當(dāng)這些都做一遍后，似乎又遇到了瓶頸，又開始尋找出路。我們就從這個階段開始說起。

實(shí)現(xiàn)效果圖是最基本的工作

把視覺稿通過頁面代碼的方式表現(xiàn)出來包含了兩個基本訴求：1.能夠真實(shí)反映視覺稿；2.能夠通過瀏覽器的兼容。這兩個訴求的達(dá)成需要我們有追求細(xì)節(jié)的態(tài)度和一定的頁面功底，能完成這兩個內(nèi)容就可以初步進(jìn)入頁面前端的從業(yè)者行列了，但這就代表著我們可以勝任頁面開發(fā)的工作了？不，才剛剛開始！

與設(shè)計(jì)師的溝通和項(xiàng)目的參與

溝通很重要。先拋出幾個問題：我們有沒有和設(shè)計(jì)師探討過某些效果對低端瀏覽器渲染效率影響比較大？有沒有探討過部分效果可以用 CSS3 實(shí)現(xiàn)從而使得結(jié)構(gòu)更加簡潔清晰？有沒有在代碼和視覺中尋追求過平衡？頁面前端的開發(fā)向基本用戶，編寫的代碼也直接作用在瀏覽器上，我們有義務(wù)對頁面的穩(wěn)定性和渲染效率負(fù)責(zé)。我們也經(jīng)常碰到項(xiàng)目在總體進(jìn)度壓力下導(dǎo)致的設(shè)計(jì)與頁面前端開發(fā)同步進(jìn)行，這時更有必要盡量多地獲取項(xiàng)目信息，了解我們還要做些什么，這些可以幫助我們充分考慮重用和框架拓展。

良好的頁面結(jié)構(gòu)

頁面結(jié)構(gòu)的編寫好比蓋房的地基建設(shè)，其好壞會直接影響到 CSS 代碼的質(zhì)量、js 開發(fā)、后臺開發(fā)還會影響到以后的頁面拓展、迭代和頁面調(diào)整。拿到視覺稿后，不要忙著動手開始，多觀察思考。先分析布局，劃分框架，然后規(guī)劃結(jié)構(gòu)，編寫代碼。特別在大型項(xiàng)目中，合理使用模塊化的開發(fā)不論從整體進(jìn)行還是拓展維護(hù)都有相當(dāng)大的好處。

關(guān)于 hack

很多同學(xué)在頁面開發(fā)時上網(wǎng)搜索最多的就是 hack 了，是否我們完全要依賴 hack 來實(shí)現(xiàn)頁面兼容性，答案是否定的。大家經(jīng)常比喻 IE6 向我們?nèi)隽艘粋€謊，結(jié)果我們要再撒一百個謊來圓這個謊。不否認(rèn) IE6 經(jīng)常讓我們口吐鮮血，但不代表我們用更多的“謊言”來彌補(bǔ)就可以心安理得。大部分情況下可以通過變換思路調(diào)整 HTML 結(jié)構(gòu)，或使用一些雖然無法解釋但相對安全的 css 來干掉 hack。誰都無法預(yù)計(jì)使用 hack 什么時候會讓我們栽一個大跟頭。比如觸發(fā) layout 或 position:relative 就可以幫助解決很多 IE6 的問題。

優(yōu)美的代碼

現(xiàn)在很多 web 項(xiàng)目功能復(fù)雜，代碼規(guī)模也會變得很龐大，如何更好地進(jìn)行協(xié)同開發(fā)和維護(hù)是我們面臨的一個問題。需要考慮完善統(tǒng)一的規(guī)劃，還有要養(yǎng)成良好的代碼開發(fā)習(xí)慣才會在面臨各種情況時游刃有余。翻閱頁面代碼，看到合理的標(biāo)簽使用、良好的注釋、清晰的代碼結(jié)構(gòu)、用意準(zhǔn)確的 css 不僅猶如欣賞一個藝術(shù)品，更為下游開發(fā)和協(xié)同開發(fā)降低了不小的溝通成本，我們有什么理由不去這么做呢？舉個反面例子：div 濫用是現(xiàn)在比較典型的一個問題。數(shù)數(shù)看自己使用的標(biāo)簽有多少個呢？不同的語義都該使用對應(yīng)的標(biāo)簽代碼，特別是 HTML5 提供了更豐富的語義化標(biāo)簽，它們都苦苦地在等待戰(zhàn)場上的沖鋒號，讓我們?nèi)ソ夥潘鼈儼桑?/p>

無障礙頁面開

可訪問性與易用性是非常主觀且人性化的東西。普通人看上去上完美呈現(xiàn)的頁面在特殊群體中不一定顯得那么貼心。當(dāng)盲人用讀屏軟件在頁面某個區(qū)域內(nèi)陷入循環(huán)時，我們應(yīng)該感到內(nèi)疚。只能說目前國內(nèi)的網(wǎng)站對此的重視程度還遠(yuǎn)遠(yuǎn)不夠，這就需要我們共同努力，讓更多的人感受到我們的熱情。

保障效率

作為項(xiàng)目開發(fā)中比較靠前的一環(huán)，頁面開發(fā)可能需要盡早完成為項(xiàng)目爭取時間，這就需要我們盡可能地提率。“工欲善其事，必先利其器”，除了實(shí)戰(zhàn)經(jīng)驗(yàn)和代碼習(xí)慣的形成可以幫助我們提率外，想要提高對自己開發(fā)的進(jìn)度掌控能力，還有很多輔助工具可以幫助我們進(jìn)行頁面開發(fā)。比如使用 Less 或 Sass 可以幫助我們拓展和組織 CSS，大大提高 CSS 的編寫效率增加了可維護(hù)性。比如可以通過 zen coding 的自動自動完成和自定義代碼塊讓你可以劍指如飛。甚至還見過通過自定義輸入法的代碼塊關(guān)鍵字來提升開發(fā)速度的。多多發(fā)掘一定會找到最合適自己使用的工具。

針對服務(wù)器的優(yōu)化

頁面開發(fā)也需要了解服務(wù)器的優(yōu)化，盡量減小服務(wù)器負(fù)擔(dān)。比如 css sprite 就是一個典型減小服務(wù)器請求數(shù)的例子。在網(wǎng)易郵箱的頁面前端開發(fā)中大家不停地在做著各種優(yōu)化，比如一直在尋求文件大小與服務(wù)器請求數(shù)的平衡；為了盡可能提高緩存利用率采用了補(bǔ)丁升級；對 class 名進(jìn)行了混淆壓縮避免命名過長的冗余；應(yīng)用 base64 減少請求數(shù)量等等措施。這些都是綜合權(quán)衡的結(jié)果，需要考慮各個方面整體優(yōu)化。因?yàn)楫?dāng)頁面訪問量達(dá)到一定的數(shù)量級時，再小的一點(diǎn)優(yōu)化都會達(dá)到可觀的效果，再小的問題都可能會形成巨大的災(zāi)難。

擁抱 HTML5

這是一個充滿機(jī)會的時代，HTML5時代的來臨伴隨著移動互聯(lián)網(wǎng)的興起創(chuàng)造了更大的機(jī)會，還有太多的東西值得我們?nèi)W(xué)習(xí)去發(fā)現(xiàn)。 HTML5 提供了豐富的 JS API 接口，需要我們?nèi)パ芯?；CSS3的絢麗吸引了足夠多的眼球，需要我們?nèi)パ芯浚灰苿釉O(shè)備上如何開發(fā)更加適配的頁面，需要我們?nèi)パ芯俊?/p>

Stay Hungry， Stay Foolish

水是越舀越多了，卻發(fā)現(xiàn)原來下面還深不見底，上面的內(nèi)容越是深入研究就越會發(fā)現(xiàn)更多山川需要翻越。保持饑餓狀態(tài)，用眼睛去努力發(fā)現(xiàn)發(fā)掘，不斷豐富技能才能找到定位，突破瓶頸，正所謂“唯有高屋建瓴方可水到渠成”。形成本文是因?yàn)橹昂屯杏懻摰狡款i的問題，想給自己，給頁面前端的同學(xué)一起找找定位，梳理一下思路。拿蘋果 CEO 在斯坦福演講的一句話“Stay Hungry， Stay Foolish”和大家共勉。