TypeScript 的命運會不會和 CoffeeScript 一樣 ?
我只知道 TypeScript 和 Flow 至少會死掉一個,也有可能都死掉。
CoffeeScript 死掉的原因是它解決的問題 ES6 逐步解決掉了,但解決的方式又不完全一樣,導致大家都必須在 CoffeeScript 和 ES6 之間做一個選擇。儘管短時間內兩者都需要轉譯,但最終瀏覽器都會支持 ES6 但不會支持 CoffeeScript,所以大家就選擇了用 ES6。學會了 ES6 之後,隨著時間推移標準普及,在瀏覽器 console 可以直接用,在 Node 也可以直接用,這 CoffeeScript 就完全處於劣勢了。
同樣的事情將來可能會再發生一次,大家依然會選用 ES 標準化的結果,而不是標準出現之前的各種事實標準,但這也正是標準存在的價值。利益相關的各方進行討價還價後最後達成共識,做一件對所有人都更有利的事情。CoffeeScript雖然也是JavaScript友好語言,但其語法借鑒ruby,崇尚極簡,對於類型和OO機制上還是偏弱,
而且這麼多年也沒發展起來,仍然是比較小眾的活著。未來比例會越來越少的。
顯然TypeScript會越來越好,TypeScript 的強大之處是要用過才知道的。
- 1)規模化編程,像Java那種,靜態類型,面向對象,前端只有TypeScript能做到
- 2)親爹是微軟安德斯·海爾斯伯格,不知道此人的請看borland傳奇去
- 3)開源,未來很好
- 4)組合拳:TypeScript + VSCode = 神器
當下前端發展速度極快,以指數級的曲線增長。以前可能1年都不一定有一項新技術,現在可能每個月都有。大前端,Node全棧,架構演進等等都在快速變化。可以說,前端越複雜,有越多的不確定性,TypeScript的機會就越大。
顯然不會。
TS 的強大之處是要用過才知道的。
有了靜態類型,閱讀代碼、debug、重構都簡單了不止一個數量級。
其實寫代碼就是給未來的人講故事,而 TS 可以講得很好呀。
在對 JS 碾壓性的優勢面前,寫類型定義消耗的時間可以忽略不計了。
目前已經把團隊的新項目全部遷移到了 TS 上。據我所知 FEX 很多項目也轉到 TS 上了【此處應 at 多益
我也在跟進百度內部的 TS 編碼規範草案,希望明年年初可以落地吧。
至於 Coffee,我感覺就是一系列已經被列入標準的語法糖而已呀,相對 JS 沒有本質上的提升。
命運難說,CoffeeScript 解決的是排版,一些髒的語法問題。TypeScript解決的是 類型問題,Flow也是解決類型問題的。這兩者的類型描述能力,都超越了Java,C#。但是語法依然醜陋不堪,CoffeeScript的凋零不見得是ES6語法糖更好,大多數前端都懶得學其它轉義語言,否則fablejs,purescript,bucklescript都是更好的選擇。es6畢竟還是屬於js,大家投資他不會吃虧。TypeScript 宣稱是js的超集,大家就誤解為ts也是js了,正中的大多前端下懷。
coffee 和 ts 都是對他們那個時代的 es 改進。
以前聽賀老講過,es6 是參考了 coffee 的一些東西,比如箭頭函數。es6 出現了,coffee 沒有了存在的必要。
ts 被大部分人看好,最後很有可能以某種方式進入標準,到時候也沒人用 ts 了。
所以 coffescript 的命運是什麼?如果是被標準 「招安」,那麼就算沒人用了結局也不算太悲慘了吧。
也許 ts 的開發者們也希望有一天 ts 因為原生支持了類型靜態檢查所以沒人用了吧。
不會。
你要看這個事物是解決什麼問題的。
coffeescript 基本上只是語法糖,並不解決任何問題。
就連簡單的函數域都不解決。
比如 ES5 時代的一個非同步循環這樣寫是錯誤的:
```
for(var i=0;i&<5;i++) {
setTimeout(function (){console.log(i)}, 1000);
}
```
這樣會輸出 5 個 5
正確寫法是
```
for(var i=0;i&<5;i++) {
(function(i) {setTimeout(function (){console.log(i)}, 1000);})(i)
}
```
這樣才是輸出 0 1 2 3 4
這個問題在 ES6 中用 let
和const
解決了 。
所以我覺得 coffeescript 是沒有解決任何實質性的問題的。
而 typescript 不同。其誕生是有實際目的的,是想解決動態語言太過於動態的問題,想加上一種靜態類型機制,方便大型項目的開發。
當然,靜態類型檢查也會有其他的方案,但是看 angular4、vscode 等知名項目的選擇,我認為 typescript 是目前最靠譜的『大型』『高要求』項目的選擇。
==================
有評論說到 coffee script 解決了這個問題
可以去 CoffeeScript 中文 試試
coffee 代碼是
```
for i in [0..4]
setTimeout (() -&> console.log i), 1000
```
編譯出來的代碼是
```
var i, _i;
for (i = _i = 0; _i &<= 4; i = ++_i) { setTimeout((function() { return console.log(i); }), 1000);}```
跑出來的結果是 5 個 5
WebAssembly基本是為靜態語言設計的,ES未來肯定會擁抱WebAssembly,那麼你猜ES語法會變成什麼樣?
比如:AssemblyScript/prototype
往js里塞點語法糖容易,往裡面塞靜態類型的阻力可要大多了吧…
Typescript,只要微軟不停止推廣visual studio code, 不說其他的,做為插件的開發語言,就會有大量的實踐存在,就會有活力,一直下去。
事物的產生和消亡是由歷史進程決定的,技術也一樣。
cs出現在 js這把寶劍缺少劍柄的時候,當js的劍柄被補上之後,cs也就完成了它這一階段的歷史使命,它的一些成功的探索和實踐也被js消化。
不能因為事物最終的消亡就否定其在歷史進程中的價值。
ts出現在js已經被大量使用於中型和大型工程,並且缺少簡單類型系統支撐的背景下。 當哪天人們在瀏覽器端編程不再囿於js(如wasm普及),或者人們對類型系統有了更深刻的需求和認識的時候,也許ts就能退出歷史舞台了。
不過從目前的情況看來,這一天還有點點早(攤手Javascript是web時代的彙編語言
想取代Javascript的語言都會死掉
我不認為Typescript想取代Javascript
JavaScript是一門函數式編程語言,scheme的表親(詳見《JavaScript函數式編程》,好書一本),沒有類,面向原型,除了動態作用域各種作用域都有(this很像動態作用域,但事實上卻是調用棧記錄,詳見《You Don"t Know JS》,我一定要神話這本書)。
這樣一門語言,對於快速開發當然是非常友好了(前提是你都會了),但是一旦規模變大,很容易失去可控性。
尤其是面臨如今的應用場景——前端到中間件,中間件到後端,第三方API,前端狀態管理,MongoDB,MySql,不同平台之間轉化,各種命名風格之間跳轉,對於一個前端開發者而言,如果不使用強類型檢查在代碼編輯時就避免類型錯誤,相信開發體驗一定會讓你呵呵噠。
TypeScript除了強類型和泛型以外,其他特性和Babel幾乎一致,因此其作為JavaScript的超集地位無可動搖,這和CoffeScript只是JavaScript語法糖的地位相比可是差距很大的。
函數式開發快,容易調試,難以理解,抽象程度高,可讀性差。
面向對象可控,穩定性好,可擴展,較為形象,可讀性高。
TypeScript彌補了JavaScript面向對象的短板,避免了this軟綁定,硬綁定,原型鏈等原因導致的類型錯誤,讓JavaScript擁有了超出其設計初衷的能力。
而JavaScript因為設計初衷的關係(網頁端,函數式),很難往靜態類型的方向發展。
這才是其價值所在,當然,很多人會問將JavaScript擴展如此有沒有意義?這個問題就很玄學了,現在的前端發展SPA有什麼意義?前端擁有伺服器端,資料庫端甚至操作集群的能力有什麼意義?
曾今拜讀過百度大神的《JavaScript設計模式》,道理我雖然都明白,但是就JavaScript實現設計模式的那凌亂代碼,我是真心沒有心情看下去。
畢竟面向對象構建,函數式運行才是軟體開發的王道!
所以為了讓同僚能看懂你的代碼,擁抱TypeScript吧!
至於質疑JavaScript是否是函數式編程語言的:
如果ts死了,那只有一種可能,就是所有ts的特性都已經被js繼承
只有這種可能:
開發者:ts簡直太好用,太強大了.......balabalbal
威遠:感謝你們的反饋和建議,我們最終決定把ts砍掉了
ts猝...閑聊下。
作為一名Ruby程序猿,我是從2012年接觸到Coffee,當然了,是被動的,因為Rails3把Coffee作為了預設配置。那時的感覺是,我終於不用寫那麼令人吐血的JavaScript了,感覺生產力提高了不少。於是我就從2012年寫Coffee一直寫到2016年,中間2014年接觸到Angular時也是用Coffee寫的,一直到2016年下半年,我們要用React了,於是我又(依然是被動地)系統地學習了ES2015,然後我就覺得Coffee要完…這是在我的程序猿生涯里,第一次覺得一個語言要壽終正寢了,其實有一點慌的,但也覺得蠻好,ES2015真的是好太多了,那就擁抱它吧。
後才我才知道了ECMA,他們有個神奇的協議,或者說語言規範,而JavaScript只是這個協議的具體實現,到ES2015,JS大概實現了其中的20%左右…Coffee的部分方法早就在協議中出現了,那麼只要JS按照規範繼續發展,替代Coffee完全是可以預料到的。我不知道協議中有覆蓋TypeScript多少的東西,但我依舊沒有主動去學…唉,要學的東西那麼多,這個其實有在backlog里,但是優先順序很低。
作為一個玩Ruby的,我還是比較喜歡動態類型,在JS中我也寫過eval,但總覺得十分羞愧;要是在Ruby中做元編程我則會覺得這是很自然的事情。
誰知道ECMA會不會擁抱靜態類型呢,或者會不會有個開關,你愛靜態就靜態,愛動態就動態呢。
也許在不久的將來,我還會見到不少語言的誕生、輝煌與消亡…那對我說如何學習學習的能力(大概是元學習?)才是更加重要的吧。
TypeScript無論是實力還是出身都比CoffeeScript要好,所以前景肯定也是要好一些的。
但是一個語言的命運,既要看它自身的特性,也要考慮歷史的行程,當年隔壁Google家的Dart,也是自詡要承天命而代JavaScript,誕生的時候各種"好頂支有希望"、"Google出品必屬精品"、"偉大光榮不作惡"……可是現在還有幾個人記得它?
在可預見的很長一段時間TS都會發展得很好。除去本身在ES上加的類型系統和IDE支持外,
1. TS目前的發展計劃是緊貼未來的ES標準的,開發團隊和ES標準委員會也有共同計劃,保證了後續和ES標準的一致性,目前也是很好的ES transpiler。
2. 很多大型知名框架和庫正在/即將使用TS,其他機遇傳統ES開發的項目也基本有社區貢獻的typings,火爆的社區活躍度也是TS生命里的保障3. 背後有MS和Google這樣的大公司背書,前段時間組裡也說馬上要逐漸轉到TS開發,估計這兩年TS在大公司會更加流行。Coffee在ES早期特別簡陋的時候能夠解決很多語言層面的缺點,乾的是取代ES的事,隨著ES新標準的普及必然會被逐漸淘汰,但TS做的是對ES的補充,同時作為ES新特性的試驗田。如果 JavaScript 也加入 gradual typing 的支持就很難說了。
從 py 的發展來看,gradual typing 也不失為一個很好的選擇。
這麼說吧,與CS只是在原生JS的基礎上添加上一層語法糖不同,TS關注的是JS應用於大型項目開發的兩大痛點:
1.動態弱類型。所謂的動態弱類型是指JS在運行時,變數的類型可以隨時變化,對象的屬性和方法可以隨時增加和刪除等;2.面向對象編程的支持。業界目前比較主流的看法是面向對象模式比較適合大規模的業務開發,而在ES6規範定稿,落地之前,基於原型機制來模仿的JS面向對象編程,如果用傳統的面向對象角度來看,無論是「形」和「神」都是差那麼點。這對於習慣於主流的C++,java類面向對象編程的人員來說,難免有點不那麼友好啊。也就是說,JS在ES5中的基於原型機制,使用了prototype的寫法不太被主流的面向對象編程寫法所認可。這就造成了大眾對於JS的這麼一個認知:「JS不太適合大規模項目的業務開發。」TS關注到了這兩個痛點,並且解決了這兩個痛點。同時它還聰明地宣稱自己只是JS的超集,意在告訴大眾,你在寫TS的時候,其實也是寫JS。同時我還給你提供JS目前缺失的類型和面向對象編程方面的支持。這種定位,正中JSer的下懷,同時還迎合了像java的這種天生使用面向對象來開發的後台程序員的喜好。目前來看,TS的生態是越來越繁榮和壯大了,從類型聲明庫數量的快速增長可見一斑。到此,我們幾乎可以說,TS不會像CS一樣隨著時間的流逝,被淹沒或遺忘在技術發展的洪流中,而是有可能成為超越JS,成為JS-Like語言中的主流。但是,老子的相對論告訴我們,凡事說得太絕對都是靠不住的,因此我們也不能那麼武斷地下此結論。因為大家不要忘了,JS有個ECMA在後面當老爹,而且一當就是當了二十多年,它是根正苗紅的嫡長子啊。而JS的社區又是如此的聲勢浩大,說不定在他們的推動下面,未來的ES9/10/11會採納TS的類型和面向對象設計方案,使得TS有的,JS也有。到那個時候,估計TS也會遭遇CS一樣的命運,不同的是,這種命運是有點功成告退的意味在。又或者是一個可用可不用的替補角色,就像如今的sass/less一樣,安靜地站在JS旁邊,你可用可不用。綜上所述,TS不會像CS一樣,它的地位有可能是並列於或者超越JS,類似於C++至於C。也有可能作為一個替補方案,退居次位,類似於Sass/Less至於CSS那樣。
typescript真的很棒,越用越喜歡。怪不得angular默認使用。就像某個答案說的,除非js繼承了ts的所有屬性
推薦閱讀:
※如何看待阿里開源的Rax框架?
※瀏覽器端js有如何為本機生成固定的uuid?
※有沒有必要將 DOM 結構緩存到本地?如果有,意義是什麼?
※前端開發有沒有必要學習less,sass,coffee script等語言?
※關於eval和數組計算的一些小問題?
TAG:JavaScript | 編程語言 | CoffeeScript | Nodejs | TypeScript |