賀師俊，網(wǎng)頁(yè)中鼠標(biāo)點(diǎn)擊與javascript的click事件怎么區(qū)分

來(lái)源：整理時(shí)間：2024-11-05 00:29:17 編輯：智能門戶手機(jī)版

1，網(wǎng)頁(yè)中鼠標(biāo)點(diǎn)擊與javascript的click事件怎么區(qū)分

先是鼠標(biāo)點(diǎn)擊dom元素，觸發(fā)js里面click方法，再執(zhí)行方法里面的邏輯。直接使用js里面click()方法相當(dāng)于模擬鼠標(biāo)點(diǎn)擊。并無(wú)什么太大區(qū)別。

如果只是在 jquery 里的話，可以判斷 e.originalevent 是否存在。不在 jquery 里，可以判斷 clientx, pagex 之類的坐標(biāo)屬性是否為零。當(dāng)然，對(duì)于第三方腳本通過 document.createevent() 和 dispatchevent 觸發(fā)的事件，如果他們也偽造了這些坐標(biāo)值，就不太有什么辦法了。只能依賴瀏覽器更底層的安全策略，即 @賀師俊說的 dom level 3 標(biāo)準(zhǔn)， event.istrusted 。這個(gè)屬性目前只有 firefox 和 ie 9+ 支持。并且 ie 上的支持還不完全。

網(wǎng)頁(yè)中鼠標(biāo)點(diǎn)擊與javascript的click事件怎么區(qū)分

2，知乎上有哪些 JavaScript 高手

提供一些名字給你。不過有些是記不得了。winter，樸靈，元彥，賀師俊，寸志，Jim Liu，題葉，月影，祖明，董必正，司徒正美，大漠，小芋頭君，拔赤，死馬，豪情，貘吃饃香，張?jiān)讫?，小爝，顧軼靈，趙望野，張克軍，愚人碼頭，堂主，Cat Chen，情封，一絲，玉伯。vue.js 尤雨溪。他們都屬于在知乎上比較活躍，并且能帶來(lái)很多新知識(shí)和思路的前輩。也可以看看他們以前的回答，必有收獲。

winter，樸靈，元彥，賀師俊，寸志，Jim Liu，題葉，月影，祖明，董必正，司徒正美，大漠，小芋頭君，拔赤，死馬，豪情，貘吃饃香，張?jiān)讫?，小爝，顧軼靈，趙望野，張克軍，愚人碼頭，堂主，Cat Chen，情封，一絲，玉伯。vue.js 尤雨溪。他們都屬于在知乎上比較活躍，并且能帶來(lái)很多新知識(shí)和思路的前輩。也可以看看他們以前的回答，必有收獲。

這個(gè)問題就好像在問，百度知道上js誰(shuí)最牛一樣再看看別人怎么說的。

知乎上有哪些 JavaScript 高手

3，現(xiàn)在網(wǎng)頁(yè)設(shè)計(jì)中的為什么少有人用 11px13px15px 等奇數(shù)的字體

偶數(shù)字號(hào)相對(duì)更容易和 web 設(shè)計(jì)的其他部分構(gòu)成比例關(guān)系。比如：當(dāng)我用了 14 px 的正文字號(hào)，我可能會(huì)在一些地方用 14 × 0.5 = 7 px 的 margin，在另一些地方用 14 × 1.5 = 21 px 的標(biāo)題字號(hào)。Windows 自帶的點(diǎn)陣宋體（中易宋體）從 Vista 開始只提供 12、14、16 px 這三個(gè)大小的點(diǎn)陣，而 13、15、17 px 時(shí)用的是小一號(hào)的點(diǎn)陣（即每個(gè)字占的空間大了 1 px，但點(diǎn)陣沒變），于是略顯稀疏。這個(gè)我不確定，需要確認(rèn)：聽說有不少字體的 hinting 都只專門處理了常用的幾個(gè)偶數(shù)字號(hào)。除了上面說的這些，奇偶字號(hào)的字體渲染效果似乎其實(shí)差別不大（尤其在 OS X 和 Linux 以及手持設(shè)備上）。即使在 Windows 里，微軟雅黑在 11 至 17 px 之間的奇偶字號(hào)效果似乎也都差不多。（呃，都差不多糟糕……）目前 12、13、14、15、16 px 其實(shí)都是很不錯(cuò)的正文字號(hào)。知乎和豆瓣的正文字號(hào)都是 13 px，而中文維基百科的正文字號(hào)是 15 px，并沒有什么不好。另，@賀師俊指出：早期的 Windows 里，中易宋體點(diǎn)陣只有 12 和 14、15、16 px，唯獨(dú)缺少 13 px。

px好像是代表像素

這些字體顯示不好看,一般用12 14 16的Arial tahoma 宋體等

如果用奇數(shù)，各個(gè)瀏覽器的解析不是一樣的。不好看。最好用偶數(shù)，一般網(wǎng)頁(yè)字體都是12px；如果不設(shè)置，瀏覽器默認(rèn)是16px

現(xiàn)在網(wǎng)頁(yè)設(shè)計(jì)中的為什么少有人用 11px13px15px 等奇數(shù)的字體

4，前端架構(gòu)師是一種怎樣的存在

1，我比較認(rèn)同的有winter和賀師俊還有張?jiān)讫堖@三位。其他沒提到的可能我不太關(guān)注，高手很多，但是能達(dá)到架構(gòu)師的其實(shí)不多，最多算是高工，或者某一領(lǐng)域?qū)I(yè)的牛人，我覺得就像前3位提到的大神，他們的編碼能力過硬，算法能力，計(jì)算機(jī)基礎(chǔ)知識(shí)都沒的說，許多回答都是干貨，有理有據(jù)，show me code風(fēng)格的，而且解答不會(huì)模糊，直接簡(jiǎn)要，能做到這些必須是肚子里有貨，我覺得這算是硬件基礎(chǔ)。2，編碼能力好，熟悉各項(xiàng)標(biāo)準(zhǔn)，算法好，API熟練，就能成為前端架構(gòu)師了么?不不，這些只能說你是個(gè)高工，你說你自己寫了許多框架和開源包，各種功能，前后端都有？no no no，也是最多算是高工而已。至少我是這樣認(rèn)為，為什么呢？因?yàn)槟悴鹊目記Q定了你架構(gòu)的能力，你的硬件基礎(chǔ)只決定了你遇坑之后的解決能力。打個(gè)比方，前端工作3年，一直在電商領(lǐng)域，或者一直在做sns，或者一直在做webview里的開發(fā)，這種經(jīng)驗(yàn)是不具備前端架構(gòu)能力的，什么？都是寫js？沒區(qū)別？錯(cuò)了，你讓一個(gè)寫了3年電商框架的人去寫一個(gè)斗魚tv或者搜狐視頻試試，寫是能寫出來(lái)，但是選型問題真不會(huì)是最佳，因?yàn)樗鹊目右欢]有專注這個(gè)領(lǐng)域的人多。什么是架構(gòu)能力？其實(shí)說白了就是幫助最后項(xiàng)目順利開發(fā)完成，易擴(kuò)展，好維護(hù)，有規(guī)范，能解決一些剛開始人看不到的麻煩。這些能力都是從一個(gè)一個(gè)真實(shí)得項(xiàng)目中鍛煉出來(lái)的，而不是說只做了一家公司的一個(gè)項(xiàng)目之后就可以說自己是前端架構(gòu)師了。。說的比較亂，其實(shí)簡(jiǎn)單比方就是個(gè)經(jīng)驗(yàn)包的問題，你的經(jīng)驗(yàn)比你的技能更大的決定了你的架構(gòu)能力。3，溝通表達(dá)能力，這個(gè)其實(shí)不是特別重要，但是單獨(dú)拿出來(lái)說，就是因?yàn)槿绻愕南敕ú荒茉趫F(tuán)隊(duì)有效的執(zhí)行下去是不行的，你必須也一定是最后說服團(tuán)隊(duì)使用你的方案的人。所以最后，回到up主問的問題上來(lái)。從一個(gè)前端工程師，如何根據(jù)目標(biāo)，制定計(jì)劃，前端架構(gòu)師需要涉及哪些知識(shí)點(diǎn)，還有哪些知識(shí)點(diǎn)是前端工程師所不具備的。希望知友提點(diǎn)。沒什么知識(shí)點(diǎn)，你必須對(duì)你要做的東西有經(jīng)驗(yàn)，至少是做過1-2次（公司級(jí)項(xiàng)目），這才是架構(gòu)師的價(jià)值，如果你根本沒做過同類的工程，你有什么資格去架構(gòu)他呢？現(xiàn)學(xué)現(xiàn)研究那只是高工而已。至于題目問的如何成為一個(gè)前端架構(gòu)師，我覺得那些已經(jīng)被很多人叫成前端架構(gòu)師的人，自己都不覺得自己算是吧，只是入行久一點(diǎn)，活的長(zhǎng)一點(diǎn)，經(jīng)驗(yàn)多一點(diǎn)，做的項(xiàng)目雜一點(diǎn)，跳槽次數(shù)猛一點(diǎn)，比你努力一點(diǎn)而已。

前端架構(gòu)師具備的知識(shí)：1、精通javascript的面向?qū)ο缶幊蹋炀氄莆兆饔糜蛞约伴]包的原理；2、有很好的優(yōu)化代碼和代碼層次結(jié)構(gòu)劃分能力，有清晰的代碼架構(gòu)思想；3、熟練使用html5、css3、html、xhtml、css等網(wǎng)頁(yè)制作技術(shù)，熟悉頁(yè)面架構(gòu)和布局；4、熟悉w3c標(biāo)準(zhǔn)，對(duì)表現(xiàn)與數(shù)據(jù)分離、web語(yǔ)義化等有較為深刻的理解；5、熟悉移動(dòng)互聯(lián)網(wǎng)應(yīng)用開發(fā)環(huán)境，對(duì)于h5在各移動(dòng)設(shè)備商的特性和應(yīng)用有較豐富的經(jīng)驗(yàn)。

我覺得架構(gòu)師是個(gè)沒有標(biāo)準(zhǔn)定義的職位，每個(gè)公司實(shí)際上的工作內(nèi)容都不太一樣?；旧暇褪且粋€(gè)負(fù)責(zé)給開發(fā)人員鋪路，防止踩雷的工作。另外作為資深技術(shù)人員，有時(shí)還有負(fù)責(zé)溝通設(shè)計(jì)、產(chǎn)品等部門，團(tuán)隊(duì)內(nèi)部負(fù)責(zé)新技術(shù)推廣，技術(shù)選型。但是也有公司回去考核架構(gòu)師的kpi……一種很傻缺的行為……架構(gòu)師的產(chǎn)出應(yīng)該是團(tuán)隊(duì)的工作效率和產(chǎn)品質(zhì)量！

5，合并HTTP 請(qǐng)求是否真的有意義

不過現(xiàn)在能更正確更理智地去看待這些事了 3次握手由于有keep-alive，一條和一百條都只需一次tcp握手--無(wú)差別；你的論斷最大的問題是這句，事實(shí)上不是這樣的當(dāng)你有100個(gè)資源時(shí)，這100個(gè)資源在瀏覽器看來(lái)是“同時(shí)都要”，而瀏覽器并沒有什么智商去判斷應(yīng)該用1個(gè)鏈接解決這100個(gè)資源，還是用100個(gè)鏈接來(lái)解決，不然瀏覽器永遠(yuǎn)都只有一個(gè)tcp鏈接了因此瀏覽器的靜態(tài)的策略是在自己可承受的范圍內(nèi)盡可能地用多的鏈接來(lái)解決，大部分瀏覽器似乎是6-8個(gè)鏈接，這就導(dǎo)致握手也是6-8次其他的如 @賀師俊老師說的，網(wǎng)絡(luò)延遲以及tcp/ip的速率協(xié)商也是很需要考慮的問題補(bǔ)充說下網(wǎng)絡(luò)延遲這東西，很多做前端的人根本不明白這一點(diǎn)，他們?cè)谟?jì)算傳輸時(shí)間的時(shí)候只會(huì)考慮到帶寬這一因素，卻絲毫不考慮延遲。我就問你一個(gè)問題：一個(gè)200m帶寬、2000ms延遲的網(wǎng)絡(luò)，和一個(gè)2m帶寬，20ms延遲的網(wǎng)絡(luò)，你喜歡哪個(gè) 實(shí)際上一個(gè)資源從客戶端發(fā)出請(qǐng)求到客戶端實(shí)際能使用的時(shí)間，排除掉dns、握手、服務(wù)器計(jì)算等，純粹資源本身和網(wǎng)絡(luò)相關(guān)的計(jì)算應(yīng)該是：網(wǎng)絡(luò)延遲 * 2 + 資源大小 / 帶寬從這個(gè)公式可以看出來(lái)，當(dāng)資源大小很小時(shí)，網(wǎng)絡(luò)延遲對(duì)性能的影響會(huì)很夸張。假設(shè)你的資源大小能在一個(gè)tcp包中傳輸，那你基本就看網(wǎng)絡(luò)延遲的臉色決定網(wǎng)絡(luò)性能了你把100個(gè)資源不合并，就意味著要享受100倍網(wǎng)絡(luò)延遲，而不合資的資源通常更小，導(dǎo)致網(wǎng)絡(luò)延遲在每一次網(wǎng)絡(luò)rou緝單光竿叱放癸虱含僵ndtrip里占比更重，會(huì)很痛苦的因此，你的“只是增多了http報(bào)文頭”這個(gè)推斷雖然正確，但其影響遠(yuǎn)不如你想象的那么小，報(bào)頭本身不大，加上gzip后更小，但是抗不住網(wǎng)絡(luò)延遲的影響，特別是3g網(wǎng)絡(luò)環(huán)境下會(huì)更嚴(yán)重當(dāng)然合并文件也是有一個(gè)限制的，這就是為啥我們?cè)谙螺d大文件的時(shí)候還是喜歡多線程下載，一般我肯定不會(huì)讓一個(gè)資源超過1m，再大就要考慮怎么切分

問題沒那么簡(jiǎn)單，首先，瀏覽器是有多連接并發(fā)進(jìn)行訪問的，同一個(gè)域名下一般是2-8個(gè)并發(fā)連接。除了合并外，Domain Hash 也是常見的優(yōu)化手段來(lái)著的。所以說，靜態(tài)資源并不一定是都放在同一個(gè)域名下的。這樣會(huì)首先導(dǎo)致三次握手要發(fā)生多次，其次是每個(gè)連接都要經(jīng)歷一次 TCP 慢速啟動(dòng)。但比起讓瀏覽器多開帶來(lái)的吞吐提升而言，這些倒都是小事了。舉例的單一連接在真實(shí)場(chǎng)景下，實(shí)際是在2-8個(gè)連接上發(fā)生的，純網(wǎng)絡(luò)部分確實(shí)如題所述，在 DNS 上、握手、服務(wù)器解析（合并絕大部分時(shí)候是用在靜態(tài)資源如 js/css 上的，通常連 upstream 開銷都沒有）上基本沒有太大區(qū)別。但發(fā)送報(bào)文、響應(yīng)內(nèi)容上都是有很大區(qū)別的。首先，在發(fā)送報(bào)文上，99次請(qǐng)求頭一般在5k-10k 左右（和主站同域名也就是沒做 cookie-less domain 的話更悲催，如果 cookie 里有512字節(jié)，那光 cookie 就50k 了），由于上下行不對(duì)稱，在 pc 上一般至少要100-250ms 左右才能傳完（國(guó)內(nèi)普遍的 512k 上行），移動(dòng)網(wǎng)絡(luò)下這個(gè)數(shù)字分分鐘可能是10-15倍以上（不要忘記移動(dòng)網(wǎng)絡(luò)丟包和延遲都要更重），也就是說達(dá)到了1-3秒左右。含512Byte Cookie 的惡劣情況下甚至可能導(dǎo)致增加10秒+的延遲。99+的頭信息在下行帶寬上的性能損耗大大低于上行，但還是有一些的，而且由于是同一個(gè)連接內(nèi)發(fā)生，也并不會(huì)有多連接時(shí)慢速啟動(dòng)所帶來(lái)的性能損耗。然而這里面造成的最大損耗是全程會(huì)出現(xiàn)更多的小包、等待和調(diào)度，即 RTT 問題被放大許多倍。在合并請(qǐng)求的前提下，客戶端發(fā)包后，服務(wù)端會(huì)持續(xù)傳輸，在寬帶下，慢啟動(dòng)調(diào)優(yōu)到合理區(qū)間后一次分組傳輸周期中發(fā)送的數(shù)據(jù)是很客觀的（initcwnd=10，mtu=1492的前提下都要發(fā)送14.5k的數(shù)據(jù)，慢啟動(dòng)完成后一般至少30k+/s的數(shù)據(jù)是很可能的）。然而，我們知道大部分的 css/js 都是小于這個(gè)尺寸的，這也就是說我們無(wú)法充分利用其傳輸優(yōu)勢(shì)，必須在串行的完成上一個(gè)請(qǐng)求的前提下才能啟動(dòng)下一個(gè)請(qǐng)求的傳輸。即，一個(gè)傳輸周期明明能發(fā)送30k+數(shù)據(jù)給客戶端，卻可能2-10k 后就結(jié)束，首先要確保所有 ACK 已收到，然后再開始等待客戶端發(fā)來(lái)下一個(gè)請(qǐng)求，這也就導(dǎo)致不能充分的利用帶寬。合并的前提下，一個(gè)分組周期內(nèi)收到數(shù)十個(gè)甚至上百個(gè)報(bào)文，只需要對(duì)最后一個(gè)序號(hào)的報(bào)文做 ACK 就可以，而獨(dú)立發(fā)送則要為了一次次中斷導(dǎo)致分組數(shù)的增多多發(fā)很多 ACK。別忘了，上面說的是寬帶的情況，移動(dòng)的情況下必然更糟。另外，這也就是為什么多開能有效提升吞吐了，因?yàn)槎嗾?qǐng)求復(fù)用單連接確實(shí)很多時(shí)候是不能充分利用帶寬的。

6，前端架構(gòu)師干什么的

前端架構(gòu)師是做網(wǎng)站前段規(guī)劃設(shè)計(jì)假設(shè)和用戶體驗(yàn)的，主要需要學(xué)習(xí)JS、HTML、XHTML、CSS等語(yǔ)言。前端架構(gòu)師具備的知識(shí)：1、精通Javascript的面向?qū)ο缶幊蹋炀氄莆兆饔糜蛞约伴]包的原理；2、有很好的優(yōu)化代碼和代碼層次結(jié)構(gòu)劃分能力，有清晰的代碼架構(gòu)思想；3、熟練使用HTML5、CSS3、HTML、XHTML、CSS等網(wǎng)頁(yè)制作技術(shù)，熟悉頁(yè)面架構(gòu)和布局；4、熟悉W3C標(biāo)準(zhǔn)，對(duì)表現(xiàn)與數(shù)據(jù)分離、Web語(yǔ)義化等有較為深刻的理解；5、熟悉移動(dòng)互聯(lián)網(wǎng)應(yīng)用開發(fā)環(huán)境，對(duì)于H5在各移動(dòng)設(shè)備商的特性和應(yīng)用有較豐富的經(jīng)驗(yàn)。前端架構(gòu)師的工作：1、負(fù)責(zé)公司前端產(chǎn)品的功能開發(fā)與其他部門的功能協(xié)調(diào)；2、負(fù)責(zé)前端架構(gòu)體系的規(guī)劃、設(shè)計(jì)、建設(shè)；3、負(fù)責(zé)部門管理工作及架構(gòu)體系的搭建；4、負(fù)責(zé)HTML5等前沿技術(shù)的研究；5、負(fù)責(zé)網(wǎng)占性能和體驗(yàn)優(yōu)化。

我比較認(rèn)同的有winter和賀師俊還有張?jiān)讫堖@三位。其他沒提到的可能我不太關(guān)注，知乎高手很多，但是能達(dá)到架構(gòu)師的其實(shí)不多，最多算是高工，或者某一領(lǐng)域?qū)I(yè)的牛人，我覺得就像前3位提到的大神，他們的編碼能力過硬，算法能力，計(jì)算機(jī)基礎(chǔ)知識(shí)都沒的說，許多回答都是干貨，有理有據(jù)，show me code風(fēng)格的，而且解答不會(huì)模糊，直接簡(jiǎn)要，能做到這些必須是肚子里有貨，我覺得這算是硬件基礎(chǔ)。2，編碼能力好，熟悉各項(xiàng)標(biāo)準(zhǔn)，算法好，API熟練，就能成為前端架構(gòu)師了么?不不，這些只能說你是個(gè)高工，你說你自己寫了許多框架和開源包，各種功能，前后端都有？no no no，也是最多算是高工而已。至少我是這樣認(rèn)為，為什么呢？因?yàn)槟悴鹊目記Q定了你架構(gòu)的能力，你的硬件基礎(chǔ)只決定了你遇坑之后的解決能力。打個(gè)比方，前端工作3年，一直在電商領(lǐng)域，或者一直在做sns，或者一直在做webview里的開發(fā)，這種經(jīng)驗(yàn)是不具備前端架構(gòu)能力的，什么？都是寫js？沒區(qū)別？錯(cuò)了，你讓一個(gè)寫了3年電商框架的人去寫一個(gè)斗魚tv或者搜狐視頻試試，寫是能寫出來(lái)，但是選型問題真不會(huì)是最佳，因?yàn)樗鹊目右欢]有專注這個(gè)領(lǐng)域的人多。什么是架構(gòu)能力？其實(shí)說白了就是幫助最后項(xiàng)目順利開發(fā)完成，易擴(kuò)展，好維護(hù)，有規(guī)范，能解決一些剛開始人看不到的麻煩。這些能力都是從一個(gè)一個(gè)真實(shí)得項(xiàng)目中鍛煉出來(lái)的，而不是說只做了一家公司的一個(gè)項(xiàng)目之后就可以說自己是前端架構(gòu)師了。。說的比較亂，其實(shí)簡(jiǎn)單比方就是個(gè)經(jīng)驗(yàn)包的問題，你的經(jīng)驗(yàn)比你的技能更大的決定了你的架構(gòu)能力。3，溝通表達(dá)能力，這個(gè)其實(shí)不是特別重要，但是單獨(dú)拿出來(lái)說，就是因?yàn)槿绻愕南敕ú荒茉趫F(tuán)隊(duì)有效的執(zhí)行下去是不行的，你必須也一定是最后說服團(tuán)隊(duì)使用你的方案的人。所以最后，回到up主問的問題上來(lái)。從一個(gè)前端工程師，如何根據(jù)目標(biāo)，制定計(jì)劃，前端架構(gòu)師需要涉及哪些知識(shí)點(diǎn)，還有哪些知識(shí)點(diǎn)是前端工程師所不具備的。希望知友提點(diǎn)。沒什么知識(shí)點(diǎn)，你必須對(duì)你要做的東西有經(jīng)驗(yàn)，至少是做過1-2次（公司級(jí)項(xiàng)目），這才是架構(gòu)師的價(jià)值，如果你根本沒做過同類的工程，你有什么資格去架構(gòu)他呢？現(xiàn)學(xué)現(xiàn)研究那只是高工而已。至于題目問的如何成為一個(gè)前端架構(gòu)師，我覺得那些已經(jīng)被很多人叫成前端架構(gòu)師的人，自己都不覺得自己算是吧，只是入行久一點(diǎn)，活的長(zhǎng)一點(diǎn)，經(jīng)驗(yàn)多一點(diǎn)，做的項(xiàng)目雜一點(diǎn)，跳槽次數(shù)猛一點(diǎn)，比你努力一點(diǎn)而已。

成為一名優(yōu)秀的web前端工程師，易龍?zhí)炀W(wǎng)認(rèn)為需要具備如下四點(diǎn)專業(yè)技能：第一、必須熟練掌握基本的web前端技術(shù)，比如：css、js、html、jquery等等。第二、必須掌握網(wǎng)站的性能優(yōu)化、seo、ue、服務(wù)器端、兼容性、存在的bug等。第三、學(xué)會(huì)用工具輔助開發(fā)。第四、有良好的代碼規(guī)范編寫習(xí)慣web前端的前景廣闊，興趣是最好的老師。加油！

成為一名優(yōu)秀的web前端工程師，易龍?zhí)炀W(wǎng)認(rèn)為需要具備如下四點(diǎn)專業(yè)技能：第一、必須熟練掌握基本的web前端技術(shù)，比如：css、js、html、jquery 等等。第二、必須掌握網(wǎng)站的性能優(yōu)化、seo、ue、服務(wù)器端、兼容性、存在的bug等。第三、學(xué)會(huì)用工具輔助開發(fā)。第四、有良好的代碼規(guī)范編寫習(xí)慣web前端的前景廣闊，興趣是最好的老師。加油！

個(gè)人認(rèn)為：構(gòu)架構(gòu)架當(dāng)時(shí)是網(wǎng)站前臺(tái)頁(yè)面的整體規(guī)劃和構(gòu)架，以及MVC設(shè)計(jì)模式，JS/Css代碼的性能優(yōu)化，提高代碼重用性，減少代碼冗余。脫離的了普通前端碼工的范疇，更注重代碼的優(yōu)化和合理性，提高網(wǎng)站的相應(yīng)速度。據(jù)說權(quán)威說一個(gè)網(wǎng)站的打開速度，前端代碼優(yōu)化后能提升97%。知道他的重要性了吧！哇，仔細(xì)一看原來(lái)是08年的帖子，看來(lái)你很關(guān)注前沿技術(shù)啊，得了拿2分走人