Sea.js作者發布微博: 應該給 Sea.js 和 KISSY 也樹一塊墓碑了。 為啥啊?過時了嗎?

貌似阿里好多輪子啊,哈哈

Dubbo也是吧?怎麼不繼續為開源做貢獻了啊?又要造個"輪子媽"?

-----------------------------------------------------------------------------------------------------

留著補充位置

-----------------------------------------------------------------------------------------------------


因為過時了。

所謂的過時,並不是指現在就不能用了,而是說出現了明顯更加先進的理念(或者標準),這會導致未來它的使用場景大為減少,整體趨勢已經步入衰落。

隨著Web相關標準的推進,有很多框架(庫)都過時了。比如:

JavaScript新的模塊標準導致了SeaJS和RequireJS的過時

原生選擇器的良好支持,導致人們對jQuery不再那麼依賴

Array和Object上面一些新特性的出現,導致underscore和lodash的作用減弱

與此同時,一些專註於做shim或者polyfill的庫反倒會比較時髦,因為它們的定位非常明確:扶上馬,送一程。

然後,Angular,Backbone,Knockout,這一大票東西,除非革自己的命,否則全部過時了。

再來看看Kissy,這也是一個時代的產物,在同一個時期,都很多類似YUI或者jQuery UI的東西,然而,它們都衰落了,不再適應新的時代。我們將來不需要用那樣的方式編寫前端框架,不需要用那樣的方式編寫界面組件,永遠不要停下自己的腳步。

中堂大人教導我們:一代人做一代人的事情。上一代前端框架/庫都已經基本完成使命了,讓我們默默記住並懷念它們。

(再次強調,過時、衰落,都代表著下降趨勢,而不是說你現在就不能用了,仍然會有合適的場景,比如你要支持ie6之類,在你的場景沒有與時俱進之前,技術選型也是不能與時俱進的。將來宣傳上有偏差,是要負責任的……)


記得今年杭州D-DAY玉伯說過能夠親眼看到seajs死掉也是一種幸福。一個大而全的前端框架,功能越做越多,迭代難度也會越來越大。其實小而美挺好的。


最近正在做基礎技術的改造,有點心得。

隨著ES6和node的發展,原本看起來非常優秀前衛的設計,反倒成為了一種累贅。

Y.add怎麼樣也無法轉到define上,Y.use本質上也和require相去甚遠,更大的問題是,無法使用社區的資源。

目前來看基於commonjs或者web component的技術方案更加開放,也是目前嘗試的改造方向,為了向前兼容也做了很多奇怪的hack,不過不知道是不是又是下一個輪迴,如果是的話,又是一個巨大的坑。

總之,不論多完美的技術方案,總是要不斷更新,才能適應越來越複雜的未來場景。


SEAJS最大的問題是CMD規範吶,你要搞CMD搞一個兼容AMD的規範啊?我去SEAJS社區反饋這個問題,我說jQuery這些AMD庫都不能直接被SEAJS載入,能不能考慮兼容一下?你猜他們咋說的,他們說:你改一下jQUERY源碼吧。。你改一下源碼。。你改一下把。。。


至少目前來說,Flex仍是活躍項目,微軟官方仍然支持SIlver Light,在各自的市場里仍然是有應用的,特別是Flex,有許多Flash的老用戶,立碑可能過早了。

YUI是不太一樣的,作為基礎庫在和jQuery的早幾年競爭里就沒有優勢,不是技術的原因,而是市場的認同度,直覺上YUI從來沒有真正有過jQuery生態系統的影響力。

SeaJS在國內開發社區里是有相當影響力的吧,個人沒有用過,但看過文檔,清晰的中文文檔我覺得是有競爭力的,不是所有的項目都必須要用最新的理念、方法和技術的,哪怕是Web Component真正成熟以後,也不見得社區里日常工作是實現功能的大多數開發人員必定要去追求,這是有一個過程的;產品和項目的角度更重要的是做什麼,而不是怎麼做,開發管理人員總是會青睞成熟,穩定經過檢驗的工具的,因為成本低。

況且在瀏覽器里的開發,要等到HTML5,ES6+生態系統的真正成熟還需要時間吧。


前端這塊,ECMAScript是標準了(JavaScript2015),anguar為迎合它出了angular2,react也是積極擁抱它,並且眾多的轉換工具,如babel等,npm上眾多的包也在迎合它,都有相應的es6支持。

ECMAScript不是即將到來,而是我們已經身在其中~


我覺得,對於小公司,年輕人來說,造輪子是能力的鍛煉么


前端造那麼多東西,最終還是為產品服務,那麼多人愛造輪子是個好事,但是從壞的一方面來講,就會導致產品需要不斷的迭代更新,迭代就會帶來更多的維護成本,這樣的話,一個產品的開發周期相當於被無限拉長,只要技術一發生更新,項目就得重構,接著又從好的一方面來看,不斷的重構會讓前端崗位一直處於供需平衡狀態,為了你不會下崗,就讓他們造輪子的人折騰去吧。反正都是js,怎麼折騰都逃不出前端工程師的手掌心。


「瀏覽器」、「語言」、「標準」進化了,polyfill的使命就結束了


看見了就無責任的說點不正能量的唄

反正偶心理陰暗

還是有名的招人煩

====== 高能預警 射鵰粉阿里粉seajs粉 kiss粉千萬別看 =======

結合內截圖的上下文意思

阮大師的說三塊墓碑漫畫裡頭

flex silverlight yui

基本上都是國際范兒

多少也是全球範圍內的一方諸侯

咱牛逼的射鵰老闆緊接著來一句

seajs kiss 也可以樹一塊兒了

擺明就是蹭名氣么

暗示這倆他經過手的東西起碼跟 flex silverlight yui 這三傢伙一個范兒的

重量級的說

同時還有後話是

反正這些東西已經賺夠了本錢

可以無責任拋棄了

簡直是聰明的不能再聰明了


前端發展太快唄,而且蠢人太多口味奇怪,盛產hacker或是ninja什麼的,誰都不服誰,誰家生存都不易。


kpi時代的產物,kpi每年一更,第二年就可以拋棄了,反正晉陞了,換kpi了,以前的東西跟自己也就不相關了


1、Node的標準是commonJS

2、國際標準是ES6,它有自己的模塊化標準

自然,順應歷史的潮流,你需要的是一個標準,一個全世界程序員能夠共同溝通、共同構建的標準。對於JS的發展而言,這無疑是件好事。

而其他一切的臨時方案,必然是發展道路上的一道回憶,可能以後甚至不會被記起。JS雖然已經20年了,但其實它的發展才開始,只有百花齊放,才會探索出一條正確的道路。

這就是大前端的必然。。。


現在的趨勢是前端越來越傾向於工程化開發,angularjs這一mv**框架奠定了很大一部分基礎。前端不再是用css和js畫頁面,而是用angular完成任務邏輯,後端只完成web service api,後端更注重後端,前端更注重前端,這種分離開發是非常好的。而隨著css3的出現,yui等框架逐漸被bootstrap和原生功能代替,很明顯已不再滿足時代需要。


感覺一直追趕的SeaJS已死 · Issue #1605 · seajs/seajs · GitHub


不說seajs,說說KISSY。

KISSY坑多,文檔爛,API比較難用,作者也跑路了(去支付寶,留下沒怎麼推廣的KISSY5和一堆坑)。除了阿里淘系之外,估計外部基本上沒什麼公司會選用這個框架,但是淘系在比較長的時間內還是沒法擺脫它,因為大部分業務都是依賴KISSY,而且業務非常多,不可能一下子都遷移到那些新的技術方案。

所以,即使這些框架在外部「過時」了,在大公司內部還是很有用的。


都已經2017年5月了,我們項目還打算用seajs 現在應該用什麼技術?


seajs,作者連域名都不續了。


感慨!好多東西還沒用就已經過時了


前端發展太快,必須跟上腳步


推薦閱讀:

在不刷新交互網站點擊鏈接,路由器能識別的出來嗎?
這個界面的導航欄是怎樣適配的,web界面和手機界面時候不一樣是用了什麼標籤還是怎樣的?

TAG:前端開發 | JavaScript | SeaJS |