1， JS不是強類型，無法很好的通過編譯的手段發現問題，使得產品迭代中，很容易出bug，如果自動化測試程度再低點，產品質量真是有點Hold不住。
2， 沒有真正的面向對象的實現框架，使得代碼組織容易混亂，代碼邏輯容易形成複雜的耦合。而且JS裏太多的僞面向對象的框架，導致了JS人員的開發風格大相徑庭，同一個工程，會有多種不同的代碼風格，規範，維護性相當的差。
所以如果有一個前段的開發平臺，它的風格更接近與C#或JAVA的話，那這個轉型就順利多了。所以給大家推薦一下微軟的typescript。它將後端人員熟悉的強類型和麪向對象的開發模式，很好的融合到了前段JS開發中，大大降低了學習成本，同時也使得代碼的組織，和團隊的合作更加高效。
也許靈活性，對於一個一開始就是前端入道的工程師更爲看重，但隨着JS代碼的複雜度的高速增長，對於後端出身的來說，還是覺得代碼的可編譯性和可組織性更爲看重，這個對於代碼的質量，對於以團隊爲單位的開發，以及快速的產品迭代，都至關重要。
回顧編程語言的發展，彙編，C，C++，C#，java等，可以看出，隨着硬件的發展和代碼複雜度的演進，部分代碼性能的損失，帶來的開發的高效和可維護，是一個實踐證明了的最佳的方案。
所以不必糾結在typescript編譯後生成的代碼，是否比程序員原生寫出的JS代碼有性能的損失，相對於開發的效率來說，性能的些許損失，絕對是利大於弊的，而且說實話，有多少JS的開發者，能保證自己的代碼，要不typescript編譯後生成的代碼更高效？！
也不必糾結於，學習typescript，會不會因爲這個語言的平臺幫開發者做了的太多的事，使得初學者無法真正學習到JS的精髓，真正對於語言的瞭解，不是僅僅在於是寫了多少，更加在於你在實戰中，解決了多少問題，而這一方面，typescript不會影響你，看的還是你個人的JS功底，所以它不會阻礙你的JS進階之路。