未來的前端web應(yīng)用技術(shù)
發(fā)表日期:2016/3/27 8:41:30 文章編輯: 瀏覽次數(shù):2463
從開始接觸互聯(lián)網(wǎng)(2009)到進(jìn)入前端開發(fā)(2011)一直到現(xiàn)在,我感受到6年前端開發(fā)來,畢業(yè)這三年絕對是我經(jīng)歷的變化最快的幾年。常常感嘆再不學(xué)習(xí)就老了,前端真的是長江后浪推前浪,前浪死在沙灘上……,作者最后一句感同身受:“未來的前端web應(yīng)用技術(shù)選型還有不小的變數(shù),身為大齡前端技術(shù)人員,一方面感慨有些自己熟知的技術(shù)逐步落幕消亡,另外一方面又看到新事物不斷出現(xiàn),以種種方式改進(jìn)和沖擊著我們的開發(fā)方式。生在這個(gè)時(shí)代是一種不幸,也是幸運(yùn)。以下為全文:
07年底,我所在的團(tuán)隊(duì)需要重構(gòu)一個(gè)產(chǎn)品,在此之前,我們的前端框架是這樣的:
使用html?Components(htc)作為基礎(chǔ)控件的實(shí)現(xiàn)方式,包括選項(xiàng)卡,樹形表格,日期選擇等控件。
在原生JS的基礎(chǔ)上作了一些簡單封裝,形成了包括表單校驗(yàn),彈出菜單(基于popup),簡單圖表(基于XML),動(dòng)態(tài)表單等功能的業(yè)務(wù)公共庫。
使用XMLHTTP作為前后端通信方式,將請求參數(shù)序列化為XML發(fā)送給服務(wù)端,反序列化之后,反射調(diào)用后端服務(wù)(Java和.net),再把返回結(jié)果序列化為XML傳輸回來,用js解析為javascript對象。這個(gè)傳輸方式從03年版本就開始使用,還在ajax概念出現(xiàn)之前,只是一直使用的是同步傳輸方式,調(diào)用的時(shí)候界面會(huì)卡死。
開發(fā)方式也是前后端分離的,前端只寫HTML和JS,后端提供接口(但并不是HTTP接口,而是服務(wù)端的類接口,然后通過一個(gè)統(tǒng)一的facade類去反射調(diào)用)。
這個(gè)時(shí)期的版本不用說,肯定都是只支持IE的,我們當(dāng)時(shí)需要兼容的瀏覽器包括IE 5.0,5.5,6,后來7出來之后還需要支持7。
這個(gè)產(chǎn)品重構(gòu)的目的是,對近幾年積累的業(yè)務(wù)需求進(jìn)行整合,并且把服務(wù)端完全遷移到Java。對于前端來說,其實(shí)不做遷移也可以,但當(dāng)時(shí)我們發(fā)現(xiàn)一個(gè)問題,F(xiàn)ireFox這個(gè)東西突然崛起了,所以,我們從原先面臨的只支持IE,變成了可能要支持跨瀏覽器。
所以我們覺得需要把這個(gè)事情做一下,因?yàn)楫?dāng)時(shí)判斷,IE的份額可能會(huì)下降到70%左右,F(xiàn)ireFox可能會(huì)占有25-30%的份額,這個(gè)兼容是有可能需要的,雖然以我們的場景,幾乎全部面向行業(yè)用戶,可以把瀏覽器限制得很死,但也有部分用戶自服務(wù)的產(chǎn)品,將來還有擴(kuò)大的趨勢。
這時(shí)候我們問題就很大了,因?yàn)榍岸说幕A(chǔ)功能面臨大改,一些校驗(yàn)之類的庫好辦,通信封裝也好辦,基于htc的控件就是個(gè)大問題了,必須全部重寫。
當(dāng)時(shí)幾個(gè)成員產(chǎn)生了熱烈的討論,jQuery那時(shí)候還沒有一家獨(dú)大,也沒有產(chǎn)生這種趨勢,可選項(xiàng)包含:
ExtJS這樣的全整合框架
jQuery,prototype,mootools,Ext Core這樣的核心js庫加外圍
在這兩個(gè)選擇里,我們排除了第一個(gè),因?yàn)殡m然看上去它很符合我們的業(yè)務(wù)場景,但我們的定制化需求比較多,不確定有能力在這個(gè)基礎(chǔ)上做定制,可控性不好。
所以我們就決定選一個(gè)核心js庫,然后自己開發(fā)外圍控件。那么,選誰呢?最終選的是prototype,因?yàn)榇蠹遗袛啵覀儾恍枰愃芻lass的機(jī)制,這樣就把后面兩個(gè)排除了,而我們不需要太多DOM方面的封裝,因?yàn)樽詈髽I(yè)務(wù)上需要直接操作DOM的東西不會(huì)很多,都會(huì)被我們封裝掉,所以又把jQuery排除了。
所以我們的需求其實(shí)也很明確,就是有一定基礎(chǔ)功能的js核心庫。然后就是在這個(gè)基礎(chǔ)上開發(fā)控件了,時(shí)間也很倉促,大約只有2-3個(gè)人,2-3個(gè)月,最后幾個(gè)東西:
數(shù)據(jù)表格
樹形表格
日期選擇(我們的日歷需求比較變態(tài),因?yàn)橛幸晾屎湍岵礌柨蛻簦詴?huì)有波斯日歷和尼泊爾日歷之類。。。)
分頁
動(dòng)態(tài)表單
國際化方案
其他一些基礎(chǔ)功能,布局指引之類
最后,因?yàn)橼s時(shí)間,這個(gè)版本的框架最終并未跨瀏覽器,部分控件的功能還是使用了IE only的特性……更致命的是,我們因?yàn)闆]時(shí)間,所以在業(yè)務(wù)開發(fā)指引上花的時(shí)間很少,這導(dǎo)致業(yè)務(wù)開發(fā)人員趕工的時(shí)候,整個(gè)就不可控了,因?yàn)槲覀兒竺孢€參與了業(yè)務(wù)開發(fā),十多個(gè)寫HTML和JS的人,被業(yè)務(wù)壓著走,壓根沒人有時(shí)間看FireFox的狀況……
后面幾年中,這個(gè)大版本被作為基礎(chǔ)版本,拉了無數(shù)分支出來,期間,面臨了IE8之類的兼容性修改,除此之外,已經(jīng)沒有機(jī)會(huì)再修改基礎(chǔ)庫的部分了。
09年底,我主導(dǎo)這個(gè)產(chǎn)品下一代版本的前端框架選型。我們現(xiàn)在回頭看這個(gè)時(shí)間點(diǎn),會(huì)發(fā)現(xiàn)很尷尬,當(dāng)時(shí)流行的,或者即將流行的所有前端方案,其實(shí)也都是第一代的理念,在現(xiàn)在這個(gè)時(shí)候,都已經(jīng)被時(shí)代大潮沖刷得死傷殆盡了。
所以我當(dāng)時(shí)非常糾結(jié),我是預(yù)見到前端這幾年的亂象的,當(dāng)時(shí)大家炒得最火的概念是什么,是HTML5,然而我看了這方面的一些資料,發(fā)現(xiàn)廣義上,更多提供的是一些功能方面的東西,或者能提升布局方式,等等,這與我們想要的東西相去甚遠(yuǎn),好比說,我們想要蒸汽機(jī)之類的東西,發(fā)現(xiàn)手里將要有的還只是各種鐵塊。
我當(dāng)時(shí)想要什么呢?想想我當(dāng)時(shí)有過什么,經(jīng)歷過什么,早在05年初,我就有了一種設(shè)想,那就是前端的全組件化開發(fā),當(dāng)時(shí)的老大問我對現(xiàn)有項(xiàng)目有什么看法,我提出了一個(gè)方案:
擴(kuò)展htc的使用場景,不限于基礎(chǔ)組件,把業(yè)務(wù)界面也全部組件化
各組件可以獨(dú)立通過XMLHTTP與服務(wù)端交互,也就是說,你把一個(gè)已經(jīng)調(diào)試好的組件加到界面之后,什么都不用管,它自己是能夠管理與服務(wù)端的通訊的,然后你只要管跟它怎么交互就行了
在此基礎(chǔ)上,考慮界面的動(dòng)態(tài)定制,像積木一樣拼裝業(yè)務(wù)界面
這個(gè)想法在當(dāng)時(shí)確實(shí)比較激進(jìn),所以當(dāng)然沒人支持。但我在05-09這幾年的開發(fā)過程中,目睹各種業(yè)務(wù)代碼的混亂,覺得可能還是應(yīng)該推進(jìn)組件化的開發(fā)理念。理念是有了,細(xì)節(jié)怎么處理呢,因?yàn)镠TML Components這一規(guī)范被廢棄之后,我發(fā)現(xiàn)現(xiàn)有的任何方案都不再能夠像原先那樣簡便地封裝組件了,如果對于業(yè)務(wù)開發(fā)人員來說,開發(fā)業(yè)務(wù)組件的代價(jià)過高,那工程成本更加不可控。
回想我們使用HTML Components的時(shí)候,開發(fā)一個(gè)組件易如反掌,就像開發(fā)普通頁面一樣簡單,只需在頭部聲明對外的屬性、方法、事件即可,樣式也是隔離的,JS作用域也是隔離的,使用起來也是非常簡單,就是一個(gè)自定義標(biāo)簽,而且是客戶端的(區(qū)別于taglib之類的服務(wù)端標(biāo)簽封裝)。
以05年時(shí)候那個(gè)產(chǎn)品的場景而言,絕大部分界面都是普通的配置和管理,每個(gè)界面的獨(dú)立性都較高,并不存在強(qiáng)集成的場景,所以是否使用組件化方式開發(fā),并不是很重要,這跟我前幾天在微博上說:“輕量級(jí)管理控制臺(tái)有至少100種做法”是一個(gè)意思。
但是后來的做的,有包括CRM和呼叫中心之類的強(qiáng)集成產(chǎn)品,不再是原先那種單菜單配置頁面了,整個(gè)產(chǎn)品幾乎就是一個(gè)菜單,然后通過各種交互去觸發(fā)一系列功能,在這種場景下,組件化就變成了一個(gè)重要的實(shí)施手段。
所以我萬般無奈,就把目光投到04年開始持續(xù)關(guān)注的一項(xiàng)技術(shù):Adobe Flex,在這個(gè)東西剛出來的時(shí)候,我曾經(jīng)預(yù)言微軟會(huì)推出一個(gè)精簡的CLR,作為瀏覽器插件運(yùn)行,與Flash平臺(tái)抗衡,后來大家看到了SilverLight,不過這個(gè)東西當(dāng)時(shí)的普及度并不好,第一代極其簡陋,第二代稍微好一點(diǎn),所以我沒有考慮它。
在2009年,Adobe Flex算是比較成熟了,帶有完善的組件化機(jī)制,生命周期管理,強(qiáng)大而易于擴(kuò)展的基礎(chǔ)控件,優(yōu)雅而強(qiáng)大的開發(fā)語言,但我當(dāng)時(shí)有判斷,這東西是一個(gè)走下坡路的平臺(tái),而且Adobe自身有很大不足,也沒有能力把它支撐和運(yùn)營好。最終,我反復(fù)權(quán)衡,仍然選擇了使用它來構(gòu)建這個(gè)版本。
所以當(dāng)時(shí)我面臨的壓力非常大,公司內(nèi)部的辯論達(dá)到白熱化,正反雙方都有相當(dāng)多的人參與,而且反對者還略多些,年輕開發(fā)者居多。在有資格參與這項(xiàng)決策的各基層管理者和技術(shù)專家組的投票來看,雙方也是基本對等的。這個(gè)爭論現(xiàn)在回頭看,很有意思,雙方考慮的事情其實(shí)不在一個(gè)層面上,從基層開發(fā)者的角度,他會(huì)從流行趨勢方面進(jìn)行一個(gè)判斷,覺得Flash必死,HTML永生,你讓我1948年加入國民黨,是何居心?
但從我們有些老員工的角度,看到的問題是由于公司開發(fā)人員水平參差不齊,導(dǎo)致很多代碼寫得非常糟糕,很難調(diào)試,也很難重構(gòu),更沒有一些全局視圖,讓我們能看到代碼的結(jié)構(gòu)是怎樣,數(shù)據(jù)的流動(dòng)又是怎樣,產(chǎn)品的質(zhì)量如何,我們覺得對于大部分低層次開發(fā)者來說,JavaScript的約束還是太弱了,這樣松散的語言在他們手里會(huì)造成開發(fā)效率極低,bug率很高。
當(dāng)時(shí)我有個(gè)比喻,我們相當(dāng)于在2000年選擇了使用Delphi。這個(gè)比喻是為了向公司高層說明,我們到底是在干什么,大家在這么激烈地吵什么。因?yàn)樗麄冸m然不一定熟悉當(dāng)時(shí)的技術(shù)方案,但都是從2000年那個(gè)時(shí)代過來的,對Delphi的盛衰還是很熟悉的。
最終我們的判斷是:5年之內(nèi),泛HTML體系的組件化方案不會(huì)有一個(gè)相對穩(wěn)定的選擇,我們是做企業(yè)軟件產(chǎn)品的,并不害怕使用的技術(shù)相對過時(shí),怕的是時(shí)常有劇烈變動(dòng),而且不能掌控。所以,打算用Adobe Flex這樣的東西,來做一個(gè)5-8年的支撐,在這段時(shí)期內(nèi),見機(jī)行事,在泛HTML體系里作一些探索,跟進(jìn)可能會(huì)流行的技術(shù),并且加以積累。另外,選擇一種輕量級(jí)的解決方案,用于構(gòu)建面向個(gè)人用戶的門戶,這條線選擇的是jQuery和BootStrap。
當(dāng)時(shí)在輕量級(jí)這條線的解決方案上,我也有一些意見,因?yàn)樵谖覀儺?dāng)時(shí)的開發(fā)團(tuán)隊(duì)中,大家對“控件”這個(gè)東西的依賴程度太高了,絕大部分人壓根不具備我們現(xiàn)在所說的前端工程師的基本能力,只有調(diào)用控件的能力。而我認(rèn)為,輕量級(jí)的場景中,應(yīng)當(dāng)嚴(yán)格控制“控件”的使用,絕大部分場景都是用基本樣式加一些DOM操作就可以做到,當(dāng)時(shí)我們的輕量場景是面向運(yùn)營商的用戶們,他們登錄上去,查詢話費(fèi),辦理業(yè)務(wù),兌換積分,購買一些服務(wù)或者禮品之類。
所以,當(dāng)我后來發(fā)現(xiàn)這樣的場景也引入了上M的js庫的時(shí)候,我的心情是非常崩潰的,后來有的團(tuán)隊(duì)考慮在這種業(yè)務(wù)場景下封裝一些服務(wù)端標(biāo)簽,這個(gè)事情我并不贊同。很多時(shí)候,我們需要去使用服務(wù)端模板之類的方式生成界面,為的是頁面性能優(yōu)化之類,但我們所在的場景,并不需要這么苛刻的優(yōu)化,頁面DOM結(jié)構(gòu)是比較簡單的,反倒是JS這塊需要嚴(yán)格控制。這么輕量級(jí)的場景,做服務(wù)端組件化的必要性也不是很大,只需引入js的模板庫就可以了。
回頭再看Flex這頭的狀況,我們用這個(gè)東西針對重量級(jí)的管理系統(tǒng)進(jìn)行開發(fā),但令人痛苦的是,絕大部分開發(fā)人員很難理解“組件化”這么一件事情,比如說,仍然保留“頁面”這個(gè)稱呼,越是老開發(fā)人員越是難改變思維,我有一次很激動(dòng)地說:我們這種模式下,哪里來的頁面?我們做的是一個(gè)軟件系統(tǒng),你可以把它理解為運(yùn)行在瀏覽器中的桌面軟件,只存在組件,不存在頁面,頁面是HTML體系中特有的稱呼。
所以,做一個(gè)全業(yè)務(wù)組件化的實(shí)踐,需要一次又一次從理念上去向業(yè)務(wù)團(tuán)隊(duì)灌輸,什么是組件,組件樹是怎樣的,組件跟數(shù)據(jù)層如何通信,組件之間如何通信等等,如何提取合適的組件,不把這些理念灌輸下去,整個(gè)產(chǎn)品也很難成功。
舉例來說,之前系統(tǒng)規(guī)劃人員增加了新模塊的時(shí)候,一般是把數(shù)據(jù)庫表結(jié)構(gòu)截圖發(fā)出來,然后最多畫個(gè)草圖表示界面,但在組件化的開發(fā)方式中,這中間至少還有一步組件規(guī)劃、整合的過程,這一步應(yīng)當(dāng)需要嚴(yán)謹(jǐn)?shù)目紤]。
我所在的基礎(chǔ)技術(shù)團(tuán)隊(duì)中,也有不少人對我們要面臨的問題看得不太清楚,把責(zé)任想得太輕。之前那種簡單的管理頁面,只需要基礎(chǔ)技術(shù)團(tuán)隊(duì)提供基礎(chǔ)組件和公共庫,公共樣式的開發(fā),但在全組件化的實(shí)踐中,做完這些事情也才完成了整個(gè)事情的30%。
除了這些,還需要對業(yè)務(wù)團(tuán)隊(duì)培訓(xùn)組件化的相關(guān)理念,需要跟蹤他們的開發(fā)過程,評(píng)審、觀察、糾偏,還需要構(gòu)建組件的管控、測試平臺(tái),否則,仍然是一種山寨的開發(fā)流程,而享受不到組件化所應(yīng)當(dāng)擁有的流水化生產(chǎn)體驗(yàn)。這一步其實(shí)沒有做下去,投入還是太少了。
這個(gè)大產(chǎn)品版本以及附屬項(xiàng)目一共有好幾十名開發(fā)人員參與,歷時(shí)2年多,雖然離我心目中的目標(biāo)還有不少差距,但在某些方面的提升是能夠感受得出來的,比如說開發(fā)效率的提升。除此之外,這個(gè)版本的美觀程度比之前所有版本都好,終于有現(xiàn)代氣息了,誰說企業(yè)用戶就都是土鱉的,甚至有一次還收到過外籍市場人員專門的郵件夸贊,這讓我們感到很振奮。
開發(fā)效率的提升另一方面還源自Flex自身的特點(diǎn),獨(dú)立于瀏覽器的插件,可以說,大部分前端開發(fā)人員都會(huì)面臨跨瀏覽器的折騰,尤其是那幾年,亂得可怕,兼容問題會(huì)把人折磨死,我們面對的客戶,從歐美到亞非拉,各種低端高端瀏覽器并存,所以我們是繞開了這個(gè)問題,而這么復(fù)雜的組件界面,如果使用傳統(tǒng)Web技術(shù),在IE6、7等瀏覽器下的性能會(huì)慘不忍睹,基于插件體系的另外一個(gè)優(yōu)點(diǎn)是,性能不受低端瀏覽器的制約,下限比較高。
在這個(gè)階段,我們實(shí)際上是做了比較取巧的選擇,但從長期角度看,還是必須回到泛HTML體系的。所以,從12年開始,我就開始考慮未來的產(chǎn)品技術(shù)選型。
在12年這個(gè)點(diǎn)上,我們能看到的東西還是比較多的,至少比幾年前有了很明顯的發(fā)展,比如說,jQuery終于一家獨(dú)大了,比如說,AMD和CMD之類js模塊封裝機(jī)制的出現(xiàn),比如說,Backbone,Knockout,Angular分別出現(xiàn)了不少使用者,比如說,ES6和Web Components規(guī)范的落地快看到曙光了。
但實(shí)事求是地說,這些所有東西加起來,開發(fā)體驗(yàn)還是比不過Adobe Flex,在重量級(jí)場景下,泛HTML體系的整合力度還是比較弱,對開發(fā)人員的技能要求也會(huì)高一些。我也關(guān)注Dart,關(guān)注TypeScript,(為什么不關(guān)注CoffeeScript,因?yàn)樗诠編缀跞侵欢甁ava的開發(fā)人員,跟Coffee的理念差別太大,推廣成本極高)。
感慨歸感慨,選型還是一直要做,只是這個(gè)選型在實(shí)際有項(xiàng)目應(yīng)用前,一直還會(huì)處于動(dòng)態(tài)調(diào)整中。
在這段時(shí)間中,我們考察了Backbone,Knockout和Angular,也持續(xù)關(guān)注了司徒正美的Avalon,最終還是比較傾向于Angular的。
傾向于Angular的主要原因是,開發(fā)團(tuán)隊(duì)經(jīng)過磨合,已經(jīng)逐步習(xí)慣了組件化的開發(fā)方式和數(shù)據(jù)綁定所帶來的開發(fā)理念的改變,Angular在這方面與Flex比較接近,學(xué)習(xí)成本很低,而且那些稍微繁瑣的配置,對于這些習(xí)慣了Java的人員來說,并非負(fù)擔(dān)。
所以,當(dāng)時(shí)我們的基礎(chǔ)技術(shù)團(tuán)隊(duì)也花了不少時(shí)間來學(xué)習(xí)Angular,看源碼,踩坑,期間,團(tuán)隊(duì)的大漠窮秋翻譯出版了國內(nèi)第一本Angular中文書籍。
我們研究Angular,還有另外一個(gè)原因。在基于Flex的這代產(chǎn)品逐步穩(wěn)定之后,又實(shí)現(xiàn)了一個(gè)二次開發(fā)平臺(tái),從數(shù)據(jù)模型的動(dòng)態(tài)定義(類似ORM),到規(guī)則、流程、服務(wù)的動(dòng)態(tài)定義,再到界面的可視化配置,動(dòng)態(tài)的數(shù)據(jù)綁定。這個(gè)平臺(tái)的有些方面考慮是不夠成熟的,尤其是動(dòng)態(tài)界面這塊,細(xì)節(jié)不展開了。
所謂的動(dòng)態(tài)數(shù)據(jù)綁定,指什么呢,其實(shí)核心機(jī)制類似于Angular的這種綁定關(guān)系。在Flex體系中,數(shù)據(jù)綁定是通過Proxy機(jī)制實(shí)現(xiàn)的,對POJO有一定程度的封裝,比如Object就封裝為ObjectProxy,而Array封裝為ArrayCollection。我們當(dāng)時(shí)需要?jiǎng)?chuàng)建的是:基于單個(gè)用戶(或者會(huì)話)的數(shù)據(jù)聯(lián)動(dòng)體系。
這個(gè)是什么意思呢,對于某個(gè)登錄用戶來說,他所可能擁有的全部數(shù)據(jù)結(jié)構(gòu)是可預(yù)測的,絕大部分是平級(jí)關(guān)系,沒有關(guān)聯(lián),部分存在聯(lián)動(dòng)關(guān)系,我們要做的就是把這些關(guān)系描述出來,用可視化的形式配置,掛接在ORM機(jī)制上作為外殼,并且提供給業(yè)務(wù)流程、業(yè)務(wù)規(guī)則和動(dòng)態(tài)界面作為綁定數(shù)據(jù)源。
這個(gè)數(shù)據(jù)的定義和描述機(jī)制,用現(xiàn)有技術(shù)類比,就好像是Meteor或者Relay,但當(dāng)時(shí)我們對有些東西沒有考慮清楚。因?yàn)閷τ谀硞€(gè)用戶而言,他的所有數(shù)據(jù)結(jié)構(gòu)與界面上的組件結(jié)構(gòu)是無關(guān)的,這意味著,如果不把數(shù)據(jù)做拆解傳遞,一旦遇到組件樹上的不同層級(jí)指向數(shù)據(jù)源同一位置之類的情況,就不好辦。因?yàn)槲覀兘M件之間也是不共享數(shù)據(jù)的,類似現(xiàn)在的React。所以我們當(dāng)時(shí)的問題就是數(shù)據(jù)中間層設(shè)計(jì)得不好。
以我們當(dāng)時(shí)的設(shè)計(jì),其實(shí)是適合Angular這種機(jī)制的,Angular里面,不同層級(jí)的組件之間,數(shù)據(jù)可以有穿透,比如說你在最頂層綁定了一個(gè)dataStore,在隔了很多級(jí)的葉子節(jié)點(diǎn)上仍然可以綁定到dataStore.a.b這樣的數(shù)據(jù),這個(gè)a.b數(shù)據(jù)路徑可以與葉子節(jié)點(diǎn)在組件樹上的路徑毫無關(guān)系。
在這個(gè)過程中,我還是一直在嘗試考慮基礎(chǔ)框架與組件化業(yè)務(wù)開發(fā)的結(jié)合,包括整個(gè)組件和數(shù)據(jù)的規(guī)劃流程,管控機(jī)制等,也寫了幾篇文章,現(xiàn)在回頭看,有一些不成熟的地方,另外有些東西當(dāng)時(shí)覺得有坑,但正好被近期出現(xiàn)的新技術(shù)填平了。
舉例來說,當(dāng)時(shí)我覺得,不管是AMD還是CMD,都是在JS模塊自身代碼中聲明依賴項(xiàng),如果是出現(xiàn)代碼路徑調(diào)整之類的情況,這些依賴項(xiàng)的變更就是個(gè)問題,所以我設(shè)想了一種類似npm的方式,用數(shù)據(jù)庫集中存放依賴關(guān)系,模塊自身的內(nèi)容不維護(hù)這個(gè)關(guān)系,然后構(gòu)建階段生成出來。
今年看到Webpack,里面提到module,bundle,entry chunk之間的關(guān)系,感到已經(jīng)差不多把我當(dāng)時(shí)考慮的那些東西全部做到了,社區(qū)的力量真是強(qiáng)大啊。
在之前爭論Flex方案的時(shí)候,反對方的有些觀點(diǎn)很典型,比如:Flex代碼編寫之后還需要編譯,JS的不用。但其實(shí)最近幾年我們看到,Web應(yīng)用的開發(fā)過程逐漸離不開構(gòu)建環(huán)節(jié),不可能再像十年前那樣,寫完代碼之后,最多只做下壓縮就上線了,那是一種很原始的生產(chǎn)方式,所以,從這個(gè)方面看,組件化、構(gòu)建過程,這些都是現(xiàn)代富Web應(yīng)用開發(fā)方案中必不可少的部分,已經(jīng)逐漸被廣泛接受了。最近兩三年,業(yè)界對前端工程化的關(guān)注度也已經(jīng)比以前高很多了,令人欣慰。
前面這些年,我們還有一個(gè)大的缺陷,那就是一直對異步編程模型關(guān)注太少了,在早期我們一直使用同步的XMLHTTP,后來到了用Flex的時(shí)候,改用異步的HTTP通信,使用AMF協(xié)議傳輸數(shù)據(jù),我們的經(jīng)驗(yàn)仍然停留在使用回調(diào)函數(shù)這種初級(jí)的方案上,間或使用事件,并不知道任何跟promise之類理念相關(guān)的東西,所以代碼有不少很不優(yōu)雅,這個(gè)跟眼界有關(guān),還是缺少學(xué)習(xí)所致。
現(xiàn)在距離09年底已經(jīng)整整6年過去了,回頭看來,6年前可能接觸到的任何前端領(lǐng)域的框架或者庫,到今天都已經(jīng)全部是過時(shí)的。這6年時(shí)間,我們可能積累出一些經(jīng)驗(yàn),但大部分東西都不可避免地失效了,這就是野蠻生長期的痛。
這6年里,我們看到AMD,CMD這些模塊機(jī)制逐步流行,然后又突然衰落,Angular為代表的前端MV*框架橫空出世,帶給前端社區(qū)巨大的沖擊,React挾組件化和Virtual DOM之力快速崛起,你方唱罷我登臺(tái),亂花漸欲迷人眼。
兩年前我從之前公司離職,心中充滿迷茫,未來的Web技術(shù)會(huì)怎樣發(fā)展,重型Web應(yīng)用應(yīng)當(dāng)采用怎樣的整體方案去建造,自己并不能說出一個(gè)精確答案。今天我們再要考慮未來的Web應(yīng)用技術(shù)選型,已經(jīng)沒有兩年前那么迷茫了,這兩年仍然在持續(xù)學(xué)習(xí),持續(xù)思考,每次面臨選型,還是如履薄冰,一再審視項(xiàng)目類型,人員狀況。
未來的前端Web應(yīng)用技術(shù)選型還有不小的變數(shù),身為大齡前端技術(shù)人員,一方面感慨有些自己熟知的技術(shù)逐步落幕消亡,另外一方面又看到新事物不斷出現(xiàn),以種種方式改進(jìn)和沖擊著我們的開發(fā)方式。生在這個(gè)時(shí)代是一種不幸,也是幸運(yùn)。毛主席教導(dǎo)我們:三天不學(xué)習(xí),不如劉少奇。說到底,保持學(xué)習(xí)和思考,是現(xiàn)在這個(gè)階段最該做的。舊技術(shù)雖然消亡了,但它們留下的思維啟發(fā)永在。
后記:最近一直有種沖動(dòng),想把過去十年(2005-2015)時(shí)間所經(jīng)歷的一些事情總結(jié)一下,昨晚開始寫,今天中午完善了一下,大致寫完,意猶未盡,與大家共勉。
原文鏈接:10年來感受的前端技術(shù)變化?版權(quán)所有,轉(zhuǎn)載時(shí)請注明出處,違者必究。
注明出處格式:前端開發(fā)博客 (http://caibaojian.com/10years-web-frontend-tech.html)
------北京網(wǎng)站建設(shè)公司 ?北京傳誠信------
-
免費(fèi)SSL證書申請網(wǎng)站topssl.cn上線
日期:2024-09-23 瀏覽次數(shù):1089
-
如何在北京順義尋找一個(gè)踏實(shí)的網(wǎng)站建設(shè)公司
日期:2023-08-10 瀏覽次數(shù):4142
-
順義網(wǎng)站建設(shè):北京順義網(wǎng)站建設(shè)的優(yōu)點(diǎn)
日期:2023-05-25 瀏覽次數(shù):4565
-
選擇網(wǎng)站公司需要考慮哪些因素
日期:2023-05-25 瀏覽次數(shù):3425
-
北京模板建站
日期:2023-03-28 瀏覽次數(shù):3606
-
2019年的網(wǎng)站設(shè)計(jì)如何
日期:2019-06-12 瀏覽次數(shù):2320
-
HTML5性能問題可能來自多方面.
日期:2015-07-16 瀏覽次數(shù):2937
-
您可能犯過的或者這在犯得9個(gè)網(wǎng)站SEO錯(cuò)誤
日期:2019-03-04 瀏覽次數(shù):2239
-
網(wǎng)站優(yōu)化_您應(yīng)該為您的企業(yè)創(chuàng)建博客嗎?
日期:2019-08-01 瀏覽次數(shù):2801
-
如何讓你的網(wǎng)站與眾不同
日期:2018-12-12 瀏覽次數(shù):2376
北京大學(xué)-北京北大新世紀(jì)集團(tuán)
北京大學(xué)旗下教育集團(tuán) 網(wǎng)站建設(shè) 網(wǎng)站制作