Яка мотивація за TypeScript?

У нас був JavaScript, потім у нас був Flash, потім у нас був Silverlight, а потім HTML5 їм усім.

Отже, яка мотивація за TypeScript? Які проблеми буде вирішено і які покращення ми отримаємо з TypeScript?

http://www.typescriptlang.org/

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

Переваги повинні бути очевидними для кожного, хто розробляється як на мовах на основі класів, так і на основі класів та на JavaScript:

• Перш за все, компілятор. Вміти перевірити наявність явних проблем з коректністю, спричиненими помилками чи необережністю до розгортання, - це те, що більшість розробників сприймає як належне, поки їм не доведеться займатися розробкою веб-сторінок, і тоді це раптом витягується з-під їхніх ніг. Браузери створені для того, щоб зробити перегляд приємним за рахунок належних засобів тестування та налагодження, а стандартне рішення, JSLint, не є заміною справжньому компілятору, оскільки воно пропускає деякі явні проблеми з коректністю та змішує купу скарг на перевірку стилів у зі своїми звітами. Наявність справжнього компілятора - це величезний крок вперед.
• А за аналогічними лініями - система типів . Системи типів покращують ваш код, полегшуючи його читання (ви точно знаєте, що передається у функцію, і що вона може робити, просто переглянувши список параметрів, наприклад,) і забезпечивши певну ступінь коректності при компіляції час. (Якщо ви очікуєте конкретного типу об'єкта, передача цілого числа - це помилка. JavaScript дозволить вам це зробити, а потім він підірветься, коли ви спробуєте запустити його; компілятор з типовою системою зловить його і повідомить про помилку для ти.)

Отже, як бачимо, основна ідея дуже хороша. Сказавши це, я не можу нічого сказати про саму мову, тому що не маю досвіду з нею. Але я використав Smart (пов’язаний вище) і виявив, що це неймовірно потужний і корисний інструмент для веб-розробки.

Наскільки я бачу кілька вагомих причин використовувати TypeScript. Перш за все, як сказав Мейсон Уілер, укладач . А точніше всі перевірки компілятора. JSLint та інші інструменти корисні, але пропускають деякі проблеми, а іноді й явно неправильні. Я, звичайно, вітаю це "нововведення".

Потім з'являється система реального типу , що покращує читабельність та застосовує правильні типи. Адже це збільшує швидкість розвитку.

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

TypeScript намагається розширити JavaScript . Компілятор генерує дуже гарний JavaScript. І на додаток до цього, воно відповідає пропозиціям ECMAScript 6 . (Наприклад, синтаксис функції стрілки , значення за замовчуванням параметрів , модулі тощо).

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

Але зрештою, це все- таки JavaScript . Немає необхідності вивчати нову мову чи синтаксис. Єдине, що він додає, - це система додаткового типу (яка чудова і прострочена).

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

Я обов'язково спробую це!

І останнє, що немає конкуренції між HTML5 та TypeScript. Але це вже інша історія.

У нас був JavaScript, потім у нас був Flash, потім у нас був Silverlight, а потім HTML5 їм усім.

Це просто НЕ правда . Html5 не володіє ними, він вводить нові націнки, що спрощують використання мультимедіа та вивчають переваги браузерів нової ери (наприклад, використання апаратного прискорення під час надання HTML).

Отже, яка мотивація за TypeScript?

Мотивація може бути обумовлена ​​причинами її використання. Всі функції TypeScript, такі як: статична перевірка, навігація на основі символів, завершення оператора та рефакторинг коду - дуже вагомі причини для цього.

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

Це може розглядатися як інструмент управління розробкою javascript, а не цілком новою мовою, що компілюється в JS. Він не хоче бути мовою розробки на сервері, як Dart, і не мати іншого синтаксису, як CoffeeScript. Він не хотів брати популярну мову (а це основна бібліотека) і компілювати її в JS, наприклад, GWT або script #. TypeScript навіть слідує тому ж синтаксису "класу", який пропонується для наступної версії JS.

Я думаю, що більшість веб-розробок робиться сьогодні, використовуючи справжній JavaScript, лише на стороні клієнта. Такі мови або рамки, як Dart, GWT, для цього не підходять. Якщо ви перейдете до coffeescript, з’явиться новий синтаксис. І ви повинні розуміти як coffeescript, так і JS. У той час як TypeScript лише додає кілька додаткових функцій, орієнтованих на тип, об'єднаних у JS, які рятують розробників від специфічних помилок (що є значною частиною помилок JS) та надають інструментам розробки більше інформації про наміри розробників.

Цей підхід не є новим. Перейдіть до розділу "Статичне введення тексту" в

Ця стаття стосується вашого запиту - http://www.eweek.com/developer/microsoft-delivers-typescript-a-better-javascript-for-big-apps/

Я думаю, що це намагання перетворити загальну ненадійну частину лайна (javascript) у власну мову, яку насправді можна використовувати для значних проектів.

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

Ваша думка може відрізнятися, але я вважаю, що вона приречена, якщо це залежить від браузерів, які постачають (різні, непослідовні) реалізації javascript та моделі DOM.