❶ CSS Sprite是什麼，談談這個技術的優缺點
個人簡述一下，不從網上摘抄
CSS Sprite技術所白了就是圖片拼合技術，主要是指將網頁上很多用於裝飾作用的小圖片全部整合到一張圖片內，減少網頁載入時的HTTP請求並發數，頁面載入時利用CSS中的背景圖片定位屬性background-position來指定需要顯示這張大圖上指定位置的部分
使用這個技術的優點就是減少頁面載入時的瞬間HTTP請求並發數，提高了載入速度
缺點是這些被整合到一張圖片的各種小圖案後期維護修改比較麻煩，修改任意一個小圖案都需要修改這張整圖，同時還需要注意小圖片在這個整圖上的位置不能改變
❷ Web Components是什麼和其他的前端開發方式有什麼優缺點
Web Components 是組件規范，但還沒有足夠多的瀏覽器支持，目前只有chrome34+支持。
簡單介紹：
Web Components的組件開發者在一個獨立的沙箱（shadow dom）當中開發組件(包含：dom,css,js)
而組件的使用者則可以通過:
<slider>
<frame><img src="1.jpg"/></frame>
<frame><img src="1.jpg"/></frame>
<frame><img src="1.jpg"/></frame>
</slider>
這樣的自定義標簽來使用組件，就像瀏覽器原生支持的一樣。
❸ 使用CSS 預處理器的優缺點有哪些
缺點：
簡單來說CSS預處理器語言較CSS玩法變得更高級了，但同時降低了自己對最終代碼的控制力。更致命的是提高了門檻，首先是上手門檻，其次是維護門檻，再來是團隊整體水平和規范的門檻。這也造成了初學學習成本的昂貴。
優點：
用一種專門的編程語言，為CSS增加了一些編程的特性，將CSS作為目標生成文件，然後開發者就只要使用這種語言進行編碼工作。通俗的說，CSS預處理器用一種專門的編程語言，進行Web頁面樣式設計，然後再編譯成正常的CSS文件，以供項目使用。CSS預處理器為CSS增加一些編程的特性，無需考慮瀏覽器的兼容性問題，例如你可以在CSS中使用變數、簡單的邏輯程序、函數等等在編程語言中的一些基本特性，可以讓你的CSS更加簡潔、適應性更強、可讀性更佳，更易於代碼的維護等諸多好處。
❹ css sprite是什麼，有什麼優缺點
CSS Sprites在國內很多人叫css精靈，是一種網頁圖片應用處理方式。它允許你將一個頁面涉及到的所有零星圖片都包含到一張大圖中去，這樣一來，當訪問該頁面時，載入的圖片就不會像以前那樣一幅一幅地慢慢顯示出來了。對於當前網路流行的速度而言，不高於200KB的單張圖片的所需載入時間基本是差不多的，所以無需 顧忌這個問題。
加速的關鍵，不是降低重量，而是減少個數。傳統切圖講究精細，圖片規格越小越好，重量越小越好，其實規格大小無所謂，計算機統一都按byte計算。客戶端每顯示一張圖片都會向伺服器發送請求，所以，圖片越多請求次數越多，造成延遲的可能性也就越大。
CSS Sprites原理
CSS Sprites其實就是把網頁中一些背景圖片整合到一張圖片文件中，再利用CSS的「background-image」，「background- repeat」，「background-position」的組合進行背景定位，background-position可以用數字能精確的定位出背景圖片的位置。
CSS Sprites優點
利用CSS Sprites能很好地減少了網頁的http請求，從而大大的提高了頁面的性能，這也是CSS Sprites最大的優點，也是其被廣泛傳播和應用的主要原因；
CSS Sprites能減少圖片的位元組，曾經比較過多次3張圖片合並成1張圖片的位元組總是小於這3張圖片的位元組總和。
CSS Sprites缺點
誠然CSS Sprites是如此的強大，但是也存在一些不可忽視的缺點
在圖片合並的時候，你要把多張圖片有序的合理的合並成一張圖片，還要留好足夠的空間，防止板塊內不會出現不必要的背景；這些還好，最痛苦的是在寬屏，高解析度的屏幕下的自適應頁面，你的圖片如果不夠寬，很容易出現背景斷裂；
CSS Sprites在開發的時候比較麻煩，你要通過photoshop或其他工具測量計算每一個背景單元的精確位置，這是針線活，沒什麼難度，但是很繁瑣；幸好騰訊的鬼哥用RIA開發了一個CSS Sprites 樣式生成工具，雖然還有一些使用上的不靈活，但是已經比photoshop測量來的方便多了，而且樣式直接生成，復制，拷貝就OK！
CSS Sprites在維護的時候比較麻煩，如果頁面背景有少許改動，一般就要改這張合並的圖片，無需改的地方最好不要動，這樣避免改動更多的css，如果在原來的地方放不下，又只能（最好）往下加圖片，這樣圖片的位元組就增加了，還要改動css。
CSS Sprites非常值得學習和應用，特別是頁面有一堆ico（圖標）。總之很多時候大家要權衡一下利弊，再決定是不是應用CSS Sprites。
❺ web前端工程師的優點和缺點
優點：HTML5APP可以在PC和移動、iOS和Android上運行。
缺點：在對性能要求較高的情況下，或選擇使用本機開發知識。
實現此目的的最佳方法是混合方法，大型框架使用本機、基本功能等，一些模塊使用HTML。Web前端工程師：使用（X）HTML／CSS／JavaScript／Flash等各種Web技術開發的客戶端產品。
Web前端工程師：完成客戶端程序（即瀏覽器端）的開發，開發JavaScript和Flash模塊，結合後台開發技術模擬整體效果，富InternetWeb開發，致力於通過技術提升用戶體驗。
Web前端工程師：對Web2．0、HTML＋CSS和瀏覽器兼容性有深刻的理解。了解其他IT編程語言，如PHP、Java、．net和vue。
(5)css前端開發優缺點擴展閱讀：
掌握以下技術：
1．掌握基本的web前端開發技術：HTML、CSS、JavaScript、DOM、BOM、AJAX等，了解其與不同瀏覽器的兼容性、渲染原理及bug
2．必須具備網站性能優化、SEO和伺服器端開發的基本知識
3．必須學會使用各種web前端開發和測試工具來輔助開發嗎
4．除了技術知識之外，還需要理論知識，包括代碼的可維護性、組件的易用性、分層語義模板和瀏覽器分層支持
5．未來的web前端開發工程師還將學習HTML5、web視覺設計、網站色彩搭配、網站交互設計模式等相關技術
網路--web前端工程師
❻ div+css與table+css的優缺點
作為一個身處 2008 年末的 Web 設計師，你是否好意思承認自己的代碼中使用了 Table，如果是，你是一個有勇氣的人，Web 設計是個奇怪的行業，你可以將自己的網站設計得像晚報的分類廣告，或者樓道里的開鎖廣告，但千萬別讓人知道你使用了 Table，在你的源代碼中發現 Table 就像一個銷售被人掀起褲腳發現穿了白襪子一樣。
Table 是如此醜陋，臃腫，哪怕只顯示一段簡單的內容，你也需要 <table><tr><td> 這三個基本的標簽，每個標簽裡面還要加上一堆亂七八糟的屬性，不像<div>，既簡單，又整潔，又時尚，它和 CSS 珠聯璧合，琴瑟和諧，它們構成最完美的 Box 模型，他們象現實中的箱子，你把東西放進去，然後，很自由地對他們進行排列，厭煩了一種布局，沒關系，簡單地改動一下 CSS 定義，一種全新的布局便誕生了；不象 Table，Table 像食堂里的餐具櫃，一排排，一列列，土裡土氣，油膩膩的，象我們的父輩，邋遢，什麼都往家裡拿，胡亂堆在角落裡，如果 Div 是小資，Table 就是老三屆，他們不屬於這個時代。
也就是近幾年的事，至多不過三五年，W3C是一個人人都認為重要但人人都不喜歡的組織，他們的官方網站十分醜陋，我敢說平生沒見過這么醜陋的網站，但他們的網站是為數不多的可以通過全部W3C標准驗證的網站，這意味著，他們的網站在語法上，在結構上，在可訪問性上是完美的，雖然依舊十分醜陋。不過這是笑談，W3C非常重要，否則微軟會把全體 Web 開發工程師帶到萬劫不復的境地，還好，Netscape 死後，涅磐出 Firefox，而 Opera 在 Firefox 橫空出世之後雖然沒得到任何好處，至少得到了精神上的支持，看到沒，終於有大哥出來收拾你。喬布斯復出後，蘋果重返昔日的光芒，這時人們才知道世界上還有一個叫做 Safari 的瀏覽器，所有這一切加在一起，讓 W3C 真正有了存在的必要。
W3C 說，Table 可以用來容納文字，格式文字，圖片，鏈接，表單，以及其它 Table ... 但是，Table 不應該單純用來做網頁布局（Tables should not be used purely as a means to layout document content），理由是，當 Web 被非可視化設備渲染的時候，Table 會出現問題，他們指定是屏幕閱讀器以及盲文瀏覽器，另外，Table 在大型顯示設備上會強迫用戶左右滾動，因此，Web 設計者應該使用 CSS 而不是 Table。參見 W3C HTML 4.01 關於 Table 的定義。 W3C 說這段話的時候，是1999年12月24日，那時盡管 CSS 早已誕生，但並沒有多少人使用，最初的 Web 像一個在線版的文檔，並沒有成為現在這樣的平台，不需要過多過多地考慮布局問題，隨著互聯網第一次泡沫的形成，涌現出大量的門戶網站，門戶網站是 Table
布局的始作俑者，因為他們的首頁比一整份報紙的所有版面拼接在一起還復雜，Table 在這方面十分順手，結合 colspan 和 rolspan，你幾乎能夠實現任何復雜的版面。
這種布局風格在2000年代初，一直到中期仍然十分流行，尤其國內，在大為美的潛意識下，人們把所有能塞到一個頁面的東西都塞進了首頁，Table 就像一個舊時代的管家，把所有東西雖不能井井有序，但至少是一樣不少地編排起來。然而這樣的 Web 終於到了讓人厭惡的地步，隨著搜索，RSS 訂閱，以及以博客為代表的個性化 Web 的出現，人們有更多渠道獲得信息，而不必去訪問那幾個讓人幾乎要暈過去的門戶的首頁，於是出現了一種清新的，輕量的 Web 風，使用更簡單的布局，更明快的配色，大圖標，大 Banner，以及更容易閱讀的大字體，同時，在這個時候，CSS 已經非常成熟，而 Firefox, Opera, Safari 為代表的瀏覽器，在遵守 W3C 標准方面要遠遠好過 IE，人們終於認識到 CSS 的威力。因為 CSS 在布局上，其核心是一個 Box
模型，人們必須為 CSS 找一個可以依附的容器對象。
Div 成為幸運者一方面因為它天生就是 Box 的最佳原型，在語義上，Div 代表頁面的一個區域，在外形上，它四四方方，更重要的是，它不像 <P> 或 <a> 那樣事先已經被賦予特殊的語義（雖然它們也能用於 Box 模型）；另一方面，則出於人們對 Table 統治一個臃腫時代的憎惡，一個時代的結束，繼任者都會努力抹去舊時代的痕跡，那些舊時代的象徵或代表的命運多半如此，人們並不是簡單地忘卻它們，而是斷然劃清界限。
Table 的一切不公平待遇就此開始。為什麼說不公平，W3C 不建議 Table 布局的時候，只說應使用 CSS 代替，這是什麼意思，Table 不支持 CSS 嗎？當然支持，而且，由於 Table 作為老牌的 HTML 對象，它的地位曾如此重要，任何瀏覽器都對 Table 提供了最完美的支持，包括 CSS 支持。當人們擁抱 Div 的時候，似乎忘記了 Table 也是 Box，而且是一個擁有多個內格的 Box，Table 作為一個整體，和 Div 在 Box 模型方面沒有任何區別，而它的內格，除了 Margin 之外，仍然是一個 Box，內格不含 Margin 概念這是應該理解的。Div 很優秀這不必說，然而當人們說 Div + CSS 的時候，似乎暗示著 Table 無法 CSS，這是天大的誤會。
Div 支持的所有 CSS 屬性，Table 全部支持，事實上，在 Div 大紅大紫之前，那些 Div 的早期採用者曾信心不足地表示，Table 能做到，Div 都能，而他們也為自己的話付出了代價，企圖在 Div 中實現垂直居中的人明白我的意思，企圖在 IE6 中不經 CSS Hack 而實現 100% Div 布局的人更明白我的意思。100% Height 問題，幾個 Div 之間的寬度自適應問題，相信任何從事 Div + CSS 設計的人會遇到。Table 在這方面的優勢並不是因為它本身多麼優秀，而是因為它老牌，沒有瀏覽器敢忽視，也因為它的特性原本如此，人們發明表格，是因為希望數據顯示得整齊，就這么簡單。然而，為什麼 Table 後來背上那麼多的惡名？Div 擁護者對 Table 的責難不外乎以下幾條。
代碼臃腫：你至少需要寫下 <table><tr><td>這三個標簽之後，才能開始真正的內容，另外，Table 的各種標簽中還包含了復雜的屬性定義，而 Div 只需 <div>一個標簽。
頁面渲染性能問題：瀏覽器需要將整個表格完全讀完後才會開始渲染。
不利於搜索引擎優化：搜索引擎喜歡內容與修飾分開。
可訪問性差：屏幕朗讀軟體和盲文瀏覽器無法很好地理解 Table 中的內容。
不夠語義（Semantic）：我們需要語義的 Web。
第1條：代碼臃腫
首先，Table 裡面唯一無法用 CSS 定義的屬性只有 Cellspacing, Cellpadding 幾個，其它屬性都可以並且應當使用 CSS，這樣，剩下的，就是 <table><tr><td> 和 <div> 的對決，我相信一個動輒幾十K大小的網頁，即使使用了幾十個 Table，因此多出來的代碼也可以忽略不計，那些埋怨 Table 代碼臃腫的人其實該檢查自己的編碼習慣，能將 Table 寫得十分臃腫的人，寫 Div 相比也未必會簡潔到哪裡。
第2條：頁面渲染性能問題
我使用一台2004年的筆記本電腦，1.6G 的 CPU 與 1G 內存，這種配置下，看不出 Table 布局和 Div 布局在頁面渲染上有任何速度差別，其實這點差別即使有，相對網路本身的延遲也可以忽略。
第3條：不利於搜索引擎優化
如果你盡可能使用 CSS 而不是 Table 的屬性，前面說了，產生的代碼和 Div 的差別也不會很大，搜索引擎會歧視 <table> 標簽嗎，這種說法的依據我至今並沒有找到。
第4條：可訪問性差
這是 Table 固有的缺陷，不過多數 Div + CSS 的擁躉似乎並不是基於這個原因才排斥 Table。
第5條：不夠語義
語義 Web 的含義要深遠得多，並不是僅僅在 Table 和 Div 上糾纏，即使 W3C，也並沒有規定 Table 只能用來顯示表格數據，很多在 Table 的語義上進行糾纏的人，其實不妨再等等 HTML 5，那才是真正的語義。
本文的目的不是讓你丟棄 Div 投身 Table，相反，如果 Div 能滿足你的設計需要，Div 仍是首選，但沒必要避諱 Table，否則會走入另外一個極端。很多使用 Div 無法簡單實現的設計，仍可以使用 Table，當然，不管使用什麼，都應該用 CSS 將內容與修飾分離。Div + CSS 和 Table + CSS 都是合法的設計，誰更簡單就用誰。根據我的經驗，當你能預見你的內容的格式，對你即將加入的內容有能力完全控制其顯示格式時，應當使用 Div + CSS；當你即將加入的內容是不固定的，你無法預見其格式，如果不想讓頁面坍塌，使用 Table + CSS 是一種保險的做法。
❼ Div+Css和Table功能實現各有什麼優缺點
DIV與TABLE本身並不存在什麼優缺點，所謂web標准只是推薦的是正確的使用標簽，好比說：DIV用於布局，而TABLE則本來就是轉二維數據的。讓TABLE做該做的事，並不是說頁面里不出現TABLE就是多麼多麼牛。
用DIV進行排版的優勢就是我不說，大家應該都比較清楚。DIV是標准，是大勢所趨，但並不意味著所有的頁面都適合用它來做。
中國的門戶和國外的有很大的區別，中國網民並不喜歡信息量少的頁面，YAHOO到了中國頁面上的內容就多了不少，而上次改為簡潔的頁面後訪問量下降的厲害以至於沒過幾天就又改了回來。正式由於中國的國情造就了搜狐、新浪這樣門戶。
為什麼DIV不適合他們？下面我從幾個方面來逐一說明：
精簡代碼：
大家都說DIV的布局精簡代碼，但是用DIV替代TABLE所節約的代碼又被CSS（樣式）所佔用，而這些樣式大多用於控制DIV的排版布局。那你會說了，CSS可以放在外部重用啊，要想得到這個問題的答案請往下看。
重用性與下載量：
統一使用一個.css的樣式表文件，可以實現修改一次，全站修改的效果，這樣使得維護的成本更低。但是請大家換一個角度想，如果所有頁面在載入時都要訪問一個文件，那這個文件每天的下載量，特別時在搜狐、新浪的網站平台上將達到幾億次，這就需要後面有很多台前端web伺服器在做支撐，那後台的成本無形中也提高了很多。如果後台支撐沒有做好，那麼頁面就會出現花屏，之前所作的工作也是白費。很多人會問，這樣的幾率太小了。我們所作的工作就是為了避免這一兩次意外的發生，如果意外發生了，對於門戶後果將是不堪設想的。
HTTP通訊：
統一的樣式表文件採用外部調用的形式，這樣每次載入單個頁面都會多一次對伺服器的http請求伺服器都會增加一次響應，這樣對前端web伺服器會是很大的消耗。而原來很長時間都是將css和js寫在頁面前端（大家可以看看sohu和sina的頁面，大多都是採用這樣的形式），而不是作為外部調用的形式，也是為了盡量避免給伺服器增加消耗。
頁面緩存：
每次用戶訪問的頁面，都會在瀏覽器緩存中保存一定時間，以保證用戶下次再訪問該頁面時能夠大大提高頁面顯示速度。而每次修改都會使頁面重新下載，對於每個外部導入的樣式文件也是如此，如果CSS文件修改，那麼訪問網站的每一個頁面都會重新下載，而以往的將樣式寫在頁面中的方式，只是修改的頁面需要重新下載。
兼容性：
對於CSS（樣式表）並不是所有瀏覽器的所有版本都支持的很好，比如IE5以前的瀏覽器對於CSS的支持就不是很好。而現在使用IE5以前版本瀏覽器的用戶不在少數，這樣就使得在頁面製作的過程中需要針對不同瀏覽器版本進行測試，以保證兼容性，無形中也增加很多工作量（至少我接觸的開發人員製作div頁面比table頁面的標准時間要長一些）。
橫切與延展性：
橫切——傳統的布局方式為了使頁面下載的更快，把頁面自上而下分成若干個塊，但是往往採用DIV進行布局的頁面都會出現這樣的情況，由於每塊中間欄或者其他欄內容條數不固定導致兩邊欄目沒有同時自適應，而出現留白。
相比之下傳統的table方式更容易規避這樣情況的發生。
以上我們只是討論某一技術在某一領域的可用性，而非技術本身。
說了這么多並不是說DIV這種布局方式不好，而是說我們應該正確的看待Table在以內容為基礎的大型門戶中的作用，而不是人雲亦雲。之所以DIV的布局方式沒有在大型網站應用，不是說門戶沒有用DIV是技術落後，是裡面的人沒有前瞻性，而是多種原因決定的。網易之所以全部採用DIV的方式是因為內容並不是他們主攻方向。而對於其他門戶來說，這樣的決策是要靠時間來驗證的。只是現在這個時機還不成熟而已。
❽ 為什麼 Web 前端開發不拋棄 HTML 和 CSS，用純 JavaScript 開發
首先要確定，即使拋開游戲不論，一般的Web應用或者網站，完全用JavaScript開發也是可行的。比如ExtJS、webOS的Enyo等。但是主流Web開發很少採用全JS的方案。原因大體有以下幾點：
1. 注重考慮那些無法運行JS的用戶代理。
用
戶使用不支持JS的瀏覽器（比如較老的手機瀏覽器），或者禁用腳本。當然你可以選擇忽略這一小撮用戶，尤其是現在絕大多數網站和應用也是如此選擇的，但是
至少我們應該對堅持考慮無JS情況的開發者予以基本的尊重。此外，如 Mobile
Transcoder或某些手機瀏覽器的「極速模式」是基於伺服器端對網頁的解析和重組，是否能支持JS很夠嗆。
更重要的因素是SEO friendly。如果是全JS生成的網頁，搜索引擎無法索引內容。這一點對於許多網站是性命攸關的。
注意，有人提到screen reader。但絕大多數讀屏軟體是根據DOM來的，因此全部由JS生成DOM也不會有問題。然而這前提是JS所生成的DOM是符合accessibility要求的。
2. 注重HTML/CSS本身的優點。
誠然JS本身也可以通過精心設計的框架和庫來實現分離等所有HTML/CSS模型的優點。但是存在許多不確定因素：
1) 有足夠好的框架和庫嗎？
要
考慮是否能滿足你的業務需求，還可能要考慮性能、可擴展性、之前提到的accessibility、學習曲線、工具鏈，乃至此框架和庫的長久的生存（有人
維護，修bug、加新功能比如對HTML5新API的支持之類的）。關鍵是，理論上說JavaScript具有更高的彈性，但是更大的自由度未必能得到更
好的
2) 框架和庫給出的抽象模型和HTML/CSS模型的阻抗是否匹配？
假如該框架或庫本質上仍然使用HTML/CSS模型，只是改變了語法（比如從markup改為json），那麼其提供的好處在哪裡？僅僅是語法統一？
如
果該框架或庫有自己獨立的抽象層，比如widget/component等，那麼它是建築在HTML/CSS之上的額外抽象層（即最終映射到HTML
/CSS），還是僅僅以HTML/CSS為純粹實現工具？對於前者，實際上最終會回歸HTML/CSS模型。而後者，可以參考的經驗教訓就是http://ASP.NET WebForm和JSF。
3) 框架和庫所設定的約束能否在開發中一以貫之的執行？
無
論是理論或者現實，HTML/CSS模型都算不上完美。但是至少是清晰和較容易被一致的執行的。但是單一語言即使提供分層機制，也容易被繞過——尤其是框
架和庫本身不夠好的情況下，可能由於不能滿足需求、有bug等情況而傾向於hack之，更不要說deadline緊迫時。
3. 注重性能。
須
知，最終Web應用、頁面是在瀏覽器中執行，而瀏覽器完全是按照HTML/CSS所設計。拋開Canvas不論，純JS的實現最終還是要生成DOM。從性
能的角度看，純JS生成DOM自然趕不上直接的markup。同樣的道理，就算用CSS預處理器也都會在部署時預先編譯——盡管在運行時可以做出更牛逼的
特性（然而實際上目前我不知道有任何CSS預處理器幹了這樣的事情——因為它們都是按照預編譯的場景設計的），再如HTML/CSS是按照漸進顯示優化的
（頁面不用全下載完就可以看部分），而純JS的架構沒有精心設計是很難做到的（比如json數據全部下載完你才能parse，數據才可用，DOM才能生
成）。
［補充：盡管LESS是可以在運行時執行的，但是從性能的角度出發是不合適的，因為CSS通常必須在頁面rendering之前就全部就位。而運行時產生CSS，
就要求在頁面rending之前至少要先下載執行LESS的腳本，然後解析編譯你的.less源代碼。這個性能開銷至少目前還不容忽視。］
［補
充：性能優化的另一點是基於HTML/CSS的聲明性特點，即只表明high-level的目標，瀏覽器才能獲得更大的優化自由度。比如CSS
transition/animation，與JavaScript通過修改style達到效果比，前者性能表現要好得多。］
4. 注重Web開發的獨特特點。
1) HTML/CSS 都是聲明式的，也就是其本身並不希望是程序員來編程。當然，一個編程語言能幹所有的事情，但是即使考慮編程本身，為什麼在通用編程語言之外還要有SQL、還有以各種語法寫的配置文件？
2) HTML/CSS是基於標準的。這與http://ASP.NET WebForm、JSF、Flash/Flex等私有技術或一個語言和平台下的標准有天壤之別。具體就不展開了。
3)
Web開發和一般應用開發有個重大區別是，Web應用、網頁的最終表現和行為，或者說Web的用戶體驗，並不是完全由開發者決定的，而是開發者和用戶共同
決定的。用戶選擇不同的設備、不同的瀏覽器、不同的瀏覽器設置、不同的瀏覽器擴展等，都能影響結果。這是缺點，也是優點。看你如何體會了。這里具體不展
開。只是一點，純JavaScript開發通常表示你想更多的控制用戶體驗，但這並非簡單的多寫代碼就能做到。
❾ CSS 的預處理程序分別都有哪些優缺點
LESS/SASS優點：
開發速度提升；
代碼優化效率提高（對開發者而言）；
代碼更通俗易懂（對開發者而言）；
維護簡單便捷；
代碼更干凈，優美；
功能更多更強，CSS做出JS的特效（其實就是JS）；
總而言之，LESS/SASS就是CSS裡面的jQuery，簡化，減少開發時間，提升開發者開發體驗。
LESS/SASS缺點：
舍棄用戶體驗來提高開發的效率，可以查考Bootstrap的缺點；
舍棄網頁打開速度換取開發效率提升；
需要一個學習的過程，用之不當反而弄巧反拙；
總而言之，LESS/SASS缺點就是需要多一個編譯器來重新編譯一次你的CSS代碼，也就是給瀏覽器多了一道工序，網頁顯示的速度會減慢（網頁顯示順序，從上至下，一般CSS放在頭部，先HTML DOM元素-->CSS-->腳本文件-->頁面元素如圖片，視頻，音頻--->最後完全顯示）
你在CSS工序加了一個步驟，速度自然慢，時間自然多了。
什麼網站適合LESS/SASS，企業網站，個人網站，普通靜態頁。
如果淘寶用了LESS/SASS，估計淘寶每年會失去至少5千億成交額