Що таке TypeScript і чому я використовую його замість JavaScript? [зачинено]


1694

Чи можете ви, будь ласка, описати, що таке мова TypeScript?

Що це може зробити, що JavaScript чи наявні бібліотеки не можуть це зробити, це могло б дати мені підстави вважати це?


11

Ось декілька думок з цього приводу
Єфім

Відповіді:


1298

Я спочатку писав цю відповідь, коли TypeScript був ще гарячим на пресі. П'ять років по тому, це ОК огляд, але подивитися на відповідь Lodewijk в поле нижче для більш глибокого

Перегляд 1000 футів ...

TypeScript - це набір JavaScript, який в першу чергу забезпечує необов'язкове статичне введення тексту, класи та інтерфейси. Однією з головних переваг є можливість IDE забезпечити більш сприятливе середовище для виявлення поширених помилок під час введення коду .

Щоб зрозуміти, що я маю на увазі, подивіться вступне відео Microsoft про мову.

Для великих проектів JavaScript прийняття TypeScript може призвести до більш надійного програмного забезпечення, при цьому він все ще може бути розгорнутий там, де працює звичайна програма JavaScript.

Це відкритий код, але ви отримуєте розумний Intellisense лише під час введення тексту, якщо використовуєте підтримуваний IDE. Спочатку це була лише Microsoft Visual Studio (також відзначена у публікації блогу від Мігеля де Ікаса ). В цей час інші IDE також пропонують підтримку TypeScript .

Чи є інші подібні технології?

Там в CoffeeScript , але це дійсно служить іншої мети. IMHO, CoffeeScript забезпечує читабельність для людей, але TypeScript також забезпечує глибоку читабельність для інструментів через його необов'язкове статичне введення тексту (див. Цю останню публікацію в блозі для трохи більше критики). Також є Dart, але це повноцінна заміна JavaScript (хоча він може створювати код JavaScript )

Приклад

Як приклад, ось декілька TypeScript (ви можете грати з цим на майданчику TypeScript )

class Greeter {
    greeting: string;
    constructor (message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}  

І ось JavaScript, який він створив би

var Greeter = (function () {
    function Greeter(message) {
        this.greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.greeting;
    };
    return Greeter;
})();

Зверніть увагу, як TypeScript визначає тип змінних членів та параметри методу класу. Це видаляється при перекладі на JavaScript, але використовується IDE та компілятором для виявлення помилок, як-от передача числового типу конструктору.

Він також може виводити типи, які не є явно оголошеними, наприклад, він би визначав greet()метод повертає рядок.

Налагодження TypeScript

Багато браузерів та IDE пропонують підтримку прямої налагодження через вихідні карти. Дивіться це запитання щодо переповнення стека для отримання більш детальної інформації: Налагодження коду TypeScript за допомогою Visual Studio

Хочете дізнатися більше?

Я спочатку писав цю відповідь, коли TypeScript був ще гарячим на пресі. Ознайомтеся з відповіддю Лодейка на це запитання, щоб ознайомитись із більш детальною деталлю.


103
WebStorm пропонує приємний IntelliSense на TypeScript зараз і є багатоплатформою.
Радек

26
Проблема цих інструментів полягає в тому, що ви ніколи не отримуєте повну продуктивність із JavaScript. Так, він забезпечує хорошу читабельність, але скомпільований код іноді дуже незграбний. Ви покладаєтесь на сторонній інструмент для написання рідного JavaScript, я думаю, що це не шлях, це як перетворення мови на іншу мову. Бажаючи змінити мову, яка не є іншою мовою, вести себе так, як інша мова, яка вам подобається, це дурно і нерозумно. ...... (кінець частини 1) ......
Codebeat

56
@Erwinus: Ви все-таки програмували з асемблером?
VikciaR

11
@Erwinus Ви робите припущення про те, як працює TypeScript. Ви можете написати звичайний JavaScript як TypeScript, а компілятор перевірити лише час компіляції. У цьому немає втрати продуктивності.
думкарепо

41
@Erwinus Суть TypeScript полягає в тому, щоб забезпечити перевірку типу компіляції. Якщо ви не бачите в цьому значення, це абсолютно чудово. TypeScript вважається "вашим першим тестовим блоком". Існує багато ресурсів, які обговорюють, чи має необов'язкова перевірка типу цінність і є детальнішою, ніж те, що ми можемо зробити тут. Я не намагаюся вас ні в чому переконувати, просто виправляю помилкове уявлення.
думкарепо

1052

Відношення TypeScript до JavaScript

TypeScript - це типовий набір JavaScript, який компілюється в звичайний JavaScript - typecriptlang.org .

JavaScript - мова програмування, розроблена Технічним комітетом EMCA 39 , який представляє групу людей, що складається з багатьох різних зацікавлених сторін. TC39 - комітет, організатором якого є ECMA : організація внутрішніх стандартів. JavaScript має багато різних реалізацій від багатьох різних постачальників (наприклад, Google, Microsoft, Oracle тощо). Мета JavaScript - стати лінгва франкою в Інтернеті.

TypeScript - це супернабір мови JavaScript, який має єдиний компілятор з відкритим кодом та розробляється в основному одним постачальником: Microsoft. Завдання TypeScript - допомогти налагодити помилки на ранніх етапах через систему типів та підвищити ефективність розробки JavaScript.

По суті, TypeScript досягає своїх цілей трьома способами:

  1. Підтримка сучасних функцій JavaScript - Мова JavaScript (не час виконання) стандартизована за допомогою стандартів ECMAScript . Не всі веб-переглядачі та JavaScript виконують всі функції всіх стандартів ECMAScript (див. Цей огляд ). TypeScript дозволяє використовувати багато найновіших функцій ECMAScript і переводить їх на старіші цілі ECMAScript на ваш вибір (див. Перелік цілей компіляції під --targetопцією компілятора). Це означає, що ви можете безпечно використовувати нові функції, такі як модулі, лямбда-функції, класи, оператор розповсюдження та знищення, залишаючись назад сумісними зі старими браузерами та режимами JavaScript.

  2. Система розширеного типу - Підтримка типу не входить до стандарту ECMAScript і, ймовірно, ніколи не буде пояснюватися інтерпретованим характером замість скомпільованого характеру JavaScript. Система типів TypeScript надзвичайно багата і включає в себе: інтерфейси, перерахунки, гібридні типи, дженерики, типи об'єднання / перетину, модифікатори доступу та багато іншого. Офіційний сайт машинописного тексту дає огляд цих можливостей. Система типів Typescript нарівні з більшістю інших набраних мов, а в деяких випадках, можливо, і потужніша.

  3. Підтримка інструментів для розробників - компілятор TypeScript може запускатися як фоновий процес для підтримки як поступової компіляції, так і інтеграції IDE, щоб ви могли легше переходити, виявляти проблеми, перевіряти можливості та рефакторувати свою кодову базу.

Відношення TypeScript до інших мов націлювання JavaScript

TypeScript має унікальну філософію порівняно з іншими мовами, що компілюють у JavaScript. Код JavaScript є дійсним кодом TypeScript; TypeScript - це набір JavaScript. Ви можете майже перейменувати свої .jsфайли у .tsфайли та почати використовувати TypeScript (див. "Взаємодія JavaScript" нижче). Файли TypeScript компілюються в читаний JavaScript, так що можлива міграція назад і розуміння компільованого TypeScript зовсім не складно. TypeScript спирається на успіхи JavaScript, покращуючи його слабкі сторони.

З одного боку, у вас є майбутні інструменти доказування, які відповідають сучасним стандартам ECMAScript і компілюють їх до старих версій JavaScript, а Babel є найпопулярнішим. З іншого боку, у вас є мови, які можуть повністю відрізнятися від JavaScript, на які націлено JavaScript, наприклад, CoffeeScript, Clojure, Dart, Elm, Haxe, Scala.js та ще безліч хостів (див. Цей список). Ці мови, хоч і можуть бути кращими за те, куди може привести майбутнє JavaScript, але ризикують не знайти достатнього прийняття, щоб гарантувати їх майбутнє. Також у вас можуть виникнути проблеми з пошуком досвідчених розробників для деяких із цих мов, хоча ті, які ви знайдете, часто можуть бути більш захопленими. Interop із JavaScript також може бути дещо задіянішим, оскільки вони далекіші від того, що насправді є JavaScript.

TypeScript знаходиться між цими двома крайнощами, врівноважуючи таким чином ризик. TypeScript не є ризиковим вибором жодного стандарту. Потрібно дуже мало зусиль, щоб звикнути, якщо ви знайомі з JavaScript, оскільки це не зовсім інша мова, має чудову підтримку оперативної сумісності JavaScript і останнім часом вона сприйняла багато прийняття.

Необов’язково статичне введення тексту та умови виводу

JavaScript вводиться динамічно. Це означає, що JavaScript не знає, який тип змінної є, поки вона фактично не інстанціюється під час виконання. Це також означає, що це може бути пізно. TypeScript додає підтримку типу JavaScript. Помилки, спричинені помилковими припущеннями про те, що певна змінна певного типу може бути повністю усунена, якщо грати в карти правильно (наскільки чітко ви вводите свій код або якщо вводити код взагалі залежить від вас).

TypeScript полегшує введення тексту набагато простіше і набагато менш чітко, використовуючи умовиводи типу. Наприклад: var x = "hello"у TypeScript - те саме, що і в TypeScript var x : string = "hello". Тип просто випливає з його використання. Навіть якщо ти чітко не вводиш типи, вони все ще є, щоб врятувати тебе від того, щоб зробити щось, що інакше призведе до помилки під час виконання.

TypeScript необов'язково вводиться за замовчуванням. Наприклад function divideByTwo(x) { return x / 2 }, допустима функція в TypeScript, яку можна викликати з будь- яким параметром, навіть якщо виклик її за допомогою рядка очевидно призведе до помилки під час виконання . Так само, як ви звикли в JavaScript. Це працює, тому що, коли жоден тип не був призначений явно і тип не міг зробити висновок, як у прикладі divideByTwo, TypeScript буде неявно призначати тип any. Це означає, що підпис типу divideByTwo автоматично стає підписом function divideByTwo(x : any) : any. Існує прапор компілятора , щоб заборонити це поведінка: --noImplicitAny. Увімкнення цього прапора забезпечує більшу ступінь безпеки, але також означає, що вам доведеться більше вводити текст.

Види мають пов’язану з ними вартість. По-перше, є крива навчання, а по-друге, звичайно, це коштуватиме вам трохи більше часу, щоб створити кодову базу, використовуючи також і правильне суворе введення тексту. На мій досвід, ці витрати повністю коштують на будь-якій серйозній кодовій базі, яку ви ділитеся з іншими. Велике дослідження мов програмування та якості коду в Github свідчить про те, що "статично типізовані мови, як правило, менш схильні до дефектів, ніж динамічні типи, і що сильне введення тексту краще, ніж слабке введення тексту в тому ж плані".

Цікаво відзначити, що цей самий документ визначає, що TypeScript менш схильний до помилок, ніж JavaScript:

Для тих, хто має позитивні коефіцієнти, ми можемо очікувати, що мова асоціюється з, ceteris paribus, більшою кількістю виправлень дефектів. Ці мови включають C, C ++, JavaScript , Objective-C, Php та Python. Мови Clojure, Haskell, Ruby, Scala та TypeScript - всі мають негативні коефіцієнти, що означає, що ці мови є менш імовірними, ніж середні, в результаті чого виправляють дефекти.

Розширена підтримка IDE

Досвід розробки з TypeScript - це велике вдосконалення порівняно з JavaScript. Ідентифікатор IDE в режимі реального часу інформує компілятор TypeScript про його багату інформацію про тип. Це дає пару основних переваг. Наприклад, за допомогою TypeScript ви можете безпечно робити рефактори, як перейменування, у всій базі коду. Завдяки заповненню коду ви можете отримати вбудовану допомогу щодо будь-яких функцій, які може запропонувати бібліотека. Більше не потрібно їх пам’ятати або шукати в онлайн-довідниках. Про помилки компіляції повідомляється безпосередньо в IDE червоною виразною лінією, поки ви зайняті кодуванням. Загалом це дозволяє значно підвищити продуктивність порівняно з роботою з JavaScript. Можна витратити більше часу на кодування та менше часу налагодження.

Існує широкий спектр IDE, які мають чудову підтримку TypeScript, такі як Visual Studio Code, WebStorm, Atom та Sublime.

Строгі нульові перевірки

Помилки під час виконання форми cannot read property 'x' of undefinedабо undefined is not a functionдуже часто викликані помилками в коді JavaScript. Вихід із поля TypeScript вже знижує ймовірність виникнення подібних помилок, оскільки не можна використовувати змінну, яка не відома компілятору TypeScript (за винятком властивостей anyнабраних змінних). Ще можливо, помилково використовувати змінну, яку встановлено undefined. Однак за допомогою версії 2.0 TypeScript ви можете усунути такі помилки разом разом за допомогою ненульових типів. Це працює так:

Якщо ввімкнено строгі нульові перевірки ( --strictNullChecksпрапор компілятора), компілятор TypeScript не дозволить undefinedпризначити змінну, якщо ви прямо не оголосите, що вона є нульовим. Наприклад, let x : number = undefinedпризведе до помилки компіляції. Це ідеально відповідає теорії типів, оскільки undefinedце не число. Можна визначити x, що тип суми numberі undefinedвиправити це: let x : number | undefined = undefined.

Як тільки тип, як відомо, є нульовим, це означає, що він має тип, який також може мати значення, nullабо undefinedкомпілятор TypeScript може визначити за допомогою аналізу типів на основі потоку управління, чи безпечно ваш код використовувати змінну чи ні. Іншими словами, коли ви перевіряєте змінну, undefinedнаприклад, через ifконстатацію, компілятор TypeScript зробить висновок про те, що тип у цій гілці потоку управління вашим кодом більше не зводиться до нуля, і тому його можна безпечно використовувати. Ось простий приклад:

let x: number | undefined;
if (x !== undefined) x += 1; // this line will compile, because x is checked.
x += 1; // this line will fail compilation, because x might be undefined.

Під час збірки, 2016-го конструктор конференції TypeScript Андерс Хейльсберг детально пояснив та продемонстрував цю функцію: відео (з 44:30 до 56:30).

Компіляція

Для використання TypeScript потрібен процес збирання для компіляції в код JavaScript. Процес збирання зазвичай займає лише пару секунд, залежно від розміру вашого проекту. Компілятор TypeScript підтримує інкрементальну компіляцію ( --watchпрапор компілятора), щоб усі наступні зміни можна було компілювати з більшою швидкістю.

Компілятор TypeScript може вбудовувати інформацію про вихідну карту в створені файли .js або створювати окремі файли .map. Інформація про вихідну карту може використовуватися утилітами налагодження, такими як Chrome DevTools та інші IDE, для відновлення рядків у JavaScript до тих, що їх генерували в TypeScript. Це дозволяє вам встановлювати точки перерви та перевіряти змінні під час виконання безпосередньо у вашому коді TypeScript. Інформація про вихідну карту працює досить добре, вона була задовго до TypeScript, але налагодження TypeScript, як правило, не таке велике, як при використанні JavaScript безпосередньо. Візьмемо thisдля прикладу ключове слово. Через змінену семантику thisключового слова навколо закриття після ES2015, він thisможе фактично існувати під час виконання у вигляді змінної _this(див. Цю відповідь). Це може заплутати вас під час налагодження, але, як правило, це не проблема, якщо ви знаєте про це або перевіряєте код JavaScript. Слід зазначити, що Бебел страждає саме такого типу питань.

Є кілька інших хитрощів, які може зробити компілятор TypeScript, наприклад, генеруючи перехоплюючий код на основі декораторів , генеруючи код завантаження модуля для різних модульних систем та аналізуючи JSX . Однак вам, швидше за все, знадобиться інструмент збірки, крім компілятора Typescript. Наприклад, якщо ви хочете стиснути свій код, для цього вам доведеться додати інші інструменти до процесу збирання.

Існують плагіни для компіляції TypeScript, доступні для Webpack , Gulp , Grunt і майже будь-який інший інструмент побудови JavaScript. Документація TypeScript має розділ про інтеграцію з інструментами збирання, що охоплюють їх усі. Лінтера також доступний в разі , якщо ви хотіли б ще більше часу складання перевірки. Також існує велика кількість насіннєвих проектів, які розпочнуть роботу з TypeScript у поєднанні з низкою інших технологій, таких як Angular 2, React, Ember, SystemJS, Webpack, Gulp тощо.

Взаємодія JavaScript

Оскільки TypeScript настільки тісно пов'язаний з JavaScript, він має великі можливості інтероперабельності, але для роботи з бібліотеками JavaScript в TypeScript потрібна деяка додаткова робота. Визначення машинопису необхідні , щоб компілятор машинопису розуміє , що виклики функцій , такі як _.groupByабо angular.copyабо $.fadeOutфактично не є незаконним заявою. Визначення для цих функцій розміщуються у .d.tsфайлах.

Найпростіша форма, яку може набути визначення, - це дозволити будь-який спосіб використовувати ідентифікатор. Наприклад, при використанні Lodash один файл визначення рядка declare var _ : anyдозволить вам викликати будь-яку функцію, яку ви хочете _, але, звичайно, ви також все ще можете помилитися: _.foobar()це був би законний виклик TypeScript, але, звичайно, , незаконне дзвінок під час виконання. Якщо ви хочете забезпечити належну підтримку та доповнення коду, ваш файл визначення повинен бути більш точним (див. Приклади означення lodash ).

Модулі Npm, які поставляються попередньо упакованими з власними визначеннями типів, автоматично розуміються компілятором TypeScript (див. Документацію ). Для майже будь-якої іншої напівпопулярної бібліотеки JavaScript, яка не включає власні визначення, хтось там уже зробив визначення типів доступними через інший модуль npm. Ці модулі мають префікс "@ types /" і походять із сховища Github під назвою DefinitelyTyped .

Є одне застереження: визначення типів повинно відповідати версії бібліотеки, яку ви використовуєте під час виконання. Якщо їх немає, TypeScript може заборонити вам викликати функцію або перенаправити змінну, яка існує, або дозволить викликати функцію або перенаправити змінну, яка не існує, просто тому, що типи не відповідають часу виконання під час компіляції . Тому переконайтеся, що ви завантажили правильну версію визначень типів для потрібної версії бібліотеки, яку ви використовуєте.

Якщо чесно, у цьому є невеликі клопоти, і це може бути однією з причин того, що ви не вибираєте TypeScript, а натомість шукаєте щось на зразок Babel, якому зовсім не страждає від необхідності отримувати визначення типу. З іншого боку, якщо ви знаєте, що ви робите, ви можете легко подолати будь-які проблеми, спричинені неправильними або відсутніми файлами визначення.

Перетворення з JavaScript в TypeScript

Будь-який .jsфайл можна перейменувати у .tsфайл та пропустити через компілятор TypeScript, щоб отримати синтаксично той самий код JavaScript, що і вихідний (якщо він був синтаксично правильним в першу чергу). Навіть коли компілятор TypeScript отримає помилки компіляції, він все одно створить .jsфайл. Він навіть може приймати .jsфайли як вхід із --allowJsпрапором. Це дозволяє відразу почати з TypeScript. На жаль, помилки компіляції, ймовірно, трапляться на початку. Потрібно пам’ятати, що це не помилки зупинки показу, як ви, можливо, звикли до інших компіляторів.

Помилки компіляції, які виникають на початку при перетворенні проекту JavaScript в проект TypeScript, неминучі за характером TypeScript. TypeScript перевіряє всі коди на валідність, тому він повинен знати про всі функції та змінні, які використовуються. Таким чином, для всіх них мають бути визначені типи, інакше помилки компіляції повинні мати місце. Як вже згадувалося в розділі вище, для майже будь-якого сценарію JavaScript є .d.tsфайли, які можна легко придбати при встановленні пакетів DefinitelyTyped. Однак, можливо, ви використовували якусь незрозумілу бібліотеку, для якої не доступні визначення TypeScript, або що ви переповнили деякі примітиви JavaScript. У цьому випадку ви повинні надати визначення цих бітів для зникнення помилок компіляції. Просто створіть .d.tsфайл і включіть його в filesмасив tsconfig.json , щоб його завжди враховував компілятор TypeScript. У ньому оголошуйте ті біти, про які TypeScript не знає як тип any. Після усунення всіх помилок ви можете поступово вводити текст, використовуючи ваші потреби.

Для введення TypeScript у конвеєр збірки також знадобиться деяка робота над (пере) налаштуванням конвеєра збірки. Як було сказано в розділі про складання, там є багато хороших ресурсів, і я закликаю вас шукати насінні проекти, які використовують комбінацію інструментів, з якими ви хочете працювати.

Найбільша перешкода - крива навчання. Я закликаю вас спочатку пограти з невеликим проектом. Подивіться, як це працює, як він створює, які файли використовує, як він налаштований, як він функціонує у вашій IDE, як він структурований, які інструменти використовує тощо. Перетворення великої бази коду JavaScript у TypeScript можливо, коли ви знаєте що ти робиш. Прочитайте, наприклад, цей блог щодо перетворення рядків 600k у машинопис за 72 години ). Просто переконайтеся, що ви добре розумієте мову, перш ніж здійснити стрибок.

Усиновлення

TypeScript є відкритим кодом (ліцензія Apache 2, див. GitHub ) та підтримується Microsoft. Андер Хейлсберг , головний архітектор компанії C #, очолює проект. Це дуже активний проект; Команда TypeScript випустила багато нових функцій за останні кілька років, і ще багато чудових ще планується прийти (див. дорожню карту ).

Деякі факти про прийняття та популярність:

  • У опитуванні розробників StackOverflow у 2017 році TypeScript був найпопулярнішим транслілером JavaScript (загальне 9-е місце) та зайняв третє місце у найбільш улюбленій мові програмування.
  • У 2018 році опитування стану js TypeScript було оголошено одним із двох великих переможців у категорії ароматів JavaScript (другий - ES6).
  • У дослідженні Decklover Deverloper 2019 StackOverlow піднявся на 9 місце найпопулярніших мов серед професійних розробників, обігнавши і C, і C ++. Він знову посів третє місце серед найбільш улюблених мов.

25
"Код JavaScript є дійсним кодом TypeScript" - це насправді не завжди так. Я маю на увазі код, наприклад, якщо (1 === '1') {} дає помилку в TS, а в JS - ні. Але в більшості випадків, якщо JS-код добре написаний, це правда.
Мацей Буковський

3
Якщо ви втратили свій дорогоцінний продуктивний час, роздуваючись над пропущеною комою, писання в Typescript було б рятуванням життя.
SoSufi

3
Типи застаріли, і поточна найкраща практика - це просто npm(або yarn) install @types/foo. Чи можете ви оновити свою відповідь?
Джед Фокс

13
TL; DR у цій відповіді
збережеться

8
@MaciejBukowski Навіть якщо TypeScript насправді скаржиться в цьому випадку, ви все одно отримаєте дійсний вихід JS (який буде кодом JS, який ви компілювали / транспілювали за допомогою TypeScript). Отже, це "компіляція з помилкою", а не недійсний TypeScript. У специфікації TypeScript записано, що будь-який дійсний код JS повинен бути дійсним TS-кодом.
Pac0

83

TypeScript робить щось подібне до того, що робить менше або sass для CSS. Вони - це супер набори, це означає, що кожен код JS, який ви пишете, є дійсним кодом TypeScript. Крім того, ви можете використовувати інші смаколики, які він додає до мови, і перекладений код буде дійсним js. Ви навіть можете встановити версію JS, на яку потрібно ввести отриманий код.

В даний час TypeScript - це супер набір ES2015, тому може бути хорошим вибором для початку вивчення нових функцій js та переведення необхідного стандарту для вашого проекту.


4
Найкращий TL; DR - це сторінка TS: "TypeScript - це набраний набір JavaScript, який збирається у звичайний JavaScript."
Хуан Мендес

1
Однак це не відповідає "чому я повинен його використовувати". Тут tl; dr буде: 1) Додавання необов'язкових статичних типів у JavaScript. Типи можуть допомогти вловлювати помилки під час компіляції та краще документувати програму. 2) Ви можете написати новий JavaScript (ES6 / ES7 / ESnext) і скомпілювати його в ES5, який необхідний для підтримки старих браузерів; Я розробив трохи більше на tsmean.com/articles/vs/typescript-vs-javascript для тих, хто цікавиться більше ніж tl; dr
bersling

1
"Транспільований код буде дійсним JS" - і це Ахіллова п'ята TypeScript, якщо ви запитаєте мене. Це означає, що вони не можуть додати кілька дуже корисних функцій до JS; найбільш помітна перевірка типу виконання . Трохи прикро мати безпеку типу компілятора, лише щоб втратити його за будь-які дані виконання, які зачитуються з вводу-виводу, або будь-який час, коли ваш перекладений код буде викликаний небезпечно від інших JS.
Jez

44

" Основи TypeScript " - відеокурс Pluralsight від Дена Уоліна та Джона Папи - справді хороший, на даний момент (25 березня 2016 р.) Оновлений для відображення TypeScript 1.8, вступу до Typescript.

Для мене справді хорошими можливостями, окрім приємних можливостей для intellisense, є класи , інтерфейси , модулі , простота реалізації AMD та можливість використання налагоджувача Visual Studio Typescript при виклику з IE.

Підводячи підсумок : Якщо використовувати за призначенням, Typescript може зробити програмування JavaScript надійнішим та простішим. Це може значно збільшити продуктивність програміста JavaScript в порівнянні з повною SDLC.


9
що таке SDLC? AMD?
Oooogi

15
@Oooogi, SDLC == Життєвий цикл розробки програмного забезпечення. AMD == Визначення асинхронного модуля. Останній характерний для JavaScript, тоді як перший досить загальний за обсягом.
Димитрій Новатчев

2
"Простота впровадження AMD, ..." - я прочитав це і подумав, що це якась оптимізація потокової стрічки чи щось таке.
jrh

15

Ecma script 5 (ES5), який підтримують і попередньо компілюють усі браузери. ES6 / ES2015 та ES / 2016 відбулися цього року з великою кількістю змін, тому для спливання цих змін є щось середнє, про що слід піклуватися про TypeScript.

• TypeScript - це типи -> означає, що ми повинні визначити тип даних кожного властивості та методів. Якщо ви знаєте C #, тоді Typescript зрозуміти легко.

• Великою перевагою TypeScript є те, що проблеми, пов’язані з типом, рано перед початком виробництва. Це дозволяє вийти з ладу тестів, якщо вони не відповідають різним типам.


2
Це не кожен рік, приятель! .. Вони змінили специфікацію після дуже довгого очікування
Subham Tripathi

... і ті зміни, які ви можете співвіднести з корпорацією Майкрософт, отримуючи свої пальці. ;-)
Тробер

2
@SubhamTripathi Це дуже це щороку. ES2015, ES2016, ES2017 і з цього моменту, поки мова не вмирає. Це було не щороку до 2015 року, але це зараз. Перейдіть на пошук "TC39 process", щоб дізнатися більше.
daemonexmachina

1
чи був великий попит на перевірку типу в спільноті javascript? У мене просто не було багато помилок, пов’язаних із перевіркою типу.
Box and Cox
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.